Kubernetes의 Pod VPN과 이그레스 게이트웨이: 터널의 주인은 누구인가

vpn-gateway 이라는 이름의 Pod을 배포하고 테스트 클라이언트를 그 주소로 향하게 하면 패킷이 사라지는 것을 봅니다. 매니페스트에는 잘못된 것이 없고 kubelet도 불평할 것이 없습니다. 이유는 구성이 아니라 구조에 있습니다. Kubernetes는 각 Pod에 고유한 네트워크 네임스페이스를 주므로 이름이나 레이블, 공유 API 네임스페이스는 패킷이 가는 곳을 바꾸지 못하며, 그래서 VPN 트래픽이 클러스터를 어떻게 떠나는지는 컨테이너 이미지가 아니라 소유권 질문에서 시작합니다.

두 가지 메커니즘이 대부분의 실제 배포를 커버하며, 서로 대체할 수 없습니다. 하나는 터널을 워크로드 자체의 네트워크 네임스페이스 안에 둡니다. 다른 하나는 CNI에 선택된 트래픽을 지정된 게이트웨이 노드를 통해 보내도록 요청합니다. 실패 방식도, 확장 방식도, 책임지는 팀도 다르기 때문에 컨테이너 질문은 대개 끝나지 않는 논쟁을 낳습니다.

Pod의 경계는 네임스페이스이지 점프 호스트가 아니다

Linux 네트워크 네임스페이스는 자신의 인터페이스, 주소, 라우트, 방화벽 규칙을 소유하며 각 Pod는 하나씩 받습니다. 그 Pod 안의 컨테이너들은 여기에 참여하므로, 보조 컨테이너가 애플리케이션이 이후에 따르는 라우트를 다시 쓸 수 있습니다. 이웃 Pod은 겉보기에는 같지만 완전히 분리된 스택을 가집니다. 게이트웨이 Pod가 상속할 공유 테이블은 없고, 한 네임스페이스에서 다른 네임스페이스로 트래픽이 암묵적으로 넘어가지도 않습니다.

그래서 게이트웨이 Pod 패턴은 상류의 무언가가 실제로 그쪽으로 패킷을 보낼 때만 동작합니다. Service, 노드의 정적 라우트, 또는 CNI의 조향 정책이 그것이며, 주소만으로는 아무것도 끌어오지 못합니다.

Pod별 터널이 주는 것과 그 비용

워크로드의 네임스페이스에서 도는 터널은 그 워크로드에 고유한 클라이언트 정체성을 부여하며, 많은 원격 접속 서비스가 세션을 승인하거나 과금하기 전에 이를 요구합니다. 영향 범위도 국소적으로 남아, 끊긴 터널은 모든 것이 쓰는 공유 경로 대신 Deployment 하나를 멈춥니다. 어떻게 도는지는 구현에 달려 있고, 바로 이 지점에서 사람들이 잘못 짐작합니다.

커널 상태만 필요한 설정은 init 컨테이너에서 끝나고 종료할 수 있습니다. Pod의 전체 수명 동안 살아 있어야 하는 사용자 공간 데몬은 Kubernetes 1.29에서 네이티브 사이드카로 도입된 재시작 가능한 init 컨테이너 형태가 필요하며, 이 차이는 취향이 아니라 터널 구현에서 나오고 이 모델의 비용은 중복입니다. 각 복제본이 인증하고 고유한 터널 주소를 받고 원격 세션 슬롯 하나를 소비하므로 오토스케일링 이벤트가 링크 반대편의 용량 이벤트가 되며, 하나의 자격 증명을 모든 복제본에 복사해도 그 비용은 사라지지 않고 감사 추적만 사라집니다. 권한도 같은 검토가 필요합니다. 자기 네임스페이스에서 NET_ADMIN 을 원하는 터널이 privileged: true 예제의 호스트 전체 권한을 상속할 이유가 없습니다.

CNI가 이그레스를 소유할 때

CNI가 지원한다면 이그레스 게이트웨이는 워크로드와 목적지 범위로 트래픽을 선택한 뒤, 예측 가능한 단일 소스 주소 아래 선택된 노드들을 통해 보냅니다. Cilium의 구현이 흔한 참조이며, 문서는 이 기능에 특정 Cilium 구성과 올바른 인터페이스 및 주소를 갖춘 게이트웨이 노드가 필요하다고 분명히 밝힙니다. 또한 Pod 생성 후 조향이 아직 적용되지 않는 초기 기간을 언급하는데, 이는 각주가 아니라 설계 입력입니다.

그 지연을 자신의 약속에 비추어 읽어 보십시오. 다른 경로로는 어떤 트래픽도 나가서는 안 된다는 규칙이라면 그 틈에 전송하는 새 Pod은 이미 규칙을 깬 것이므로, 정책이 적용될 때까지 애플리케이션을 붙잡아 두거나 그 창을 받아들이고 문서화해야 합니다.

주장은 좁게 유지하십시오. 이그레스 게이트웨이는 경로를 선택하고 변환합니다. VPN을 종료하지 않으며, 뒤에 지원되는 연결이 없으면 클러스터를 원격 네트워크의 클라이언트로 만들지도 않습니다.

변환은 원격 측이 보는 것을 조용히 바꾼다

게이트웨이가 소스를 다시 쓰는 순간 Pod별 주소는 사라지고, 정체성을 기준으로 한 허용 목록이 하나의 공유 주소 기준 목록이 됩니다. 이는 결함이 아니라 교환으로, 유지할 규칙은 줄고 무언가 잘못 동작할 때 귀속은 거칠어집니다.

애플리케이션 계층 인증과 요청 로깅이 네트워크가 더 이상 보고하지 않는 것을 떠안아야 합니다. 게이트웨이 용량과 교체를 공유 인프라로 다루고, 단일 노드 재부팅이 이제 그 뒤의 모든 워크로드를 중단시킨다는 점과 반환 경로를 일찍 확인해야 한다는 점을 기억하십시오. 원격 측은 변환된 주소에 어떻게 도달하는지 알아야 하며 보통 매니페스트가 아니라 사람이 소유해야 하는 라우트나 NAT를 거치고, 클러스터와 원격 범위가 겹치면 어느 모델이든 깨지며 IPv6 도입이 상충하는 계획을 변명하지는 않습니다.

소유권으로 결정하고, 약속한 실패를 시험하라

원격 서비스가 개별 워크로드를 인증할 때, 링크가 필요한 Deployment가 몇 개뿐일 때, 실패가 국소적으로 남아야 할 때 Pod별 터널을 고르십시오. 네트워크 팀이 이미 경로를 소유하고 있을 때, 많은 워크로드가 하나의 목적지를 공유할 때, 안정적인 소스 주소가 이 연습의 목적 전부일 때 게이트웨이를 고르십시오.

어느 쪽이든 안정 상태가 아니라 당신이 판 속성을 검증하십시오. Pod을 만들고 즉시 전송하게 한 뒤, 터널에서 아무것도 빠져나가지 않는다는 약속이었다면 처음 몇 초를 보십시오. 복제본 다섯 개로 늘리고, 약속이 워크로드별 정체성이었다면 원격 측이 보고하는 세션 수를 세십시오. 이 두 확인은 매니페스트 검토보다 훨씬 빠르게 메커니즘의 한계를 드러내며, 다음 사고가 어느 팀의 것인지 알려 줍니다.