반응형
원래는 책과 Kubernetes Web Docs, CNI 문서를 읽고 이해한 것을 정리하려고 했는데,
이미 이렇게 정리한 블로그와 YouTube 영상을 발견해서, 
원래 계획을 접고, 관련 블로그 정보를 리스팅하는 페이지를 만들었다.

 

 

Kubernetes Service Network (YouTube 자료)

이 보다 쉽게 설명할 수 있을까 싶을 정도로 쉽게 설명하는 영상을 찾았다.

 

kubernetes service network

 

 

위 동영상을 본 이후에 아래 Web Docs를 보면, 확실히 Kubernetes의 IP Traffic을 처리하는 방식을 이해하기 좋다.

 

 

Kubernetes Network, Kube-Proxy 전반적인 내용 (Blog 자료)

이 문서는 꼭 보는 것을 권장한다.

 

Kubernetes kube-proxy Mode 분석

 

54. Kubernetes kube-proxy Mode 분석

Kubernetes kube-proxy Mode 분석 [kubernetes kube-proxy 관련 글 목록] 54. Kubernetes kube-proxy Mode 분석 70. Kubernetes kube-proxy IPVS Mode 설정 74. Kubernetes NodePort Networking 분석 (ku..

ikcoo.tistory.com

 

Kubernetes kube-proxy IPVS Mode 설정

 

70. Kubernetes kube-proxy IPVS Mode 설정

Kubernetes kube-proxy IPVS Mode 설정 [kubernetes kube-proxy 관련 글 목록] 54. Kubernetes kube-proxy Mode 분석 70. Kubernetes kube-proxy IPVS Mode 설정 74. Kubernetes NodePort Networking 분..

ikcoo.tistory.com

 

Kubernetes Node Port Networking 분석 (kube-proxy: iptable mode)

 

74. Kubernetes NodePort Networking 분석 (kube-proxy : iptable mode)

kubernetes NodePort Networking 분석 kube-proxy = iptable mode CNI = Flannel [kubernetes kube-proxy 관련 글 목록] 54. Kubernetes kube-proxy Mode 분석 70. Kubernetes kube-proxy IPVS Mode 설정..

ikcoo.tistory.com

 

 

Kubernetes LoadBalancer Networking 분석 (kube-proxy: iptable mode)

 

75. kubernetes LoadBalancer Networking 분석 (kube-proxy : iptable mode)

kubernetes LoadBalancer Networking 분석 kube-proxy = iptable mode CNI = Flannel [kubernetes kube-proxy 관련 글 목록] 54. Kubernetes kube-proxy Mode 분석 70. Kubernetes kube-proxy IPVS Mode ..

ikcoo.tistory.com

 

 

Kubernetes Node Port Networking 분석 (kube-proxy: IPVS mode)

 

76. kubernetes NodePort Networking 분석 (kube-proxy : IPVS mode)

kubernetes NodePort Networking 분석 kube-proxy : IPVS mode CNI = Flannel [kubernetes kube-proxy 관련 글 목록] 54. Kubernetes kube-proxy Mode 분석 70. Kubernetes kube-proxy IPVS Mode 설정 74..

ikcoo.tistory.com

 

 

 

 

IPTABLES :: The Kubernetes Networking Guide

IPTABLES Most of the focus of this section will be on the standard node-local proxy implementation called kube-proxy. It is used by default by most of the Kubernetes orchestrators and is installed as a daemonset on top of an newly bootstrapped cluster: $ k

k8s.networkop.co.uk

 

 

 

 

 

반응형

 

참고할 문서

CISCO SDN  (www.oss.kr에서 download한 pdf 문서)

https://www.oss.kr/editor/file/3bd27047/download/99fb53a9-31c4-46f9-91ad-79eeaa927f16

위 문서에서 중요한 부분만 발췌한 내용 (아래)

Application Centric Infra (CISCO)

 

 

ACI VMM 아키텍처 - Openstack Neutron ML2

 

 


 

 

ACI & Kubernetes – The Cisco K8s CNI

CISCO ACI와 Kubernetes 조합으로 Network를 구성하고 싶다면, 아래  Documents를 참고할 것.

 

ACI & Kubernetes - The Cisco K8s CNI (Part One) - Haystack Networks

A look and review of the integration between Cisco ACI, Kubernetes and the Cisco K8 CNI.

haystacknetworks.com

 

 

 

Enable Consistent Application Services for Containers

Seamless developer experience intended to maintain the simplicity of Kubernetes while still enabling advanced capabilities within the Cisco ACI fabric, and maintaining application availability, security, and visibility across the infrastructure.

blogs.cisco.com

 

YouTube 영상: Kubernetes integration with CISCO ACI

 

 

 

 

ACI Networking Plugin for Kubernetes

https://pubhub.devnetcloud.com/media/netdevops-live/site/files/s01t07.pdf

 

 

 

ACI CNI Plugin (GitHub Source Code)

 

 

GitHub - noironetworks/aci-containers: Plugins for integrating ACI with container orchestration systems

Plugins for integrating ACI with container orchestration systems - GitHub - noironetworks/aci-containers: Plugins for integrating ACI with container orchestration systems

github.com

 

 

 

 

EPG, Contract, AP(Application Profile), BD(Broadcast Domain) 등 개념이 머릿속에 잘 그려지지 않아서 

이런 개념을 Use Case로 그린 Diagram만 우선 보고자 한다.

 

Cisco ACI Multi-Site Architecture White Paper (2021-11-23)

 

Cisco Application Centric Infrastructure - Cisco ACI Multi-Site Architecture White Paper

Cisco Application Centric Infrastructure (Cisco ACI) as a pervasive fabric technology, enterprises and service providers commonly need to interconnect separate Cisco ACI fabrics.

www.cisco.com

 

 

Cisco Application Centric Infrastructure - White Papers

Cisco Application Centric Infrastructure - white papers

www.cisco.com

 

 

EPGs and Preferred Groups

 

 

Referencing objects across templates and across schemas

 

Specific strat egy to define templates inside a schema

 

Layer 3 intra-V RF Layer 3 communication across sites

 

 

Intra-VRF Layer 3 communication across sites stretching an EPG

 

Layer 3 inter-VRF communication across sites

 

Inter-VRF communication across sites (shared services)

 

Interconnecting Cisco ACI fabrics for Layer 3 communication via L3Outs

 

Initial state: layer 3 intersite communication using the L3Out path

 

Issue when mixing VXLAN and L3Out traffic paths

 

 

Use cases for integrating Cisco ACI Multi-Pod and Cisco ACI Multi-Site

 

Single network infrastructure offering both IPN and ISN connectivity

 

Hierarchical MP -BGP EVPN peering

 

Multi-Site and traditional L3Out connections on border leaf nodes

 

Use of a stretched external EPG (Ext-EPG)

 

 

Multi-Site and traditional L3Out connections with a stretched bridge domain

 

Cisco ACI EPG-based network model

 

 

An example of stretched application between on-premises Cisco ACI and cloud sites

 

 

An example of stretched EPGs across sites

 

An example of intersite shared services

 

 

An example of Cloud L3Out

 

An example of On-Premises L3Out for cloud endpoints

 

 

On-premises service chaining for a stretched application tier

 

 

 

 

Cisco ACI policy model (Tenant, VRF, BD, EPG, EndPoint, Taboo, Contracts, Pod, Path, Node)

 

 

 

 

반응형

Kubernetes, OCP(Openshift Container Platform)을 사용하다 보면, Resource에 대한 접근 권한 때문에 답답한 경우가 많다.

SCC(SecurityContext)를 잘 관리할 줄 알면, 제일 좋지만 급하게.. 그리고 간단하게 테스트만 하는 상황이라면,

아래와 같이 시스템의 모든 자원에 접근할 수 있도록 권한을 최고 수준(privileged)으로 올려주고 테스트하는 것이 정신 건강에 좋다.

(상용 서비스에서는 절대 이렇게 하면 안 된다.  Test bed 같은 곳에서 잠깐 Feasibility check만 하고 Pod를 종료시킨다는 가정하에 사용할 것)

 

apiVersion: v1
kind: Pod
metadata:
  name: my-example-pod
spec:
  hostNetwork: true    ## <-- 이 설정이 있으면, Pod 내부에서 Host Network이 보인다
                       ##     예를 들어, Host OS의 eno3 network port를 보기 위해
                       ##     ifconfit eno3  명령 실행이 가능해진다.
  containers:
    ...
    securityContext:
      privileged: true   ## <-- 이렇게 하면 모든 자원에 접근 가능해진다.
    ...
  securityContext: {}
  ...

 

 

만약, 극단적으로 Pod 내부에 있는 Process가 Host OS의 자원에 제약 없이 접근하고 싶다면 아래 예제 YAML처럼 권한 설정을 하면 된다.  이렇게 하면, Pod 내부에서 Pod 밖(즉 Host OS)의 IP network 자원, TCP Stack, IPC, ProcessID(PID) 등에 자유롭게 접근할 수 있다.

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: privileged
  annotations:
    seccomp.security.alpha.kubernetes.io/allowedProfileNames: '*'
spec:
  privileged: true
  allowPrivilegeEscalation: true
  allowedCapabilities:
  - '*'
  volumes:
  - '*'
  hostNetwork: true
  hostPorts:
  - min: 0
    max: 65535
  hostIPC: true
  hostPID: true
  runAsUser:
    rule: 'RunAsAny'
  seLinux:
    rule: 'RunAsAny'
  supplementalGroups:
    rule: 'RunAsAny'
  fsGroup:
    rule: 'RunAsAny'

 

위 YAML에 대해 자세히 알고 싶다면, 아래 kubernetes.io 문서를 참고하세요.

 

 

Pod Security Policies

FEATURE STATE: Kubernetes v1.21 [deprecated] Caution: PodSecurityPolicy is deprecated as of Kubernetes v1.21, and will be removed in v1.25. We recommend migrating to Pod Security Admission, or a 3rd party admission plugin. For a migration guide, see Migrat

kubernetes.io

 

 

 

 

다시 한번 강조하지만, 위와 같이 securityContext.privileged: true 설정된 Pod를 상용 서비스를 제공하는 클러스터에서 구동한 상태로 오래 방치하면 결국 해커의 먹이감이 된다.  꼭 10분~20분 정도 테스트만 하고 바로 Pod를 종료(삭제)해야 한다.

 

 

 


 

 

 


아래 내용은 참고용으로만 볼 것!!!

 

DaemonSet으로 구동하는 Pod들은 securityContext 값이 privileged 으로 설정된 경우가 많다.

왜냐하면 이런 DaemonSet으로 구동된 Pod들은 각 노드에서 Host 자원에 접근해야 하는 경우가 있기 때문이다.

아래 예시를 보면 바로 이해가 될것이다.

 

Multus 배포 예시

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: multus
  namespace: openshift-multus
  ... 중간 생략 ...
  
  spec:
    template:
    ... 중간 생략 ...
    
    spec:
      containers:
      ... 중간 생략 ...
      
        securityContext:
          privileged: true      ## <-- 이 부분
... 중간 생략 ...

 

 

Openshift SDN 배포 예시

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: sdn
  ... 중간 생략 ...
spec:
  template:
  ... 중간 생략 ...
  
    spec:
      containers:
      ... 중간 생략 ...
      
        securityContext:
          privileged: true   ## <-- 이 부분
      ... 중간 생략 ...

 

 

게시물 작성자: sejong.jeonjo@gmail.com

 

반응형

 

Kubernetes SRIOV Network Device Plugin에 관해 Code Level 스터디를 하고 싶다면,

아래 2개의 문서를 읽어보라~~~

(지금 하고 있던 업무 끝내고, 빨리 읽고 정리해야겠다 ㅠㅠ)

 

 

 

GitHub - k8snetworkplumbingwg/sriov-network-device-plugin: SRIOV network device plugin for Kubernetes

SRIOV network device plugin for Kubernetes. Contribute to k8snetworkplumbingwg/sriov-network-device-plugin development by creating an account on GitHub.

github.com

 

 

 

GitHub - k8snetworkplumbingwg/sriov-cni: DPDK & SR-IOV CNI plugin

DPDK & SR-IOV CNI plugin. Contribute to k8snetworkplumbingwg/sriov-cni development by creating an account on GitHub.

github.com

 

반응형

Kubernetes 기술 문서에 대한 한글화가 참 빠르다.

2018년에 처음 Kubernetes 접할 때와 비교해보면, 4년 사이에 빠르게 한글 문서가 잘 구축되었다.

 

원문(영어 문서)로 읽으면 더 좋겠지만, 시간이 없고 급할 때는 다른 사람이 만들어준 한글 문서가 나의 시간을 많이 아껴준다 :)

 

 

