nginx Ingress vs ALB Ingress — L7과 L4

쿠버네티스에서 Ingress 는 클러스터 밖 트래픽을 안쪽 서비스로 라우팅하는 규칙이고, 이 규칙을 실제로 처리하는 구현체는 여러 가지입니다. 클러스터 안에서 nginx 파드가 처리하는 nginx Ingress Controller 와, AWS 관리형 로드밸런서인 ALB(Application Load Balancer)가 처리하는 ALB Ingress 를 견줍니다.

nginx Ingress 와 ALB Ingress 둘 다 “외부 트래픽을 받는 컴포넌트” 라고 부를 수 있습니다. 맞는 말인데, 구현이 완전히 다릅니다.

트래픽을 받는 곳이 안이냐 밖이냐

nginx Ingress Controller 는 라우팅을 클러스터 안에서 하고, ALB Ingress 는 클러스터 밖에서 합니다. 이 차이가 그림에 드러납니다.

nginx 쪽은 Pod 자체가 클러스터 안에서 돌며 경로·호스트 기반 라우팅을 직접 합니다. ALB 쪽에서 Controller 는 라우팅을 직접 하지 않습니다. ALB 를 생성하고 설정하는 역할만 하고, 실제 트래픽을 받아 라우팅하는 건 클러스터 밖의 AWS ALB 입니다.

항목	nginx Ingress	ALB Ingress
트래픽 받는 곳	클러스터 안 (nginx Pod)	클러스터 밖 (AWS ALB)
L7 라우팅 담당	nginx	AWS ALB
Controller 역할	라우팅 직접 실행	ALB 생성·설정만
클라우드 종속성	없음	AWS 전용

이 차이가 중요한 이유는, 문제가 생겼을 때 어디를 봐야 하는지가 달라지기 때문입니다. nginx 는 Pod 로그를 보고, ALB 는 AWS 콘솔의 ALB 를 봅니다.

Ingress는 L7 전용 — NLB는 Service로

“Ingress 는 HTTP L7 라우팅만 표현 가능” 이라는 말이 있습니다. 맞습니다. K8s Ingress 스펙 자체가 HTTP 전용입니다.

kind: Ingress
spec:
  rules:
    - host: app.example.com   # HTTP 호스트
      http:                   # http만 있음
        paths:
          - path: /api

host 와 http.paths 만 있습니다. TCP·UDP 를 표현할 방법이 스펙에 없습니다.

그래서 NLB(L4, TCP/UDP)는 Ingress 가 아니라 Service 로 노출합니다.

apiVersion: v1
kind: Service
metadata:
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-type: "nlb"
spec:
  type: LoadBalancer   # Ingress 아님, Service임
  ports:
    - port: 443
      protocol: TCP

리소스	레이어	비고
K8s Ingress	L7 (HTTP/HTTPS)	스펙이 HTTP만
Service LoadBalancer + NLB	L4 (TCP/UDP)	Ingress 아님
Service LoadBalancer + ALB	L7 가능	LBC가 ALB 생성

“Ingress = L7” 은 맞는 말이고, L4 가 필요하면 Ingress 가 아니라 Service 레벨에서 NLB 로 처리합니다. TCP 트래픽을 Ingress 로 어떻게 넣을지 고민하는 건 방향이 틀린 겁니다 — 그건 Service 의 일입니다.