Skip to content
Published on

2026 Ingress Controller 종합 비교 — 8종 벤치마크와 선택 가이드

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

들어가며

Kubernetes 클러스터를 운영하다 보면 가장 먼저 마주치는 선택지 중 하나가 "어떤 Ingress Controller를 쓸 것인가"입니다. 외부 트래픽을 클러스터 내부 서비스로 라우팅하는 이 컴포넌트는 한번 선택하면 수년간 함께 가는 핵심 인프라입니다. 그런데 막상 비교하려고 하면 후보가 너무 많습니다. ingress-nginx, Traefik, HAProxy, Contour, Envoy Gateway, Kong, APISIX, Emissary까지 각자 다른 데이터플레인과 철학을 가지고 있습니다.

2026년 현재 이 선택은 단순히 "어느 것이 빠른가"의 문제가 아닙니다. Ingress API 자체가 frozen 상태가 되어 더 이상 새 기능이 추가되지 않고, Gateway API가 후계 표준으로 자리 잡으면서 "이 컨트롤러가 Gateway API를 얼마나 성숙하게 지원하는가"가 미래 비용을 좌우하는 핵심 변수가 되었습니다. 게다가 가장 널리 쓰이던 ingress-nginx가 유지보수 모드로 전환되고 여러 보안 이슈(CVE)가 보고되면서, 많은 조직이 대안을 진지하게 검토하기 시작했습니다.

이 글에서는 8종의 컨트롤러를 설정 방식, CRD 모델, TLS 자동화, 성능, 관측성, Gateway API 지원, 생태계, 라이선스 관점에서 종합 비교합니다. 단순 스펙 나열이 아니라 "어떤 상황에서 무엇을 골라야 하는가"라는 의사결정 관점으로 정리했습니다.

Ingress Controller의 기본 아키텍처

Ingress Controller는 두 부분으로 나뉩니다. 하나는 Kubernetes API를 감시하면서 Ingress/CRD 리소스 변화를 읽어 설정을 생성하는 컨트롤 플레인이고, 다른 하나는 실제 트래픽을 처리하는 **데이터 플레인(프록시 엔진)**입니다.

                  외부 트래픽
                      │
                      ▼
            ┌───────────────────┐
            │  LoadBalancer/    │   (클라우드 LB 또는 NodePort)
            │  Service          │
            └─────────┬─────────┘
                      │
                      ▼
      ┌───────────────────────────────┐
      │     Ingress Controller Pod     │
      │  ┌──────────┐   ┌───────────┐  │
      │  │ Control  │──▶│  Data     │  │
      │  │ Plane    │   │  Plane    │  │
      │  │ (watch)  │   │  (proxy)  │  │
      │  └────┬─────┘   └─────┬─────┘  │
      └───────┼───────────────┼────────┘
              │               │
       watch Ingress/CRD      ▼
              │        라우팅 → backend Service/Pod
              ▼
        Kubernetes API

데이터 플레인이 무엇이냐에 따라 컨트롤러의 성격이 크게 갈립니다. 크게 세 계열로 나눌 수 있습니다.

  • nginx 계열: ingress-nginx. 검증된 nginx 엔진. 설정 reload 기반.
  • Envoy 계열: Contour, Envoy Gateway, Emissary. xDS 기반 동적 설정, hot reload 불필요.
  • 자체/기타 엔진: Traefik(Go 자체 엔진), HAProxy(haproxy 엔진), Kong(nginx+lua/OpenResty 기반), APISIX(nginx+lua 기반).

엔진 차이는 동적 설정 반영 속도, 메모리 사용량, 기능 확장 방식에 직접 영향을 줍니다. 예를 들어 nginx 기반은 설정 변경 시 reload가 필요해 연결이 많은 환경에서 순간적인 부담이 생길 수 있는 반면, Envoy 기반은 xDS로 무중단 동적 갱신이 가능합니다.

8종 종합 비교 테이블

먼저 핵심 항목을 한눈에 비교합니다.

