https://100.116.194.42:8080(server1의 target-tracking-service)가 "예전엔 됐었는데 겑자기 안 된다"는 증상으로 시작해서, 실제로는 server1(Control Plane) 노드의 flannel VXLAN 인터페이스 자체가 사라진 클러스터 전역 장애였던 걸 밝혀낸 과정.

1. 증상

• 브라우저로 https://100.116.194.42:8080/ 접속 시 ERR_CONNECTION_REFUSED
• "원래 됐었다" — 즉 회귀(regression). 코드 변경 없이 겑자기 끓긴 상황이라 인프라/네트워크 계층을 먼저 의심.

2. 진단 — 계층을 하나씩 좋힌 순서

2-1. 언더레이(Tailscale) 자체는 살아있는가

tailscale status
ping -c 3 100.116.194.42

→ tailscale status에 server1이 active로 표시되고, ping도 정상 응답. VPN/언더레이 네트워크 자체는 문제가 없다는 걸 가장 먼저 제거.

2-2. 포트 자체가 열려있는가

curl -vk https://100.116.194.42:8080/
nc -zv 100.116.194.42 8080

→ Connection refused. 방화벽에 막혀 패킷이 드롭되는 것(타임아웃)이 아니라, 그 포트에 리스닝하는 프로세스가 아예 없다는 신호.

2-3. 클러스터 상태 확인 — 진짜 문제 발견

kubectl get pods -A로 c4i 네임스페이스에서 예상 밖 상태 발견: kafka와 target-tracking-service(server1) 파드가 CrashLoopBackOff, target-tracking-service(server2) 파드만 Running. 같은 앱인데 노드에 따라 결과가 다르다는 게 첫 결정적 단서 — 코드/이미지 문제였다면 모든 replica가 동일하게 실패해야 한다.

2-4. 로그로 실패 지점 좋히기

• kafka → server3에서 실행 중, zookeeper(server1)에 소켓은 열리지만 40초간 응답이 없어 타임아웃: ERROR Timed out waiting for connection to Zookeeper server
• target-tracking-service (server1 replica) → postgres(server2) 이름 자체를 못 찾음: java.net.UnknownHostException: postgres-service.c4i.svc.cluster.local

두 실패의 공통점: 실패하는 두 서비스 쌍이 전부 서로 다른 노드에 떠 있다. 정상 동작하던 target-tracking-service replica는 postgres와 같은 노드(server2)에 있었다. → "노드 내부 통신은 되는데 노드 간 통신이 안 된다" 가설 수립.

3. 가설 검증 — 디버그 파드로 크로스노드 연결성 직접 테스트

같은 네임스페이스에 임시 디버그 파드(nicolaka/netshoot)를 특정 노드에 강제 스케줄링해서 파드 간 통신을 직접 찌러봤다.

# server3 파드 → server1 파드 IP로 기본 ping
kubectl exec netdebug-server3 -- ping -c 5 10.42.0.18
# → 5 packets transmitted, 0 received, 100% packet loss