[네떡스터디🔥kans] Gateway API

CloudNet@ 가시다님이 진행하는 쿠버네티스 네트워크 스터디 KANS 3기 내용을 정리한 글입니다.

 

Gateway API

Ingress를 많이 사용하지 않았지만, 현재 회사에서 운영 중인 서비스 메시 정책들을 모두 Ingress로 변환하라는 요청이 들어온다면 매우 길고 복잡한 Ingress들이 다수 발생할 것 같습니다. 심지어 TCP/UDP 프로토콜로 개발된 서비스들도 일부 존재하기 때문에, Ingress만으로는 이 모든 서비스들을 처리하는 것이 불가능합니다.

 

운영하고 있는 쿠버네티스 클러스터는 큰 규모는 아니지만, 그럼에도 불구하고 이러한 다양한 요구 사항들이 발생하고 있습니다. 더 큰 규모의 클러스터를 운영하는 조직에서는 이러한 문제들이 더욱 빈번하게 나타날 것이며, 당연히 Ingress에 대한 개선 요구도 많았을 것입니다.

 

이러한 문제를 해결하기 위해, 쿠버네티스는 1.19 버전에서 처음으로 Gateway API를 도입했습니다. Gateway API는 1.22 버전에서 베타로 진입하였고, 1.27 버전부터는 GA(General Availability)가 되었습니다. 가장 최신 버전의 쿠버네티스가 1.31 버전으로 GA가 된지 꽤 오래 되어서 Ingress를 사용하고 계시다면 Gateway API를 사용하는것이 앞으로는 좋을 것 같습니다. 게다가 Nginx Ingress가 표준처럼 자리 잡은 Ingress와는 달리, Istio, Cilium 등 다양한 도구들이 Gateway API와의 연동을 적극 지원하고 있습니다.

 

 

 

Gateway의 각 리소스별 역할 분리

Gateway API가 지원하는 다양한 기능들도 좋지만 개인적으로는 리소스별로 역할을 분리한다는 점이 Gateway API를 사용해야할 핵심적인 이유라고 생각합니다.  Ingress의 경우에는 개발자가 직접 스스로 자신의 서비스를 만들고 싶어도 내 서비스로 트래픽을 처리하고자 할때 꼭 클러스터 운영자의 요청이 필요하기 때문입니다. 

🧩  GatewayClass

GatewayClass는 네트워크 인프라의 전반적인 설정 정책을 설정하는 역할을 합니다. 예를 들어, NGINX, Istio, Cilium 같은 네트워크 도구의 동작 방식을 정의하고, 각 게이트웨이가 어떤 기능을 사용할 수 있는지 정의해 둘 수 있습니다. 이러한 설정을 통해 운영자는 네트워크 인프라를 일관되게 유지하고, 필요할 때 쉽게 변경하거나 확장할 수 있습니다. StorageClass, IngressClass와 유사합니다. 

 

🚪 Gateway

Gateway는 클러스터 외부에서 내부로 트래픽을 전달하는 문의 역할을 합니다. Ingress보다 더 유연하고 확장성이 높은 기능을 제공하며, HTTPRoute, TLSRoute, TCPRoute 등 여러 유형의 Route를 사용할 수 있습니다. 또, Ingress는 주로 HTTP/HTTPS 트래픽만 처리할 수 있는 반면, Gateway는 다양한 유형의 트래픽을 처리하고 더 복잡한 요구 사항을 충족하는 데 적합합니다.

 

🐾 Route

Route는 Gateway와 연결되어 트래픽을 적절한 서비스로 라우팅하는 역할을 합니다. 여러 개의 Route가 하나의 Gateway를 사용할 수 있고, 특정 요구 사항에 따라 단독으로 Gateway를 사용할 수도 있습니다. Route와 Gateway의 관계는 다양한 방식으로 설정될 수 있습니다:

1. 일대일 (One-to-one): Gateway와 Route는 하나의 소유자가 사용하며, 서로 1:1로 연결될 수 있습니다.
2. 일대다 (One-to-many): 하나의 Gateway는 여러 Routes에 연결될 수 있으며, 각 Route는 다른 팀이나 네임스페이스에 속할 수 있습니다.
3. 다대일 (Many-to-one): 여러 Route가 하나의 Gateway에 연결될 수 있으며, 이는 하나의 Route가 여러 IP, 로드 밸런서 또는 네트워크에 걸쳐 애플리케이션을 노출할 수 있게 해줍니다.

 

HTTPRoute

HTTPRoute는 HTTP와 HTTPS 요청을 라우팅하는 역할을 합니다. HTTPS 트래픽은 Gateway에서 암호화가 해제된 후 HTTP로 처리되며, 암호화된 상태로 직접 처리되지 않습니다. Path, Method, Header 등 다양한 HTTP 속성을 기준으로 트래픽을 정밀하게 특정 서비스로 보내는 기능을 제공합니다. 

 

TLSRoute

TLSRoute는 암호화된 TLS 트래픽을 처리하며, SNI(Server Name Indication)를 통해 트래픽을 라우팅합니다. SNI는 클라이언트가 서버에 연결할 때 어떤 호스트 이름으로 연결하고 싶은지를 서버에 알려주는 기능으로, 여러 도메인이 동일한 IP 주소를 공유할 수 있게 해줍니다. TLSRoute는 이를 활용해 적절한 백엔드로 트래픽을 전달합니다. 또한, TLSRoute는 TLS Passthrough와 TLS Termination 두 가지 방식을 지원합니다. TLS Termination은 게이트웨이에서 암호화를 해제하고, TLS Passthrough는 암호화된 트래픽을 그대로 백엔드로 전달합니다. 이를 통해 TLSRoute는 암호화된 연결을 유지하거나 해제하면서 트래픽을 올바른 서비스로 라우팅할 수 있습니다.

 

TCPRoute

TCPRoute는 TCP 트래픽을 전송 계층에서 처리하여 클라이언트의 TCP 연결을 적절한 백엔드 서비스로 라우팅하는 역할을 합니다. Listener에 도착한 TCP 연결을 미리 설정된 규칙에 따라 관리하고, 특정 포트로 들어오는 트래픽을 여러 백엔드로 분배할 수 있습니다.

 

UDPRoute

UDPRoute는 Listener에 도착한 UDP 패킷을 지정된 백엔드로 전달합니다. 간단히 UDP 트래픽을 특정 서비스로 라우팅하는 역할을 합니다.

 

GRPCRoute

GRPCRoute는 gRPC 트래픽을 처리하는 역할을 하며, HTTP/2를 기반으로 클라이언트의 gRPC 요청을 적절한 백엔드 서비스로 라우팅합니다. GRPCRoute와 HTTPRoute 간에는 호스트 이름이 겹치지 않도록 해야 하며, gRPC와 HTTP 트래픽에는 별도의 호스트 이름을 사용하는 것이 권장됩니다. 이를 통해 두 종류의 트래픽을 명확히 구분하고 효율적으로 관리할 수 있습니다.

 

---

 

Istio의 Gateway와 VirtualService, DestinationRule을 사용해서 클러스터를 운영해왔던 경험으로 보면 Istio의 VirtualService의 경우 동일 Host의 VirtualService 규칙을 하나의 규칙으로 만들기 때문에 동일 Host 동일 Path에 대해서는 정책이 충돌할 가능성이 있었습니다. GatewayAPI의 경우에는 병합하여 사용되지는 않으나 완전 동일한 설정의 2개의 리소스가 있다면 역할 기반으로 나뉘어져 있어도 문제가 생길 여지는 있을 것 같습니다.