Pod, 노드, 클러스터: VPN 사이드카가 실제로 다시 라우팅하는 범위

Kubernetes Pod 안의 VPN 사이드카는 예의가 바른 호스트 수준 VPN처럼 보이지만, 그 유사성은 네임스페이스 경계에서 끝납니다. 한 Pod의 컨테이너는 주소와 포트 공간을 포함한 네트워크 네임스페이스를 공유하므로, 경로와 정책을 설정하는 사이드카는 애플리케이션 패킷이 어디로 가는지를 실제로 바꿉니다. 노드의 다른 Pod에는 아무것도 바꾸지 않으며, 그렇게 구성하지 않는 한 노드 자체의 스택도 건드리지 않습니다. 이 경계를 제대로 이해하는 것이 무엇을 배포할 수 있고 무엇을 테스트해야 하는지를 결정합니다. 아래 절들은 네임스페이스에서 바깥으로 이어집니다.

공유된 네임스페이스, 공유된 결과

Pod 안의 두 컨테이너는 loopback으로 통신하고 같은 인터페이스를 봅니다. 사이드카 패턴이 성립하는 이유가 바로 이것입니다. 애플리케이션은 터널의 존재를 알 필요가 없습니다. 해석하는 경로가 자신이 사용하는 네임스페이스에 설치되어 있기 때문입니다. 같은 성질은 사이드카의 실수가 애플리케이션의 실수라는 뜻이기도 합니다. 너무 많이 잡는 경로나 터널 안의 리졸버를 가리키는 DNS 변경은 그 Pod의 모든 프로세스에 즉시 적용됩니다. 공유 네임스페이스에는 컨테이너별 라우팅이 없으므로 사이드카를 하나의 프로세스로 한정할 수 없습니다.

검토할 때 기억해야 할 구조는 이것입니다. 영향 범위는 Pod이며 노드도 클러스터도 아닙니다.

사이드카가 닿지 않는 곳

다른 Pod는 각자의 네임스페이스와 라우팅을 유지하므로, 같은 이그레스가 필요한 워크로드는 같은 사이드카가 필요하거나 대신 노드 수준 설계가 필요합니다. 노드의 트래픽도 Pod 네임스페이스 밖에 있고, 호스트 네트워크를 쓰는 Pod는 이 격리에서 의도적으로 완전히 빠집니다. 편리한 무언가에 닿으려고 사이드카를 호스트 네트워크로 실행한다면, 범위를 Pod 하나에서 노드 전체로 넓힌 것이며 그렇게 말해야 합니다.

클러스터 서비스로 가는 트래픽이 또 다른 흔한 놀라움입니다. Pod 안의 넓은 기본 경로는 API 서버나 ClusterIP 서비스로 향하는 요청을 붙잡을 수 있고, 그 요청은 터널이 깨진 것처럼 보이는 방식으로 실패합니다.

경로 계획: Pod, 서비스, 노드, VPN 범위

네 가지 범위를 적고 무엇이든 배포하기 전에 겹침을 확인하세요. Pod CIDR, 서비스 CIDR, 노드 주소, VPN 뒤의 목적지입니다. VPN의 사설 범위와 클러스터 자체 공간의 겹침은 드물지 않으며, 기본 경로는 그에 대한 잘못된 해법입니다. 경로 계획은 매니페스트와 같은 저장소에 있어야 합니다. 다음 클러스터가 전혀 다른 Pod와 서비스 범위를 줄 수 있기 때문입니다.

DNS는 계획의 일부이며 별도의 걱정거리가 아닙니다. 리졸버 구성을 다시 쓰는 사이드카는 외부 조회를 완벽하게 만들면서 클러스터 내부의 서비스 검색을 깨뜨릴 수 있습니다.

시작과 실패는 명시적 상태

실행 중인 사이드카 프로세스는 이그레스 정책이 아닙니다. 터널이 준비되기 전에 어떤 트래픽이 흐를 수 있는지, 그리고 나중에 그것이 죽으면 무슨 일이 일어나는지를 정하고, 그 결정을 구현하세요. 애플리케이션 컨테이너를 게이트하는 프로브, 기본적으로 거부하는 네트워크 정책, 또는 둘 다입니다. 둘 중 하나도 없으면 터널이 아직 연결되는 동안 애플리케이션이 시작하고 이름을 해석하고 노드의 정상 경로 밖으로 트래픽을 보냅니다.

그 틈은 건강한 클러스터에서는 짧고 망가진 클러스터에서는 영구적이며, 공격자나 우발적 데이터 유출이 선호하는 성질이 바로 이것입니다.

순서를 실패 테스트와 짝지으세요. 사이드카를 죽이고 애플리케이션이 조용히 후퇴하는 대신 의도한 이그레스를 잃는지 확인합니다.

권한, 정책, 앱 컨테이너에서의 테스트

인터페이스를 만들고 경로를 바꾸는 데 필요한 권한을 부여하는 것은 특권 결정이며, 격리된 Pod에 적합한 특권이 노드 스택에도 자동으로 적합하지는 않습니다. 클러스터가 지원하는 네트워크 및 보안 정책 메커니즘을 사용하고, 모든 CNI나 정책 구현이 VPN 인터페이스를 같게 다룬다고 가정하지 마세요. 차이는 당신이 신경 쓰는 실패 사례에서 정확히 드러납니다.

실제 애플리케이션 컨테이너에서 사설 목적지, 클러스터 서비스, 공용 인터넷으로 새 요청을 보내 테스트하세요. 사이드카에서의 테스트는 터널이 동작함을 증명할 뿐, 애플리케이션이 필요한 곳에 닿는지는 증명하지 않습니다.

클러스터의 네트워크 가정을 VPN 구성 옆에 문서화하세요. 그러면 워크로드를 다른 클러스터로 옮기는 일은 조용히 작동을 멈추는 이미지 변경이 아니라 경로 계획을 점검하는 작업이 됩니다.