GKE 파드가 VPN을 통해 온프레미스 호스트에 도달하지 못하는 이유

노드에서는 핑이 되고 파드에서는 실패하며, 온프레미스 쪽에는 아무것도 도착하지 않는다. 터널과 경로는 정상이고, 회선 위의 출발지 주소가 정상이 아니다. 두 경우를 가르는 것은 패킷이 클러스터를 떠날 때 자신을 무엇이라고 주장하는가이며, GKE는 이에 대한 의견이 있다. 메커니즘은 매스커레이드 예외 목록이고, 그것을 읽는 데 명령 하나면 된다.

무엇이든 바꾸기 전에 유효한 목록을 읽어라

GKE는 대상 범위마다 파드 트래픽을 나갈 때 노드 주소로 다시 쓸지 결정하는 에이전트를 함께 제공한다. 기본 구성은 세 개의 RFC1918 블록, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 를 예외 대상으로 지정한다. 따라서 파드에서 온프레미스 10.x 호스트로 보낸 것은 파드 자신의 주소를 그대로 단 채 노드를 떠난다. 노드 자체의 트래픽은 다시 쓰이지 않으며, 바로 그래서 노드의 핑은 된다.

의도된 구성과 실제로 설치된 규칙을 읽어 보라. 둘은 어긋날 수 있다. kubectl -n kube-system get configmap ip-masq-agent -o yaml 는 에이전트에 무엇이 전달되었는지 보여 주고, kubectl -n kube-system get pods -l k8s-app=ip-masq-agent 는 그것을 적용할 무언가가 돌고 있는지 보여 준다. 노드에서 iptables-save | grep -i masq 는 커널에 실제로 존재하는 규칙을 보여 준다. ConfigMap이 한 말을 하고 규칙이 다른 말을 하면, 의심 대상은 네트워크가 아니라 에이전트다.

캡처로 출발지 주소를 확인하라

목록을 바꾸기 전에 캡처하라. 대상 하나로 필터를 걸면 출력이 읽기 쉬워진다: tcpdump -ni any host 10.20.30.40.

그것을 반대편이 보고하는 것과 비교하라. 온프레미스에서 한 캡처에 파드 주소가 찍히고 응답이 없다면 이야기는 끝난다. 예외 목록이 비대칭을 설명하며 터널 결함은 없다. 하나의 출발지 주소에 대한 두 번의 관찰이면 CNI에 대한 추측을 멈출 수 있다.

예외를 파드 CIDR로 좁혀라

지원되는 수정은 예외를 없애지 않고 좁힌다: 파드 CIDR만 예외로 남기고 10.x 공간의 나머지는 뺀다. 그 목록은 에이전트의 ConfigMap에서 nonMasqueradeCIDRs 아래에 있으며, 바꾸는 것은 편집이고 그 뒤에 롤아웃이 따른다. 넓은 항목을 클러스터의 실제 파드 범위로 바꾸고, 클러스터 내부 트래픽이 아직 필요하면 다른 사설 블록은 남기고, 이유가 없다면 resyncInterval 는 건드리지 마라. 적용하고, 에이전트 파드가 재시작되었는지 확인하고, 커널 규칙이 바뀌었는지 확인하라.

이것은 실제 영향 범위를 가진 클러스터 전체 변경이다. 적용되고 나면 이전에 파드 출발지를 유지하던 트래픽이 이제 노드로 다시 쓰여 도착하므로, 그 파드 주소에 의존하던 모든 것이 다른 송신자를 보게 된다. 희생자는 파드 주소를 지목한 로그, 허용 목록, 온프레미스 방화벽 규칙이며, 이들은 조용히 실패한다. 변경은 수정이 아니라 동작 변경으로 공지하라.

노드 풀이 여러 개인 클러스터에서는 영향받는 파드가 실제로 도는 노드에 에이전트가 스케줄되어 있는지 확인하라. DaemonSet이 없는 풀은 옛 규칙을 유지하며, ConfigMap에는 그것이 드러나지 않는다.

대안과 그 비용

다른 선택지는 파드 주소를 그대로 두고 경로에 그것을 가르친다. 파드 CIDR이 Cloud VPN 트래픽 선택자에 들어가고, 온프레미스 쪽은 응답이 어디로 갈지 알도록 되돌아갈 경로가 필요하다. 이는 일부 보안 모델이 원하는 파드 정체성을 보존하고, 반대편이 받아들여야 할 라우팅과 방화벽 범위를 모두 넓힌다.

거래는 가독성 대 범위다. 변환을 하면 온프레미스 쪽은 노드마다 주소 하나를 보게 되어 허용 목록에 넣기 쉽고 어느 파드가 무엇을 보냈는지는 가려진다. 변환을 하지 않으면 파드 주소가 끝에서 끝까지 유지되어 귀속에는 좋고, 새 범위를 배워야 하는 경로상의 모든 장비에는 나쁘다. 어느 쪽도 Docker나 CNI의 결함이 아니며, 둘 다 운영 비용이 따르는 라우팅 결정이다. 팀이 지불할 수 있는 쪽을 고르고 그 이유를 적어 두라.

검증과 롤백

같은 캡처를 다시 실행하라. 편집 후에도 노드 수준 캡처에 파드 주소가 찍힌다면 ConfigMap이 무엇이라 하든 규칙은 바뀌지 않은 것이다. 사실은 회선이고, 나머지는 추론이다.

그다음 반대 방향을 확인하라. 이런 변경의 절반은 나가는 방향만 검증되기 때문이다. 응답이 요청을 보낸 노드나 파드에 도달하는지, 그리고 애플리케이션이 SYN만 받은 것이 아니라 완료되었는지 확인하라. 요청만 있고 응답이 없는 캡처는 이쪽의 매스커레이드 문제가 아니라 반대편의 라우팅 문제다.

롤백은 이전 ConfigMap을 같은 방식으로 적용하는 것이며, 에이전트가 재시작되고 규칙이 바뀌었다는 같은 확인을 거친다. 변경 기록에 알려진 요청 하나의 변경 전후 출발지 주소를 남겨라. 그 한 줄이 변경이 말한 대로 했음을 증명한다. GKE IP 매스커레이드 에이전트 가이드에 기본값과 ConfigMap 필드가 문서화되어 있다. 롤아웃 후에도 출발지 주소가 그대로라면 그 노드에서 에이전트가 돌지 않는 것이며, YAML을 아무리 고쳐도 해결되지 않는다.