🚀 쿠버네티스 네트워킹의 새로운 표준: Gateway API 완벽 정복 (GatewayClass, Gateway, HTTPRoute)

안녕하세요! 👋 오늘은 쿠버네티스(Kubernetes, k8s) 클러스터로 들어오는 트래픽을 관리하는 새로운 표준, Gateway API에 대해 깊이 있게 알아보겠습니다. 기존의 Ingress 방식에 어떤 한계를 느꼈고, Gateway API가 어떻게 그 문제들을 해결하며 더 나은 경험을 제공하는지 궁금하셨나요? 이 글을 통해 GatewayClass, Gateway, HTTPRoute라는 핵심 리소스를 중심으로 TLS 인증서 적용 방법부터 Ingress와의 차이점까지 속 시원하게 설명해 드릴게요! 🤓

 

 

---

🤔 쿠버네티스는 왜 새로운 트래픽 관리 방식을 필요로 했을까?

쿠버네티스 환경이 복잡해지고 여러 팀이 하나의 클러스터를 공유하는 사례가 늘어나면서, 기존의 Ingress 방식은 몇 가지 분명한 한계에 부딪혔습니다.

• 역할 분리의 부재: 클러스터 관리자와 애플리케이션 개발자 간의 책임과 권한이 명확하게 분리되지 않았어요. 인프라 설정과 라우팅 규칙이 하나의 Ingress 객체에 섞여 있어, 사소한 라우팅 변경이 전체 인프라에 영향을 줄 수 있는 위험이 있었죠. 😰
• 표준화되지 않은 확장: 기본적인 기능 외에 트래픽 가중치 기반 라우팅, 헤더 기반 라우팅 등 고급 기능을 사용하려면 각 Ingress 컨트롤러(Nginx, Traefik 등)마다 다른 어노테이션(annotation)을 사용해야 했습니다. 이는 특정 벤더에 종속되게 만들고, 설정을 다른 환경으로 이식하기 어렵게 만들었습니다.
• 제한적인 프로토콜 지원: Ingress는 기본적으로 HTTP/HTTPS 트래픽에만 초점을 맞추고 있어, TCP, UDP, gRPC 등 다른 프로토콜을 다루기에는 부족했습니다.

이러한 문제들을 해결하기 위해, 더 유연하고, 표현력이 뛰어나며, 역할 기반으로 설계된 Gateway API가 등장하게 된 것입니다. 🎉

---

GATEWAY API의 핵심 3요소: GatewayClass, Gateway, HTTPRoute

Gateway API는 역할을 명확히 나누는 세 가지 핵심 리소스를 중심으로 동작합니다. 이는 마치 역할을 분담하여 효율적으로 일하는 팀과 같습니다.

리소스	담당자 (페르소나)	역할
GatewayClass	인프라 제공자 (Infra Provider)	어떤 종류의 로드밸런서를 사용할지 정의하는 템플릿 (e.g., AWS LB, GCP LB, Nginx)
Gateway	클러스터 운영자 (Cluster Operator)	GatewayClass를 사용하여 실제 로드밸런서 인스턴스를 생성하고, 어떤 포트와 프로토콜을 사용할지, 어떤 라우팅 규칙을 허용할지 정의
HTTPRoute	애플리케이션 개발자 (App Developer)	Gateway에 연결하여, 특정 호스트 이름이나 경로로 들어오는 트래픽을 어떤 서비스로 보낼지 상세한 라우팅 규칙을 정의

 

이러한 역할 분리는 각 담당자가 자신의 책임 영역에만 집중할 수 있게 하여, 안정성과 보안을 크게 향상시킵니다.

1. GatewayClass: 로드밸런서의 청사진 📜

GatewayClass는 클러스터 전체에 적용되는 리소스로, 어떤 컨트롤러가 게이트웨이를 관리할지를 정의합니다. 클라우드 제공업체의 로드밸런서를 사용할 수도 있고, 클러스터 내에 직접 설치한 Nginx나 Istio 같은 컨트롤러를 지정할 수도 있습니다.

 

YAML 예시:

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: my-gateway-class
spec:
  controllerName: example.com/gateway-controller

• controllerName: 이 GatewayClass를 구현하고 관리할 컨트롤러의 이름을 지정합니다.

2. Gateway: 트래픽이 들어오는 문 🚪

Gateway는 GatewayClass를 참조하여 실제 로드밸런서 인스턴스를 생성합니다. 클러스터 운영자는 이 리소스를 통해 외부 트래픽을 받아들일 포트, 프로토콜, 그리고 TLS 인증서 등을 설정합니다.

 

YAML 예시 (TLS 인증서 포함):

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: my-gateway
  namespace: my-app-ns
