본문 바로가기
리눅스

K8S Flannel CNI 통신

by Justin입니다. 2025. 4. 17.

 

pod가 한개도 없는 상태에서 kubectl run nginx --image=nginx 를 입력하면 worker1 노드에 아래와 같은 NIC 가 생성된다.

 

생성된 pod1 안의 eth0 은 worker1의 veth(virtual ethernet) 페어를 이루고 있다.

pod 를 생성할때마다 veth의 갯수는 일어난다. 

생성된 veth 들은 worker1 의 cni0 가상 브릿지 인터페이스와 연결되어 IP 를 할당받는다.

 

 

worker1의 ip route

 

pod1 -> pod2 의 ping 통신 과정

과정은 아래와 같다.

pod1 -> veth -> cni0 -> flannel.1 -> eth3 -> worker2의 eth3 -> flannel.1 -> cni0 -> veth -> pod2

 

worker1안의 서로 다른 가상 인터페이스 간의 패킷전달을 가능하게 하려면  커널 파라미터를 수정해야한다.

cat <<EOF> /etc/sysctl.d/k8s-mod.conf
net.ipv4.ip_forward=1
EOF

 

1. pod1 -> veth

pod1 의 eth0 와 veth 는 페어임으로 pod1 에서 요청한 ping은 veth으로 이동하고 veth는 cni0 에 attach 되어있음으로 

패킷은 cni0 으로 이동한다.

 

2.  cni0 -> flannel.1 

worker1의 ip route 결과엔 "10.244.2.0/24 via 10.244.2.0 dev flannel.1 onlink" 가 명시되어있다.

cni0으로 도착한 패킷을 flannel.1으로 포워딩 해버린다. 

 

3. flannel.1 -> eth3

패킷을 전달받은 flannel 은 아래와 같이 감싸서 전송함

[Outer Ethernet Frame]
├── Src MAC: worker1의 ens3 MAC
├── Dst MAC: worker2의 ens3 MAC
└── Payload: [Outer IP]
              └── [UDP]
                  └── [VXLAN Header] 
                       └── [Inner Ethernet Frame]
                            └── [Inner IP(pod a IP -> pod b IP)]
                                 └── [ICMP 요청]

 

이건 VXLAN 캡슐화 방식 이라고 불린다. Flannel 은 전달받은 이너뎃 프레임을 UDP로 캡슐화한다.

 

Outer Ethernet Frame & Outer IP

flannel 은 모든 노드 의 Pod CIDR 매핑 정보를 알고있고 arp 요청을 통해 목적지 노드의 MAC 주소획득 가능

 

UDP

Flannel 은 기본적으로 8472 포트 사용

 

VXLAN Header

Overlay 네트워크 구분을 위한값이 포함되어있다. 

예를들어 10.244.1.0/24 네트워크에 속한 패킷은 VNI=1 로 설정될 수도 있다.

 

Inner Ethernet Frame

이건 어떤 MAC 주소가 들어갈지 잘 모르겠다. 그냥 포장지 느낌으로 쓰일지도..

 

 

Flannel 이 UDP 를 사용하는 이유는 경량성 때문!

TCP 처럼 핸드쉐이크 필요가 없고 Overlay 네트워크 트래픽에 더 빠르게 반응할수있다.

 

 

 

'리눅스' 카테고리의 다른 글

DNS Zone 파일  (0) 2025.04.15
DNS 이중화  (0) 2025.04.15
ls 명령어를 하면 무슨일이 일어날까  (0) 2025.04.02
systemctl enable  (0) 2025.04.02
Redis Master/Slave + HAProxy  (0) 2025.03.18