Post 5/10 — Ingress에서 Gateway API로: 더 안전하고 스마트한 Traffic Control

Source: Dev.to

Comparison: Ingress vs. Gateway API

Gateway API Concepts

• GatewayClass – 기본 구현(예: Istio, NGINX)을 정의합니다.
• Gateway – 플랫폼 팀이 배포하며, 트래픽이 클러스터에 들어오는 지점을 나타냅니다.
• HTTPRoute – 애플리케이션 팀이 연결하며, 트래픽 라우팅 방식을 기술합니다.

Example Manifests

gateway.yaml

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: web-gw
  namespace: platform
spec:
  gatewayClassName: nginx
  listeners:
  - name: https
    port: 443
    protocol: HTTPS
    tls:
      mode: Terminate
      certificateRefs:
      - name: my-cert
    allowedRoutes:
      namespaces:
        from: All

route.yaml

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: shop-route
  namespace: shop
spec:
  parentRefs:
  - name: web-gw
    namespace: platform
  hostnames: ["shop.example.com"]
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: shop-svc
      port: 80

Advanced Features

rules:
- matches:
  - headers:
    - name: x-region
      value: eu
  backendRefs:
  - name: shop-svc-eu
    port: 80
filters:
- type: RequestTimeout
  requestTimeout:
    duration: 5s
- type: Retry
  retry:
    count: 3
    statusCodes: ["5xx"]

Weighted traffic splits (first‑class support):

backendRefs:
- name: shop-svc
  port: 80
  weight: 80
- name: shop-svc-canary
  port: 80
  weight: 20

여러 HTTPRoute 객체를 단일 Gateway에 안전하게 연결할 수 있으며, 각 객체는 자체 네임스페이스에 한정됩니다.

Migration: Ingress → Gateway API

Legacy Ingress

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: shop
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  tls:
  - hosts: [shop.example.com]
    secretName: my-cert
  rules:
  - host: shop.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: shop-svc
            port:
              number: 80

After Migration

위에 보여진 gateway.yaml과 route.yaml을 적용합니다.

Verification

kubectl get gateways -A
kubectl get httproutes -A
kubectl describe httproute shop-route

Canary test

kubectl get endpoints shop-svc-canary -o wide
curl -H "x-canary:true" https://shop.example.com

제어된 트래픽 흐름, 향상된 가시성, 명확한 소유권을 확인할 수 있습니다.

Common Commands

꼭 기억할 필드

• listeners.protocol, tls.mode, allowedRoutes
• rules.matches, filters, backendRefs.weight

Pitfalls to Watch

1. 정책 적용 순서 – 게이트웨이 수준 정책이 라우트 수준 정책보다 먼저 평가되며, 우선순위가 중요합니다.
2. 중복 라우트 – 동일한 호스트/경로를 가진 여러 HTTPRoute 객체가 존재하면 컨트롤러마다 다른 우선순위 로직이 적용될 수 있습니다.
3. 네임스페이스 간 참조 – allowedRoutes.from=Same이면 개발 팀이 다른 네임스페이스의 라우트를 연결할 수 없습니다.
4. 컨트롤러 지원 여부 – Gateway와 HTTPRoute 객체의 status.conditions를 항상 확인하여 리스너가 정상적으로 수락됐는지 확인합니다.

Conclusion

Gateway API를 사용하면 쿠버네티스가 정책 기반 트래픽 제어를 제공하게 되며, 팀과 환경을 가로질러 확장 가능한 안전하고 깔끔한 자동화 환경을 구현할 수 있습니다.

Next up: Helm Fundamentals (Post 6) – 이 Gateway 객체들을 템플릿화하고 라우트를 올바르게 파라미터화하는 방법을 다룹니다.