쿠버네티스 Ingress Controller, 뭘 써야 할지 모르겠다면?

쿠버네티스(Kubernetes)를 처음 도입할 때 가장 많이 막히는 부분 중 하나가 바로 Ingress Controller(인그레스 컨트롤러) 선택이에요. 저도 처음엔 “Nginx 쓰면 되는 거 아닌가?” 하고 무심코 설치했다가, 나중에 Traefik이 더 편하다는 걸 알고 갈아엎은 경험이 있거든요. 그리고 최근엔 Gateway API라는 새로운 표준까지 등장해서 선택지가 더 복잡해졌습니다.

이 글에서는 쿠버네티스 클러스터 운영에서 가장 중요한 선택 중 하나인 Ingress Controller의 세 가지 주요 선택지를 실제 운영 경험을 바탕으로 비교해 드릴게요. 홈랩부터 프로덕션까지 다양한 환경에서 직접 써본 입장에서 솔직하게 이야기해 보겠습니다.

▲ 쿠버네티스 클러스터에서 외부 트래픽이 Ingress Controller를 거쳐 내부 서비스로 전달되는 전체 흐름 다이어그램

Ingress Controller가 뭔지부터 짚고 가자

쉽게 말해서, Ingress(인그레스)는 외부에서 쿠버네티스 클러스터 안으로 들어오는 HTTP/HTTPS 트래픽을 어떻게 라우팅할지 정의하는 규칙이에요. 근데 이 규칙만 있다고 실제로 동작하는 게 아니에요. 규칙을 실제로 실행해 주는 주체가 바로 Ingress Controller(인그레스 컨트롤러)입니다.

비유하자면, Ingress 리소스는 “1번 도메인은 A 서비스로, 2번 도메인은 B 서비스로 보내라”는 지시서고, Ingress Controller는 그 지시서를 읽고 실제로 트래픽을 처리하는 리버스 프록시(Reverse Proxy) 서버라고 보시면 됩니다.

쿠버네티스 자체에는 Ingress Controller가 기본 내장되어 있지 않아요. 그래서 우리가 직접 선택해서 설치해야 합니다. 그리고 이 선택이 생각보다 중요한 결정이거든요.

왜 선택이 중요한가요?

• 운영 중에 교체하면 서비스 중단이 발생할 수 있어요
• 각 컨트롤러마다 지원하는 기능과 설정 방식이 달라요
• 팀의 기술 스택과 러닝 커브도 고려해야 합니다
• 트래픽 규모와 패턴에 따라 성능 특성이 다르게 나타나요

세 가지 선택지 한눈에 비교

본격적인 비교 전에 전체 그림을 먼저 보시죠.

Nginx Ingress Controller — 검증된 베테랑

솔직히 말씀드리면, 저도 처음 쿠버네티스 클러스터 구성할 때 고민 없이 Nginx Ingress를 선택했어요. 이유는 단순했습니다. Nginx를 이미 10년 넘게 써왔으니까요.

Nginx Ingress Controller는 CNCF(Cloud Native Computing Foundation) 산하 프로젝트인 kubernetes/ingress-nginx와, Nginx Inc.에서 만든 nginxinc/kubernetes-ingress 두 가지가 있어요. 헷갈리시는 분들이 많은데, 커뮤니티에서 주로 쓰는 건 전자인 ingress-nginx입니다.

Helm으로 설치하기

# Nginx Ingress Controller Helm 설치
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update

helm install ingress-nginx ingress-nginx/ingress-nginx \
  --namespace ingress-nginx \
  --create-namespace \
  --set controller.replicaCount=2

기본 Ingress 리소스 예시

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
spec:
  ingressClassName: nginx
  tls:
  - hosts:
    - myapp.example.com
    secretName: myapp-tls
  rules:
  - host: myapp.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-app-service
            port:
              number: 80

Nginx Ingress의 장단점

✅ 장점

• 레퍼런스가 압도적으로 많아요. 구글에서 뭐든 찾을 수 있습니다
• Nginx에 익숙한 분들은 Annotation으로 세밀한 튜닝이 가능해요
• 안정성이 검증된 오랜 역사를 가지고 있습니다
• 대규모 트래픽 처리에 강점이 있어요

