Kubernetes 네트워킹 — Broken Labs & 인시던트 대응

Source: Dev.to

트래픽이 실패할 때는 절대 추측하지 마세요.
항상 다음 순서를 따르세요:

Ingress
↓
Service
↓
Endpoints
↓
Pod
↓
Container

한 레이어가 실패하면 그 위의 모든 것이 실패합니다.

LAB 1 — ClusterIP 서비스 (가장 흔한 프로덕션 장애)

시나리오

• Pods가 Running 상태
• Service가 존재함
• 브라우저 / curl이 아무것도 반환하지 않음

잘못된 설정

Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 2
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api-v1   # ❌ 잘못된 라벨
    spec:
      containers:
      - name: app
        image: hashicorp/http-echo:0.2.3
        args:
          - "-listen=:8080"
          - "-text=API OK"
        ports:
        - containerPort: 8080

Service

apiVersion: v1
kind: Service
metadata:
  name: api-svc
spec:
  selector:
    app: api   # ❌ 불일치
  ports:
  - port: 80
    targetPort: 8080

증상

kubectl get pods
kubectl get svc
kubectl get endpoints api-svc

출력

ENDPOINTS: 

근본 원인

Service selector가 Pod 라벨과 일치하지 않음.

해결 방법

kubectl edit deployment api

Pod 라벨을 Service selector와 일치하도록 변경:

labels:
  app: api

확인:

kubectl get endpoints api-svc

DevOps 면접 답변

Q: Service는 존재하지만 트래픽이 없고, Pods는 실행 중입니다. 무엇을 확인해야 할까요?
A: Endpoints를 확인합니다. 엔드포인트가 비어 있으면 selector 불일치 또는 readiness 문제를 의미합니다.

ClusterIP 사용 시점

• 내부 API
• 백엔드 서비스
• 마이크로서비스

장단점

장점

• 안전함 (외부에 노출되지 않음)
• 클러스터 내에서 안정적인 IP 제공
• Pod 수에 따라 자동으로 스케일링

단점

• 클러스터 내부에서만 접근 가능

Source: …

LAB 2 — NodePort (왜 위험한가)

시나리오

• NodePort가 노출됨
• 가끔은 정상 동작
• 노드가 바뀌면 실패

설정

apiVersion: v1
kind: Service
metadata:
  name: node-svc
spec:
  type: NodePort
  selector:
    app: api
  ports:
  - port: 80
    targetPort: 8080
    nodePort: 30080

증상

• 하나의 노드 IP 로 서비스에 접근하면 동작
• 다른 노드 IP 로 접근하면 실패
• 보안 팀이 열린 포트를 지적

근본 원인

NodePort는 클러스터의 모든 노드에 동일한 포트를 열어, 라우팅 제어가 불가능하고 어떤 노드 IP에 접속하느냐에 따라 서비스가 달라집니다.

DevOps 해결책

NodePort를 다음 중 하나로 교체하세요:

• ClusterIP + Ingress
• LoadBalancer (클라우드 제공자가 지원하는 경우)

인터뷰 답변

Q: 왜 NodePort는 실제 운영 환경에서 거의 사용되지 않을까요?
A: 모든 노드를 노출하고, 세밀한 보안·라우팅 제어가 부족하며, 확장성이 좋지 않기 때문입니다.

NodePort가 허용되는 경우

• 디버깅 / 빠른 테스트
• 임시 외부 접근
• 학습이나 샌드박스 환경

LAB 3 — LoadBalancer 서비스 (클라우드 현실)

시나리오

• LoadBalancer 서비스는 외부 IP를 생성합니다
• 애플리케이션에 접근할 수 없습니다

설정

apiVersion: v1
kind: Service
metadata:
  name: lb-svc
spec:
  type: LoadBalancer
  selector:
    app: api
  ports:
  - port: 80
    targetPort: 8080

증상

kubectl get svc

일반적인 출력은 외부 IP가 할당된 것을 보여주지만, curl이나 브라우저로 서비스에 접근할 수 없습니다.

일반적인 근본 원인

1. 클라우드 제공자 지연 – 외부 로드밸런서가 아직 프로비저닝 중일 수 있습니다.
2. 방화벽 규칙 누락 – 클라우드 방화벽이 할당된 포트로의 트래픽을 차단합니다.
3. Pod 준비 상태 – Pod가 준비되지 않아 로드밸런서에 정상적인 엔드포인트가 없습니다.

