VPN 사이드카에는 시작 규칙과 실패 규칙이 필요하다

파드가 앱보다 터널 컨테이너를 먼저 시작하고 첫 요청이 성공합니다. 바로 그 상황이 문제를 가립니다. 순서는 경합 하나를 고칠 뿐, 터널이 죽은 뒤 네 시간 후에 앱이 시작하는 트래픽에 대해서는 아무것도 말해 주지 않습니다. 이는 별개의 두 결정입니다. 보통 둘 중 하나만 설계됩니다.

순서는 첫 요청만 막는다

Kubernetes는 재시작 가능한 init 컨테이너로 구성하는 사이드카 수명 주기를 지원합니다. 그 모델에서 시작 프로브는 터널이 준비됨을 보고할 때까지 다음 초기화 단계를 붙잡아 둘 수 있습니다. 이는 실질적인 개선이며, 진입점 스크립트에 sleep을 넣는 대신 의도적으로 쓰는 편이 좋습니다. 게이트는 그것이 검사하는 조건만큼만 유효합니다.

그 모델 밖에서는 순서의 의미가 사용 중인 런타임이나 의존성 시스템에 속하며, 서로 일치할 필요는 없습니다. 다른 플랫폼에서 복사한 배포는 앱이 우연히 느리게 시작해서 터널을 기다리는 것처럼 보일 수 있습니다. 그것은 같은 보장이 아니며 부하에서 무너집니다.

게이트가 무엇을 관찰하는지 밝히세요. 프로세스가 있다, 인터페이스가 있다, 핸드셰이크가 끝났다. 각각은 “이 파드에 필요한 목적지로 가는 데이터 경로가 작동한다”보다 약한 주장입니다.

데이터 경로를 가정하지 말고 강제하라

프로브는 한 순간의 점검이고 방화벽은 순간 사이에 성립하는 성질입니다. 앱 트래픽이 터널 밖으로 절대 나가지 않아야 한다는 요구라면, 공유 네트워크 네임스페이스에서 수락-또는-폐기 규칙으로 표현해야 합니다. 컨테이너 시작 순서는 그 요구를 담을 수 없습니다. 규칙만이 담을 수 있습니다.

한 파드의 컨테이너는 그 네임스페이스를 공유합니다. 따라서 강제 지점은 네임스페이스 자체입니다. 무엇을 쓰든 터널 자체의 외부 연결은 사용 가능하게 남겨야 합니다. 앱을 보호하려고 그것을 막으면 앱이 필요로 하는 경로가 끊기기 때문입니다.

실패 정책을 명시적으로 정하세요. 터널이 비정상일 때 앱 트래픽을 완전히 멈춰야 할까요, 아니면 계속하되 보호되지 않음으로 표시해야 할까요? 둘 다 타당하며, 어느 쪽도 컨테이너를 특정 순서로 시작해서 얻는 것이 아닙니다.

언급하지 않은 트래픽을 시험하라

통제된 터널 장애 중에 새 요청을 보내 밖으로 나가는지 보세요. 그다음 출구 주소 시험이 절대 건드리지 않는 경로에 대해 점검을 반복하세요. 클러스터 내부의 DNS 확인, IPv6 목적지, 그리고 공용 인터넷이 아니라 클러스터 내부 주소로 도달하는 서비스입니다. 터널이 죽은 뒤에도 조용히 계속 작동하는 경로가 이것들입니다.

출구 주소 페이지는 한 요청이 그 순간 예상한 곳으로 갔다는 것을 증명합니다. 다른 경로를 목록화할 수는 없으며, 시험한 것과 파드가 도달할 수 있는 것 사이의 간극이 흥미로운 장애가 사는 곳입니다.

깨끗한 시작 후뿐 아니라 사이드카 재시작 후에도 시험을 반복하세요. 재시작된 터널 컨테이너는 네임스페이스에 경로와 정책을 중간 상태로 남길 수 있습니다.

배포 기록을 쓰라

배포 노트에는 세 가지 사실이 들어갑니다. 준비 상태 시험과 그것이 관찰하는 것, 그 시험이 실패할 때의 복구 조치, 그리고 이그레스를 통제하는 강제 규칙입니다. 사이드카 컨테이너 문서는 수명 주기 역학을 다루고 그 정책 결정은 여러분에게 남깁니다. 그 분업은 옳으며, 그래서 정책이 대개 빠져 있습니다.

보호로 오인된 상태 점검은 가장 값비싼 종류의 초록 지표입니다. 사람들이 질문하기를 멈추게 하기 때문입니다. 문서에서 정확히 이름 붙이는 데 문장 하나가 들고, 그것을 막습니다.

마지막으로 앱을 실행한 상태에서 복구 경로를 한 번 시험하세요. 이그레스를 되살리려고 파드를 다시 만들어야 하는 설계는 결정이며, 발견한 것이 아니라 여러분이 내린 결정이어야 합니다.