⚠️ 단점

• 설정 변경 시 nginx.conf를 reload해야 해서, 대규모 클러스터에선 부담이 될 수 있어요
• Annotation이 너무 많아서 처음엔 뭘 써야 할지 헷갈립니다
• 내장 대시보드가 없어서 별도로 Prometheus + Grafana를 구성해야 해요

Traefik — 쿠버네티스 네이티브의 매력

Traefik을 처음 접한 건 홈랩에서 Docker Compose로 운영하다가였어요. 당시에 “이거 레이블(Label) 하나 달면 자동으로 라우팅이 된다고?” 하면서 신기해했던 기억이 납니다. 쿠버네티스에서도 비슷한 경험을 할 수 있어요.

Traefik의 핵심 철학은 동적 설정(Dynamic Configuration)이에요. 새로운 서비스가 배포되면 자동으로 감지해서 라우팅 규칙을 업데이트합니다. Nginx처럼 reload가 없어요.

Traefik Helm 설치

# Traefik Helm 설치
helm repo add traefik https://helm.traefik.io/traefik
helm repo update

helm install traefik traefik/traefik \
  --namespace traefik \
  --create-namespace \
  --set dashboard.enabled=true \
  --set ingressRoute.dashboard.enabled=true

Traefik IngressRoute CRD 예시

Traefik은 표준 Ingress 리소스도 지원하지만, 자체 CRD인 IngressRoute를 쓰면 훨씬 풍부한 기능을 쓸 수 있어요.

apiVersion: traefik.io/v1alpha1
kind: IngressRoute
metadata:
  name: my-app-ingressroute
  namespace: default
spec:
  entryPoints:
    - websecure
  routes:
    - match: Host(`myapp.example.com`)
      kind: Rule
      services:
        - name: my-app-service
          port: 80
      middlewares:
        - name: my-ratelimit
  tls:
    certResolver: letsencrypt

Middleware로 Rate Limiting 적용

apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
  name: my-ratelimit
spec:
  rateLimit:
    average: 100
    burst: 50

💡 Traefik의 진짜 강점은 Let’s Encrypt 인증서 자동 발급이 내장되어 있다는 거예요. cert-manager를 별도로 설치하지 않아도 TLS 인증서를 자동으로 관리해 줍니다. 홈랩에서 이거 하나 때문에 Traefik으로 갈아탔을 정도로 편하더라고요.

▲ Traefik 내장 대시보드에서 라우터, 서비스, 미들웨어 현황을 한눈에 확인할 수 있는 화면

Traefik의 장단점

✅ 장점

• 동적 설정 갱신 — 서비스 변경 시 reload 없이 즉시 반영돼요
• 내장 대시보드로 라우팅 현황을 바로 확인할 수 있어요
• Let’s Encrypt 자동 인증서 발급/갱신 내장
• Middleware로 인증, Rate Limiting, 헤더 조작 등을 깔끔하게 구성 가능

⚠️ 단점

• CRD 방식이 Nginx Annotation과 달라서 러닝 커브가 있어요
• Nginx에 비해 레퍼런스가 적습니다 (그래도 요즘은 많이 늘었어요)
• 초대형 클러스터에서의 성능 검증 사례가 Nginx보다 적은 편이에요

Gateway API — 쿠버네티스 네트워크의 미래

처음 Gateway API 문서를 읽었을 때 솔직히 “이게 뭐가 다른 건데?” 싶었어요. 근데 알고 보니 기존 Ingress 리소스의 한계를 근본적으로 해결하려는 시도더라고요.

Gateway API는 SIG Network(쿠버네티스 네트워킹 특별관심그룹)에서 만든 공식 표준이에요. 2023년에 v1.0으로 GA(Generally Available, 정식 출시)를 달성했습니다. Ingress 리소스를 대체하려는 게 아니라, 더 표현력 있고 역할 기반으로 분리된 네트워크 설정을 가능하게 하는 게 목표예요.

