컨테이너 네트워킹 (Bridge, Overlay, CNI)

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

쿠버네티스 클러스터를 처음 실서비스에 올렸을 때, 서비스 간 연결 불안정으로 이틀을 날렸습니다. 문제는 애플리케이션 코드가 아니라 네트워크였고, 그때부터 컨테이너 네트워킹만큼은 반드시 바닥부터 이해하고 넘어가기로 했습니다. 지금 돌아보면 그 이틀은 비싼 수업료였지만, 덕분에 컨테이너 네트워크 구조를 계층별로 완전히 이해하는 계기가 됐습니다. Bridge부터 CNI 플러그인까지, 직접 부딪혀가며 정리한 내용을 공유합니다.

개발 환경의 시작, Bridge 네트워크와 Host 네트워크

Docker를 처음 공부할 때 가장 먼저 마주치는 게 Bridge 네트워크입니다. 컨테이너들이 가상 스위치인 docker0에 연결되고, 같은 브리지 안에 있는 컨테이너끼리는 IP 주소로 직접 통신할 수 있는 구조입니다. docker-compose로 멀티 컨테이너 애플리케이션을 띄울 때 아무 설정 없이도 컨테이너 이름으로 서로를 찾을 수 있는 이유가 바로 이 브리지 덕분입니다.

그런데 제가 직접 써봤을 때 가장 먼저 당황했던 것은 서로 다른 브리지에 놓인 컨테이너끼리 ping이 안 된다는 점이었습니다. docker network ls로 네트워크 목록을 확인해보니 두 컨테이너가 완전히 다른 브리지에 붙어 있었습니다. 기본 격리 정책 때문이었는데, 이걸 모르면 한참 헤맵니다. 저도 처음에 컨테이너 자체의 문제인 줄 알고 이미지를 다시 빌드하는 삽질을 했습니다. 네트워크 구조를 먼저 확인했더라면 5분 만에 해결할 수 있었을 일이었습니다.

Bridge와 반대편에 있는 개념이 Host 네트워크입니다. Host 네트워크란 컨테이너가 별도의 네트워크 네임스페이스를 갖지 않고 호스트의 네트워크 스택을 그대로 공유하는 방식입니다. 가상화 계층이 없으니 당연히 성능이 가장 좋습니다. 저는 고성능 패킷 처리가 필요한 네트워크 모니터링 에이전트를 배포할 때 이 방식을 써봤는데, tcpdump와 iperf3로 측정해보니 Bridge 방식 대비 레이턴시가 눈에 띄게 줄어들었습니다. 다만 포트 충돌이 생기기 쉬워서, 동일 호스트에 여러 컨테이너를 올리는 환경에서는 주의가 필요합니다. 실제로 같은 포트를 쓰는 컨테이너 두 개를 올리다가 충돌로 서비스가 뜨지 않는 상황을 경험했고, 그 이후로 Host 네트워크 사용 전에는 반드시 포트 현황을 먼저 확인하는 습관이 생겼습니다.

Docker 공식 문서에 따르면 Bridge 네트워크는 동일 호스트 내 컨테이너 간 통신에 최적화된 기본 드라이버이며, Host 네트워크는 네트워크 성능이 최우선인 특수 목적 용도로 권장됩니다.

멀티 노드의 핵심, Overlay 네트워크(VXLAN)

단일 호스트를 넘어 여러 노드에 걸친 파드 간 통신이 필요해지면 Overlay 네트워크가 등장합니다. VXLAN(Virtual Extensible LAN)이란 물리 네트워크 위에 가상의 L2 터널을 만들어, 서로 다른 호스트에 있는 컨테이너가 마치 같은 스위치에 연결된 것처럼 통신하게 해주는 기술입니다. 패킷을 UDP로 캡슐화해서 전달하기 때문에, 기존 물리 네트워크 구성을 바꾸지 않아도 됩니다.

처음 Flannel을 설치하고 멀티 노드 클러스터를 구성했을 때, 서로 다른 노드의 파드끼리 통신이 전혀 안 됐습니다. 솔직히 이건 예상 밖이었습니다. 설치는 분명히 정상적으로 됐는데 계속 실패하길래 tcpdump로 패킷을 추적해봤더니, 방화벽에서 VXLAN이 사용하는 UDP 4789 포트를 막고 있었습니다. 그 이후로 CNI 플러그인 설치 전에 반드시 방화벽 포트 요구사항을 먼저 확인하는 체크리스트를 만들어서 운영 중입니다. 이 경험에서 배운 교훈은 단순합니다. 새로운 네트워크 기술을 도입할 때는 해당 기술이 어떤 포트를 사용하는지 반드시 먼저 파악하고, 인프라 방화벽과 맞춰봐야 합니다.

