💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

들어가며

Kubernetes 클러스터에 서비스를 외부로 노출할 때 거의 모든 팀이 처음 마주치는 질문이 있습니다. "인그레스 컨트롤러로 무엇을 쓸 것인가"입니다. 그리고 그 답을 찾는 과정에서 가장 자주 비교 대상에 오르는 두 후보가 바로 Traefik과 ingress-nginx입니다.

이 둘은 표면적으로는 같은 일을 합니다. 외부에서 들어오는 HTTP/HTTPS 트래픽을 받아 클러스터 내부의 적절한 서비스로 라우팅하는 일입니다. 하지만 조금만 깊이 들어가 보면 두 프로젝트는 출발점부터 설계 철학, 설정을 표현하는 방식, 동적 변경을 처리하는 메커니즘, 그리고 생태계에서 차지하는 위치까지 상당히 다릅니다.

저는 금융권 고객사의 온프레미스 클러스터와 클라우드 기반 AI 서빙 플랫폼을 운영하면서 두 컨트롤러를 모두 프로덕션에 올려본 경험이 있습니다. 그 과정에서 "어느 쪽이 더 좋은가"라는 질문이 사실은 잘못된 질문이라는 것을 배웠습니다. 더 정확한 질문은 "우리 팀의 운영 방식과 요구사항에 어느 쪽이 더 잘 맞는가"입니다.

특히 2026년 현재는 이 비교에 중요한 맥락이 하나 더 추가되었습니다. Kubernetes의 Ingress API는 기능적으로 동결(frozen)되어 더 이상 새로운 기능이 추가되지 않습니다. 후속 표준인 Gateway API가 GA에 도달해 사실상의 차세대 표준으로 자리 잡았습니다. 게다가 ingress-nginx 프로젝트는 유지보수 모드로 전환되었고, 과거 여러 차례 보안 이슈를 겪은 이력이 있습니다. 이런 변화는 컨트롤러 선택의 무게중심을 바꾸고 있습니다.

이 글에서는 두 컨트롤러를 설계 철학부터 실전 운영 디테일까지 깊이 비교하고, 동일한 요구사항을 양쪽에서 어떻게 구현하는지 YAML 예시로 나란히 보여드린 뒤, 마지막에 시나리오별 추천과 의사결정 테이블로 정리하겠습니다.

두 컨트롤러의 정체성

ingress-nginx — 검증된 NGINX 위의 얇은 제어 계층

먼저 용어부터 정리하겠습니다. "nginx 인그레스"라는 말은 사실 두 가지 서로 다른 프로젝트를 가리킬 수 있어 혼란을 유발합니다.

- **ingress-nginx**: Kubernetes 프로젝트(community)가 관리하는 컨트롤러입니다. 이 글에서 다루는 대상이며, 가장 널리 쓰입니다.

- **nginx-ingress**: NGINX(F5) 회사가 관리하는 별도의 상용/오픈소스 컨트롤러입니다. 어노테이션 체계와 CRD가 다릅니다.

이 글에서 "ingress-nginx"라고 하면 전자, 즉 kubernetes.github.io/ingress-nginx 에서 관리되는 커뮤니티 프로젝트를 의미합니다.

ingress-nginx의 핵심 아이디어는 "이미 수십 년간 검증된 NGINX를 데이터 플레인으로 쓰고, 그 위에 Kubernetes 리소스를 감시해 nginx.conf를 생성하는 얇은 제어 계층을 얹는다"입니다. 컨트롤러는 Ingress 리소스의 변경을 감지하면 템플릿을 통해 새로운 nginx.conf를 만들고 NGINX에 reload를 지시합니다.

이 설계의 장점은 명확합니다. NGINX는 성능과 안정성 측면에서 업계 표준이고, 운영자들이 이미 익숙합니다. 단점도 명확합니다. 세밀한 동작 제어가 Ingress 리소스의 어노테이션에 의존하게 되고, 복잡한 요구사항은 결국 nginx.conf 스니펫을 직접 주입하는 방식으로 흘러가기 쉽습니다.

Traefik — 클라우드 네이티브를 위해 처음부터 설계된 프록시