Gateway API의 핵심 개념

기존 Ingress는 개발자와 인프라 관리자가 같은 리소스를 수정해야 했어요. Gateway API는 역할을 명확히 분리합니다.

• GatewayClass: 인프라 제공자가 정의 (“이 구현체를 쓸게”)
• Gateway: 클러스터 운영자가 정의 (“이 포트, 이 프로토콜로 받을게”)
• HTTPRoute: 개발자가 정의 (“이 경로는 내 서비스로 보내줘”)

Gateway API 설치 (CRD 먼저)

# Gateway API CRD 설치
kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.1.0/standard-install.yaml

# 구현체 예시: Nginx Gateway Fabric
helm install ngf oci://ghcr.io/nginxinc/charts/nginx-gateway-fabric \
  --namespace nginx-gateway \
  --create-namespace

Gateway와 HTTPRoute 설정 예시

# Gateway 리소스 (운영자가 관리)
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: main-gateway
  namespace: infra
spec:
  gatewayClassName: nginx
  listeners:
  - name: https
    port: 443
    protocol: HTTPS
    tls:
      mode: Terminate
      certificateRefs:
      - name: main-tls-cert
    allowedRoutes:
      namespaces:
        from: Selector
        selector:
          matchLabels:
            gateway-access: allowed

# HTTPRoute 리소스 (개발자가 관리)
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: my-app-route
  namespace: my-app-ns
spec:
  parentRefs:
  - name: main-gateway
    namespace: infra
  hostnames:
  - myapp.example.com
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /api
    backendRefs:
    - name: api-service
      port: 8080
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: frontend-service
      port: 3000

보이시나요? Gateway는 인프라팀이 관리하고, HTTPRoute는 각 개발팀이 자기 네임스페이스에서 독립적으로 관리할 수 있어요. 멀티 팀 환경에서 진짜 강력한 구조입니다.

Gateway API의 장단점

✅ 장점

• 역할 기반 분리로 멀티 팀 환경에 최적화되어 있어요
• 표현력이 풍부해서 복잡한 라우팅 규칙도 명확하게 표현 가능
• 쿠버네티스 공식 표준이라 장기적으로 생태계 지원이 확대될 거예요
• 구현체를 교체해도 HTTPRoute 설정은 그대로 재사용 가능 (이식성)

⚠️ 단점

• 개념이 많아서 처음 배우기가 쉽지 않아요. 저도 꽤 헷갈렸습니다
• 구현체마다 지원하는 기능이 달라서 사전 확인이 필요해요
• 소규모 팀이나 단순한 환경에선 오버엔지니어링이 될 수 있어요
• 레퍼런스와 사례가 아직 Nginx/Traefik에 비해 적습니다

⚠️ 실제 트러블슈팅 경험담

각 컨트롤러를 쓰면서 제가 직접 겪은 문제들을 공유할게요.

Nginx Ingress — 413 Request Entity Too Large

파일 업로드 기능이 있는 서비스에서 자꾸 413 에러가 났었어요. Nginx 기본 설정의 client_max_body_size 제한 때문이었는데, Annotation으로 해결했습니다.

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

Traefik — 인증서가 갱신 안 되는 문제

Let’s Encrypt 인증서를 Traefik이 자동으로 갱신해 주는 게 편한데, 어느 날 갑자기 인증서 만료 알림이 왔어요. 알고 보니 acme.json 파일이 저장된 PersistentVolume이 Pod 재시작 시 초기화되는 문제였습니다. acme.json은 반드시 영구 스토리지에 마운트해야 해요.

# values.yaml에서 persistence 설정
persistence:
  enabled: true
  storageClass: "longhorn"
  size: 128Mi

Gateway API — 구현체 호환성 확인 필수

HTTPRoute의 고급 기능(예: RequestRedirect, URLRewrite)을 사용했는데, 특정 구현체에서 지원하지 않아서 라우팅이 묵묵히 실패하는 경우가 있었어요. 구현체의 Conformance Report(적합성 보고서)를 미리 확인하는 게 중요합니다. Gateway API 공식 문서에서 구현체별 지원 기능표를 제공하고 있어요.

