GKE 파드가 1.14 이후 VPN 접근을 잃었습니다: 소스를 고치는 두 가지 방법

1.14 이후 파드는 자체 주소로 VPN에 도달하므로 피어가 응답을 버립니다. 소스 계약을 선택한 다음 nonMasqueradeCIDRs를 그에 맞게 설정하십시오.

업그레이드가 적용되자 터널 건너편의 시스템이 지난주까지 동작하던 파드 트래픽을 거부하기 시작한다. 터널은 살아 있고 방화벽 규칙도 그대로이며 아무도 피어 정책을 편집하지 않았다. 달라진 것은 클러스터 로그에 보이지 않는다:그 시스템이 지금 보는 소스 주소. 이 간극이 네트워크 장애처럼 보이면서 권한 문제처럼 동작하는 고장을 설명한다.

유효한 답은 두 가지이며 서로 다른 곳으로 이끈다. ConfigMap을 편집하기 전에 소스 계약을 선택하라.

더 이상 설치되지 않는 기본 규칙

이전 GKE 릴리스는 목적지가 10.0.0.0/8 밖에 있을 때마다 파드 소스를 노드 주소로 바꾸는 masquerade 규칙을 설치했다. 그 범위 안의 VPN 게이트웨이는 파드 주소를 보았고, 더 멀리 있는 것은 노드에서 온 것처럼 보였다. 피어는 자신들이 관측한 대로 노드 주소를 기준으로 허용 목록과 반환 경로를 만들었다.

이후 릴리스는 그 기본 규칙을 설치하지 않았다. 파드 트래픽은 이제 목적지가 무엇이든 파드 주소로 게이트웨이에 도착한다. 노드 주소만 라우팅하는 피어는 응답을 버리고, 어느 쪽도 쓸모 있는 로그를 남기지 않는다. 요청은 먼 쪽에서 성공하기까지 하며, 그래서 이 고장은 추적하기 어렵다.

죽은 구성 요소라는 의미에서는 아무것도 고장 나지 않았다. 양쪽이 어느 소스가 정당한지만 두고 의견이 다를 뿐이다.

피어가 보아야 할 소스를 선택하라

파드 주소를 유지하는 것이 더 정확한 계약이다. 먼 쪽은 트래픽을 만든 워크로드를 보고, 로그는 정직하게 남으며, 파드별 정책이 가능해진다. 대가는 피어가 파드 프리픽스를 들고 다녀야 한다는 점이다.

노드 주소를 유지하는 것이 더 저렴한 계약이다. 그 목적지에 대해 masquerade를 다시 켜면 피어는 이미 신뢰하는 주소를 계속 본다.

한 가지 질문이 둘 사이를 가른다: 피어가 소스로 무엇을 하는가. 로그를 남기거나 소스별 정책을 적용하거나 좁은 반환 라우팅을 강제한다면 파드 주소가 추가 설정을 정당화한다. 응답을 보내기만 하면 된다면 masquerade가 더 저렴하고 상대방에게 아무것도 요구하지 않는다. 두 팀이 적어 두기만 하면 어느 선택도 방어할 수 있다.

세 번째 선택지는 대개 실수다: 전부 masquerade하고 트래픽을 귀속할 능력을 잃는 것. 피어가 정말로 노드 주소 외에는 아무것도 라우팅할 수 없을 때가 아니면 피하라.

nonMasqueradeCIDRs를 실제 범위로 향하게 하라

GKE는 kube-system에서 ip-masq-agent를 실행하며, 그 ConfigMap은 masquerade를 건너뛰는 목적지를 나열한다. 터널 쪽으로 파드 소스를 보존하려면 파드 범위, 노드 서브넷, 온프레미스 프리픽스가 모두 그 목록에 들어간다.

예시 값을 자신의 클러스터 범위로 바꾸고, 요구보다 목록을 넓히지 말라. 추가 항목마다 다른 목적지가 보는 것이 달라지기 때문이다. 아래 세 항목은 파드 네트워크, 노드 서브넷, 터널 뒤의 프리픽스를 뜻한다:

nonMasqueradeCIDRs:
  - 10.12.0.0/14
  - 10.100.0.0/16
  - 172.16.0.0/12
masqLinkLocal: false
resyncInterval: 60s

0.0.0.0/0 항목은 모든 목적지에 대해 masquerade를 끄며, 이는 무관한 워크로드가 외부 서비스에 보이는 방식을 바꾸므로 의도되는 일은 드물다. 에이전트는 resyncInterval에서 설정을 다시 읽으므로 보통 재시작이 필요 없다. 에이전트 파드가 실행 중인지 확인한 다음 그 안에 마운트된 파일을 열어라. 그 파일을 읽는 것이 변경이 반영되었다는 증거다.

반환 경로가 나머지 절반이다

masquerade는 요청 소스만 바꾸고 그 밖에는 아무것도 바꾸지 않는다. 피어가 어떤 소스를 받든 그곳으로 돌아갈 경로가 여전히 필요하고, 클러스터도 여전히 피어 쪽으로 갈 경로가 필요하다.

VPN 게이트웨이에서의 캡처는 두 고장을 빠르게 분리한다. 파드 주소로 도착해 응답을 전혀 받지 못하는 패킷은 피어에 파드 프리픽스 경로가 없다는 뜻이다. 게이트웨이에 나타나지만 클러스터에 도달하지 않는 응답은 로컬 경로가 빠졌다는 뜻이다. 어느 경우든 계약을 티켓에 적어라: 피어가 보는 소스와 응답을 되돌려 보낼 프리픽스다.

업그레이드할 때마다 다시 확인하라

masquerade의 기본 동작은 이미 한 번 바뀌었고, 노드 풀 교체는 클러스터 네트워킹을 초기화할 수 있다. 소스 계약을 가정할 것이 아니라 검증할 것으로 다루라.

업그레이드 후 파드에서 온프레미스 서비스로 요청 하나를 보내고 피어가 기록하는 소스를 읽어라. 그 한 번의 관찰이 터널 상태 페이지가 당당히 정상이라고 보고할 회귀를 잡아낸다. 반복하는 데 일 분이 들고 다음 사람의 저녁 하나가 절약된다.

관련 글