Traefik은 처음부터 동적이고 컨테이너 중심적인 환경을 위해 Go로 작성된 리버스 프록시입니다. Docker 시절부터 "서비스가 뜨고 사라지는 환경에서 사람이 설정 파일을 다시 쓰지 않아도 자동으로 라우팅을 갱신한다"는 목표를 핵심 가치로 내세웠습니다.

Traefik의 설정은 정적 설정(static configuration)과 동적 설정(dynamic configuration)으로 나뉩니다. 정적 설정은 EntryPoint(리스닝 포트), 프로바이더, 로그 등 프로세스 시작 시 결정되는 부분이고, 동적 설정은 Router, Service, Middleware 등 런타임에 계속 바뀌는 라우팅 규칙입니다. Kubernetes에서는 이 동적 설정을 Ingress 리소스로도, 혹은 Traefik 고유의 CRD(IngressRoute, Middleware 등)로도 표현할 수 있습니다.

핵심 차별점은 Traefik이 동적 설정을 **무중단으로 반영**한다는 점입니다. 라우팅 규칙이 바뀌어도 프로세스 reload나 재시작이 필요 없습니다. 이 점이 두 컨트롤러를 가르는 가장 근본적인 설계 차이입니다.

설계 철학 비교

두 컨트롤러의 차이를 한 장의 표로 압축하면 다음과 같습니다.

| 항목 | ingress-nginx | Traefik |

| --- | --- | --- |

| 데이터 플레인 | NGINX(C 기반) | 자체 Go 프록시 |

| 출발점 | 기존 NGINX 위의 K8s 어댑터 | 클라우드 네이티브 전용 설계 |

| 설정 표현 | Ingress + 어노테이션 + 스니펫 | Ingress 또는 CRD(IngressRoute/Middleware) |

| 설정 반영 | nginx.conf 생성 후 reload | 무중단 동적 반영 |

| 미들웨어 모델 | 어노테이션/스니펫 기반 | 선언적 Middleware 체인 |