▲ Prometheus와 Grafana를 활용한 Ingress Controller 모니터링 대시보드 — 요청 수, 에러율, 레이턴시를 실시간으로 확인

상황별 선택 가이드

“그래서 뭘 써야 하나요?” 라고 물어보신다면, 상황에 따라 다르다고 답할 수밖에 없어요. 하지만 경험상 이런 기준으로 선택하시면 크게 후회는 없더라고요.

Nginx Ingress Controller를 선택하세요, 만약…

• 팀에 Nginx 경험자가 있고, 레퍼런스가 많은 안정적인 선택을 원할 때
• 대규모 트래픽을 처리해야 하고 검증된 성능이 필요할 때
• 기존 Nginx 설정을 쿠버네티스로 마이그레이션할 때
• 복잡한 Nginx 설정(custom snippet 등)이 필요할 때

Traefik을 선택하세요, 만약…

• 홈랩이나 소규모 환경에서 편리하게 운영하고 싶을 때
• Let’s Encrypt 자동 인증서 관리를 간단하게 하고 싶을 때
• 내장 대시보드로 라우팅 현황을 빠르게 파악하고 싶을 때
• 동적 환경에서 서비스 변경이 잦을 때

Gateway API를 선택하세요, 만약…

• 여러 팀이 각자의 라우팅 설정을 독립적으로 관리해야 할 때
• 장기적으로 쿠버네티스 표준에 맞춰 가고 싶을 때
• 복잡한 트래픽 분산(카나리 배포, A/B 테스트 등)이 필요할 때
• 구현체 이식성을 확보하고 싶을 때

▲ 환경과 요구사항에 따른 Ingress Controller 선택 가이드 요약 인포그래픽

마무리 — 정답은 없지만, 기준은 있다

13년 동안 인프라를 운영하면서 느낀 건, 기술 선택에 절대적인 정답은 없다는 거예요. 중요한 건 내 환경과 팀의 요구사항에 맞는 선택을 하는 겁니다.

개인적으로는 이렇게 정리하고 싶어요.

• 처음 시작하는 분들: Nginx Ingress로 시작하세요. 레퍼런스가 많아서 막힐 때 찾기 쉬워요
• 홈랩이나 소규모 팀: Traefik을 강력 추천합니다. 편의성이 정말 좋아요
• 엔터프라이즈/멀티 팀 환경: Gateway API를 진지하게 검토해 보세요. 미래 방향성이 여기 있거든요

그리고 하나 더 — 저는 지금 홈랩에서 Traefik을 쓰고, 회사 프로덕션에서는 Nginx Ingress를 씁니다. 두 개 다 쓸 줄 알면 더 좋아요. 😄

다음 글에서는 Traefik의 Middleware를 활용한 인증/인가(Authentication/Authorization) 설정을 더 자세히 다룰 예정이에요. cert-manager를 이용한 TLS 자동화 내용도 이전 글에서 다룬 적 있으니 참고해 보세요.

자주 묻는 질문 (FAQ)

Q. Nginx Ingress Controller와 Nginx Gateway Fabric은 다른 건가요?

네, 다릅니다. ingress-nginx는 기존 Ingress API 기반이고, Nginx Gateway Fabric은 Gateway API 표준의 구현체예요. 용도와 설정 방식이 다릅니다.

Q. 하나의 클러스터에 여러 Ingress Controller를 동시에 쓸 수 있나요?

가능합니다. ingressClassName을 통해 어떤 컨트롤러를 사용할지 지정할 수 있어요. 다만 운영 복잡도가 올라가니 꼭 필요한 경우에만 권장합니다.

Q. Gateway API는 Ingress를 완전히 대체하나요?

장기적으로는 그 방향이지만, 현재는 공존하는 상태예요. 기존 Ingress 리소스가 deprecated되지는 않았고, Gateway API가 더 복잡한 요구사항을 위한 차세대 표준으로 자리잡고 있는 중입니다.