Kubernetes Ingress + MetalLB 트래픽 흐름 완전 해부

― Pod 라벨부터 External IP까지, 실제 패킷이 지나가는 경로

베어메탈 또는 온프렘 Kubernetes 환경에서는
Service type=LoadBalancer가 자동으로 외부 IP를 만들지 못한다.
이 공백을 메우는 것이 MetalLB,
그리고 외부 HTTP 트래픽을 실제 서비스로 분기하는 것이 Ingress다.

문제는 이 둘이 함께 쓰일 때
트래픽이 어디서부터 어디까지 어떻게 흐르는지를
정확히 이해하지 못하면 설정은 맞는데 동작은 안 하는 상황이 반복된다는 점이다.

이 글에서는 매니페스트 이전에 반드시 이해해야 할
Ingress + MetalLB 전체 트래픽 흐름을 하나의 개념도로 정리한다.

전체 트래픽 흐름 개념도 (Ingress + MetalLB)

아래 개념도는 외부 → 클러스터 내부 → Pod까지
실제 패킷 흐름을 순서대로 나타낸 것이다.

이 구조를 이해하면
Ingress + MetalLB 환경에서 발생하는 90% 이상의 문제 원인을
눈으로 바로 추적할 수 있다.

1. 외부 트래픽은 어디로 들어오는가

클라이언트는 Kubernetes를 전혀 모른다.

• Pod IP도 모른다
• Service도 모른다
• Node 구조도 모른다

사용자는 오직 도메인 또는 IP로 접근한다.

https://demo.local

이때 DNS 또는 hosts 파일에 매핑된 IP가
바로 MetalLB가 할당한 External IP다.

---

2. MetalLB는 “IP까지만” 책임진다

MetalLB의 역할은 단순하다.

“이 External IP로 들어오는 트래픽은
이 Service가 받는다”

MetalLB는 다음을 전혀 하지 않는다.

• HTTP 해석 ❌
• Host / Path 판단 ❌
• Pod 선택 ❌

MetalLB는 L4 이전 단계에서 끝난다.
이 점을 이해 못 하면 Ingress랑 역할이 섞인다.

---

3. External IP는 Ingress Controller Service에 붙는다

MetalLB가 IP를 붙여주는 대상은 보통 다음이다.

Service: ingress-nginx-controller
Type: LoadBalancer

여기까지의 흐름은:

Client
 → External IP (MetalLB)
 → Ingress Controller Service

아직 이 시점에서는
어떤 애플리케이션으로 갈지 전혀 모른다.

---

4. 실제 트래픽 분기는 Ingress Controller Pod에서 일어난다

Ingress 리소스는 규칙 정의서일 뿐이다.
실제 HTTP 요청을 받아 처리하는 건 Ingress Controller Pod다.

이 Pod에서 처음으로:

• Host 헤더를 읽고
• Path를 비교하고
• Ingress 리소스와 대조한다

예:

rules:
- host: demo.local
  http:
    paths:
    - path: /
      backend:
        service:
          name: demo-web-svc
          port: 80

여기서 비로소:

“이 요청은 demo-web-svc로 보내라”

라는 판단이 내려진다.

---

5. Ingress는 Pod로 직접 가지 않는다

이건 매우 중요하다.

Ingress → Pod 직행은 없다.

항상 이 경로를 따른다.

Ingress Controller
 → Service (ClusterIP)
 → Endpoint
 → Pod

Ingress backend에는 항상 Service 이름만 들어간다.

---

6. Service는 라벨로 Pod를 고른다

Service는 selector를 통해 Pod를 선택한다.

selector:
  app: demo-web

Pod에는 반드시 대응되는 라벨이 있어야 한다.

labels:
  app: demo-web

이게 맞지 않으면:

• Endpoint가 생성되지 않고
• Ingress에서는 502 / 503이 발생한다

이 경우 Ingress 설정을 아무리 봐도 답이 안 나온다.
문제는 Service–Pod 연결에 있다.

---

7. 전체 흐름을 다시 한 줄로 정리하면

Client
 → MetalLB External IP
 → Ingress Controller Service (LoadBalancer)
 → Ingress Controller Pod (L7 처리)
 → Backend Service (ClusterIP)
 → Pod (labels로 선택)

이 순서를 머릿속에 고정해 두면,
Ingress + MetalLB 환경에서 구조가 흔들릴 일이 없다.

ClusterIP 에 관한 글을 이 글에 이어 쓸 계획이니 이 글의 맨 아래 하단에서 next page를
클릭하기 바란다.

---

8. 이 개념도가 실전에서 중요한 이유

이 구조를 이해하면 장애 지점이 명확해진다.

증상	의심 지점
External IP 없음	MetalLB
IP는 되는데 Host 안 먹힘	Ingress
503 / 502	Service selector / Endpoint
특정 Pod만 안 됨	Pod 상태

“대충 Ingress 문제겠지”라는 접근이 사라진다.

---

마무리

Ingress + MetalLB는 복잡해 보이지만,
실제로는 역할이 명확히 분리된 구조다.

• MetalLB는 IP
• Ingress Controller는 HTTP
• Service는 Pod 연결

이 글의 개념도를 기준으로 매니페스트를 보면
설정 하나하나가 왜 필요한지 보이기 시작할 것이다.

🛠 마지막 수정일: 2026.01.01