| 자동 TLS | cert-manager 별도 구성 | 내장 ACME(Let's Encrypt) 지원 |

| 관측성 | 메트릭/로그(별도 구성 비중 큼) | 메트릭/트레이싱/대시보드 내장 |

| 설정 철학 | 명령형에 가까움 | 선언형 지향 |

이 표만 봐도 두 프로젝트가 같은 문제를 매우 다른 사고방식으로 접근한다는 것이 드러납니다. ingress-nginx는 "강력하고 익숙한 엔진을 Kubernetes에 연결"하는 데 집중하고, Traefik은 "Kubernetes의 선언형 모델에 프록시 자체를 동화"시키는 데 집중합니다.

설정 방식 — 어노테이션 vs CRD/미들웨어

이 부분이 일상 운영에서 체감 차이가 가장 큰 영역입니다.

ingress-nginx의 어노테이션 모델

ingress-nginx에서는 Ingress 리소스 본문은 단순한 호스트/경로 라우팅만 표현하고, 그 외 거의 모든 부가 동작(리다이렉트, 재작성, 인증, 레이트 리밋, 타임아웃 등)은 어노테이션으로 지정합니다.

apiVersion: networking.k8s.io/v1

kind: Ingress

metadata:

annotations:

nginx.ingress.kubernetes.io/rewrite-target: /$2

nginx.ingress.kubernetes.io/ssl-redirect: 'true'

nginx.ingress.kubernetes.io/proxy-body-size: 50m

nginx.ingress.kubernetes.io/rate-limit-rps: '20'

nginx.ingress.kubernetes.io/configuration-snippet: |

more_set_headers "X-Custom: hello";

spec:

ingressClassName: nginx

rules:

- host: app.example.com

http:

paths:

- path: /web(/|$)(.*)

pathType: ImplementationSpecific

backend:

service:

port:

number: 80

이 방식은 단순한 케이스에서는 매우 빠르고 직관적입니다. 그러나 요구사항이 복잡해질수록 어노테이션 키가 길게 나열되고, 결국 `configuration-snippet`이나 `server-snippet`으로 원시 nginx.conf 조각을 주입하게 됩니다. 이 스니펫 주입은 강력하지만 동시에 가장 위험한 부분입니다. 잘못된 스니펫 하나가 전체 reload를 실패시키거나, 과거에는 보안 우회 경로가 되기도 했습니다. 실제로 2025년에 보고된 ingress-nginx의 심각한 취약점들은 이 스니펫/설정 주입 경로와 관련이 깊습니다.

Traefik의 CRD와 Middleware 모델

Traefik은 부가 동작을 어노테이션이 아니라 독립된 선언형 리소스인 Middleware로 표현합니다. 그리고 라우팅 자체도 IngressRoute라는 CRD로 더 풍부하게 표현할 수 있습니다.

apiVersion: traefik.io/v1alpha1

kind: Middleware

metadata:

spec:

rateLimit:

average: 20

burst: 40

apiVersion: traefik.io/v1alpha1

kind: Middleware

metadata:

spec:

headers:

customRequestHeaders:

X-Custom: hello

apiVersion: traefik.io/v1alpha1

kind: IngressRoute

metadata:

spec:

entryPoints:

- websecure

routes:

- match: Host(`app.example.com`) && PathPrefix(`/web`)

kind: Rule

middlewares:

- name: rate-limit

- name: custom-header

services:

- name: web-svc

port: 80

차이가 보이시나요. Traefik에서는 rate-limit이라는 정책이 재사용 가능한 객체이고, 여러 라우트에서 참조할 수 있으며, RBAC로 권한을 분리할 수도 있습니다. 라우팅 매칭 규칙도 Host와 PathPrefix를 논리 연산자로 조합하는 표현식으로 작성합니다. 이는 어노테이션 문자열보다 검증과 테스트가 쉽고, GitOps 환경에서 변경 이력을 추적하기에 유리합니다.

대신 비용도 있습니다. CRD를 클러스터에 설치해야 하고, 팀원들이 Ingress 표준이 아닌 Traefik 고유 리소스를 학습해야 합니다. 표준 Ingress 리소스로도 Traefik을 쓸 수 있지만, 그렇게 하면 Traefik의 강점 중 상당 부분을 포기하게 됩니다.

자동 TLS

HTTPS 인증서 발급/갱신은 운영에서 빼놓을 수 없는 주제입니다. 두 컨트롤러의 접근법이 크게 다릅니다.

Traefik의 내장 ACME

Traefik은 Let's Encrypt 같은 ACME 제공자와의 연동을 컨트롤러 자체에 내장하고 있습니다. 정적 설정에 인증서 리졸버를 정의하면, EntryPoint에 도착한 도메인에 대해 자동으로 인증서를 발급하고 갱신합니다.

Traefik 정적 설정 (values.yaml 일부)

certificatesResolvers:

letsencrypt:

acme:

email: ops@example.com

storage: /data/acme.json

httpChallenge:

entryPoint: web

IngressRoute에서 이 리졸버를 지정하면 끝입니다. 별도 컨트롤러 설치가 필요 없습니다.

apiVersion: traefik.io/v1alpha1

kind: IngressRoute

metadata:

spec:

entryPoints:

- websecure

routes:

- match: Host(`secure.example.com`)

kind: Rule

services:

- name: secure-svc

port: 80

tls:

certResolver: letsencrypt

다만 이 내장 ACME는 단일 인스턴스 스토리지(acme.json)를 전제로 하는 경우가 많아, 여러 레플리카로 스케일아웃하려면 분산 스토리지나 외부 인증서 관리가 필요합니다. 고가용성 구성에서는 이 점이 함정이 될 수 있습니다.

ingress-nginx + cert-manager

ingress-nginx는 인증서 발급 기능을 자체 내장하지 않습니다. 대신 사실상의 표준인 cert-manager와 조합합니다. cert-manager는 Certificate/Issuer CRD로 인증서를 선언하고, 발급된 인증서를 Secret으로 저장하며, ingress-nginx는 그 Secret을 참조합니다.

apiVersion: cert-manager.io/v1

kind: ClusterIssuer

metadata:

spec:

acme:

server: https://acme-v02.api.letsencrypt.org/directory

email: ops@example.com

privateKeySecretRef:

solvers:

- http01:

ingress:

apiVersion: networking.k8s.io/v1

kind: Ingress

metadata:

annotations:

cert-manager.io/cluster-issuer: letsencrypt-prod

spec:

ingressClassName: nginx

tls:

- hosts:

- secure.example.com

secretName: secure-app-tls

rules:

- host: secure.example.com

http:

paths:

- path: /

pathType: Prefix

backend:

service:

port:

number: 80

언뜻 보면 구성 요소가 하나 더 늘어 복잡해 보이지만, 실무에서는 오히려 이 분리가 장점이 됩니다. cert-manager는 HA 환경, 와일드카드 인증서, DNS-01 챌린지, 사내 PKI(Vault, ACME 사설 CA) 연동까지 폭넓게 지원합니다. 인증서 관리 책임이 컨트롤러와 분리되어 있어 컨트롤러를 교체해도 인증서 인프라는 그대로 재사용할 수 있습니다.

성능과 리소스

성능은 가장 자주 논쟁되지만 가장 일반화하기 어려운 영역입니다. 정확한 수치는 워크로드, 커넥션 패턴, 설정에 따라 크게 달라지므로 절대치보다는 경향과 특성을 이해하는 것이 중요합니다.

| 특성 | ingress-nginx | Traefik |

| --- | --- | --- |

| 데이터 플레인 언어 | C(NGINX) | Go |

| 정적 고부하 처리 | 매우 강함(검증된 NGINX) | 강함 |

| 커넥션당 메모리 | 대체로 낮음 | GC 특성상 변동 가능 |

| 설정 변경 비용 | reload 발생 | 무중단(reload 없음) |

| 대량 라우트 변경 | reload 빈발 시 부담 | 거의 무비용 |

ingress-nginx의 데이터 플레인인 NGINX는 정적이고 안정적인 고부하 환경에서 수년간 검증된 성능을 보여줍니다. 반면 Traefik은 Go의 가비지 컬렉션 특성상 극단적 고부하에서 미세한 지연 변동이 있을 수 있지만, 대부분의 실무 워크로드에서는 차이를 체감하기 어렵습니다.

오히려 실무에서 더 중요한 성능 차이는 "설정 변경의 비용"입니다. ingress-nginx는 Ingress가 자주 바뀌는 환경에서 reload가 빈번하게 발생합니다. 마이크로서비스가 수백 개이고 배포가 잦은 환경, 또는 동적으로 라우트가 생성/삭제되는 멀티테넌트 플랫폼에서는 reload 자체가 부담이 될 수 있습니다. 다음 절에서 이 차이를 자세히 다룹니다.

동적 설정과 reload 차이

이 차이는 두 컨트롤러의 가장 본질적인 구분점이므로 별도로 깊이 살펴보겠습니다.

ingress-nginx의 reload 모델

ingress-nginx는 Ingress/Service/Endpoint 변경을 감지하면 다음 흐름으로 동작합니다.

[K8s API] --watch--> [ingress-nginx controller]

새 nginx.conf 생성(템플릿)

NGINX reload (nginx -s reload)

새 워커 프로세스가 새 설정 적용

NGINX의 reload는 graceful합니다. 기존 워커는 진행 중인 커넥션을 마무리하고 종료되며, 새 워커가 새 설정으로 트래픽을 받습니다. 하지만 reload가 매우 빈번하면 워커 프로세스가 계속 생성/소멸하며 메모리 사용량이 출렁이고, 장기 커넥션(웹소켓, gRPC 스트림)이 reload 시점에 영향을 받을 수 있습니다. 이를 완화하기 위해 ingress-nginx는 엔드포인트 변경만 있는 경우 Lua 기반으로 reload 없이 반영하는 최적화를 일부 도입했지만, Ingress 구조 자체가 바뀌면 여전히 reload가 필요합니다.

Traefik의 무중단 반영

Traefik은 동적 설정을 메모리 내 라우팅 테이블로 관리합니다. CRD나 Ingress가 바뀌면 새 라우팅 규칙을 원자적으로 교체할 뿐, 프로세스 reload나 워커 재생성이 없습니다.

[K8s API] --watch--> [Traefik provider]

동적 설정 갱신(메모리)

라우팅 테이블 원자적 스왑

(커넥션 영향 없음, reload 없음)

라우트가 초당 수십 번 바뀌는 환경, 예를 들어 함수 단위로 라우트가 생성/삭제되는 서버리스 플랫폼이나 대규모 멀티테넌트 SaaS에서는 이 무중단 특성이 결정적인 장점이 됩니다.

관측성

운영의 절반은 "지금 무슨 일이 일어나는지 보는 것"입니다.

Traefik의 내장 관측성

Traefik은 Prometheus 메트릭, 분산 트레이싱(OpenTelemetry), 액세스 로그, 그리고 웹 대시보드를 컨트롤러 자체에 내장하고 있습니다. 설정 한두 줄로 메트릭 엔드포인트와 대시보드를 켤 수 있습니다.

Traefik 정적 설정 일부

metrics:

prometheus:

addEntryPointsLabels: true

addServicesLabels: true

tracing:

otlp:

grpc:

endpoint: otel-collector:4317

api:

dashboard: true

대시보드에서 현재 등록된 라우터, 서비스, 미들웨어, 헬스 상태를 한눈에 볼 수 있어 "내 라우팅 규칙이 실제로 어떻게 반영됐는가"를 빠르게 확인할 수 있습니다. 단, 대시보드는 운영 환경에서 반드시 인증으로 보호해야 합니다.

ingress-nginx의 관측성

ingress-nginx도 Prometheus 메트릭을 제공하며, NGINX의 풍부한 로그 변수를 활용할 수 있습니다. 다만 트레이싱과 대시보드는 기본 내장이 아니라 별도 구성(예: 트레이싱 모듈 활성화, Grafana 대시보드 임포트)이 필요한 비중이 큽니다. 대신 NGINX 생태계의 성숙한 로깅/모니터링 자산을 그대로 활용할 수 있다는 점은 강점입니다. VirtualServer/Upstream 단위 메트릭, 응답 시간 히스토그램 등은 SRE가 익숙하게 다룰 수 있습니다.

생태계와 거버넌스

Gateway API와의 관계

2026년 현재 가장 중요한 맥락입니다. Kubernetes Ingress API는 동결되어 새 기능이 추가되지 않으며, Gateway API가 차세대 표준으로 자리 잡았습니다. Gateway API는 역할 기반 분리(Infrastructure Provider/Cluster Operator/Application Developer), 표현력 있는 라우팅, L4/L7 통합 모델을 제공합니다.

- **Traefik**: Gateway API를 프로바이더 형태로 지원하며, 자체 CRD(IngressRoute)와 병행해 사용할 수 있습니다. 클라우드 네이티브 표준을 적극 수용하는 방향입니다.

- **ingress-nginx**: 프로젝트가 유지보수 모드로 전환되면서, Kubernetes 진영의 Gateway API 기반 후속 프로젝트(예: NGINX Gateway Fabric 등 Gateway API 구현체)로의 이전 흐름이 형성되고 있습니다. 신규 도입이라면 Gateway API 기반 구현을 진지하게 검토할 때입니다.

즉, 장기적으로는 두 진영 모두 Gateway API로 수렴하고 있으며, 신규 프로젝트라면 컨트롤러 선택과 동시에 "Ingress냐 Gateway API냐"를 함께 고민해야 합니다.

유지보수 상태와 보안

ingress-nginx는 매우 널리 쓰였지만, 프로젝트 관리 리소스 부족과 유지보수 모드 전환, 그리고 설정 주입 경로와 관련된 심각한 보안 취약점(예: 2025년에 공개된 일련의 CVE) 이력이 있습니다. 이는 ingress-nginx가 나쁘다는 뜻이 아니라, 신규 도입 시 보안 운영 부담과 장기 로드맵을 반드시 평가해야 한다는 의미입니다. Traefik은 활발히 개발되는 상용 백킹(Traefik Labs)이 있는 프로젝트로, 기능 추가와 문서화가 꾸준합니다.

학습 곡선

| 관점 | ingress-nginx | Traefik |

| --- | --- | --- |

| 초기 진입 | 쉬움(Ingress 표준만 알면 됨) | 보통(CRD 개념 학습 필요) |

| 단순 라우팅 | 매우 빠름 | 빠름 |

| 복잡한 정책 | 어노테이션/스니펫 누적으로 가팔라짐 | Middleware로 완만하게 확장 |

| 트러블슈팅 | nginx.conf 디버깅 지식 필요 | 대시보드로 직관적 파악 |

| 표준 친화성 | Ingress 표준 그대로 | Ingress 또는 CRD 선택 |

ingress-nginx는 표준 Ingress만 알면 바로 시작할 수 있어 진입 장벽이 낮습니다. 그러나 요구사항이 복잡해질수록 어노테이션과 스니펫이 쌓이며 난이도가 가파르게 올라갑니다. Traefik은 초기에 CRD와 정적/동적 설정 개념을 배워야 해서 약간의 학습 비용이 있지만, 일단 익히면 복잡한 정책도 완만하게 확장됩니다.

동일 요구사항 구현 비교

이론은 충분합니다. 동일한 요구사항을 양쪽에서 어떻게 구현하는지 나란히 보겠습니다. 요구사항은 다음과 같습니다.

1. app.example.com 의 /api 경로를 api-svc로, 나머지를 web-svc로 라우팅

2. HTTP를 HTTPS로 강제 리다이렉트

3. /api 경로에 기본 인증(Basic Auth) 적용

4. 초당 요청 수 제한

ingress-nginx 구현

apiVersion: v1

kind: Secret

metadata:

type: Opaque

data:

htpasswd로 생성한 사용자/비밀번호 (base64)

auth: dXNlcjokYXByMSRleGFtcGxlaGFzaA==

apiVersion: networking.k8s.io/v1

kind: Ingress

metadata:

annotations:

nginx.ingress.kubernetes.io/ssl-redirect: 'true'

nginx.ingress.kubernetes.io/limit-rps: '20'

spec:

ingressClassName: nginx

tls:

- hosts:

- app.example.com

secretName: app-tls

rules:

- host: app.example.com

http:

paths:

- path: /api

pathType: Prefix

backend:

service:

port:

number: 80

- path: /

pathType: Prefix

backend:

service:

port:

number: 80

Basic Auth는 /api 경로만 적용해야 하므로, ingress-nginx에서는 인증이 필요한 경로를 별도 Ingress 객체로 분리하고 그 객체에만 인증 어노테이션을 붙이는 패턴이 일반적입니다.

apiVersion: networking.k8s.io/v1

kind: Ingress

metadata:

annotations:

nginx.ingress.kubernetes.io/auth-type: basic

nginx.ingress.kubernetes.io/auth-secret: api-basic-auth

nginx.ingress.kubernetes.io/auth-realm: 'Authentication Required'

nginx.ingress.kubernetes.io/ssl-redirect: 'true'

spec:

ingressClassName: nginx

rules:

- host: app.example.com

http:

paths:

- path: /api

pathType: Prefix

backend:

service:

port:

number: 80

정책이 경로마다 다르면 Ingress 객체를 쪼개야 하거나 어노테이션이 복잡해진다는 점을 알 수 있습니다.

Traefik 구현

apiVersion: v1

kind: Secret

metadata:

type: Opaque

data:

users: dXNlcjokYXByMSRleGFtcGxlaGFzaA==

apiVersion: traefik.io/v1alpha1

kind: Middleware

metadata:

spec:

basicAuth:

secret: api-basic-auth

apiVersion: traefik.io/v1alpha1

kind: Middleware

metadata:

spec:

rateLimit:

average: 20

burst: 40

apiVersion: traefik.io/v1alpha1

kind: Middleware

metadata:

spec:

redirectScheme:

scheme: https

permanent: true

이제 라우팅에서 미들웨어를 경로별로 조합합니다. HTTPS 리다이렉트는 HTTP EntryPoint(web)에서, 인증과 레이트 리밋은 경로별로 적용합니다.

apiVersion: traefik.io/v1alpha1

kind: IngressRoute

metadata:

spec:

entryPoints:

- websecure

routes:

- match: Host(`app.example.com`) && PathPrefix(`/api`)

kind: Rule

middlewares:

- name: api-auth

- name: ratelimit

services:

- name: api-svc

port: 80

- match: Host(`app.example.com`)

kind: Rule

middlewares:

- name: ratelimit

services:

- name: web-svc

port: 80

tls:

certResolver: letsencrypt

차이가 분명합니다. Traefik에서는 정책(인증, 레이트 리밋, 리다이렉트)이 재사용 가능한 객체로 분리되어 있고, 라우트에서 필요한 정책을 조합해 붙입니다. 경로별로 다른 정책을 적용해도 Ingress 객체를 쪼갤 필요가 없습니다. 반면 ingress-nginx는 단순 케이스에서 더 간결하지만, 경로별 정책 분기가 늘어날수록 객체 분리와 어노테이션 누적이 불가피합니다.

운영과 튜닝

ingress-nginx 운영 포인트

- **worker-processes / worker-connections**: ConfigMap으로 NGINX 워커 설정을 조정합니다. 노드 자원에 맞춰 워커 수를 튜닝합니다.

- **proxy 버퍼/타임아웃**: 대용량 업로드나 느린 백엔드 대응을 위해 proxy-body-size, proxy-read-timeout 등을 조정합니다.

- **reload 빈도 관리**: 배포가 잦다면 엔드포인트 변경이 Lua 경로로 처리되는지 확인하고, 불필요한 Ingress 변경을 줄입니다.

- **keepalive**: 업스트림 keepalive를 조정해 커넥션 재사용을 높입니다.

apiVersion: v1

kind: ConfigMap

metadata:

data:

worker-processes: 'auto'

max-worker-connections: '16384'

proxy-body-size: '100m'

upstream-keepalive-connections: '320'

use-gzip: 'true'

Traefik 운영 포인트

- **EntryPoint 튜닝**: 타임아웃(readTimeout, writeTimeout, idleTimeout)을 EntryPoint 수준에서 설정합니다.

- **레플리카와 ACME**: 내장 ACME를 쓰면서 스케일아웃하려면 인증서 스토리지 공유 전략이 필요합니다. HA에서는 cert-manager나 외부 발급을 검토합니다.

- **프로바이더 throttle**: 설정 변경 폭주 시 providersThrottleDuration으로 갱신을 묶어 처리합니다.

- **대시보드 보안**: 운영 환경에서는 대시보드를 인증/네트워크 정책으로 반드시 보호합니다.

Traefik 정적 설정 일부

entryPoints:

websecure:

address: ':443'

transport:

respondingTimeouts:

readTimeout: 60s

writeTimeout: 60s

idleTimeout: 180s

providers:

kubernetesCRD:

allowCrossNamespace: false

providersThrottleDuration: 2s

함정과 트러블슈팅

운영하면서 실제로 마주친 함정들을 정리합니다.

ingress-nginx에서 자주 만나는 함정

- **스니펫 주입 비활성화**: 보안 강화로 `allow-snippet-annotations`가 기본 비활성화되는 추세입니다. 스니펫에 의존하던 설정이 갑자기 무시되어 장애로 이어질 수 있습니다. 업그레이드 시 반드시 확인합니다.

- **rewrite-target과 정규식**: rewrite-target과 경로 캡처 그룹 조합은 자주 실수를 유발합니다. pathType과 정규식 동작을 정확히 이해해야 합니다.

- **reload 폭주**: 대규모 환경에서 잦은 배포가 reload를 유발해 메모리가 출렁이고 장기 커넥션이 끊길 수 있습니다.

- **CVE 대응**: 보안 패치 릴리스를 빠르게 따라가야 합니다. 유지보수 모드 상황에서 패치 주기를 운영 정책에 반영해야 합니다.

Traefik에서 자주 만나는 함정

- **CRD 버전 불일치**: traefik.io API 버전과 차트 버전이 어긋나면 IngressRoute가 무시됩니다. CRD 설치 버전을 항상 차트와 맞춥니다.

- **ACME 스토리지 경합**: 멀티 레플리카에서 acme.json을 공유하면 발급 경합이 발생합니다. HA에서는 별도 인증서 전략이 안전합니다.

- **크로스 네임스페이스 참조**: 미들웨어를 다른 네임스페이스에서 참조하려면 명시적 허용 설정이 필요합니다. 기본은 차단입니다.

- **대시보드 노출**: 대시보드를 무인증으로 외부에 노출하는 사고가 흔합니다. 반드시 보호합니다.

공통 디버깅 흐름

컨트롤러 로그 확인

kubectl logs -n ingress-nginx deploy/ingress-nginx-controller

kubectl logs -n traefik deploy/traefik

실제 적용된 설정 확인 (ingress-nginx)

kubectl exec -n ingress-nginx deploy/ingress-nginx-controller -- cat /etc/nginx/nginx.conf

라우트 상태 확인 (Traefik 대시보드 또는 API)

kubectl port-forward -n traefik deploy/traefik 8080:8080

인그레스 리소스와 이벤트 확인

kubectl describe ingress example-ingress

kubectl get events --sort-by=.lastTimestamp

마이그레이션 고려사항

한쪽에서 다른 쪽으로 옮길 때 고려할 점입니다.

- **어노테이션 vs CRD 매핑**: ingress-nginx 어노테이션을 Traefik Middleware로 일대일 매핑하기 어려운 경우가 있습니다. rewrite, auth, rate-limit 등 정책을 미들웨어로 재설계해야 합니다.

- **IngressClass 분리 운영**: 두 컨트롤러를 동시에 띄우고 IngressClass로 트래픽을 점진적으로 이전하면 무중단 마이그레이션이 가능합니다.

- **TLS 인프라 재사용**: cert-manager를 쓰고 있었다면 Traefik에서도 cert-manager가 만든 Secret을 그대로 참조하도록 구성하면 인증서 재발급 없이 옮길 수 있습니다.

- **Gateway API 동시 검토**: 마이그레이션을 한다면, 이 기회에 Ingress 대신 Gateway API로 직행하는 선택지도 함께 평가하는 것이 장기적으로 유리합니다.

의사결정 테이블

| 상황/요구사항 | 추천 |

| --- | --- |

| 표준 Ingress만으로 단순 라우팅 | ingress-nginx 또는 Gateway API 구현체 |

| 경로별로 복잡하고 재사용 가능한 정책이 많음 | Traefik(Middleware) |

| 무중단 동적 라우팅이 빈번(서버리스/멀티테넌트) | Traefik |

| 내장 자동 TLS와 대시보드를 원함 | Traefik |

| HA 와일드카드/DNS-01/사내 PKI 인증서 | ingress-nginx + cert-manager |

| NGINX 운영 경험이 풍부한 팀 | ingress-nginx |

| 신규 그린필드 프로젝트(장기 표준 지향) | Gateway API 우선 검토 |

| 보안 운영 부담 최소화가 최우선 | 유지보수 활발한 옵션(Traefik/Gateway 구현체) |

마치며

처음으로 돌아가 보겠습니다. "Traefik과 ingress-nginx 중 무엇이 더 좋은가"라는 질문에는 정답이 없습니다. 두 컨트롤러는 같은 문제를 다른 철학으로 풉니다.

시나리오별로 정리하면 다음과 같습니다.

- **NGINX에 익숙하고 단순한 라우팅이 주력인 팀**이라면 ingress-nginx가 여전히 빠르고 익숙한 선택입니다. 단, 유지보수 모드와 보안 패치 부담을 운영 정책에 반영해야 합니다.

- **경로별로 정교한 정책, 무중단 동적 라우팅, 내장 TLS/관측성**이 필요하다면 Traefik이 더 자연스럽게 맞습니다. CRD 학습 비용을 한 번 지불하면 복잡도를 완만하게 다룰 수 있습니다.

- **HA 인증서 관리, 와일드카드, 사내 PKI**가 핵심이라면 어느 컨트롤러를 쓰든 cert-manager를 인증서 계층으로 두는 구성이 안정적입니다.

- **2026년에 새로 시작하는 그린필드 프로젝트**라면, Ingress API가 동결되었다는 사실을 직시하고 Gateway API 기반 구현을 1순위로 검토하시길 권합니다. Traefik은 Gateway API를 지원하고, ingress-nginx 진영도 Gateway API 구현체로 이동하고 있습니다.

결국 핵심은 "우리 팀의 운영 모델, 요구사항의 복잡도, 그리고 장기 표준 전략"의 교차점에서 선택하는 것입니다. 컨트롤러는 도구일 뿐이고, 좋은 선택은 도구의 우열이 아니라 맥락과의 적합성에서 나옵니다.

참고 자료

- [Kubernetes Ingress 공식 문서](https://kubernetes.io/docs/concepts/services-networking/ingress/)

- [Kubernetes Ingress Controllers 개요](https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/)

- [ingress-nginx 공식 문서](https://kubernetes.github.io/ingress-nginx/)

- [ingress-nginx 어노테이션 레퍼런스](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/)

- [Traefik Proxy 공식 문서](https://doc.traefik.io/traefik/)

- [Traefik Kubernetes IngressRoute 프로바이더](https://doc.traefik.io/traefik/providers/kubernetes-crd/)

- [Gateway API 공식 문서](https://gateway-api.sigs.k8s.io/)

- [cert-manager 공식 문서](https://cert-manager.io/docs/)

- [Helm 공식 문서](https://helm.sh/docs/)

- [Let's Encrypt 공식 문서](https://letsencrypt.org/docs/)