도커/쿠버네티스 네트워크 완전 가이드 – 컨테이너끼리 통신하는 5가지 방법과 실무 설계 포인트

도커/쿠버네티스 네트워크 완전 가이드

도커/쿠버네티스 네트워크 완전 가이드 – 컨테이너끼리 통신하는 5가지 방법과 실무 설계 포인트

."도커/쿠버네티스 네트워크"를 이해하면, 수백 개의 컨테이너가 물리적으로 다른 서버에 분산돼 있어도 마치 같은 네트워크에 있는 것처럼 통신할 수 있는 구조가 어떻게 만들어지는지 알 수 있다.

컨테이너 네트워크는 처음 보면 진짜 헷갈린다. Pod에 IP가 있고, Service에 IP가 있고, 노드에도 IP가 있다. 어떤 IP로 통신하는 건지, 패킷이 어디서 어떻게 변환되는 건지 감이 안 잡힌다. 이 글에서 그 혼란을 정리해보겠다.

📌목차

• 컨테이너 네트워크가 어려운 이유
• 도커 네트워크의 기본 – bridge, host, overlay 모드
• 쿠버네티스 네트워크 모델의 핵심 원칙
• Pod 간 통신 – 같은 노드, 다른 노드
• Service – 쿠버네티스의 가상 로드밸런서
• CNI 플러그인 – Flannel, Calico, Cilium 비교
• Ingress – 외부 트래픽을 내부로 들이는 관문
• 정리

---

😵 컨테이너 네트워크가 어려운 이유

컨테이너는 호스트 OS에서 네트워크 네임스페이스를 분리해서 만들어진다. 각 컨테이너는 자기만의 독립적인 네트워크 스택(인터페이스, IP, 라우팅 테이블)을 가진다. 근데 이 네임스페이스가 분리돼 있어서 컨테이너끼리 기본적으로는 통신이 안 된다.

컨테이너들이 통신하려면 어떤 방식으로든 이 네임스페이스 경계를 넘어야 한다. 그 방법이 도커에서는 **가상 이더넷 쌍(veth pair)**과 **가상 스위치(docker0 브리지)**다.

쿠버네티스는 여기서 더 복잡해진다. 노드가 여러 개고, Pod가 여러 노드에 분산되니까. 그래서 CNI라는 표준 인터페이스가 있고, 다양한 플러그인이 이걸 구현한다.

---

🐳 도커 네트워크의 기본 – bridge, host, overlay 모드

도커는 기본적으로 몇 가지 네트워크 드라이버를 제공한다.

bridge 모드 (기본값) 도커 데몬이 시작될 때 docker0라는 가상 브리지를 만든다. 각 컨테이너가 시작되면 veth pair가 생성되고, 한쪽은 컨테이너 네임스페이스 안에(eth0), 다른 쪽은 호스트의 docker0 브리지에 붙는다.

컨테이너끼리 통신할 때는 docker0 브리지를 통한다. 외부로 나갈 때는 NAT(iptables MASQUERADE)를 통해서 호스트 IP로 나간다.

host 모드 컨테이너가 호스트의 네트워크 스택을 그대로 쓴다. 컨테이너에 별도 IP가 없고 호스트 IP를 그대로 쓴다. 성능은 가장 좋지만, 포트 충돌 위험이 있고 격리가 안 된다.

overlay 모드 Docker Swarm처럼 멀티 호스트 환경에서 컨테이너들을 연결할 때 쓴다. VXLAN 기반으로 동작한다. 쿠버네티스에서는 잘 안 쓰고, Swarm 환경에서 주로 사용한다.

---

☸️ 쿠버네티스 네트워크 모델의 핵심 원칙

쿠버네티스는 네트워크에 대해 몇 가지 기본 원칙을 정해놨다.

1. 모든 Pod는 NAT 없이 다른 모든 Pod와 통신할 수 있어야 한다
2. 모든 노드는 NAT 없이 모든 Pod와 통신할 수 있어야 한다
3. Pod가 자신을 보는 IP는 다른 Pod가 그 Pod를 보는 IP와 같아야 한다

이 원칙들이 중요한 이유는, 컨테이너 안에서 ifconfig로 보이는 내 IP가 실제로 다른 곳에서 나한테 접근할 때 쓰는 IP와 같아야 한다는 거다. NAT 없이 직접 IP로 통신한다는 의미다.

이 원칙을 구현하는 건 CNI 플러그인의 몫이다.

---

🔄 Pod 간 통신 – 같은 노드, 다른 노드

같은 노드 내 Pod 간 통신 같은 노드에 있는 Pod들은 노드의 가상 브리지(cbr0 또는 CNI가 만든 브리지)를 통해 통신한다. 도커의 bridge 모드와 비슷한 개념이다. L2 통신이라 빠르다.

