잘 쓰던 Nginx Ingress Controller에서 Gateway로 마이그레이션(Istio)

빼빼로데이에 빼빼로대신 이런 걸 받았다.

https://kubernetes.io/blog/2025/11/11/ingress-nginx-retirement/

Ingress NGINX Retirement: What You Need to Know

 

요약하자면, Ingress Nginx에 대한 지원이 26년 3월까지고 + Gateway API를 추천하는 글이였다.

Nginx Ingress Controller를 야무지게 잘 쓰고 있었는데,,,설치한지 5개월밖에 안됐는데,,또 갈아치워야 한다더라..

 

울며 겨자먹기로 Gateway API 구현체들을 찾아보던 도중, 최근에 들은 친구가 눈에 띄었다. 바로..

Istio

왜 익숙하냐하면, 불과 저번 주에 들은 2025 당근마켓 컨퍼런스에서 Istio를 활용하여 프록시 패턴으로 인증 등을 구현한 발표를 들었기 때문이다. 부끄럽게도, 그때는 Nginx Ingress Controller만 알고 있던 나로써 저걸 왜쓰지? 라는 생각이 들었었다. 하지만..당근은 계획이 있더라..

 

+ 게다가 출시된지 8년된 제품이라니..전혀몰랐다..

Gateway VS Ingress Controller

아래 특징과 등장 배경, 주요 차이점은 AI를 활용했다.

Ingress Controller의 특징

Ingress는 Kubernetes 초기부터 존재했던 개념으로, HTTP/HTTPS 트래픽을 클러스터 내부 서비스로 라우팅하는 리소스입니다. Ingress 리소스 자체는 라우팅 규칙만 정의하고, 실제 트래픽 처리는 Ingress Controller(nginx, Traefik, HAProxy 등)가 담당합니다. 현재 여러분 프로젝트에서 사용하는 nginx ingress controller가 바로 이런 구현체입니다.

하지만 Ingress에는 몇 가지 한계가 있습니다. 먼저 HTTP/HTTPS만 지원하고 TCP/UDP 같은 프로토콜은 별도 설정이 필요합니다. 또한 각 Ingress Controller 벤더마다 annotation을 통해 고급 기능을 구현하는데, 이게 표준화되지 않아서 Controller를 바꾸면 설정을 다시 작성해야 하는 문제가 있습니다. 그리고 Ingress는 단일 리소스 타입이라 역할 기반 접근 제어(RBAC)가 제한적입니다.

Gateway API의 등장 배경

Gateway API는 Kubernetes SIG-Network에서 Ingress의 한계를 극복하고자 2020년대 초반부터 개발한 차세대 트래픽 관리 API입니다. 2023년 10월에 GA(Generally Available) 상태에 도달했고, Ingress를 대체하기 위한 표준으로 설계되었습니다.

Gateway API는 역할 분리(role-oriented)를 핵심 설계 원칙으로 삼고 있습니다. GatewayClass, Gateway, HTTPRoute, TCPRoute 등 여러 리소스로 나뉘어 있어서, 인프라 관리자는 Gateway를 관리하고 개발자는 Route를 관리하는 식으로 책임을 명확히 분리할 수 있습니다. 이는 여러분처럼 인프라 팀 리더와 서버 개발자 역할을 동시에 하는 경우, 팀 내 권한 분배를 더 명확히 할 수 있게 해줍니다.

 

주요 차이점

프로토콜 지원 면에서 Gateway API는 HTTP, HTTPS, gRPC, TCP, UDP를 네이티브로 지원하며, 여러분의 WebSocket(STOMP) 같은 프로토콜도 더 자연스럽게 처리할 수 있습니다.

표현력과 유연성도 크게 향상되었습니다. Ingress에서는 annotation으로 해결하던 트래픽 분할(canary 배포), 헤더 기반 라우팅, 미러링 같은 고급 기능들이 Gateway API에서는 표준 리소스로 정의되어 있습니다. 예를 들어 A/B 테스트나 카나리 배포를 할 때 HTTPRoute의 weight 필드로 명시적으로 트래픽 비율을 조정할 수 있습니다.

백엔드 참조 방식도 개선되었습니다. Ingress는 같은 네임스페이스의 Service만 참조할 수 있지만, Gateway API는 ReferenceGrant를 통해 다른 네임스페이스의 Service나 다른 종류의 백엔드를 안전하게 참조할 수 있습니다. 마이크로서비스 아키텍처에서 네임스페이스를 서비스별로 분리할 때 유용합니다.

 

 

