[쿠버네티스 DevOps 구축] - Ingress NGINX 대신 Traefik 적용하기

2026-04-22

Ingress Nginx 의 서비스 종료

2025년 11월 11일자 기준으로 쿠버네티스 공식문서에 Ingress Nginx 에 대한 서비스 지원 종료 관련 공지가 올라왔습니다.

때문에, Ingress Nginx 를 다른 서비스로 교체를

이번 전환의 목적은 단순히 Ingress Controller를 교체하는 것보다, 라우팅 설정을 조금 더 선언적으로 관리하고 HTTPS 리다이렉션, Middleware, 대시보드, CRD 기반 라우팅을 한 곳에서 정리하는 데 있었다.

Ingress NGINX도 충분히 많이 쓰이는 안정적인 선택지지만, 실제 운영에서 다음과 같은 요구가 생기면 Traefik이 더 편하게 느껴질 수 있다.

Ingress annotation보다 더 명확한 라우팅 구성이 필요할 때
경로 재작성, 인증, 리다이렉트 같은 기능을 재사용 가능한 단위로 관리하고 싶을 때
표준 Ingress와 전용 CRD 방식을 함께 쓰고 싶을 때
Kubernetes 외에도 Docker, Swarm, Nomad 같은 여러 provider와 비슷한 방식으로 운영하고 싶을 때

Traefik 이란

Traefik은 리버스 프록시이면서 로드 밸런서이고, Kubernetes에서는 Ingress Controller 또는 Gateway 역할로 사용할 수 있는 오픈소스 프록시다.

공식 문서 기준으로 Traefik은 Kubernetes에서 크게 두 가지 방식으로 사용할 수 있다.

Kubernetes Ingress provider
Traefik 전용 CRD provider (IngressRoute, Middleware 등)

즉, 가장 단순하게는 기존 Ingress 리소스를 그대로 받아 라우팅할 수 있고, 더 많은 기능이 필요하면 Traefik CRD를 이용해 라우팅을 더 세밀하게 제어할 수 있다.

Traefik 의 핵심 개념

Traefik을 처음 볼 때는 용어만 정리해도 이해가 빨라진다.

EntryPoint: Traefik이 외부 요청을 받는 진입 포인트다. 보통 web(80), websecure(443)를 사용한다.
Router: 어떤 요청을 어떤 규칙으로 받을지 결정한다. 예를 들어 Host, PathPrefix 조건이 여기에 들어간다.
Middleware: 요청과 응답을 가공하는 단계다. redirect, stripPrefix, basicAuth 같은 기능을 붙일 수 있다.
Service: 실제 트래픽을 전달할 백엔드다. Kubernetes에서는 보통 Service 리소스를 가리킨다.
Provider: Traefik이 설정을 어디서 읽을지 결정한다. Kubernetes Ingress, Kubernetes CRD, Docker 등이 provider가 된다.

Ingress NGINX에 익숙하다면 다음처럼 이해하면 된다.

Ingress 규칙 = Traefik의 Router 역할
annotation = Traefik의 Middleware 또는 추가 설정
backend service = Traefik의 Service

차이는 Traefik이 이 개념을 더 분리해서 보여 준다는 점이다.

Kubernetes 에서 Traefik 을 사용하는 방식

Kubernetes에서 Traefik은 보통 아래 두 방식 중 하나로 사용한다.

1. 표준 Ingress 사용

기존 Kubernetes Ingress 리소스를 그대로 사용하는 방식이다.

기존 구조에서 가장 쉽게 도입할 수 있다.
Ingress NGINX에서 넘어올 때 진입 장벽이 낮다.
다만 복잡한 기능은 annotation이나 별도 설정이 늘어날 수 있다.

2. Traefik CRD 사용

IngressRoute, Middleware, TLSOption, TraefikService 같은 CRD를 사용하는 방식이다.

라우팅 구성이 더 명확하다.
Middleware를 리소스로 재사용할 수 있다.
annotation 의존도가 줄어든다.
Traefik의 장점은 이 방식에서 더 잘 드러난다.

실무에서는 처음에는 Ingress로 시작하고, 복잡한 라우팅이 필요한 서비스부터 IngressRoute로 옮기는 방식도 충분히 괜찮다.

Helm 으로 Traefik 설치하기

공식 문서에서는 Helm chart를 이용한 설치를 기본 경로로 안내한다.

helm repo add traefik https://traefik.github.io/charts
helm repo update

kubectl create namespace traefik

helm upgrade --install traefik traefik/traefik \
  --namespace traefik

기본 chart만 설치해도 web, websecure entryPoint와 Traefik Service가 함께 구성된다.

조금 더 운영 친화적으로 쓰려면 values.yaml을 분리하는 것이 낫다.

values.yaml 예제

아래 예시는 가장 많이 필요한 항목만 넣은 간단한 설정이다.

HTTP 80 포트
HTTPS 443 포트
HTTP -> HTTPS 리다이렉트
Dashboard 활성화
Kubernetes Ingress / CRD provider 활성화

providers:
  kubernetesIngress:
    enabled: true
  kubernetesCRD:
    enabled: true

ports:
  web:
    port: 80
    redirections:
      entryPoint:
        to: websecure
        scheme: https
  websecure:
    port: 443
    tls:
      enabled: true

api:
  dashboard: true

적용은 다음처럼 하면 된다.

helm upgrade --install traefik traefik/traefik \
  --namespace traefik \
  --values values.yaml

운영 환경에서는 여기서 추가로 아래 항목들을 같이 보게 된다.

service.type: LoadBalancer 또는 NodePort
ingressClass
dashboard 노출 여부
ACME 또는 cert-manager 기반 TLS
Prometheus metrics, access log, tracing

