Kubernetes 네트워크 구조와 CNI, Pod 간 통신 원리
Kubernetes 네트워크 구조와 CNI, Pod 간 통신 원리
1. Kubernetes 네트워크를 이해해야 하는 이유
Docker Compose에서는 컨테이너들이 동일한 Docker 네트워크에 연결되면 서비스 이름을 통해 통신할 수 있었습니다.
하지만 Kubernetes는 여러 서버에 걸쳐 수많은 Pod가 실행될 수 있습니다.
예를 들어 다음과 같은 환경을 생각해 보겠습니다.
사용자
|
v
Load Balancer
|
v
Kubernetes Cluster
|
+-----------+-----------+
| |
v v
Worker Node 1 Worker Node 2
| |
+-------+ +-------+
| Pod A | | Pod C |
| API | | API |
+-------+ +-------+
| |
+-------+ +-------+
| Pod B | | Pod D |
| Redis | | DB |
+-------+ +-------+
이 환경에서 다음과 같은 문제가 발생합니다.
- 서로 다른 Worker Node에 있는 Pod는 어떻게 통신할까?
- Pod에 IP 주소는 어떻게 할당될까?
- Pod가 재시작되면 IP 주소는 어떻게 될까?
- 물리 서버의 네트워크와 Pod 네트워크는 어떻게 연결될까?
- Kubernetes는 네트워크를 어떤 방식으로 관리할까?
이러한 내용을 이해하려면 Kubernetes의 네트워크 기본 구조와 CNI를 알아야 합니다.
2. Kubernetes 네트워크의 기본 원칙
Kubernetes 네트워크에는 중요한 기본 원칙이 있습니다.
첫 번째, 모든 Pod는 클러스터 내에서 고유한 IP 주소를 가져야 합니다.
Pod마다 별도의 IP가 할당되므로 Pod 간 통신 시 별도의 NAT를 거치지 않고 직접 통신할 수 있는 네트워크 구조를 제공합니다.
두 번째, 같은 노드에 있든 다른 노드에 있든 Pod 간 통신이 가능해야 합니다.
Pod A와 Pod B가 동일한 Worker Node에 있을 수도 있고, 서로 다른 Worker Node에 있을 수도 있습니다.
Kubernetes 네트워크 플러그인은 이러한 통신을 가능하게 해야 합니다.
세 번째, Pod는 다른 Pod와 통신할 수 있어야 합니다.
기본적인 Kubernetes 네트워크 모델에서는 Pod 간 통신을 허용합니다. 다만 실제 클러스터에서는 NetworkPolicy와 CNI 구현에 따라 접근이 제한될 수 있습니다.
전체적인 구조는 다음과 같습니다.
Kubernetes Cluster
|
+------------+------------+
| |
v v
Worker Node 1 Worker Node 2
| |
+---------+ +---------+
| Pod A | | Pod C |
|10.10.1.2| |10.10.2.2|
+---------+ +---------+
| |
+---------- CNI ----------+
|
Pod Network
여기서 중요한 역할을 담당하는 것이 CNI입니다.
3. CNI란 무엇인가?
CNI는 Container Network Interface의 약자입니다.
컨테이너 런타임과 네트워크 플러그인이 통신하기 위한 표준 인터페이스입니다.
쉽게 설명하면 컨테이너가 생성될 때 네트워크를 연결하고 IP 주소를 할당하는 작업을 네트워크 플러그인이 담당하도록 만든 규격입니다.
Kubernetes 자체가 모든 네트워크 기능을 직접 구현하는 것은 아닙니다.
실제 Pod 네트워크 구성은 CNI 플러그인이 담당합니다.
대표적인 CNI 플러그인은 다음과 같습니다.
CNI특징CalicoBGP, 라우팅, NetworkPolicy 지원CiliumeBPF 기반 네트워크 및 보안Flannel단순한 Overlay Network 구성Weave NetOverlay 기반 Pod 네트워크AntreaOpen vSwitch 기반 네트워크
운영 환경에서는 클러스터의 네트워크 요구사항에 따라 CNI를 선택합니다.
3-1. CNI의 동작 과정
Pod가 생성될 때 네트워크가 구성되는 과정을 살펴보겠습니다.
kubectl apply
|
v
Kubernetes API Server
|
v
Scheduler
|
v
Worker Node의 Kubelet
|
v
Container Runtime
|
v
CNI Plugin 호출
|
+------------------+
| |
v v
IP 할당 네트워크 연결
| |
+--------+---------+
|
v
Pod Network
실제 구현은 Container Runtime과 CNI 플러그인에 따라 세부 과정이 달라질 수 있지만, 기본적으로 Pod 네트워크를 구성하는 과정에서 CNI가 호출됩니다.
3-2. CNI 설정 파일 확인
일반적인 Linux Kubernetes 노드에서는 다음 디렉터리를 확인할 수 있습니다.
ls -l /etc/cni/net.d/
예시:
10-calico.conflist
CNI 실행 파일은 일반적으로 다음 위치에 설치됩니다.
ls -l /opt/cni/bin/
예시:
bridge host-local loopback portmap
단, 실제 설치 경로와 파일 구성은 Kubernetes 배포 방식과 CNI 구현에 따라 다를 수 있습니다.
4. Pod 네트워크의 내부 구조
Pod는 하나의 컨테이너만 실행하는 경우도 있지만 여러 컨테이너를 함께 실행할 수도 있습니다.
Kubernetes에서 같은 Pod에 속한 컨테이너들은 일반적으로 네트워크 네임스페이스를 공유합니다.
따라서 다음과 같은 특징이 있습니다.
- 동일한 Pod 안의 컨테이너는 같은 IP 주소를 사용합니다.
- 컨테이너 간에는 localhost를 통해 통신할 수 있습니다.
- 동일한 포트를 동시에 사용할 수 없습니다.
- Pod가 재생성되면 새로운 IP가 할당될 수 있습니다.
예를 들어 다음과 같은 구조입니다.
Pod
IP: 10.10.1.10
|
+--------+--------+
| |
v v
+---------+ +---------+
| Nginx | | App |
| Port 80 | | Port8000|
+---------+ +---------+
Nginx와 App은 동일한 네트워크 네임스페이스를 공유하므로 다음과 같이 통신할 수 있습니다.
localhost:8000
단, 두 컨테이너가 동일한 포트를 사용하려고 하면 포트 충돌이 발생합니다.
5. Network Namespace와 veth Pair
앞선 Docker 네트워크 교육에서 Linux Network Namespace와 veth Pair를 실습했습니다.
Kubernetes의 Pod 네트워크 역시 Linux 커널의 네트워크 기능을 활용합니다.
대표적인 구성 요소는 다음과 같습니다.
- Network Namespace
- veth Pair
- Linux Bridge
- Routing Table
- iptables 또는 nftables
- eBPF
일반적인 veth 기반 네트워크 연결 구조를 살펴보겠습니다.
Linux Host
|
+---------+
| Bridge |
| cni0 |
+---------+
| |
| |
veth-host veth-host
| |
+----+ +----+
| |
Pod A Pod B
eth0 eth0
veth Pair는 서로 연결된 가상 Ethernet 인터페이스 두 개로 구성됩니다.
한쪽 인터페이스에 패킷이 전달되면 연결된 반대쪽 인터페이스로 전달됩니다.
다만 모든 CNI가 Linux Bridge를 사용하는 것은 아닙니다.
Calico는 라우팅이나 eBPF 등의 방식을 사용할 수 있고, Cilium은 eBPF 기반 데이터 경로를 활용할 수 있습니다.
따라서 실제 운영 중인 CNI의 네트워크 구조를 먼저 확인해야 합니다.
6. Kubernetes Pod IP 확인
Kubernetes에서 실행 중인 Pod의 IP 주소를 확인해 보겠습니다.
전체 Pod 확인:
kubectl get pods -A -o wide
예시:
NAMESPACE NAME READY STATUS IP default web-abc 1/1 Running 10.10.1.2 default api-def 1/1 Running 10.10.2.3 default redis-ghi 1/1 Running 10.10.1.4
특정 Pod 상세 정보:
kubectl describe pod web-abc
IP 주소만 출력:
kubectl get pod web-abc \
-o jsonpath='{.status.podIP}'
특정 Namespace의 Pod만 확인하려면 다음 명령을 사용합니다.
kubectl get pods -n default -o wide
여기서 중요한 것은 Pod IP가 고정 주소가 아니라는 점입니다.
Pod가 삭제되고 다시 생성되면 새로운 IP가 할당될 수 있습니다.
따라서 운영 환경에서는 Pod IP를 직접 설정 파일에 입력하는 방식보다 Kubernetes Service를 사용하는 것이 일반적입니다.
7. 같은 Worker Node의 Pod 간 통신
먼저 동일한 Worker Node에서 실행되는 두 Pod의 통신을 살펴보겠습니다.
Worker Node 1
IP: 192.168.66.10
|
+-------------+
| CNI Network |
+-------------+
| |
v v
+------+ +------+
|Pod A | |Pod B |
|10.10 | |10.10 |
|.1.2 | |.1.3 |
+------+ +------+
Pod A에서 Pod B로 패킷을 전송하면 CNI가 구성한 네트워크 경로를 통해 전달됩니다.
Bridge 기반 구성이라면 Linux Bridge를 경유할 수 있습니다.
라우팅 기반 또는 eBPF 기반 CNI라면 데이터 전달 경로가 달라집니다.
실습: Pod 생성
kubectl run pod-a \ --image=busybox:1.36 \ --restart=Never \ --command -- sleep 3600 kubectl run pod-b \ --image=busybox:1.36 \ --restart=Never \ --command -- sleep 3600
Pod 상태 확인:
kubectl get pods -o wide
Pod IP 확인:
kubectl get pod pod-a \
-o jsonpath='{.status.podIP}'
kubectl get pod pod-b \
-o jsonpath='{.status.podIP}'
Pod A에서 Pod B로 Ping을 실행합니다.
kubectl exec pod-a -- ping -c 4 <Pod-B-IP>
정상적으로 통신된다면 다음과 같은 결과를 확인할 수 있습니다.
64 bytes from 10.10.1.3 64 bytes from 10.10.1.3 64 bytes from 10.10.1.3 64 bytes from 10.10.1.3
실제 IP는 클러스터 환경에 따라 달라집니다.
또한 일부 CNI나 보안 정책은 ICMP 통신을 제한할 수 있으므로 Ping 실패만으로 전체 Pod 네트워크가 장애라고 판단해서는 안 됩니다.
8. 서로 다른 Worker Node의 Pod 간 통신
Kubernetes에서 중요한 부분은 서로 다른 Worker Node에 있는 Pod 간 통신입니다.
예를 들어 다음과 같은 구조입니다.
Kubernetes Cluster
|
+-----------+-----------+
| |
v v
Worker Node 1 Worker Node 2
192.168.66.10 192.168.66.11
| |
+-------+ +-------+
| Pod A | | Pod B |
|10.10.1.2 |10.10.2.3
+-------+ +-------+
| |
+----------+------------+
|
Pod Network
Pod A가 Pod B에 패킷을 전송하면 CNI가 구성한 네트워크 경로를 통해 다른 Worker Node까지 패킷을 전달합니다.
이때 CNI 구현 방식에 따라 데이터 전달 구조가 달라집니다.
8-1. Overlay Network
Overlay Network는 기존 물리 네트워크 위에 별도의 가상 네트워크를 구성하는 방식입니다.
대표적으로 VXLAN을 사용할 수 있습니다.
Pod A
10.10.1.2
|
Worker Node 1
|
VXLAN Encapsulation
|
Physical Network
|
VXLAN Decapsulation
|
Worker Node 2
|
Pod B
10.10.2.3
Pod A에서 Pod B로 전달되는 패킷은 물리 네트워크를 통과할 때 VXLAN 등의 방식으로 캡슐화될 수 있습니다.
VXLAN은 일반적으로 UDP 4789 포트를 사용합니다.
실제 사용 포트와 캡슐화 방식은 CNI 설정에 따라 다르므로 반드시 해당 CNI 문서를 확인해야 합니다.
8-2. Routing 기반 네트워크
일부 CNI는 Overlay 대신 노드 간 라우팅을 이용합니다.
예를 들어 각 Worker Node의 Pod CIDR을 라우팅 테이블에 등록합니다.
Worker Node 1 Pod CIDR: 10.10.1.0/24 Worker Node 2 Pod CIDR: 10.10.2.0/24
Worker Node 1은 10.10.2.0/24로 향하는 패킷을 Worker Node 2로 전달합니다.
이 방식에서는 물리 네트워크와 라우팅 구성을 정확하게 이해하는 것이 중요합니다.
9. Kubernetes CNI 종류별 네트워크 구조
실제 운영 환경에서 자주 접하는 CNI를 비교해 보겠습니다.
Calico
Calico는 Kubernetes 환경에서 널리 사용되는 네트워크 플러그인입니다.
주요 특징:
- BGP 기반 라우팅 지원
- IP-in-IP 또는 VXLAN 등 Overlay 구성 지원
- NetworkPolicy 지원
- eBPF 데이터 경로 지원
물리 네트워크와 연계한 라우팅 구성이 필요한 환경에서 활용할 수 있습니다.
Flannel
Flannel은 비교적 단순한 Kubernetes 네트워크 구성을 지원합니다.
주요 특징:
- Overlay Network 구성
- VXLAN 기반 통신
- 비교적 간단한 설치와 운영
다만 Flannel 자체는 Kubernetes NetworkPolicy를 직접 구현하지 않으므로 정책 적용이 필요하다면 별도 플러그인과의 조합 등을 검토해야 합니다.
Cilium
Cilium은 eBPF를 활용하는 네트워크 및 보안 솔루션입니다.
주요 특징:
- eBPF 기반 패킷 처리
- Kubernetes NetworkPolicy 지원
- L3/L4 및 L7 수준의 정책 지원
- 네트워크 관측 기능
대규모 Kubernetes 환경에서 네트워크 성능과 보안, 관측성을 함께 고려할 때 활용할 수 있습니다.
10. Kubernetes 노드에서 네트워크 확인
이제 Worker Node에 직접 접속해서 네트워크 상태를 확인하겠습니다.
10-1. 네트워크 인터페이스 확인
ip addr
라우팅 테이블 확인:
ip route
일반적인 Linux Bridge 기반 환경에서는 다음과 같은 인터페이스를 볼 수 있습니다.
cni0 vethxxxx eth0
하지만 CNI에 따라 인터페이스 이름과 구조는 다릅니다.
10-2. 네트워크 인터페이스 상세 확인
ip -d link show
Bridge가 존재하는 경우:
bridge link
Bridge의 MAC 주소 학습 정보:
bridge fdb show
10-3. VXLAN 인터페이스 확인
VXLAN을 사용하는 환경에서는 다음 명령어로 확인할 수 있습니다.
ip -d link show type vxlan
VXLAN 인터페이스가 존재한다면 VNI, UDP 포트, 원격 IP 등의 정보를 확인할 수 있습니다.
10-4. 패킷 분석
특정 노드의 물리 네트워크 인터페이스에서 패킷을 확인합니다.
tcpdump -ni eth0
VXLAN UDP 포트 확인:
tcpdump -ni eth0 udp port 4789
특정 Pod IP의 패킷 확인:
tcpdump -ni any host 10.10.1.2
운영 서버에서는 패킷 캡처가 CPU와 디스크 사용량에 영향을 줄 수 있으므로 대상 인터페이스와 필터를 지정하고 짧은 시간 동안 수행하는 것이 좋습니다.
11. 실전 장애 분석
Kubernetes 네트워크 장애는 다음 순서로 분석하는 것이 좋습니다.
Pod 상태 확인
|
v
Pod IP 확인
|
v
같은 노드 통신 확인
|
v
다른 노드 통신 확인
|
v
CNI 상태 확인
|
v
Node Routing 확인
|
v
물리 네트워크 확인
장애 1. Pod가 IP를 할당받지 못하는 경우
증상:
Pod Status: ContainerCreating
또는 Pod 이벤트에 다음과 같은 오류가 나타날 수 있습니다.
FailedCreatePodSandBox
확인:
kubectl describe pod <Pod명>
CNI Pod 상태 확인:
kubectl get pods -n kube-system -o wide
확인해야 할 항목:
- CNI Pod 정상 여부
- CNI 설정 파일 존재 여부
- CNI 실행 파일 존재 여부
- IPAM 주소 풀 고갈 여부
- 노드의 네트워크 설정 문제
장애 2. 같은 노드에서는 통신되지만 다른 노드에서는 통신되지 않는 경우
가능한 원인:
- VXLAN UDP 포트 차단
- 노드 간 라우팅 오류
- BGP 세션 장애
- 물리 네트워크 방화벽
- CNI 터널 인터페이스 장애
확인:
ip route ip -d link show type vxlan tcpdump -ni eth0 udp port 4789
VXLAN을 사용하는 경우에는 노드 간 UDP 4789 통신이 가능한지 확인합니다.
Calico BGP 구성을 사용하는 경우에는 BGP 피어링 상태와 TCP 179 통신 여부 등을 확인해야 합니다.
장애 3. Pod IP로는 통신되지만 서비스 이름으로 접속되지 않는 경우
이 문제는 Pod 네트워크 장애와 DNS 장애를 구분해야 합니다.
확인:
kubectl get pods -n kube-system
CoreDNS 상태 확인:
kubectl get deployment -n kube-system coredns
DNS 서비스 확인:
kubectl get svc -n kube-system
Pod 내부에서 DNS 조회:
nslookup kubernetes.default
CoreDNS 로그:
kubectl logs -n kube-system \ -l k8s-app=kube-dns
DNS가 정상적으로 동작하지 않는다면 CoreDNS 상태, Service 연결, NetworkPolicy, Pod의 DNS 설정 등을 확인해야 합니다.
장애 4. 특정 Pod에서만 통신이 안 되는 경우
가능한 원인:
- Pod 내부 애플리케이션 문제
- NetworkPolicy 차단
- 잘못된 Pod IP 사용
- 애플리케이션 리스닝 주소 오류
- 컨테이너 내부 방화벽 설정
확인:
kubectl describe pod <Pod명> kubectl get networkpolicy -A
Pod의 IP와 실행 노드를 확인합니다.
kubectl get pods -o wide
장애 5. Pod가 실행 중인데 외부에서 접근되지 않는 경우
이 경우 Pod 네트워크뿐 아니라 Service, Ingress, Load Balancer까지 확인해야 합니다.
kubectl get svc -A kubectl get ingress -A kubectl get endpoints -A
또는 EndpointSlice를 확인합니다.
kubectl get endpointslices -A
Service에 연결된 실제 Pod가 정상적으로 등록되어 있는지 확인합니다.
12. 운영 환경에서 반드시 기억해야 할 사항
Kubernetes 네트워크 장애를 분석할 때 다음 사항을 기억해야 합니다.
1. Pod IP는 고정 주소가 아니다.
Pod가 삭제되고 다시 생성되면 IP가 변경될 수 있습니다. 애플리케이션에서 Pod IP를 직접 참조하지 않는 것이 좋습니다.
2. CNI에 따라 네트워크 구조가 다르다.
Calico, Flannel, Cilium은 패킷 전달 방식과 노드 간 통신 구조가 다릅니다.
3. Pod 네트워크와 Service 네트워크는 구분해야 한다.
Pod IP는 실제 Pod에 할당되는 주소이고, Service IP는 여러 Pod에 대한 안정적인 접근 지점입니다.
4. Ping만으로 통신 정상 여부를 판단하지 않는다.
ICMP가 차단되어 있을 수 있습니다. 실제 애플리케이션 포트로 TCP 연결을 확인해야 합니다.
5. 네트워크 장애는 계층별로 확인한다.
Pod → CNI → Node Routing → 물리 네트워크 순서로 확인하면 장애 범위를 좁히는 데 도움이 됩니다.
13. 마무리
이번 편에서는 Kubernetes 네트워크의 기본 구조와 CNI의 역할을 살펴봤습니다.
핵심 내용을 정리하면 다음과 같습니다.
- Kubernetes는 Pod마다 고유한 IP를 할당하는 네트워크 모델을 제공한다.
- CNI는 Pod 네트워크를 구성하는 표준 인터페이스다.
- Pod 내부 컨테이너들은 일반적으로 네트워크 네임스페이스를 공유한다.
- veth Pair와 Linux 커널 네트워크 기능은 Pod 통신의 기반이 될 수 있다.
- 서로 다른 노드의 Pod 통신은 CNI의 Overlay 또는 Routing 방식 등에 따라 구현된다.
- Calico, Flannel, Cilium은 서로 다른 네트워크 구현 방식과 기능을 제공한다.
- Kubernetes 네트워크 장애는 Pod, CNI, Routing, 물리 네트워크 순서로 분석하는 것이 좋다.
시스템 엔지니어는 Kubernetes에서 Pod가 실행되는지만 확인해서는 안 됩니다.
Pod가 어떤 IP를 사용하고 있는지, 어떤 네트워크를 통해 통신하는지, 노드 간 패킷이 어떤 경로로 이동하는지까지 이해해야 실제 운영 장애를 해결할 수 있습니다.
다음 편에서는 Kubernetes 네트워크의 핵심 구성 요소인 Service를 다루겠습니다.
다음 편: 시스템 엔지니어 실전 교육 25편 — Kubernetes Service와 ClusterIP, NodePort, LoadBalancer 동작 원리
댓글
아직 댓글이 없습니다.
로그인 후 댓글을 남길 수 있습니다.