쿠버네티스 문서

쿠버네티스는 컨테이너화된 애플리케이션의 배포, 확장 및 관리를 자동화하기 위한 오픈소스 컨테이너 오케스트레이션 엔진이다. 오픈소스 프로젝트는 Cloud Native Computing Foundation에서 주관한다.

kubernetes.io

 

반응형

 

아래의 Go App을 Build해서 Kubernetes Worker Node에서 돌려보면,

각 Container가 사용하는 CPU Set(즉, Container App이 Pinning한 Core 정보), Memory Hugepages, Network 주소 및 PCI 정보를 알 수 있다.

 

 

https://github.com/openshift/app-netutil/tree/master/samples/go_app

 

GitHub - openshift/app-netutil: app-netutil is a library that provides API methods for applications to get pod network informati

app-netutil is a library that provides API methods for applications to get pod network information. - GitHub - openshift/app-netutil: app-netutil is a library that provides API methods for applicat...

github.com

 

그리고, 위 Repository에 DPDK example app container도 있으니까, DPDK 테스트할 때도 이용하면 좋다.

 

 

 

 

반응형

이것저것 문서를 다 찾아보았지만 아래 Red Hat 설명이 제일 깔끔하고, 정확하다.

(Red Hat 검증팀이 직접 테스트해보면서, 그 절차를 문서화한 것이니까 당연히 정확할 듯)

 

 

