동작 과정 요약

규칙 세팅(Service/Pod 변경 시)

1. Service가 생성되면 API Server에 등록

2. kube-proxy가 이를 watch하다가 변경이 감지

3. iptables 명령 실행
   → nat table의 KUBE-SERVICES에 매칭 rule 추가
   → KUBE-SVC-XXX chain 생성 (LB)
   → KUBE-SEP-XXX chain 생성 (실제 DNAT rule)

3-2. iptables 명령을 실행하여 netfilter 커널 메모리에 규칙을 바로 저장
	- 이때 들어가는 규칙의 구조는 hook, table, chain, rule로 이루어져 있음
		- hook은 패킷 처리의 어느 지점에서 개입할지를 정하는 위치
		- table은 용도별 분류(nat, filter 등)
		- chain은 실제 처리 규칙인 rule이 들어 있음

[ 번외 ]
- kube-proxy는 주로 nat table에 커스텀 chain(KUBE-SERVICES, KUBE-SVC-, KUBE-SEP-)을 추가

- nat table은 PREROUTING, INPUT, OUTPUT, POSTROUTING 4개 hook에 등록되어 동작

패킷 처리(런타임)

1. 패킷이 들어오면 netfilter가 커널 메모리에 저장된 규칙을 순차 평가
    - 이로 인해서 O(n) 시간 복잡도를 가지며, 전체 rule 수가 많으면 대규모 클러스터에서는
	    성능 병목
	     - 이를 해결하기 위해 해시 테이블 기반 O(1)인 IP 사용

2. nat table의 KUBE-SERVICES chain에서 목적지 Service IP에 매칭되는 KUBE-SVC chain으로
	 점프하고, 확률 기반으로 KUBE-SEP chain을 선택해서 DNAT을 수행
    - 이 시점에서는 kube-proxy 개입 X

3. DNAT 이후에는 커널의 routing subsystem이 변환된 Pod IP를 보고 같은 노드인지
	 다른 노드인지 경로를 결정하고, 다른 노드라면 POSTROUTING hook에서 SNAT을 처리한 뒤
	 eth0으로 내보냄

아래 사진 Ver

Pod A → Service IP(10.96.0.10)로 요청

① NF_IP_PRE_ROUTING hook (인터페이스 진입 시)
   nat table의 PREROUTING chain 실행
   → KUBE-SERVICES로 점프
     → 매칭되는 KUBE-SVC-XXX로 점프 (확률 기반 LB)
       → KUBE-SEP-XXX로 점프
         → DNAT: Service IP → Pod IP로 변환
   → conntrack에 변환 기록 저장

② routing subsystem (라우팅 결정)
   커널 라우팅 테이블 조회 (CNI가 세팅해둔 것)
   ├─ 10.244.1.0/24 dev cni0        → 같은 노드면 cni0로
   ├─ 10.244.2.0/24 via 192.168.1.20 → 다른 노드면 Node B로
   └─ 192.168.1.0/24 dev eth0

③-A 같은 노드인 경우
   → cni0 브릿지 → FDB → veth → Pod B 도착

③-B 다른 노드인 경우
   │
   ├─ NF_IP_FORWARD hook (다른 host로 포워딩)
   │  filter table의 FORWARD chain 실행
   │  → KUBE-FORWARD: DNAT된 패킷 ACCEPT
   │
   ├─ NF_IP_POST_ROUTING hook (인터페이스로 나갈 시)
   │  nat table의 POSTROUTING chain 실행
   │  → KUBE-POSTROUTING: SNAT/MASQUERADE
   │
   └─ eth0 → 물리 네트워크 → Node B
        │
        Node B에서
        ├─ NF_IP_PRE_ROUTING → 라우팅 결정
        └─ cni0 → FDB → veth → Pod B 도착

④ 응답 돌아올 때
   conntrack이 저장된 기록 보고 자동 역변환
   Pod A 입장에서는 Service IP에서 응답이 온 것처럼 보임

추가. 확률적 LB

[ 설명 ]
- iptables mode는 확률 기반 LB로 동작

[ 동작 예시 ]
KUBE-SVC-XXX chain
├─ rule 1: --probability 0.333 → KUBE-SEP-111 (Pod 1로 DNAT)
├─ rule 2: --probability 0.500 → KUBE-SEP-222 (Pod 2로 DNAT)
└─ rule 3: (나머지 전부)       → KUBE-SEP-333 (Pod 3로 DNAT)

그림