sejong.jeonjo@gmail.com

Kuberentes를 사용하면서 이해하기 어려운 부분이 CNI(Cluter Network Interface)이다.

실제로 각 CNI 마다 동작하는 방식과 구현이 다른데 CNI라고 퉁쳐서 표현하다보니 Kubernetes를 사용하는 운영자 입장에서는 CNI가 어떻게 IP Traffic(트래픽)을 처리하는지 알기 어렵다.

여러 종류의 CNI 중에서 내가 사용하고 있는 특정 CNI에 대해서 깊이 있게 설명하는 자료도 별로 없으니 스터디하기가 더욱 어렵다.

나의 일터에서는 주로 Openshift SDN을 사용하기 때문에 오늘은 시간을 내서 Openshift SDN을 깊게 파헤쳐보려 한다.

우선 아래 그림에 있는 빨간색 숫자를 따라 가면서 보자.

이 빨간 색 숫자의 순서대로 요청 패킷이 처리된다.

그림에 순서에 맞게 설명을 적었기 때문에 전반적인 설명은 필요 없을 것 같다.

단, 복잡한 처리가 있는 부분을 좀더 살펴 본다면,

(2) Netfilter를 이용하여 DNAT, SNAT 처리

Kubernetes Pod 정보를 조회해보면 Cluster IP를 볼 수 있다. 바로 그 Pod의 Cluster IP로 DNAT 처리되는 것이다.

즉, 10.10.12.208:8080 목적지 주소를 보고, 이 주소 값과 Mapping되는 Kubernetes Pod IP를 찾고 Netfilter를 이용하여 DNAT 처리한다.

Worker 1 Node에서 iptables 명령을 이용하여 Netfilter의 Chain Rule을 조회하면 실제로 아래와 같이 정보를 볼 수 있다.

이 Chain Rule대로 관련 Packet 조건을 찾고, 그 조건에 맞는 Netfilter Chain을 따라가면서 DNAT처리하는 것이다.

$  iptables -t nat -L KUBE-SERVICES -nv | grep 10.10.12.208
 1760  106K KUBE-FW-BAR7JSQD2GL6A2KT  tcp  --  *      *       0.0.0.0/0            10.10.12.208         /* almighty/almighty5:web loadbalancer IP */ tcp dpt:8080

… 중간 생략 …

$ iptables -t nat -L KUBE-SEP-ZBWV76PMI2XAVMCD -nv
 1949  117K DNAT       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            /* almighty/almighty5:web */ tcp to:10.128.2.151:8080

—> kube-proxy가 실제 iptables 룰 생성시 사용한 명령은 아래와 같음.
KUBE-SEP-ZBWV76PMI2XAVMCD -p tcp -m comment --comment "almighty/almighty5:web" -m tcp -j DNAT --to-destination 10.128.2.151:8080

만약 Destination Pod가 다른 Worker Node에 있다면, 다른 Worker Node로 IP Packet을 보내기 위해 tun0 인터페이스를 이용하여야 한다. 이때 tun0의 IP Address로 SNAT 하도록 하는 Chain Rule 적용을 받는다.

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
OPENSHIFT-MASQUERADE  all  --  anywhere             anywhere             /* rules for masquerading OpenShift traffic */
KUBE-POSTROUTING  all  --  anywhere             anywhere             /* kubernetes postrouting rules */

Chain KUBE-POSTROUTING (1 references)
target     prot opt source               destination
RETURN     all  --  anywhere             anywhere             mark match ! 0x1/0x1
MARK       all  --  anywhere             anywhere             MARK xor 0x1
MASQUERADE  all  --  anywhere             anywhere             /* kubernetes service traffic requiring SNAT */ random-fully

(3) DST IP로 갈 수 있는 Routing Table을 조회하여 tun0로 Packet을 보냄

아마 대부분 Kubernetes 사용자가 헷갈려하는 부분일 것이다.

만약 Destination Pod가 같은 Worker Node에 있다면, 단순히 Netfilter가 처리한 대로 Packet Forward만 하면 된다.

그런데, Destination Pod가 다른 Worker Node에 있다면 관련있는 물리 Network Port를 찾아서 보내야 한다.

위 그림에서 Worker 1과 Worker 2의 tun0 간에는 ARP Packet이 브로드캐스팅되므로, 이미 Worker 1에서는 Destination Pod IP에 해당하는 MAC Address를 알고 있다. 

(참고: arp 명령으로 Worker 1 노드의 ARP Table 조회 가능)

따라서 일반적인 L2 Forward 처리와 동일하게 처리된다.

(4) ~ (5) Encapsulate, Decapsulate

일반적인 VxLAN 터널링을 사용하여 Worker Node간에 Pod의 메시지를 전송해준다.

VxLAN 터널링 때문에 tun0의 MTU는 1450 byte가 된다. (왜냐하면, 터널링 헤더 메시지 때문에 50 Byte만큼 tun0 포트의 MTU가 작아지게 된다)

나머지 절차는 모두 L2 Switching이기 때문에 딱히 설명할 것이 없다.

응답 메시지는 따로 설명하지 않았다.

왜냐하면,

L2 Switching 구간은 단순히 Source Address와 Destination Address를 반대로 뒤집으면 되고,

Netfilter가 SNAT 처리한 부분의 Connection Track 정보를 찾아서 원래의 주소값으로 치환해주면 되기 때문이다.

블로그 작성자: sejong.jeonjo@gmail.com

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

Kubernetes Service Network (YouTube 자료)

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

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

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

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

Kubernetes kube-proxy Mode 분석

Kubernetes kube-proxy IPVS Mode 설정

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

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

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

참고할 문서

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

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

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

ACI & Kubernetes – The Cisco K8s CNI

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

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)

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

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

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

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 문서를 참고하세요.

다시 한번 강조하지만, 위와 같이 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개의 문서를 읽어보라~~~

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

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

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

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

아래의 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

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

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

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

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

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

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

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

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