🌐

[CKA] 61. Cluster/Pod Networking

Date

2026/02/01

Cluster Networking

쿠버네티스 클러스터가 뜨지 않는 이유는 네트워크 기본 조건이 안 맞아서인 경우가 많다. 특히 초반에 많이 발견되는 것은 두 가지다.

•

노드 식별 충돌: hostname / MAC이 겹침 (VM clone 했을 때 흔함)

•

포트/방화벽 막힘: controlplane  worker 통신 오류

Node의 기본 조건

각 노드는 최소한 아래는 만족해야 한다.

•

네트워크에 연결된 인터페이스가 1개 이상 있어야 함

•

각 인터페이스에 IP 주소가 설정되어 있어야 함

•

호스트는 고유 hostname을 가져야 함

•

호스트는 고유 MAC 주소를 가져야 함

Port

쿠버네티스는 구성요소들이 서로 API 호출로 붙는 구조라서 포트가 막히면 장애가 발생한다.

Controlplane

포트	용도	누가 쓰나
6443/TCP	Kubernetes API Server	전체(워커, kubectl, 컨트롤 플레인 컴포넌트)
2379~/TCP	etcd client API	kube-apiserver, etcd
10250/TCP	Kubelet API	self, control plane
10259/TCP	kube-scheduler	self
10257/TCP	kube-controller-manager	self

Worker Node

포트	용도	누가 쓰나
10250/TCP	Kubelet API	self, control plane
10256/TCP	kube-proxy	self, Load balancers
30000-32767/TCP+UDP	NodePort 서비스 기본 범위	전체

참고: 기본 포트는 변경될 수 있다.

Pod Networking

노드 간 네트워크가 물론 맞춰져야 하지만 애플리케이션을 올리려면 Pod 레벨의 네트워크가 추가로 필요하다.

클러스터에서 실제로 동작하는 것은 결국 Pod이고, Pod끼리 통신이 되지 않으면 서비스는 정상 동작을 하지 못한다.

Pod Networking 조건

쿠버네티스는 “어떻게 구현하라”는 것을 주진 않지만 “반드시 만족해야 하는 요구사항”은 명확하게 말한다.

모든 Pod는 고유한 IP를 가진다.

같은 노드 안에서, Pod는 그 IP로 다른 Pod에 바로 붙을 수 있어야 한다.

다른 노드에 있는 Pod에게도, 같은 IP로 바로 붙을 수 있어야 한다.

NAT 규칙 없이도(= 주소 변환 없이도) Pod IP로 end-to-end 통신이 되어야 한다.

IP 대역이 뭐든 상관없다. 중요한 건 Pod IP로 노드 경계를 넘어 직접 통신이 가능해야 한다.

구현

노드들이 외부 네트워크(예: 192.168.1.0/24)에 붙어있다고 가정한다:

•

node1: 192.168.1.11

•

node2: 192.168.1.12

•

node3: 192.168.1.13

1) 각 노드에 Pod 전용 네트워크 만들기

Pod는 컨테이너 네트워크 네임스페이스에서 돌아간다. 때문에 노드 안에 Pod들을 붙일 내부 네트워크가 필요하다.

•

노드마다 bridge 생성

◦

노드 내부에 bridge 네트워크를 하나 만든다.

◦

Pod 네임스페이스는 이 bridge에 붙는다

•

노드별 Pod subnet을 따로 준다

◦

node1 Pod subnet: 10.244.1.0/24

◦

node2 Pod subnet: 10.244.2.0/24

◦

node3 Pod subnet: 10.244.3.0/24

•

각 노드의 bridge에 IP를 부여한다

◦

node1 bridge: 10.244.1.1

◦

node2 bridge: 10.244.2.1

◦

node3 bridge: 10.244.3.1

여기까지 완료하면 “한 노드 안에서 Pod끼리 통신”은 가능하다

2) 네트워크 작업

Pod 하나를 네트워크에 붙이려면 매번 아래 과정이 필요하다:

# Create veth pair
ip link add ...

# Attach veth pair
ip link set ...
ip link set ...

# Assign IP Address
ip -n <namespace> addr add ...
ip -n <namespace> route add ...

# Bring Up Interface
ip -n <namespace> link set ...
Shell
복사

즉 Pod가 하나 생성될 때마다 네트워크 작업이 반복된다.

3) 라우팅

이제 다른 노드의 Pod와 통신이 가능할까? node1의 Pod가 node2의 Pod로 ping을 날리면 현재 상태에서는 실패한다.

node1입장에서는 10.244.2.0/24가 자기 네트워크가 아니다. 그래서 어디로 보내야 하는지 모른다.

해결은 노드 라우팅 테이블에 다른 노드 Pod Subnet 경로를 추가하는 것이다.

node1$ ip route add 10.244.2.2 via 192.168.1.12
node1$ ip route add 10.244.3.2 via 192.168.1.13
node2$ ip route add 10.244.1.2 via 192.168.1.11
node2$ ip route add 10.244.3.2 via 192.168.1.13
node3$ ip route add 10.244.1.2 via 192.168.1.11
node3$ ip route add 10.244.2.2 via 192.168.1.12
Shell
복사

Pod IP 대역(10.244.x.x) 들을 노드 간 네트워크(192.168.1.x) 위에서 라우팅해주는 구조이다. 위와 같이 모든 노드에 대해 경로를 추가하면 Pod IP가 노드 경계를 넘어 end-to-end 통신을 한다.

결국 CNI

bridge 생성 → veth 붙이기 → IP 할당 → route 추가

이 과정을 스크립트로 만들어 수동 실행하는 것은 대규모 환경에서 불가능하다. 따라서 쿠버네티스는

“파드가 생성되자마자 네트워킹 구성도 자동으로 수행되어야 한다”

라고 말한다. 그 자동화의 접점이 CNI다

CNI가 하는 역할은:

•

쿠버네티스(Runtime)에게

◦

“컨테이너 만들면 ADD로 플러그인 호출해”

◦

“컨테이너 지우면 DEL로 플러그인 호출해”

•

플러그인(스크립트)에게

◦

“이런 인터페이스(add/del/check)를 맞춰야 해”

◦

“컨테이너ID/네임스페이스 같은 파라미터 받아야 해”

즉, 중개자(표준 인터페이스)로써 런타임과 네트워크 구현체를 연결해준다.

이전 게시물

[CKA] 60. The Why and What of CNI

다음 게시물

[CKA] 62. CNI in Kubernetes