가장 단순한 사용법: Ingress 로 서비스 노출하기

Traefik을 Ingress Controller로만 사용할 생각이라면 기존 Ingress 리소스를 거의 그대로 쓸 수 있다.

먼저 테스트용 애플리케이션을 하나 올린다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: whoami
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: whoami
  template:
    metadata:
      labels:
        app: whoami
    spec:
      containers:
        - name: whoami
          image: traefik/whoami
          ports:
            - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: whoami
  namespace: default
spec:
  selector:
    app: whoami
  ports:
    - port: 80
      targetPort: 80

그 다음 Ingress를 적용한다.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: whoami-ingress
  namespace: default
spec:
  ingressClassName: traefik
  rules:
    - host: whoami.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: whoami
                port:
                  number: 80

이 방식의 장점은 분명하다.

기존 Ingress 중심 운영 방식과 유사하다.
Ingress NGINX에서 넘어올 때 이해하기 쉽다.
간단한 서비스 공개에는 충분하다.

다만 Traefik의 진짜 강점은 CRD를 사용할 때 더 잘 보인다.

Traefik 답게 사용하기: IngressRoute 와 Middleware

Traefik CRD를 사용하면 annotation 대신 리소스 단위로 설정을 분리할 수 있다.

예를 들어 /api 경로를 백엔드 서비스로 보내되, 실제 백엔드에는 /api를 제거해서 보내고 싶다고 해 보자.

Ingress NGINX에서는 annotation으로 처리하는 경우가 많지만, Traefik에서는 Middleware를 따로 만들고 Route에 연결하면 된다.

Middleware 예제

apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
  name: api-strip-prefix
  namespace: default
spec:
  stripPrefix:
    prefixes:
      - /api

IngressRoute 예제

apiVersion: traefik.io/v1alpha1
kind: IngressRoute
metadata:
  name: whoami-route
  namespace: default
spec:
  entryPoints:
    - websecure
  routes:
    - match: Host(`whoami.example.com`) && PathPrefix(`/api`)
      kind: Rule
      middlewares:
        - name: api-strip-prefix
      services:
        - name: whoami
          port: 80

이 구성을 적용하면 외부에서는 다음처럼 호출할 수 있다.

https://whoami.example.com/api
https://whoami.example.com/api/hello

하지만 백엔드 서비스는 실제로 다음 경로로 요청을 받게 된다.

/
/hello

이 방식이 좋은 이유는 라우팅과 가공 규칙이 분리된다는 점이다.

Route는 어떤 요청을 받을지에 집중한다.
Middleware는 요청을 어떻게 바꿀지에 집중한다.
같은 Middleware를 여러 Route에서 재사용할 수 있다.

HTTPS 리다이렉트 예제

실무에서는 거의 항상 HTTP에서 HTTPS로 리다이렉트가 필요하다.

이 부분은 애플리케이션 단이 아니라 EntryPoint 수준에서 처리하면 관리가 더 편하다.

위의 values.yaml에서 이미 설정한 부분이 바로 이 기능이다.

ports:
  web:
    port: 80
    redirections:
      entryPoint:
        to: websecure
        scheme: https

이렇게 두면 서비스별로 redirect 설정을 반복하지 않아도 된다.

Traefik 을 적용하면서 느낀 점

Ingress NGINX는 Kubernetes Ingress를 가장 정석적으로 다루는 데 익숙한 도구이고, annotation 중심 운영에 익숙하다면 여전히 좋은 선택이다.

반면 Traefik은 다음 상황에서 체감 장점이 컸다.

Ingress 설정이 점점 복잡해질 때
path rewrite, redirect, auth 규칙이 많아질 때
annotation이 많아져서 가독성이 떨어질 때
서비스별로 라우팅 규칙을 재사용 가능한 단위로 나누고 싶을 때

특히 Middleware와 IngressRoute는 “설정을 선언적으로 분리해서 관리한다”는 느낌이 강했다. Ingress 하나에 모든 옵션을 밀어 넣는 방식보다 읽기 쉬웠다.

운영 시 같이 보면 좋은 항목

Traefik을 실제 운영에 적용할 때는 아래 항목도 같이 보는 편이 좋다.

ingressClass를 명확히 지정해서 다른 Ingress Controller와 충돌하지 않게 하기
dashboard를 외부에 열 경우 반드시 인증을 붙이기
TLS는 cert-manager 또는 ACME 정책과 함께 정리하기
access log, metrics, tracing 활성화 여부 검토하기
Ingress만 쓸지 IngressRoute까지 쓸지 팀 표준을 정하기

특히 한 클러스터에 여러 Ingress Controller가 공존하는 경우라면 ingressClassName과 provider 설정을 먼저 명확히 정리하는 것이 중요하다.

정리

Traefik은 Kubernetes에서 사용할 수 있는 또 하나의 Ingress Controller이지만, 단순히 “Ingress를 처리하는 프록시”에 그치지 않고 EntryPoint, Router, Middleware, Service를 분리해서 다룬다는 점이 특징이다.

정리하면 다음과 같다.

기존 Ingress 방식도 지원하므로 도입 장벽이 낮다.
Traefik CRD를 쓰면 annotation보다 더 읽기 쉬운 구성이 가능하다.
HTTPS 리다이렉트, prefix 제거, 인증 같은 기능을 Middleware로 재사용할 수 있다.
Kubernetes에서 라우팅 정책이 복잡해질수록 장점이 커진다.

Ingress NGINX에서 Traefik으로 넘어가야 하는 상황이라면, 처음에는 표준 Ingress로 옮기고 이후 복잡한 서비스부터 IngressRoute와 Middleware로 분리하는 방식이 현실적이다.

딴짓하는 개발자

Kubernetes