이 조사 내용을 읽은 뒤, 지금 이전한 것이 아주 다행라는 생각이 들었다.

지금 빠르게 개발하고 있는 프로젝트에는, MSA, gRPC 등 다양한 통신 프로토콜을 사용할 계획이였다.

이를 구현하기 더 쉬운게 확실히 Gateway API인 것 같아서, 바로 마이그레이션 진행하기로 하였다.

기본 설치 과정

1. Helm 레포지토리 추가

helm repo add istio https://istio-release.storage.googleapis.com/charts
helm repo update

2. Istio Base 설치 (CRDs 및 클러스터 역할)

helm install istio-base istio/base -n istio-system --create-namespace --wait

3. Istiod 설치 (컨트롤 플레인)

helm install istiod istio/istiod -n istio-system --wait

4. 설치 확인

helm ls -n istio-system
kubectl get deployments -n istio-system --output wide

 

 

설치가 다 끝났다. 하지만 Ingress Controller를 사용할 때의 Ingress.yaml을 그대로 사용해서 HTTPS가 적용되냐? 아니다.

Istio를 위한 추가 설정이 필요하다.

 

HTTPS 적용을 위한 설정들

아래는, 여러 서비스가 여러 도메인을 사용하는 것을 단일 Gateway + 여러 와일드카드 인증서 발급/사용 기준으로 작성하였다.

필요에 맞게 수정하면 된다.

1. 전역 gateway.yaml 설정

gpt에 전역으로 적용될 gateway 작성해달라고 하면 된다. 자세히 작성 안하는 이유는, 다음에 올라올 트러블슈팅과도 관련있지만,, 베어메탈서버에서 Kubernetes Gateway API를 istio로 구현하여 사용하는 것을 실패했기 때문이다. 하지만 시도해본 바로는 아래 설정들은 필요한 설정이라고 알고있다. 추후에 istio가 안정화된다면 다시 시도할 것이다.

TLS Mode 종류

Mode 설명 용도

Terminate	Gateway에서 TLS 종료(복호화 후 HTTP로 전달)	가장 일반적, SSL 인증서 관리
Passthrough	TLS를 그대로 통과(암호화된 채로 백엔드로)	백엔드가 직접 TLS 처리

예시

Terminate (일반적)

클라이언트 --HTTPS--> Gateway --HTTP--> ArgoCD
         (암호화됨)           (복호화됨)

• Gateway가 인증서 필요 
• 백엔드는 HTTP만 처리
• 대부분의 경우 이것 사용

Passthrough (특수 상황)

클라이언트 --HTTPS--> Gateway --HTTPS--> ArgoCD
         (암호화됨)           (암호화 유지)

• Gateway는 인증서 불필요
• 백엔드가 인증서 필요
• SNI 기반 라우팅만 가능

선택 기준

일반적인 경우 (99%) - Terminate
백엔드가 자체 TLS 처리할 때만 - Passthrough

(certificateRefs 불필요)

 

2.  httproures.yaml 설정

gpt에 전역으로 적용될 httproures 작성해달라고 하면 된다. 자세히 작성 안하는 이유는, 다음에 올라올 트러블슈팅과도 관련있지만,, 베어메탈서버에서 Kubernetes Gateway API를 istio로 구현하여 사용하는 것을 실패했기 때문이다. 하지만 시도해본 바로는 아래 설정들은 필요한 설정이라고 알고있다. 추후에 istio가 안정화된다면 다시 시도할 것이다.

3.  certificates.yaml 설정

TLS Secret(chabin-cert, ckqls-cert)을 자동 갱신해주는 설정

# kubectl apply -f certificates.yaml
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: 
  namespace: istio-system
spec:
  secretName:  # 이 이름으로 인증서 생성
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer
  dnsNames:
  - 
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: 
  namespace: istio-system
spec:
  secretName: 
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer
  dnsNames:
  -

 

 

4.  reference-grant.yaml 설정

# kubectl apply -f reference-grant.yaml
apiVersion: gateway.networking.k8s.io/v1beta1
kind: ReferenceGrant
metadata:
  name: allow-gateway-cert-ref
  namespace: {your-namespace}
spec:
  from:
  - group: gateway.networking.k8s.io
    kind: Gateway
    namespace: {your-namespace}
  to:
  - group: ""
    kind: Secret
    name: {your-cert-name}
  - group: ""
    kind: Secret
    name: {your-cert-name}