해결 체크리스트

• EXTERNAL-IP 열에 실제 IP가 표시될 때까지 기다립니다 (빈칸이 아니라).
• 클라우드 방화벽/보안 그룹이 서비스 포트(보통 80 또는 443)로의 인바운드 트래픽을 허용하는지 확인합니다.
• Pod가 Ready 상태인지(kubectl get pods)와 서비스에 엔드포인트가 있는지(kubectl get endpoints lb-svc) 확인합니다.
• 프라이빗 VPC를 사용하는 경우, IP에 접근할 수 있는 방법(VPN, bastion 호스트 등)이 있는지 확인합니다.

DevOps 인터뷰 답변

Q: LoadBalancer 서비스에 외부 IP가 표시되지만 앱에 접근할 수 없습니다. 무엇을 확인하시겠습니까?
A:

1. 클라우드 제공자의 로드밸런서 프로비저닝 상태.
2. 방화벽/보안 그룹 규칙.
3. Pod 준비 상태와 엔드포인트 존재 여부.

추가 LoadBalancer 문제 해결

LoadBalancer 문제 및 트러블슈팅

• 외부 IP 존재
• 브라우저 타임아웃

트러블슈팅

kubectl describe svc lb-svc
kubectl get endpoints lb-svc

클라우드 확인

• 헬스 체크
• 보안 그룹
• 대상 포트 불일치

근본 원인

클라우드 LB 헬스 체크 실패 원인:

• 잘못된 포트
• 애플리케이션이 리스닝 안 함
• 레디니스 프로브 실패

DevOps 해결 방안

• 포트 정렬
• 레디니스 프로브 추가
• 보안 그룹 검증

인터뷰 답변

Q: 모든 서비스에 LoadBalancer를 사용하지 않는 이유는?
A: 비용, 라우팅 부재, Ingress에 비해 제한된 유연성 때문입니다.

LAB 4 — Ingress (Most Interviewed Topic)

시나리오

• Ingress 생성
• 404 오류 반환

잘못된 Ingress 매니페스트

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
spec:
  rules:
  - http:
      paths:
      - path: /app
        pathType: Prefix
        backend:
          service:
            name: wrong-svc   # ❌ wrong name
            port:
              number: 80

증상

• Ingress IP는 동작함
• 항상 404 반환

트러블슈팅

kubectl describe ingress
kubectl get svc
kubectl get pods -n ingress-nginx

근본 원인

Ingress가 존재하지 않는 서비스로 라우팅하고 있음.

해결 방법

Ingress 스펙의 백엔드 서비스 이름을 올바르게 수정합니다.

면접 답변

Q: Ingress가 404를 반환한다면 가장 먼저 어디를 확인하나요?
A: Ingress 규칙, 서비스 이름, 서비스 포트, 그리고 컨트롤러 로그를 확인합니다.

LAB 5 — DNS 실패 (숨겨진 킬러)

시나리오

• 서비스가 존재함
• DNS 이름 실패

테스트

kubectl run test --rm -it --image=busybox -- sh
nslookup api-svc

근본 원인

• CoreDNS가 실행되지 않음
• 잘못된 네임스페이스
• 서비스가 삭제됨

해결 방법

kubectl get pods -n kube-system | grep dns

필요하면 DNS 파드를 재시작하십시오.

인터뷰 답변

Q: 파드가 서비스를 어떻게 발견합니까?
A: Kubernetes DNS를 통해 서비스 이름을 해당 ClusterIP로 해석합니다.

인시던트 대응 플레이북 (Real DevOps)

단계별

1. Ingress 확인
2. Service 확인
3. Endpoints 확인
4. Pod 준비 상태 확인
5. 컨테이너 로그 확인

절대 단계를 건너뛰지 마세요.

최종 결정 매트릭스 (매우 중요)

INTERVIEW RAPID FIRE (Must Memorize)

• Q: Empty endpoints means?
  A: Selector mismatch or readiness failure.

• Q: Most used service in prod?
  A: ClusterIP.

• Q: Why Ingress?
  A: Routing, TLS, cost efficiency.

• Q: NodePort in prod?
  A: Avoid.

실제 DevOps 진실

Networking issues are:

• 예측 가능함
• 계층화됨
• 항상 관찰 가능함

The difference between struggling and solving fast is 체계적인 사고.