컨트롤러데이터플레인설정 방식전용 CRDTLS 자동화Gateway API
ingress-nginxnginxIngress + 어노테이션거의 없음cert-manager 연동별도 프로젝트(ingate)로 분리
TraefikTraefik(Go)CRD(IngressRoute) + 어노테이션풍부(Middleware 등)내장 ACME성숙
HAProxyHAProxyIngress + 어노테이션 + ConfigMap일부 CRDcert-manager 연동지원(성장 중)
ContourEnvoyCRD(HTTPProxy)HTTPProxycert-manager 연동성숙
Envoy GatewayEnvoyGateway API 네이티브Gateway API 중심cert-manager 연동네이티브(1순위)
Kongnginx/OpenRestyCRD + 어노테이션KongPlugin 등cert-manager 연동지원
APISIXnginx/OpenRestyCRD(ApisixRoute)ApisixRoute 등cert-manager 연동지원
EmissaryEnvoyCRD(Mapping)Mapping 등내장 ACME지원(부분)

성능과 운영 항목을 추가로 비교합니다.

컨트롤러동적 reload관측성API 게이트웨이 기능생태계/성숙도라이선스
ingress-nginxreload 필요Prometheus 메트릭제한적매우 큼(유지보수 모드)Apache 2.0
Traefik무중단대시보드 + 메트릭 + 트레이싱중간큼MIT
HAProxy부분 무중단풍부한 stats + 메트릭제한적큼Apache 2.0
Contour무중단(xDS)Envoy 메트릭/트레이싱낮음중간(CNCF)Apache 2.0
Envoy Gateway무중단(xDS)Envoy 메트릭/트레이싱중간(정책 CRD)성장 중(CNCF)Apache 2.0
Kong부분풍부(플러그인)매우 높음큼Apache 2.0 + 엔터프라이즈
APISIX무중단(etcd)풍부(플러그인)매우 높음중간(ASF)Apache 2.0
Emissary무중단(xDS)Envoy 메트릭/트레이싱높음중간Apache 2.0

표에서 보듯 "API 게이트웨이 기능이 필요한가"와 "Gateway API를 얼마나 중시하는가" 두 축이 선택을 크게 가릅니다.

컨트롤러별 상세

ingress-nginx

가장 널리 쓰여 온 컨트롤러입니다. 검증된 nginx 엔진을 사용하며, 대부분의 튜토리얼과 운영 사례가 이 컨트롤러를 기준으로 작성되어 있습니다. 설정은 Ingress 리소스 + 어노테이션으로 합니다.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    nginx.ingress.kubernetes.io/proxy-body-size: "10m"
spec:
  ingressClassName: nginx
  rules:
    - host: app.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web
                port:
                  number: 80

2026년 핵심 주의점은 ingress-nginx가 유지보수 모드로 전환되고 있다는 점입니다. 과거 어노테이션을 통한 임의 설정 주입(snippet) 기능에서 여러 보안 이슈(CVE)가 보고되었고, snippet 기능은 기본 비활성화 흐름으로 갔습니다. 후계 Gateway API 구현은 별도 프로젝트로 분리되어 진행되는 형태라, 장기적으로는 다른 컨트롤러나 Gateway API 네이티브 구현으로의 전환을 검토하는 것이 합리적입니다.

Traefik

