컨테이너가 늘어나면 통신이 복잡해진다
컨테이너 하나는 가볍고 다루기 쉽습니다. 그러나 수백 개가 여러 노드에 흩어져 돌아가기 시작하면, “어느 컨테이너가 어느 컨테이너와 어떻게 통신하는가”가 곧 만만찮은 난제가 됩니다. 컨테이너는 수시로 생겼다 사라지고, 그때마다 위치가 바뀌며, 같은 노드에 있을 수도 다른 노드에 있을 수도 있습니다.
전통적인 방식대로 포트를 일일이 매핑하고 주소를 수동으로 관리하면 이 규모를 감당할 수 없습니다. 쿠버네티스는 이 문제를 풀기 위해 독자적인 네트워킹 모델을 정의했습니다. 그 핵심은 의외로 단순합니다. 모든 파드가 주소 변환 없이 서로의 고유 IP로 직접 통신할 수 있어야 한다는 원칙입니다. 복잡함을 더하는 대신 전제를 단순하게 만들어, 그 위에서 모든 것이 일관되게 동작하도록 한 것입니다.
쿠버네티스 네트워킹의 세 가지 약속
쿠버네티스 네트워크 모델은 몇 가지 기본 전제 위에 서 있습니다. 이 약속들이 지켜져야 그 위의 모든 통신이 예측 가능해집니다.
파드마다 고유 IP
모든 파드는 클러스터 전체에서 유일한 IP를 받습니다. 마치 각 파드가 자기만의 작은 가상 머신인 것처럼 동작합니다. 덕분에 같은 노드에 여러 파드가 있어도 포트가 충돌할 걱정 없이 각자 원하는 포트를 쓸 수 있습니다. 포트를 두고 다투거나 복잡하게 매핑할 필요가 사라지는 셈입니다.
NAT 없는 파드 간 통신
파드는 같은 노드에 있든 다른 노드에 있든, 상대의 IP로 곧장 통신합니다. 중간에 주소를 바꾸는 변환 단계가 없습니다. 이 점이 중요한 이유는, 주소가 도중에 바뀌지 않으니 통신 경로를 추적하고 문제를 진단하기가 훨씬 쉬워지기 때문입니다. 보내는 쪽이 본 주소와 받는 쪽이 보는 주소가 같아, 혼란의 여지가 줄어듭니다.
노드와 파드의 상호 접근
각 노드에서 돌아가는 관리 에이전트는 그 노드의 모든 파드에 접근할 수 있어야 합니다. 이 전제가 있어야 파드의 상태를 점검하고, 준비됐는지 확인하고, 문제가 생긴 파드를 교체하는 관리 작업이 가능합니다. 통신뿐 아니라 운영의 토대가 되는 약속입니다.
통신 유형별로 보는 구조
클러스터 안의 통신은 그 성격에 따라 몇 갈래로 나뉘며, 각각 다른 방식으로 처리됩니다.
같은 파드 안의 컨테이너
한 파드 안에 여러 컨테이너가 함께 들어 있을 수 있습니다. 이들은 같은 네트워크 공간을 공유하므로, 사실상 같은 호스트 안에 있는 것처럼 로컬 주소로 서로를 부릅니다. 가장 가깝고 빠른 통신이며, 긴밀히 협력하는 컨테이너들을 한 파드에 묶는 이유이기도 합니다.
파드 사이의 통신
서로 다른 파드 간 통신은 CNI(Container Network Interface) 플러그인이 담당합니다. 이 플러그인이 각 파드에 IP를 부여하고, 노드를 넘나드는 패킷이 올바른 파드에 닿도록 경로를 프로그래밍합니다. 쿠버네티스가 약속한 평평한 주소 공간, 즉 모든 파드가 서로 직접 통신할 수 있는 환경은 바로 이 플러그인이 실제로 구현해냅니다.
서비스라는 추상화
파드는 수시로 생성되고 삭제되며, 그때마다 IP가 바뀝니다. 그렇다면 다른 구성 요소가 어떻게 그 파드를 안정적으로 부를 수 있을까요. 매번 바뀌는 IP를 쫓아다니는 것은 비현실적입니다. 그래서 쿠버네티스는 서비스라는 개념을 둡니다.
서비스는 같은 역할을 하는 파드 그룹을 대표하는 고정된 가상 IP를 제공합니다. 다른 구성 요소는 개별 파드가 아니라 이 서비스 주소로 요청을 보내고, 서비스는 그 요청을 뒤에 있는 살아 있는 파드들에게 부하 분산합니다. 이 가상 주소는 클러스터 내부 DNS를 통해 이름으로 찾을 수 있어, 숫자 대신 의미 있는 이름으로 서비스를 부를 수 있습니다. 파드가 교체되고 IP가 바뀌어도 서비스의 이름과 주소는 그대로 유지되므로, 변화 속에서도 안정적인 연결점이 됩니다.
네트워크 정책으로 통신 제한하기
모든 파드가 서로 자유롭게 통신할 수 있다는 기본 전제는 편리하지만, 보안 관점에서는 위험할 수 있습니다. 한 파드가 침해되면 거기서 다른 모든 파드로 거리낌 없이 접근할 수 있기 때문입니다. 그래서 쿠버네티스는 네트워크 정책으로 이 기본 허용을 좁힐 수 있게 합니다.
네트워크 정책은 어떤 파드가 어떤 파드와 통신할 수 있는지를 규칙으로 정의합니다. 예를 들어 웹 파드는 애플리케이션 파드와만 통신하고, 데이터베이스 파드는 애플리케이션 파드의 접근만 허용하도록 묶을 수 있습니다. 이렇게 통신 경로를 필요한 만큼만 열어두면, 한 곳이 뚫려도 피해가 클러스터 전체로 번지는 것을 막을 수 있습니다. 다만 이 정책 역시 이를 지원하는 CNI 플러그인이 있어야 실제로 동작하므로, 플러그인 선택 단계에서 함께 고려해야 합니다.
CNI 플러그인의 선택
쿠버네티스 자체는 네트워킹을 직접 구현하지 않습니다. 대신 CNI라는 규격만 정해두고, 그 규격을 만족하는 플러그인에 실제 구현을 맡깁니다. 덕분에 환경과 요구사항에 맞는 플러그인을 골라 쓸 수 있는 유연함이 생깁니다. 단순하고 빠른 것을 원하면 가벼운 플러그인을, 세밀한 정책 제어가 필요하면 기능이 풍부한 플러그인을 선택하는 식입니다.
선택할 때 반드시 챙겨야 할 점은 파드에 할당하는 IP 대역이 클러스터 외부 네트워크와 겹치지 않게 하는 것입니다. 겹치면 클러스터 안과 밖의 주소가 충돌해 통신이 엉킵니다. 모델의 공식 정의와 플러그인이 갖춰야 할 요건은 쿠버네티스 공식 문서의 네트워크 플러그인 페이지에 정리돼 있습니다.