쿠버네티스 Gateway API — Ingress를 대체하는 새 트래픽 표준

쿠버네티스에서 외부 트래픽을 클러스터 안으로 들여보내는 표준이 바뀌고 있다. 오랫동안 그 자리를 지켜온 Ingress를 대신해 Gateway API가 사실상의 후계 표준으로 자리를 잡는 중이다. 한 문장으로 말하면, Gateway API는 "누가 무엇을 설정하는가"를 역할별로 쪼갠 새로운 트래픽 관리 규격이다.

나는 Ingress로 몇 년을 버텨봤는데, 언제나 걸리는 지점이 똑같았다. 경로 하나 붙이는 것까지는 쉬운데, 조금만 복잡한 요구가 들어오면 전부 컨트롤러 벤더가 만든 어노테이션(annotation) 뭉치로 해결해야 했다. 그 순간부터 이식성은 사라진다.

Ingress는 왜 한계에 부딪혔나

Ingress는 단순함이 장점이었다. 호스트와 경로를 서비스에 연결하는 것, 딱 거기까지가 규격이었다. 문제는 현실이 그렇게 단순하지 않다는 데 있다. 헤더 기반 라우팅, 가중치 기반 카나리, mTLS, 리다이렉트 같은 요구는 규격에 없으니 각 컨트롤러가 자기 방식대로 어노테이션을 만들어 메웠다.

결과적으로 NGINX용으로 짠 설정은 Traefik이나 HAProxy로 그대로 옮겨지지 않았다. "표준"이라는 이름을 달고 있었지만, 실제로는 벤더마다 다른 방언을 쓰는 셈이었다. 관리자가 보안 정책을 강제하기도 어려웠다. 한 리소스에 모든 게 뭉쳐 있으니, 개발자에게 라우팅 권한을 주면 리스너 설정까지 손댈 수 있었다.

Gateway API가 다르게 접근한 것

핵심은 리소스를 역할별로 쪼갠 것이다. 인프라 제공자는 GatewayClass를 정의하고, 플랫폼 팀은 어떤 포트와 인증서로 트래픽을 받을지 Gateway로 정한다. 서비스 팀은 자기 앱으로 오는 트래픽만 HTTPRoute·GRPCRoute 같은 Route 리소스로 다룬다.

표현력이 규격 안으로 들어왔다

예전엔 어노테이션으로 우겨넣던 것들이 이제 정식 필드다. 경로·헤더·쿼리 파라미터로 매칭하고, 여러 백엔드에 가중치를 나눠 카나리 배포를 하고, 요청 헤더를 다시 쓰는 일이 규격 수준에서 정의된다. 덕분에 Istio, Envoy Gateway, Cilium, Kong처럼 서로 다른 구현체 위에서도 같은 YAML이 통한다.

지금 옮겨야 할까

서두를 필요는 없다고 본다. Ingress는 사라지지 않고, 단순한 웹 서비스라면 여전히 충분하다. 다만 새로 짓는 클러스터거나, 서비스 메시를 함께 굴리거나, 카나리·트래픽 분할을 자주 쓴다면 Gateway API로 시작하는 편이 낫다. 나중에 어노테이션 지옥을 걷어내는 것보다 처음부터 표준 필드로 짜는 게 훨씬 편하기 때문이다.

널리 쓰이던 Ingress-NGINX 계열 구성요소들의 유지보수 방향이 흔들리면서, 마이그레이션을 고민하는 팀도 늘고 있다. 이 흐름은 Gateway API 채택을 자연스럽게 밀어 올리는 배경이 됐다.

자주 묻는 질문

Gateway API를 쓰면 Ingress는 못 쓰나요?

아니다. 둘은 공존할 수 있다. 같은 클러스터에서 기존 서비스는 Ingress로 두고, 새 서비스만 Gateway API로 받는 식의 점진적 전환이 가능하다.

서비스 메시가 있어야 하나요?

필수는 아니다. Envoy Gateway나 NGINX Gateway Fabric처럼 메시 없이 게이트웨이 용도로만 쓰는 구현체도 많다. 다만 Istio 같은 메시는 Gateway API를 남북·동서 트래픽 모두에 활용한다.

어떤 구현체를 골라야 하나요?

이미 쓰는 데이터플레인에 맞추는 게 편하다. Cilium을 쓰면 Cilium 구현을, Envoy 기반이면 Envoy Gateway나 Istio를 고려한다. 규격이 표준이라 나중에 갈아타기도 상대적으로 수월하다.

기존 어노테이션 설정은 어떻게 옮기나요?

대부분의 어노테이션은 Route의 필터나 정책 필드로 대응된다. 컨트롤러별로 변환 가이드나 도구를 제공하는 경우가 많으니, 트래픽이 적은 서비스부터 하나씩 옮겨 검증하는 방식을 권한다.