spec:
  gatewayClassName: my-gateway-class
  listeners:
  - name: https-listener
    protocol: HTTPS
    port: 443
    hostname: "example.com"
    tls:
      mode: Terminate
      certificateRefs:
      - name: example-com-tls-secret # TLS 인증서와 개인 키가 저장된 Secret
        kind: Secret
    allowedRoutes:
      namespaces:
        from: Selector
        selector:
          matchLabels:
            expose: "true"

• gatewayClassName: 사용할 GatewayClass를 지정합니다.
• listeners: 트래픽을 수신할 포트와 프로토콜을 정의합니다.
• hostname: 특정 호스트 이름으로 들어오는 트래픽만 처리하도록 제한할 수 있습니다.
• tls.certificateRefs: HTTPS 통신을 위해 사용할 TLS 인증서가 담긴 Secret을 참조합니다. mode: Terminate는 이 게이트웨이에서 TLS 연결을 종료하고, 게이트웨이와 내부 파드(Pod) 간에는 암호화되지 않은 HTTP 통신을 하겠다는 의미입니다.
• allowedRoutes: 이 게이트웨이에 연결할 수 있는 Route(예: HTTPRoute)를 네임스페이스 레이블을 통해 제한하여 보안을 강화합니다.

3. HTTPRoute: 똑똑한 교통 경찰관 👮

애플리케이션 개발자는 HTTPRoute를 사용하여 Gateway로 들어온 트래픽을 어떻게 처리할지 상세하게 정의합니다. 경로 기반 라우팅, 헤더 기반 라우팅, 가중치 기반 트래픽 분할 (카나리 배포) 등 정교한 제어가 가능합니다.

 

YAML 예시 (가중치 기반 트래픽 분할):

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: my-app-route
  namespace: my-app-ns
  labels:
    expose: "true" # Gateway의 allowedRoutes selector와 일치해야 함
spec:
  parentRefs:
  - name: my-gateway # 연결할 부모 Gateway를 지정
    namespace: my-app-ns
  hostnames:
  - "example.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: my-app-v1 # 서비스 이름
      port: 80
      weight: 90
    - name: my-app-v2 # 새로운 버전의 서비스
      port: 80
      weight: 10

• parentRefs: 이 라우팅 규칙을 적용할 Gateway를 지정합니다.
• hostnames: 이 규칙이 적용될 호스트 이름을 명시합니다.
• rules: 실제 라우팅 규칙을 정의합니다. 위 예시는 example.com/으로 들어오는 트래픽의 90%를 my-app-v1 서비스로, 10%를 my-app-v2 서비스로 보내는 카나리 배포 시나리오입니다.

---

Gateway API vs Ingress: 무엇이 다른가?

기능	Ingress	Gateway API
역할 분리	❌ 없음 (단일 리소스)	✅ 명확함 (GatewayClass, Gateway, Route)
이식성	⚠️ 낮음 (벤더별 어노테이션)	✅ 높음 (표준화된 필드)
표현력	⚠️ 제한적 (경로/호스트 기반)	✅ 뛰어남 (헤더, 가중치, 필터 등)
프로토콜	HTTP, HTTPS	HTTP, HTTPS, TCP, UDP, gRPC, TLS
권한 모델	⚠️ 광범위한 권한 필요	✅ 역할 기반의 세분화된 권한 제어
크로스 네임스페이스	⚠️ 제한적이고 위험	✅ 안전한 참조 모델 제공 (ReferenceGrant)

 

가장 큰 차이점은 역할 기반의 아키텍처입니다. Gateway API는 인프라 담당자와 앱 개발자의 책임을 명확히 분리하여, 여러 팀이 안전하고 독립적으로 하나의 클러스터를 공유할 수 있는 강력한 기반을 제공합니다. 개발자는 더 이상 인프라 세부 사항을 신경 쓰지 않고 자신의 애플리케이션 라우팅에만 집중할 수 있게 됩니다.

---

✨ 결론: 미래의 표준을 준비하세요!

Gateway API는 단순한 Ingress의 대체재가 아닙니다. 이는 쿠버네티스 네트워킹의 패러다임을 바꾸는 진화입니다. 역할 기반의 유연하고 확장 가능한 아키텍처를 통해 복잡한 마이크로서비스 환경의 트래픽 관리를 훨씬 더 안전하고 효율적으로 만들어줍니다.

아직 Ingress를 사용하고 있더라도, 앞으로는 Gateway API가 표준으로 자리 잡을 것이 분명합니다. 지금부터 Gateway API의 개념을 이해하고, 여러분의 클러스터에 어떻게 적용할 수 있을지 고민해 보세요! 여러분의 쿠버네티스 여정이 한 단계 더 발전할 것입니다. 🌟

 

태그: 쿠버네티스, Kubernetes, Gateway API, Ingress, GatewayClass, Gateway, HTTPRoute, MSA, DevOps, 클라우드 네이티브