다른 노드의 Pod 간 통신 여기서 CNI 플러그인의 역할이 중요해진다. 방법은 크게 두 가지다.

오버레이 방식 (Flannel VXLAN 등) 패킷을 VXLAN으로 캡슐화해서 다른 노드로 보낸다. 구현이 간단하고 물리 네트워크 수정이 필요 없다. 오버헤드가 있다.

언더레이 방식 (Calico BGP 등) 각 노드가 Pod CIDR에 대한 경로를 BGP로 전파한다. 물리 라우터들이 Pod IP에 대한 경로를 알게 되고, 캡슐화 없이 직접 라우팅한다. 오버헤드가 없고 성능이 좋다. 대신 물리 네트워크가 BGP를 지원해야 한다.

---

🎯 Service – 쿠버네티스의 가상 로드밸런서

Pod에 직접 접근하는 방식은 문제가 있다. Pod는 언제든 죽고 다시 생길 수 있고, IP가 바뀐다. 그래서 "도커/쿠버네티스 네트워크"에서 Service 개념이 등장한다.

Service는 고정된 가상 IP(ClusterIP)를 제공하고, 해당 IP로 오는 트래픽을 실제 Pod들로 분산시켜준다. 구현 방식을 보면:

iptables 방식 (기본) 각 노드의 kube-proxy가 iptables 규칙을 설정한다. ClusterIP로 오는 패킷을 DNAT(Destination NAT)로 실제 Pod IP로 변환한다. 단점은 Pod가 많아지면 iptables 규칙 수가 폭발적으로 늘어나는 것.

IPVS 방식 iptables 대신 IPVS(IP Virtual Server)를 사용한다. IPVS는 커널 레벨 로드밸런서로 성능이 훨씬 좋고, 다양한 로드밸런싱 알고리즘을 지원한다. 대규모 클러스터에서 권장된다.

eBPF 방식 (Cilium) iptables, IPVS 없이 eBPF 프로그램으로 커널에서 직접 패킷을 처리한다. 성능이 가장 좋다.

Service 타입에 따라 외부 노출 방식이 다르다:

• ClusterIP: 클러스터 내부에서만 접근 가능
• NodePort: 모든 노드의 특정 포트로 접근 가능
• LoadBalancer: 클라우드 로드밸런서와 연동 (AWS ELB, GCP LB 등)

---

🔌 CNI 플러그인 – Flannel, Calico, Cilium 비교

CNI(Container Network Interface)는 쿠버네티스가 네트워크 플러그인과 통신하는 표준 인터페이스다. 대표적인 플러그인들을 비교해보면:

Flannel 가장 단순하고 설정이 쉽다. VXLAN 오버레이 방식이 기본. 성능보다 단순함이 중요한 소규모 클러스터나 학습용으로 적합하다. 네트워크 정책(NetworkPolicy) 지원이 없어서 별도 플러그인이 필요하다.

Calico BGP 기반 언더레이 라우팅으로 오버헤드가 없다. 네트워크 정책 지원이 강력하다. 물리 네트워크 환경에 따라 VXLAN 모드로 전환도 가능하다. 대규모 프로덕션 환경에서 많이 쓴다.

Cilium eBPF 기반으로 동작한다. 기존 iptables 방식을 완전히 대체해서 성능이 뛰어나다. L7 수준의 네트워크 정책도 지원한다. 관측성(Observability) 기능도 강력하다. 설정이 복잡하지만 요즘 점점 표준이 되어가는 추세다.

---

🚪 Ingress – 외부 트래픽을 내부로 들이는 관문

Service의 LoadBalancer 타입으로 외부에 노출할 수 있지만, 서비스마다 로드밸런서 하나씩 붙이면 비용이 엄청나다. Ingress는 하나의 진입점에서 경로(Path)나 호스트 이름 기반으로 여러 서비스로 라우팅한다.

Ingress Controller가 실제로 이 기능을 구현한다. 대표적인 것들:

• NGINX Ingress Controller: 가장 많이 쓰인다
• Traefik: 설정이 간단하고 자동 디스커버리가 강점
• AWS ALB Ingress Controller: AWS 환경에서 ALB와 직접 연동

---

"도커/쿠버네티스 네트워크"는 처음에는 복잡해 보이지만, 레이어별로 나눠서 보면 이해가 된다. 컨테이너 내부 → 같은 노드 → 다른 노드 → 외부 트래픽으로 레이어를 나눠서 각각 어떻게 동작하는지 파악하는 게 핵심이다.

---

출처 및 참고

• Kubernetes 공식 네트워킹 문서: https://kubernetes.io/docs/concepts/cluster-administration/networking/
• CNI GitHub: https://github.com/containernetworking/cni
• Cilium 문서: https://docs.cilium.io/
• Calico 문서: https://docs.projectcalico.org/