minikube가 프라이빗 API에 닿지 않나요? 먼저 드라이버를 확인하세요

호스트, 노드, Pod는 각자 자신의 경로와 리졸버를 가집니다. 드라이버를 특정하고 같은 엔드포인트를 세 곳에서 시험한 뒤 실패한 컨텍스트를 고치세요.

프라이빗 API가 노트북에서는 응답하는데 minikube 안의 Pod는 거기에 닿지 못합니다. 호스트에서 무엇이든 바꾸기 전에 활성 프로필 뒤에 있는 드라이버를 특정하세요, 왜냐하면 이 한 가지 사실이 요청이 실제로 어느 네트워크에서 나가는지를 결정하기 때문입니다. 그다음 같은 엔드포인트를 호스트, 노드, Pod에서 시험합니다. 그중 실패한 것은 하나뿐이며, 잘못된 추측은 반나절을 낭비합니다.

0단계: 드라이버와 출발점 특정하기

minikube에 어느 프로필이 활성이고 어떻게 실행되는지 물어보세요. 컨테이너 드라이버는 노드를 당신의 머신 위 컨테이너에 넣고, VM 드라이버는 가상 머신에 넣으며, 원격 드라이버는 전혀 다른 곳에 둡니다.

minikube profile list
minikube status
kubectl config current-context

거기서 요청이 어디서 시작되는지 적어 두세요. 답에 따라 누구의 리졸버와 어떤 경로가 중요한지가 정해지며, 항상 호스트의 것은 아닙니다. 같은 노트북의 두 프로필이 같은 URL에 대해 전혀 다르게 동작할 수 있습니다.

ContextWhat has to work
Host processHost resolver and host route to the private destination
minikube nodeThe node's own resolver and its outbound path
PodPod DNS through cluster services plus the cluster network path

1단계: 같은 엔드포인트를 세 번 시험하기

무해한 엔드포인트 하나를 쓰고 세 시험 모두에서 호스트 이름, 포트, 주소 체계를 똑같이 유지하세요. 실행 사이에 이 중 하나라도 바꾸면 결과를 비교할 수 없습니다.

curl -sS -o /dev/null -w '%{http_code}\n' https://api.corp.example/health
minikube ssh -- curl -sS -o /dev/null -w '%{http_code}\n' https://api.corp.example/health
kubectl run probe --rm -it --image=curlimages/curl --restart=Never -- \
  curl -sS -o /dev/null -w '%{http_code}\n' https://api.corp.example/health

노드가 이미지를 성공적으로 받아왔다고 해서 프라이빗 호스트의 이름 해석이 증명되지는 않습니다. 공개 요청이 성공하면 더더욱 그렇지 않습니다. 결과를 컨텍스트별로 따로 기록하세요, 왜냐하면 세 줄에 걸친 패턴이 진단이고 단발성 실패는 단서일 뿐이기 때문입니다.

호스트 줄도 실패한다면 멈추세요. 호스트 네트워크 문제이며 클러스터는 상관없습니다.

2단계: 호스트에서 클러스터로 가는 경로 유지하기

사람들이 잊는 두 번째 방향이 있습니다: 호스트는 클러스터 자체의 API와 서비스에 계속 닿아야 합니다. VPN 클라이언트는 minikube가 노드 네트워크, 서비스 범위, Pod 범위에 사용하는 프리픽스와 경쟁하는 경로를 설치할 수 있습니다.

그러면 증상이 헷갈립니다: 터널은 동작하는데 kubectl이 응답하지 않거나 NodePort가 연결을 거부합니다. 클러스터 장애처럼 보이지만 실제로는 노트북의 라우팅 장애입니다.

터널을 의심하기 전에 호스트 라우팅 테이블을 minikube의 범위와 대조하세요. 겹침은 보통 클러스터가 자기 것이라고 여기는 프리픽스에 대해 더 구체적인 경로가 터널 인터페이스를 가리키는 형태로 나타납니다.

3단계: VPN을 끄지 않고 겹침 해결하기

minikube 자체의 VPN 및 프록시 안내서는 이런 충돌을 다루며 예시 범위를 보편적 목록이 아니라 점검해야 할 대상으로 취급합니다. 실제로 가진 프로필과 함께 읽으세요.

진짜 겹침이 있다면 지원되는 답은 겹치지 않는 범위로 바꾸거나 VPN 소유자가 승인한 의도적인 로컬 접근 정책입니다. 서비스 범위를 바꾸는 것은 Pod 범위를 바꾸는 것과 같지 않고, 둘 다 노드 네트워크를 바꾸는 것과 같지 않습니다.

로컬 클러스터가 돌아가게 하려고 회사 터널을 끄는 것은 우회 방법이 아니라 다른 사람이 내려야 할 정책 결정입니다. 모두가 퇴근한 뒤 조용히 하지 말고 그 담당자에게 가져가세요. 이미 껐다면 묻기 전에 되돌려 놓으세요.

4단계: 프록시, DNS, 네 가지 장애 형태 분리하기

프록시가 필요하다면 어느 컨텍스트에 필요한지 특정하세요. 호스트의 브라우저 설정은 노드 안의 프로세스를 구성하지 않으며, Pod에는 환경 변수나 클러스터 수준 프록시 구성이 필요합니다.

그다음 장애를 설명하지 말고 분류하세요. 해석되지 않는 이름은 DNS입니다. 해석되지만 연결을 거부하면 라우팅이나 리스너입니다. 연결이 맺어지고 신원에서 실패하면 TLS입니다. 연결은 성공했는데 오류 본문이 오면 애플리케이션입니다.

이 네 가지는 각각 다른 해결책에 속하고, VPN과 관련된 것은 하나뿐입니다. 각 컨텍스트에서 무엇을 관찰했는지 적어 두면 다음 사람은 이야기가 아니라 증거를 물려받습니다.

관련 글