Kubernetes 네트워킹 완벽 가이드: Pod 통신부터 Service까지

들어가며

Kubernetes를 운영하다 보면 가장 헷갈리는 부분 중 하나가 바로 네트워킹입니다. Pod은 어떻게 서로 통신하고, Service는 무엇이며, 왜 필요한지 정확하게 이해해야 클러스터를 안정적으로 관리할 수 있습니다.

이 글에서는 Kubernetes 네트워킹의 기초부터 실무 팁까지 단계적으로 살펴보겠습니다.

1. 쿠버네티스 네트워킹 3가지 핵심 원칙

Kubernetes 네트워킹은 다음 3가지 원칙을 따릅니다:

Pod-to-Pod 통신: 같은 노드 또는 다른 노드의 Pod들이 NAT 없이 직접 통신 가능
Pod-to-Node 통신: Pod은 자신이 실행되는 노드와 통신 가능
External-to-Pod 통신: Service를 통한 외부 접근

이 원칙들이 Kubernetes 네트워킹 아키텍처의 기반을 이룹니다.

2. Pod-to-Pod 통신: CNI(Container Network Interface)

CNI란?

CNI는 Container Network Interface의 약자로, 컨테이너 네트워킹을 구현하는 표준입니다. Kubernetes는 CNI 플러그인을 통해 Pod 간 네트워킹을 관리합니다.

# Pod이 생성될 때 CNI가 수행하는 작업:
1. 각 Pod에 고유한 IP 주소 할당
2. Pod의 network namespace 생성
3. Pod들을 가상 네트워크로 연결

주요 CNI 플러그인

플러그인	특징	사용 난이도
Calico	BGP 기반, 정책 관리 우수	중상
Flannel	가볍고 간단함	하
Weave	자동 발견, 암호화 지원	중
Cilium	eBPF 기반, 성능 우수	상

3. Service: Pod 접근의 추상화

Service가 필요한 이유

Pod은 일시적(ephemeral)입니다. Pod이 죽으면 새로운 IP를 받고, Deployment가 Pod을 재생성할 때도 IP가 바뀝니다. 이렇게 계속 바뀌는 Pod IP에 직접 접근하는 것은 비효율적이고 위험합니다.

Service는 Pod 그룹에 안정적인 진입점(Endpoint)을 제공합니다.

Service 타입별 특징

ClusterIP (기본값)

apiVersion: v1
kind: Service
metadata:
  name: my-app
spec:
  selector:
    app: my-app
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080
  type: ClusterIP

클러스터 내부에서만 접근 가능
가상 IP(VIP) 할당
대부분의 내부 서비스에 사용

NodePort

type: NodePort
ports:
- protocol: TCP
  port: 80
  targetPort: 8080
  nodePort: 30001  # 30000-32767 범위

모든 노드의 특정 포트로 접근 가능
개발/테스트 환경에서 빠르게 외부 접근이 필요할 때 사용

LoadBalancer

type: LoadBalancer

클라우드 제공자의 로드밸런서 활용
AWS ELB, GCP Load Balancer 등과 통합
프로덕션 환경에서 권장

4. Service 동작 원리: iptables와 kube-proxy

Service는 실제 리소스가 아닙니다. 각 노드의 kube-proxy가 iptables 규칙을 생성하여 Service IP를 Pod IP로 변환합니다.

Client → Service IP:Port → iptables 규칙 적용 
  → Pod IP:Port로 포워딩 → Pod의 응답

실습: 동작 확인

# Service 확인
kubectl get svc -n default

# Service의 상세 정보
kubectl describe svc my-app -n default

# 해당 Service의 endpoints 확인
kubectl get endpoints my-app -n default

# 노드의 iptables 규칙 확인 (디버깅용)
sudo iptables -L -n -t nat | grep my-app

5. DNS: 서비스 발견

Kubernetes 클러스터에는 CoreDNS라는 DNS 서버가 동작합니다. Pod들은 서비스 이름으로 자동 DNS 조회가 가능합니다.

# Pod 내부에서 DNS 조회
kubectl exec -it my-pod -- nslookup my-app

# 출력 예:
# Name:   my-app
# Address: 10.0.0.42

DNS 네이밍 규칙

<service-name>.<namespace>.svc.cluster.local

예시:

nginx → 같은 namespace의 nginx service
redis.cache → cache namespace의 redis service
api.production.svc.cluster.local → 전체 FQDN

6. 실무 팁

Tip 1: Service Selector로 유연한 라우팅

apiVersion: v1
kind: Service
metadata:
  name: api-gateway
spec:
  selector:
    tier: api        # 여러 Pod 그룹을 동적으로 묶을 수 있음
  ports:
  - port: 80
    targetPort: 3000

Tip 2: headless Service로 직접 Pod 접근

apiVersion: v1
kind: Service
metadata:
  name: mongodb
spec:
  clusterIP: None  # headless Service
  selector:
    app: mongodb
  ports:
  - port: 27017
    targetPort: 27017

Headless Service는 Pod의 DNS A 레코드를 직접 반환하므로, StatefulSet 같은 특수한 경우에 유용합니다.

Tip 3: Network Policy로 트래픽 제어

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

기본적으로 모든 트래픽을 차단하고, 필요한 것만 허용하는 Zero Trust 원칙을 적용할 수 있습니다.

마치며

Kubernetes 네트워킹은 복잡해 보이지만, 기본 원칙만 이해하면 충분히 관리 가능합니다:

✅ Pod은 직접 통신하고, Service는 안정적인 진입점 제공
✅ kube-proxy가 iptables로 라우팅 담당
✅ DNS를 통한 자동 서비스 발견
✅ Network Policy로 보안 강화

다음 글에서는 Ingress와 외부 트래픽 관리에 대해 자세히 다루겠습니다.

혹시 궁금한 점이나 실무 경험이 있으시다면 댓글로 남겨주세요! 🚀

자바자바

마크다운 테스트