pod가 한개도 없는 상태에서 kubectl run nginx --image=nginx 를 입력하면 worker1 노드에 아래와 같은 NIC 가 생성된다.
생성된 pod1 안의 eth0 은 worker1의 veth(virtual ethernet) 페어를 이루고 있다.
pod 를 생성할때마다 veth의 갯수는 일어난다.
생성된 veth 들은 worker1 의 cni0 가상 브릿지 인터페이스와 연결되어 IP 를 할당받는다.
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 |