인그레스를 Gateway API로 이전

이 페이지에서는 Google Kubernetes Engine (GKE)에서 인그레스 API에서 게이트웨이 API로 트래픽 관리를 이전하는 방법을 보여줍니다. 게이트웨이 API는 애플리케이션 트래픽을 처리하기 위한 완전 관리형 Google Cloud 솔루션을 제공합니다.

다운타임을 최소화하고 위험을 완화하려면 게이트웨이 API로 이전하는 가장 효과적인 방법은 기존 인그레스 API와 새 게이트웨이 API 구성을 동시에 실행하는 것입니다. 이 방법을 사용하면 현재 서비스에 영향을 주지 않고 라이브 환경에서 새 게이트웨이 구성을 철저히 테스트할 수 있습니다. 새 게이트웨이 구성을 검증한 후 빠른 DNS 컷오버를 실행하여 트래픽을 게이트웨이 API로 리디렉션하고 원활하고 위험이 적은 전환을 보장할 수 있습니다.

대략적으로 마이그레이션 전략에는 다음 단계가 포함됩니다.

  1. 새 부하 분산기를 구성합니다.
  2. 수신 트래픽 처리 규칙을 정의합니다.
  3. 새 구성을 배포하고 새 게이트웨이 IP 주소로의 트래픽 흐름을 테스트합니다.
  4. 프로덕션 트래픽을 Gateway API로 전환합니다.
  5. 나머지 인그레스 리소스를 정리합니다.

새 부하 분산기 구성

이 단계에서는 Kubernetes 게이트웨이 리소스를 배포하여 GKE 클러스터로 트래픽을 부하 분산합니다. 게이트웨이 리소스를 배포하면 GKE는 계층 7 애플리케이션 부하 분산기를 구성하여 클러스터에서 실행되는 애플리케이션에 HTTP(S) 트래픽을 노출합니다. 필요한 각 클러스터 또는 각 부하 분산기에 대해 하나의 게이트웨이 리소스를 배포합니다.

다음 예에서는 전역 외부 애플리케이션 부하 분산기를 구성합니다. 게이트웨이를 만들려면 다음 매니페스트를 gateway.yaml로 저장합니다.

kind: Gateway
apiVersion: gateway.networking.k8s.io/v1
metadata:
  name: external-http-gateway
spec:
  gatewayClassName: gke-l7-global-external-managed # GKE's managed external Application Load Balancer
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    allowedRoutes:
      namespaces:
        from: Same # Only allow HTTPRoutes from the same namespace

위 매니페스트는 다음 필드를 포함하는 게이트웨이를 설명합니다.

  • gatewayClassName: gke-l7-global-external-managed: 이 게이트웨이에 GatewayClass를 지정합니다. 이 게이트웨이 클래스는 전역 외부 애플리케이션 부하 분산기를 사용합니다.
  • protocol: HTTP 및 port: 80: 게이트웨이가 HTTP 트래픽에 대해 포트 80을 노출하도록 지정합니다.

수신 트래픽에 대한 트래픽 규칙 정의

경로 리소스는 게이트웨이에서 백엔드 서비스로 트래픽을 매핑하기 위한 프로토콜 특정 규칙을 정의합니다.

이 단계에서는 인그레스 매니페스트를 HTTPRoute 리소스로 변환합니다. 인그레스 매니페스트를 변환하려면 ingress2gateway 도구의 단계를 따르세요.

이 예시에서는 다음과 같은 Ingress 리소스가 있다고 가정합니다.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cafe-ingress
spec:
  ingressClassName: nginx
  rules:
  - host: cafe.example.com
    http:
      paths:
      - path: /tea
        pathType: Prefix
        backend:
          service:
            name: tea-svc
            port:
              number: 80
      - path: /coffee
        pathType: Prefix
        backend:
          service:
            name: coffee-svc
            port:
              number: 80

ingress2gateway 도구를 사용하여 매니페스트를 변환하면 번역된 HTTPRoute 매니페스트가 출력됩니다.

다음 샘플 매니페스트를 httproute.yaml로 저장합니다.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: cafe-route
spec:
  # This route attaches to our new Gateway
  parentRefs:
  - name: external-http-gateway
  # The hostname is the same as before
  hostnames:
  - "cafe.example.com"
  # The routing rules are now more explicit
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /tea
    backendRefs:
    - name: tea-svc
      port: 80
  - matches:
    - path:
        type: PathPrefix
        value: /coffee
    backendRefs:
    - name: coffee-svc
      port: 80

HTTPRoute 매니페스트의 rules 필드는 원래 인그레스 매니페스트에 정의된 라우팅 규칙에 직접 해당합니다.

새 구성 배포 및 테스트

이 단계에서는 앞의 두 단계에서 만든 게이트웨이 및 HTTPRoute 매니페스트를 적용하고 트래픽이 게이트웨이의 새 IP 주소로 흐르는지 테스트합니다.

  1. 게이트웨이 및 HTTPRoute 매니페스트를 적용합니다.

    kubectl apply -f gateway.yaml
