쿠버네티스 네트워킹 오류, Pod 통신 실패부터 Service Mesh까지 단계별 해결 가이드

쿠버네티스(Kubernetes)는 컨테이너 오케스트레이션의 혁신을 가져왔지만, 그만큼 네트워킹의 복잡성도 극대화했습니다. "애플리케이션 코드는 완벽한데, 왜 통신이 안 될까?"라는 질문에 직면했을 때, 막막함을 느끼는 것은 지극히 정상입니다. 쿠버네티스 네트워킹은 단순한 IP 연결을 넘어, 서비스 디스커버리, 정책 적용, 로드 밸런싱 등 수많은 레이어가 얽혀있기 때문입니다.

이 가이드는 여러분이 네트워킹 문제에 직면했을 때, 감(感)에 의존하는 것이 아니라, 마치 과학 수사대처럼 체계적이고 단계적인 접근법으로 근본 원인을 찾아낼 수 있도록 돕는 실전 매뉴얼입니다.

🚀 네트워킹 문제 해결을 위한 3단계 디버깅 접근법

네트워크 문제를 해결하는 가장 중요한 원칙은 '가장 낮은 레이어부터 올라가며 검증하는 것'입니다. 즉, 애플리케이션 레벨(L7)의 문제로 의심하기 전에, IP 주소 할당(L3)부터 패킷 전달(L2/L3)까지 순차적으로 점검해야 합니다.

💡 실전 디버깅 흐름도 (Troubleshooting Flowchart)

1. [Layer 3/4 검증] Pod IP 확인 및 Reachability:
   • kubectl get pods로 대상 Pod의 IP를 확인합니다.
   • kubectl exec -it <pod-name> -- ping <target-ip>: Pod 내부에서 직접 IP 통신이 가능한지 확인합니다. (가장 먼저 시도)
2. [CNI/OS 검증] 네트워크 경로 및 정책 확인:
   • kubectl describe pod <pod-name>: IP, Node, Status 필드를 확인하여 IP 할당에 문제가 없는지 점검합니다.
   • 패킷 캡처: kubectl exec -it <pod-name> -- tcpdump -i eth0 host <target-ip>를 사용하여 실제로 패킷이 나가는지, 혹은 도착하는지 확인합니다. (가장 확실한 증거 수집)
3. [Service/L7 검증] 서비스 레이어 검증:
   • kubectl get svc <service-name>: 서비스가 정상적으로 생성되었는지, 포트가 열려있는지 확인합니다.
   • kubectl get endpoints <service-name>: 해당 서비스가 실제 Pod IP 목록(Endpoint)을 가지고 있는지 확인합니다. (가장 흔한 실패 지점)

🧩 시나리오 1: Pod 간 직접 통신 실패 (CNI 및 IP 문제)

두 Pod A와 B가 같은 네임스페이스에 있어도 통신이 안 될 수 있습니다. 이는 주로 IP 주소 충돌, 네트워크 정책 위반, 또는 CNI(Container Network Interface) 자체의 문제일 때 발생합니다.

✅ CNI 문제 진단 및 비교

CNI는 쿠버네티스 클러스터의 '신경망'과 같습니다. 주요 CNI들은 각기 다른 방식으로 네트워킹을 구현하며, 이 차이를 이해하는 것이 중요합니다.

최근 트렌드는 **eBPF 기반의 솔루션(Cilium)**으로 이동하고 있습니다. eBPF는 커널 내부에서 네트워킹 로직을 처리하므로, 기존의 iptables 기반 방식보다 오버헤드가 적고, 패킷이 어느 단계에서 드롭되었는지에 대한 가시성(Visibility)이 압도적으로 높다는 장점이 있습니다.

🛠️ 실습: Pod 내부에서 경로 확인하기

Pod 내부로 들어가 ip route 명령을 실행하여, 해당 Pod가 외부 네트워크로 나가는 경로(Gateway)가 올바르게 설정되어 있는지 확인하는 습관을 들이는 것이 좋습니다.

🌐 시나리오 2: Service Discovery 및 로드 밸런싱 오류

Pod A가 Service X를 호출할 때, IP 주소를 직접 알 필요가 없습니다. Service X의 DNS 이름만 알면 됩니다. 이 과정에서 문제가 발생하면 통신은 실패합니다.

🚨 가장 흔한 실수: Endpoint 미생성

서비스가 정상적으로 생성되었더라도, 백엔드 Pod가 다운되거나 레이블 선택자(Selector)가 잘못되면 Endpoints 리소스가 비어버립니다.

# 1. 서비스 정의 확인
kubectl get svc my-service

# 2. 엔드포인트 확인 (가장 중요!)
kubectl get endpoints my-service

# 만약 <none>으로 표시된다면?
# -> 레이블 셀렉터가 Pod의 실제 레이블과 일치하는지,
# -> 해당 Pod가 실제로 Running 상태인지 재확인해야 합니다.

✨ 전문가의 실무 팁: 저는 서비스 호출 실패 시, curl이나 wget 같은 도구 대신, grpcurl 같은 gRPC 클라이언트 도구를 사용하여 특정 포트와 프로토콜로 직접 호출해보는 것을 선호합니다. 이는 DNS나 L4 로드 밸런싱 계층을 우회하여, 애플리케이션 코드 레벨에서 문제가 발생하는지, 아니면 인프라 레벨에서 막히는지 명확히 분리해 주기 때문입니다.

🛡️ 시나리오 3: 고급 네트워크 문제 (NetworkPolicy 및 Service Mesh)

가장 복잡하고 까다로운 영역입니다. 여기서 발생하는 문제는 보통 '의도치 않은 차단'입니다.

1. NetworkPolicy (L3/L4 차단): NetworkPolicy는 "누가, 어디서, 무엇을 할 수 있는지"를 명시적으로 정의하는 방화벽 규칙입니다. 만약 Pod A가 Pod B와 통신해야 하는데, Policy가 존재하지 않거나, ingress 또는 egress 규칙이 누락되었다면, 통신은 아무런 로그 없이 실패합니다. **"명시적으로 허용하지 않으면, 기본적으로 차단된다"**는 원칙을 항상 기억해야 합니다.

2. Service Mesh (Istio 등)의 Sidecar 패턴: Service Mesh는 서비스 간의 통신(Service-to-Service)에 대한 가시성과 제어 기능을 제공합니다. Sidecar 패턴을 통해 모든 트래픽을 프록시(예: Envoy)를 거치게 만듭니다.

• 문제 발생 시 체크리스트:
  1. Sidecar 배포 확인: 모든 파드에 프록시 컨테이너가 제대로 붙어 있는지 확인합니다.
  2. 정책 충돌: AuthorizationPolicy나 VirtualService 같은 정책이 너무 엄격하게 설정되어 트래픽을 차단하고 있는지 확인합니다.
  3. 메트릭 확인: Istio의 메트릭 시스템을 통해 트래픽이 프록시를 통과하는지, 아니면 중간에 드롭되는지 확인하는 것이 필수적입니다.

요약 체크리스트 (문제 해결 순서)

1. Ping/Telnet 테스트: Pod 간의 네트워크 연결 자체에 문제가 없는지 확인합니다. (가장 기본)
2. Service/Endpoint 확인: Service가 올바른 Pod의 IP 주소를 바라보고 있는지 확인합니다.
3. Policy/Security Group 검토: 방화벽, NetworkPolicy, Istio Policy 등 모든 차단 규칙을 점검합니다.
4. 애플리케이션 로그 분석: 통신 실패가 네트워크 레벨인지, 아니면 애플리케이션 로직(예: 인증 실패) 때문인지 분리합니다.