16.9. DPDK 및 RDMA 사용 OpenShift Container Platform 4.10 | Red Hat Customer Portal

Access Red Hat’s knowledge, guidance, and support through your subscription.

access.redhat.com

 

 

Kubernetes Cluster에서 DKDP 테스트할 때, 필요한 예제 App과 Library !!!

 

 

GitHub - openshift/app-netutil: app-netutil is a library that provides API methods for applications to get pod network informati

app-netutil is a library that provides API methods for applications to get pod network information. - GitHub - openshift/app-netutil: app-netutil is a library that provides API methods for applicat...

github.com

 

 

GitHub - openshift/app-netutil: app-netutil is a library that provides API methods for applications to get pod network informati

app-netutil is a library that provides API methods for applications to get pod network information. - GitHub - openshift/app-netutil: app-netutil is a library that provides API methods for applicat...

github.com

 

 


 

아래 문서들은 호기심 해소를 위해 보면 좋은 자료들.

아직 내용을 다 읽어보진 않았지만, 설명 그림(illustration)이 괜찮게 보여서 인용해본다.

 

 

 

GitHub - intel/userspace-cni-network-plugin

Contribute to intel/userspace-cni-network-plugin development by creating an account on GitHub.

github.com

 

위 문서에 있는 이미지들...

 

 

 

 

 