Go로 작성된 자체 엔진을 사용하며, 동적 설정과 풍부한 CRD가 강점입니다. ACME(Let's Encrypt) 인증서 자동 발급이 내장되어 있어 cert-manager 없이도 TLS 자동화가 됩니다. IngressRoute, Middleware 같은 CRD로 표현력 있는 라우팅을 구성합니다.

apiVersion: traefik.io/v1alpha1
kind: IngressRoute
metadata:
  name: web
spec:
  entryPoints:
    - websecure
  routes:
    - match: Host(`app.example.com`) && PathPrefix(`/api`)
      kind: Rule
      services:
        - name: api
          port: 80
      middlewares:
        - name: rate-limit

대시보드가 직관적이고, 미들웨어 체인 모델이 깔끔합니다. 다만 무료 버전과 엔터프라이즈(Traefik Hub) 간 기능 차이가 있으니 필요한 기능이 어디에 속하는지 확인이 필요합니다.

HAProxy

오랜 시간 검증된 HAProxy 엔진을 사용합니다. 안정성과 세밀한 부하분산 제어가 강점이며, 풍부한 stats 페이지와 메트릭을 제공합니다. Ingress + 어노테이션 + 글로벌 ConfigMap 조합으로 설정합니다.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web
  annotations:
    haproxy.org/load-balance: "roundrobin"
    haproxy.org/timeout-client: "30s"
spec:
  ingressClassName: haproxy
  rules:
    - host: app.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web
                port:
                  number: 80

L4/L7 모두에서 강력한 부하분산 알고리즘과 헬스 체크를 제공하므로, 까다로운 트래픽 제어가 필요한 환경에 적합합니다.

Contour

CNCF 프로젝트로, Envoy를 데이터플레인으로 사용합니다. HTTPProxy라는 CRD로 위임(delegation) 기반 멀티테넌시를 우아하게 표현하는 것이 특징입니다. xDS 기반이라 설정 변경 시 reload 없이 동적으로 반영됩니다.

apiVersion: projectcontour.io/v1
kind: HTTPProxy
metadata:
  name: web
spec:
  virtualhost:
    fqdn: app.example.com
    tls:
      secretName: app-tls
  routes:
    - conditions:
        - prefix: /
      services:
        - name: web
          port: 80

HTTPProxy의 include 기능으로 루트 도메인은 플랫폼 팀이, 하위 경로는 각 팀이 관리하는 구조를 만들 수 있어 멀티테넌시에 강합니다.

Envoy Gateway

Envoy 진영이 Gateway API를 일급 시민으로 구현한 프로젝트입니다. Ingress 어노테이션 모델 대신 처음부터 Gateway API(GatewayClass, Gateway, HTTPRoute)를 중심으로 설계되었습니다. 2026년 신규 설계라면 가장 유망한 선택지 중 하나입니다.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: web
spec:
  parentRefs:
    - name: eg
  hostnames:
    - app.example.com
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /
      backendRefs:
        - name: web
          port: 80

정책(타임아웃, 재시도, 레이트리밋 등)은 Gateway API의 확장 정책 CRD로 표현합니다. Ingress가 frozen된 흐름에 가장 잘 맞는 모델입니다.

Kong

OpenResty(nginx+Lua) 기반으로, 단순 Ingress를 넘어 본격적인 API 게이트웨이 기능을 제공합니다. 인증, 레이트리밋, 변환 등 수많은 플러그인을 KongPlugin CRD로 붙일 수 있습니다.

apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
  name: rate-limit
plugin: rate-limiting
config:
  minute: 100
  policy: local

API 제품화(개발자 포털, 키 관리, 사용량 기반 과금)가 필요하다면 강력한 선택입니다. 다만 풀 기능은 엔터프라이즈 영역이 많습니다.

APISIX

Apache 재단 프로젝트로, 역시 nginx+Lua 기반이며 etcd로 동적 설정을 관리합니다. ApisixRoute CRD와 풍부한 플러그인, Admin API가 특징입니다. 동적 라우팅 갱신이 빠르고 플러그인 생태계가 활발합니다.

apiVersion: apisix.apache.org/v2
kind: ApisixRoute
metadata:
  name: web
spec:
  http:
    - name: rule1
      match:
        hosts:
          - app.example.com
        paths:
          - /*
      backends:
        - serviceName: web
          servicePort: 80
      plugins:
        - name: limit-count
          enable: true
          config:
            count: 100
            time_window: 60

오픈소스만으로도 API 게이트웨이 기능을 폭넓게 쓸 수 있는 것이 장점입니다.

Emissary (Ambassador)

Envoy 기반의 초창기 API 게이트웨이 중 하나로, Mapping CRD로 라우팅을 표현합니다. 개발자 친화적인 선언적 모델과 내장 ACME가 특징입니다.

apiVersion: getambassador.io/v3alpha1
kind: Mapping
metadata:
  name: web
spec:
  hostname: app.example.com
  prefix: /
  service: web:80

Envoy의 기능을 비교적 단순한 CRD로 노출하므로, Envoy 기능은 원하지만 raw Envoy 설정은 부담스러운 팀에 맞습니다.

선택 기준

스펙 비교만으로는 결정하기 어렵습니다. 다음 축으로 판단하면 좋습니다.

규모

  • 소규모/단순 라우팅: ingress-nginx(기존 자산이 있다면) 또는 Traefik. 진입장벽이 낮고 자료가 많습니다.
  • 중대규모/멀티팀: Contour(HTTPProxy 위임) 또는 Envoy Gateway(Gateway API 역할 분리)가 멀티테넌시에 유리합니다.
  • 대규모/API 제품화: Kong 또는 APISIX. 플러그인 기반 정책과 API 관리가 필요할 때.

팀 역량

Envoy 기반(Contour, Envoy Gateway, Emissary)은 Envoy 개념(xDS, 리스너, 클러스터)을 어느 정도 이해하면 강력하지만 학습 곡선이 있습니다. 반면 ingress-nginx와 Traefik은 진입이 쉽습니다. 팀이 nginx에 익숙하다면 APISIX/Kong의 디버깅도 상대적으로 수월합니다.

API 관리 필요 여부

단순히 트래픽을 라우팅하는 것이 목적이면 Contour/Envoy Gateway/Traefik으로 충분합니다. 인증, 레이트리밋, 변환, 개발자 포털, 사용량 과금 같은 API 게이트웨이 기능이 핵심이라면 Kong 또는 APISIX가 적합합니다.

온프렘 환경

클라우드 LB가 없는 온프렘에서는 MetalLB 같은 LB 구현과의 궁합, 그리고 자체 인증서 운영(cert-manager)과의 연동이 중요합니다. 대부분의 컨트롤러가 잘 동작하지만, HAProxy/ingress-nginx는 오랜 온프렘 운영 사례가 많아 참고 자료를 찾기 쉽습니다.

워크로드별 추천

워크로드추천이유
단순 웹 서비스Traefik, ingress-nginx빠른 시작, 풍부한 자료
멀티테넌트 플랫폼Contour, Envoy Gateway역할 분리/위임 모델
신규 그린필드(2026)Envoy GatewayGateway API 네이티브
API 제품/포털Kong, APISIX플러그인 기반 API 관리
까다로운 L4/L7 제어HAProxy세밀한 부하분산/헬스체크
Envoy 기능 + 단순 CRDEmissaryEnvoy를 쉬운 CRD로

마이그레이션 난이도

기존 컨트롤러에서 다른 컨트롤러로 옮길 때 난이도는 "설정 모델이 얼마나 다른가"에 비례합니다.

  • Ingress 어노테이션 → 다른 Ingress 어노테이션 (예: ingress-nginx → HAProxy): 어노테이션 매핑만 하면 되어 상대적으로 쉽습니다. 다만 rewrite, 경로 매칭 동작 차이를 검증해야 합니다.
  • Ingress → CRD 모델 (예: ingress-nginx → Traefik IngressRoute, Contour HTTPProxy): 리소스를 새로 작성해야 하므로 변환 작업이 큽니다.
  • Ingress → Gateway API (예: ingress-nginx → Envoy Gateway): ingress2gateway 같은 변환 도구가 있지만, 정책 부분은 수동 매핑이 필요합니다.

핵심은 어떤 경우든 IngressClass를 분리해 두 컨트롤러를 공존시키고, DNS나 트래픽 가중치로 점진 전환하는 것입니다.

총소유비용(TCO) 관점

겉으로 보이는 컨테이너 비용 외에 다음을 고려해야 합니다.

  • 로드밸런서 비용: 클라우드에서 컨트롤러마다 LoadBalancer 서비스를 따로 두면 LB 비용이 곱으로 늘어납니다. 공유 LB + 단일 Ingress 진입점이 비용 효율적입니다.
  • 운영 인력 비용: 학습 곡선이 가파른 컨트롤러는 초기 도입 비용이 큽니다. 자료가 풍부한 컨트롤러는 트러블슈팅 시간이 짧습니다.
  • 엔터프라이즈 라이선스: Kong/Traefik 등 일부 기능은 상용 라이선스가 필요할 수 있습니다. 오픈소스 범위를 명확히 확인해야 합니다.
  • 마이그레이션 비용: 유지보수 모드 컨트롤러에 머무르면 나중에 전환 비용이 한꺼번에 발생합니다. 장기 TCO에서는 이 점이 큽니다.

2026 트렌드: Ingress frozen → Gateway API

가장 중요한 흐름은 Ingress API가 frozen 상태라는 점입니다. 즉, Ingress API에는 더 이상 새 기능이 추가되지 않으며, 모든 신규 기능은 Gateway API로 들어갑니다. Gateway API는 GatewayClass/Gateway/HTTPRoute의 3계층 역할 분리, 멀티 프로토콜(HTTP, gRPC, TCP, UDP, TLS), 표준화된 정책 모델을 제공합니다.

   과거(Ingress)              미래(Gateway API)
   ────────────              ─────────────────
   Ingress + 어노테이션        GatewayClass (플랫폼/인프라)
   (벤더별 비표준)                  │
                              Gateway (클러스터 운영자)
                                   │
                              HTTPRoute/GRPCRoute (앱 개발자)

따라서 2026년 신규 도입이라면 Gateway API를 일급으로 지원하는 컨트롤러(Envoy Gateway 등)를 우선 검토하는 것이 미래 비용을 줄이는 길입니다. 기존 Ingress 자산이 큰 조직도 ingress2gateway 같은 도구로 점진 전환 경로를 계획해 두는 것이 좋습니다.

의사결정 플로우

마지막으로 선택 과정을 흐름도로 정리합니다.

                    시작: Ingress Controller 선택
                              │
              ┌───────────────┴───────────────┐
              │ API 게이트웨이 기능(인증/      │
              │ 레이트리밋/포털)이 핵심인가?    │
              └───────────────┬───────────────┘
                   예 │              │ 아니오
                      ▼              ▼
              ┌──────────────┐   ┌──────────────────────┐
              │ Kong / APISIX │   │ 멀티테넌시/역할 분리   │
              └──────────────┘   │ 가 중요한가?          │
                                 └──────────┬───────────┘
                              예 │                 │ 아니오
                                 ▼                 ▼
                      ┌────────────────┐   ┌────────────────────┐
                      │ Gateway API     │   │ 빠른 시작/풍부한    │
                      │ 네이티브 원하나? │   │ 자료가 중요한가?    │
                      └───────┬────────┘   └─────────┬──────────┘
                       예│       │아니오         예 │
                         ▼       ▼                  ▼
                 ┌──────────┐ ┌─────────┐   ┌───────────────────┐
                 │ Envoy    │ │ Contour │   │ Traefik /         │
                 │ Gateway  │ │         │   │ ingress-nginx     │
                 └──────────┘ └─────────┘   └───────────────────┘

마치며

Ingress Controller 선택에 정답은 없습니다. 다만 2026년에는 두 가지 큰 흐름을 반드시 고려해야 합니다. 첫째, Ingress API는 frozen되었고 Gateway API가 표준 미래라는 점. 둘째, ingress-nginx가 유지보수 모드로 가면서 안정성과 보안 측면에서 대안 검토가 필요해졌다는 점입니다.

기존 자산이 크고 단순 라우팅이면 Traefik이나 기존 ingress-nginx로 충분하지만, 신규 그린필드라면 Envoy Gateway 같은 Gateway API 네이티브 구현을 1순위로 검토하시길 권합니다. 멀티테넌시가 중요하면 Contour, API 제품화가 핵심이면 Kong이나 APISIX가 답이 됩니다. 무엇을 고르든, IngressClass 분리를 통한 공존 전략을 미리 익혀 두면 나중에 전환할 때 큰 도움이 됩니다.

참고 자료

Discuss on Twitter • View on GitHub