쿠버네티스 클러스터에서 파드 간 통신을 위해 확인해야 할 주요 포트는 다음과 같습니다. UDP 4789는 VXLAN 터널링(Flannel 등 Overlay CNI)에 사용됩니다. TCP/UDP 8472는 Flannel VXLAN 일부 버전에서 사용됩니다. TCP 179는 Calico BGP 피어링에 필요합니다. TCP 4240은 Cilium health check에 사용됩니다. 이 포트들이 방화벽에서 열려 있지 않으면, CNI 플러그인이 정상 설치되어도 파드 간 통신은 묵묵히 실패합니다. 제 경험상 이 부분을 놓치는 경우가 생각보다 많습니다.

실서비스의 선택, CNI 플러그인과 Service 리소스

실서비스 환경에서는 단순한 오버레이 연결만으로는 부족합니다. 네트워크 정책(Network Policy)으로 파드 간 트래픽을 세밀하게 통제해야 하고, 보안 요구사항도 충족해야 합니다. CNI(Container Network Interface)란 쿠버네티스가 네트워크 플러그인과 통신하기 위한 표준 인터페이스 명세로, 이 규격을 구현한 플러그인이 Calico, Flannel, Cilium 같은 것들입니다.

저는 실서비스에서 Calico를 도입해 파드 간 통신을 L3 라우팅 기반으로 전환했습니다. Calico는 BGP(Border Gateway Protocol)를 사용해 파드 IP 경로를 노드 간에 교환하는 방식이라, VXLAN 오버헤드 없이 직접 패킷을 전달할 수 있습니다. BGP란 인터넷에서 AS(자율 시스템)들 사이에 경로 정보를 교환하는 라우팅 프로토콜인데, Calico는 이걸 클러스터 내부 라우팅에 활용합니다. 성능은 좋지만, BGP 설정이 잘못됐을 때 전체 클러스터 파드 통신이 한 번에 끊기는 장애를 맛봤습니다. calicoctl 명령어로 BGP 피어 상태를 하나씩 확인하며 원인을 추적하던 새벽이 지금도 기억납니다. 그 장애를 계기로 BGP 구성 변경은 반드시 유지보수 시간에 진행하고 롤백 계획을 미리 준비하는 원칙을 세웠습니다.

파드는 재시작되면 IP가 바뀌기 때문에, 안정적인 통신 엔드포인트를 유지하려면 Service 리소스가 필수입니다. Service 타입별로 사용 목적이 다릅니다. ClusterIP는 클러스터 내부 전용 가상 IP로 외부에서는 접근 불가합니다. NodePort는 모든 노드의 특정 포트를 통해 외부 접근을 허용합니다. LoadBalancer는 클라우드 프로바이더의 로드밸런서를 자동 생성합니다.

제 경험상 온프레미스 환경에서 LoadBalancer 타입을 무심코 쓰면 External IP가 Pending 상태에서 영원히 바뀌지 않습니다. 클라우드 연동이 없으면 로드밸런서를 프로비저닝할 주체가 없기 때문입니다. MetalLB를 도입해 온프레미스에서 L2 모드로 외부 IP를 할당하는 방식으로 해결했는데, 이런 선택지가 있다는 걸 처음부터 알았다면 삽질을 훨씬 줄일 수 있었을 겁니다. Pending 상태를 보면서 쿠버네티스 버그인 줄 알고 한참을 파고들었던 기억이 부끄럽게 남아 있습니다.

Cilium처럼 eBPF 기반의 최신 CNI는 성능과 네트워크 가시성 면에서 뛰어나지만, 커널 버전 요구사항이 높아 레거시 환경에서는 도입 자체가 어렵습니다. eBPF(extended Berkeley Packet Filter)란 커널 코드를 수정하지 않고도 네트워크 패킷 처리, 성능 추적, 보안 정책 같은 기능을 커널 레벨에서 직접 실행할 수 있는 기술입니다. 최신 환경이라면 충분히 고려할 만하지만, 환경부터 먼저 확인해야 합니다. 저도 Cilium을 도입하려다 클러스터 일부 노드의 커널 버전이 낮아서 포기한 적이 있습니다. 기술 자체의 매력보다 현재 환경의 제약이 항상 먼저입니다.

결국 "쿠버네티스 쓰면 네트워크는 알아서 되지 않냐"는 생각은 오해입니다. 컨테이너 네트워킹은 추상화 레이어가 여러 겹 쌓여 있어서, 문제가 발생했을 때 CNI 플러그인 계층인지, iptables 규칙인지, 방화벽인지 추적하려면 각 계층을 모두 이해하고 있어야 합니다. 클러스터를 처음 구성하기 전에 IP 라우팅, 방화벽, 포트 요구사항을 한 번만 제대로 정리해두면 나중에 훨씬 빠르게 문제를 잡을 수 있습니다. 그 이틀이 아깝지 않았던 건, 덕분에 이 구조를 제대로 이해하게 됐기 때문입니다.

---

출처 및 참고

• 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/