MISC

Red Hat이 공식 Container Image Registry를 통해서 아래와 같이 제공하는 container image도 있기는 한데, 라이센스 문제나 비용 문제 때문에 쓸수 없으니까, 그냥 내용 참고만 하고 나중에 돈이 충분하게 생기면 한번 image pulling해서 써봐야겠다.

 

https://catalog.redhat.com/software/containers/openshift4/dpdk-base-rhel8/5e32be6cdd19c77896004a41?container-tabs=dockerfile&gti-tabs=registry-tokens 

 

Red Hat Ecosystem Catalog

Your role Select your roleArchitectDeveloperDevOps EngineerProduct ManagerSystems AdministratorOther

catalog.redhat.com

 

반응형

Kubernetes의 Pod Scheduling에 관한 공부를 하다보면,

  • Node Label을 이용한 NodeSelector, Node Affinity
  • Node Taint, Tolerlation

가 꼭 등장한다.

위 2가지를 따로 따로 공부하면, 그렇구나 라고 이해가 되다가 

이 2가지를 같이 놓고 생각해보면, 비슷한 기능을 하는 것 같은데 왜 이렇게 2가지 모두 있는거지 라는 질문이 자연스레 떠오른다.

 

아래 블로그가 이런 질문에 대한 답을 잘 하고 있다.

 

https://fisache.tistory.com/19

 

CKA 준비 (7) - Scheduling 2 (Node Selector, Node Affinity)

본 포스팅은 Udemy Certificated Kubernetes Administrator 강좌를 공부한 내용입니다. Certified Kubernetes Administrator (CKA) Practice Exam Tests Prepare for the Certified Kubernetes Administrators C..

fisache.tistory.com

 

 

Node Taint 및 Toleration에 대해 기초부터 알고 싶다면, 아래의 Kubernetes Web Docs를 보면 좋다.

 

https://kubernetes.io/ko/docs/concepts/scheduling-eviction/taint-and-toleration/

 

테인트(Taints)와 톨러레이션(Tolerations)

노드 어피니티는 노드 셋을 (기본 설정 또는 어려운 요구 사항으로) 끌어들이는 파드의 속성이다. 테인트 는 그 반대로, 노드가 파드 셋을 제외할 수 있다. 톨러레이션 은 파드에 적용되며, 파드

kubernetes.io

 

# TODO

위 Web Docs에 TolerationSeconds에 관한 설명이 나오는데, 

내 생각에는 Node 장애가 발생했을 때, 빠르게 Pod가 장애가 발생한 Node에서 종료 처리되고 다른 Node로 스케쥴링되게 하려면, 300초로 설정된 값을 1초로 줄이면 되지 않을까하는 상상을 해본다. 

시간 여유가 있을 때, 한번 1초로 변경하고 Node를 다운시켜서 테스트해봐야겠다.

 

참고:
쿠버네티스는 사용자나 컨트롤러에서 명시적으로 설정하지 않았다면, 자동으로 node.kubernetes.io/not-ready 와 node.kubernetes.io/unreachable 에 대해 tolerationSeconds=300 으로 톨러레이션을 추가한다.
자동으로 추가된 이 톨러레이션은 이러한 문제 중 하나가 감지된 후 5분 동안 파드가 노드에 바인딩된 상태를 유지함을 의미한다.

 

+ Recent posts