kubectl apply -f httproute.yaml

  2. 게이트웨이의 IP 주소를 가져옵니다. IP 주소를 할당하는 데 몇 분 정도 걸릴 수 있습니다.

    kubectl get gateway external-http-gateway -o=jsonpath="{.status.addresses[0].value}" --watch

    출력은 게이트웨이의 외부 IP 주소입니다(예: 203.0.113.90).

  3. 새 게이트웨이 IP 주소를 테스트합니다. 다음 curl 명령어를 사용하여 IP 주소로 요청을 전송하고 cafe.example.com 호스트 이름을 지정합니다. 예를 들면 다음과 같습니다.

    curl --resolve cafe.example.com:80:203.0.113.90 http://cafe.example.com/tea
curl --resolve cafe.example.com:80:203.0.113.90 http://cafe.example.com/coffee

    203.0.113.90를 이전 단계에서 가져온 외부 IP 주소로 바꿉니다. 출력은 새 게이트웨이 IP 주소가 DNS 조회를 실행하지 않고 cafe.example.com의 트래픽을 올바르게 라우팅하는지 확인합니다.

새 게이트웨이 IP 주소로 트래픽 전달

이 단계에서는 새 게이트웨이 IP 주소를 가리키도록 DNS 레코드를 업데이트하여 이전 인그레스에서 새 게이트웨이로 실시간 트래픽을 전환합니다. DNS 레코드를 업데이트하는 정확한 단계는 DNS 제공업체에 따라 다릅니다.

예를 들어 인그레스에서 cafe.example.com를 구성한 경우 DNS 제공업체에서 cafe.example.com의 A 레코드를 찾아 이전 인그레스 IP 주소 값을 새 게이트웨이 IP 주소인 203.0.113.90로 변경합니다.

DNS 레코드를 업데이트하면 트래픽이 인그레스에서 게이트웨이로 이동하기 시작하지만 모든 클라이언트에서 즉시 전환이 발생하지는 않습니다. 이전 레코드가 캐시된 DNS 리졸버는 레코드의 TTL (수명) 값이 만료될 때까지 기다린 후 레코드를 다시 쿼리하고 업데이트된 IP 주소를 수신합니다. 따라서 인그레스로의 트래픽이 중단되었는지 확인할 때까지 기존 인그레스와 새 게이트웨이를 함께 실행해야 합니다. 이는 DNS 전파가 완료되었으며 클라이언트가 더 이상 이전 IP 주소로 리디렉션되지 않음을 나타냅니다. 부하 분산기 또는 인그레스 컨트롤러의 트래픽을 모니터링하여 이를 확인할 수 있습니다. 자세한 내용은 DNS 전파 확인을 참고하세요.

Cloud DNS를 사용하는 경우 타겟 가중치를 사용하여 트래픽을 오래된 IP 주소에서 새 IP 주소로 점진적으로 이동할 수 있습니다. 자세한 내용은 DNS 라우팅 정책 및 상태 점검 구성을 참고하세요.

나머지 인그레스 리소스 정리

새 게이트웨이가 성공적으로 실행되는지 확인한 후 이전 인그레스 리소스를 정리합니다.

  1. 인그레스 리소스를 삭제합니다.

    kubectl delete ingress cafe-ingress

  2. ingress-nginx 컨트롤러를 제거합니다. 예를 들어 Helm을 사용하여 컨트롤러를 설치한 경우 다음 명령어를 실행합니다.

    helm uninstall ingress-nginx -n ingress-nginx

인그레스 NGINX와 GKE Gateway 간의 기능 비교

Gateway API는 인그레스를 구성하는 더 표준화된 방법을 제공하며 라우팅, 헤더, 트래픽 분할과 같은 가장 일반적인 기능에 대한 기능 패리티가 있습니다.

다음 표에서는 인그레스 컨트롤러와 Gateway API의 일반적인 기능에 사용되는 주석을 비교합니다.

기능 인그레스의 주석 GKE 게이트웨이의 주석 패리티
URL 재작성 nginx.ingress.kubernetes.io/rewrite-target urlRewrite 필터를 사용하여 HTTPRoute를 호출합니다. 부분 패리티 GKE 게이트웨이는 접두사 대체만 지원합니다.
헤더 조작 nginx.ingress.kubernetes.io/proxy-set-headers 또는 add-headers HTTPRoute을 requestHeaderModifier 수정자 또는 responseHeaderModifier 필터로 바꿉니다. 완전한 패리티
경로 기반 라우팅 인그레스 객체의 spec.rules.http.paths HTTPRoute 객체의 rules.matches.path 완전한 패리티
호스트 기반 라우팅 인그레스 객체의 spec.rules.host HTTPRoute 객체의 hostnames 완전한 패리티
트래픽 분할 nginx.ingress.kubernetes.io/canary 주석 가중치가 적용된 backendRefs이 있는 HTTPRoute 완전한 패리티 또한 세부적인 제어를 통해 트래픽을 분할할 수 있습니다.
인증 외부 인증을 위한 nginx.ingress.kubernetes.io/auth-url
  • IAP (Identity-Aware Proxy): BackendPolicy CRD
  • 기타: 서비스 메시 또는 맞춤 필터를 사용하여 더 맞춤화된 접근 방식이 필요합니다.
 부분 패리티 IAP(Identity-Aware Proxy)는 게이트웨이를 보호하는 데 권장되는 방법이며 백엔드에서 구성됩니다.

다음 단계