게이트웨이

이 페이지에서는 GKE 게이트웨이 컨트롤러를 사용하여 Kubernetes Gateway API의 Google Kubernetes Engine(GKE) 구현에 대해 설명합니다.

이 페이지는 조직의 네트워크를 설계하는 클라우드 설계자 및 네트워킹 전문가를 대상으로 합니다. Google Cloud 콘텐츠에서 참조하는 일반적인 역할 및 예시 작업에 대해 자세히 알아보려면 일반 GKE Enterprise 사용자 역할 및 작업을 참조하세요.

Gateway API는 서비스 네트워킹을 위한 오픈소스 표준입니다. Gateway API는 다음과 같은 방법으로 인그레스 리소스를 발전시키고 개선합니다.

• 역할 중심: 게이트웨이는 클러스터 운영자, 개발자, 인프라 제공업체에 해당하는 API 리소스로 구성됩니다. 그 결과 클러스터 운영자가 팀간 조정이 없는 여러 개발자팀에서 공유 인프라를 사용하는 방법을 정의할 수 있습니다.

• 이동성: Gateway API는 여러 구현이 포함된 오픈소스 표준입니다. 이 API는 해당 환경 및 구현의 기본 기능을 지원하기 위해 유연성 및 확장성을 아직 갖고 있는 이동성이 뛰어난 코어 API(인그레스)를 촉진하는 유연한 규정 준수 개념을 사용하여 설계되었습니다. 그 결과 구현 및 환경 간에 개념 및 핵심 리소스의 일관성을 높이고 복잡성은 줄이면서 사용자 친숙성을 늘릴 수 있습니다.

• 표현성: Gateway API 리소스는 헤더 기반 일치, 트래픽 가중, 커스텀 주석을 통해 인그레스에서만 가능한 기타 기능을 위한 기본 제공 기능을 제공합니다.

Gateway API 리소스

Gateway API는 Kubernetes 네트워킹과 상호작용하는 캐릭터를 위해 설계된 역할 중심 리소스 모델입니다. 다음 다이어그램과 같이 이 모델을 사용하면 소유자 간 조정이 없는 여러 서비스 소유자가 플랫폼 관리자의 정책 및 제어를 중앙화하는 방식으로 동일한 기본 네트워크 인프라를 안전하게 공유할 수 있습니다.

Gateway API에는 다음 리소스 유형이 포함됩니다.

• GatewayClass: 클러스터에서 부하 분산기를 만들기 위한 템플릿인 클러스터 범위 리소스를 정의합니다. GKE는 GKE 클러스터에서 사용될 수 있는 GatewacyClass를 제공합니다.
• 게이트웨이: 부하 분산기가 트래픽을 리슨하는 위치 및 방법을 정의합니다. 클러스터 운영자는 GatewayClass를 기준으로 자신의 클러스터에 게이트웨이를 만듭니다. GKE는 게이트웨이 리소스에 정의된 구성을 구현하는 부하 분산기를 만듭니다.
• HTTPRoute: 게이트웨이에서 Kubernetes 서비스로 요청을 라우팅하기 위한 프로토콜 특정 규칙을 정의합니다. GKE는 HTTP(S) 기반 트래픽 라우팅을 위해 HTTPRoute를 지원합니다. 애플리케이션 개발자는 게이트웨이를 사용하여 HTTP 애플리케이션을 노출하기 위해 HTTPRoute를 만듭니다.
• 정책: 게이트웨이 리소스의 구현별 특성 집합을 정의합니다. 게이트웨이, 경로 또는 Kubernetes 서비스에 정책을 연결할 수 있습니다.

GatewayClass

GatewayClass는 Kubernetes 클러스터에서 HTTP(S)(수준 7) 부하 분산기용 템플릿을 정의하는 리소스입니다. GKE는 GatewayClass를 클러스터 범위 리소스로 제공합니다. 클러스터 운영자는 자신의 클러스터에서 게이트웨이를 만들 때 GatewayClass를 지정합니다.

다른 GatewayClass는 서로 다른 Google Cloud 부하 분산기에 해당합니다. GatewayClass를 기반으로 게이트웨이를 만들면 지정된 구성을 구현하기 위해 해당 부하 분산기가 생성됩니다.

일부 GatewayClass는 멀티 클러스터 부하 분산을 지원합니다.

다음 표에서는 GKE 클러스터에서 사용 가능한 GatewayClass 및 기본 부하 분산기 유형을 보여줍니다. GatewayClass에 대한 자세한 내용은 GatewayClass 기능 및 사양을 참조하세요.

각 GatewayClass는 기본 부하 분산기의 제한사항을 따릅니다.

게이트웨이

클러스터 운영자는 부하 분산기가 트래픽을 리슨하는 위치 및 방법을 정의합니다. 게이트웨이는 연관된 GatewayClass로부터 동작을 가져옵니다(구현 방법).

게이트웨이 사양에는 게이트웨이의 GatewayClass, 리슨할 포트 및 프로토콜과 게이트웨이에 바인딩될 수 있는 경로가 포함됩니다. 게이트웨이는 경로 메타데이터, 특히 경로 리소스의 종류, 네임스페이스, 라벨을 기준으로 경로를 선택합니다.

게이트웨이 배포 예시는 게이트웨이 배포를 참조하세요.

멀티 클러스터 게이트웨이를 배포하는 예시는 멀티 클러스터 게이트웨이 배포를 참조하세요.

HTTPRoute

HTTPRoute는 게이트웨이에서 수신되는 HTTP 및 HTTPS 요청이 서비스로 전달되는 방법을 정의합니다. 애플리케이션 개발자는 게이트웨이를 통해 애플리케이션을 노출하기 위해 HTTPRoute를 만듭니다.

HTTPRoute는 트래픽을 라우팅할 수 있는 게이트웨이, 라우팅할 서비스, HTTPRoute와 일치하는 트래픽을 정의하는 규칙을 정의합니다. 게이트웨이 및 경로 바인딩은 양방향입니다. 즉, 두 리소스 모두 서로를 바인딩하도록 선택해야 합니다. HTTPRoute는 요청 헤더의 세부정보를 기준으로 요청을 일치시킬 수 있습니다.

정책

정책은 클러스터 운영자가 게이트웨이, 경로 또는 Kubernetes 서비스에 연결할 수 있는 게이트웨이 리소스(일반적으로 구현별)의 특성을 정의합니다. 정책은 기본 Google Cloud 인프라가 작동하는 방법을 정의합니다.

정책은 일반적으로 네임스페이스에 연결되고 동일한 네임스페이스의 리소스를 참조할 수 있으며 액세스 권한은 RBAC를 통해 부여됩니다. Gateway API의 계층적 특성을 사용하면 정책을 네임스페이스의 최상위 리소스(게이트웨이)에 연결하고 다른 네임스페이스의 모든 리소스에서 해당 정책의 특성을 수신하게 할 수 있습니다.

GKE Gateway Controller는 다음 정책을 지원합니다.

• HealthCheckPolicy: 백엔드 Pod 상태를 확인하는 데 사용되는 상태 점검의 매개변수와 동작을 정의합니다.
• GCPGatewayPolicy: Google Cloud 부하 분산기 프런트엔드의 특정 매개변수를 정의합니다. 이는 인그레스 리소스의 FrontendConfig와 비슷합니다.
• GCPBackendPolicy: 부하 분산기의 백엔드 서비스가 엔드포인트에 트래픽을 분산하는 방법을 정의합니다. 이는 인그레스 리소스의 BackendConfig와 비슷합니다.

게이트웨이 소유권 및 사용 패턴

게이트웨이 및 경로 리소스는 조직 내에서 소유 및 배포되는 방법에 유연성을 제공합니다. 즉, 인프라팀에서 단일 부하 분산기를 배포하고 관리할 수 있지만 특정 도메인 또는 경로 아래의 라우팅은 다른 Kubernetes 네임스페이스의 다른 팀에 위임될 수 있습니다. GKE 게이트웨이 컨트롤러는 네임스페이스, 클러스터, 리전에서 공유되는 부하 분산기의 멀티 테넌트 사용을 지원합니다. 더 많은 분산 소유권이 필요한 경우에도 게이트웨이를 공유할 필요가 없습니다. 다음은 GKE에서 게이트웨이에 가장 일반적인 몇 가지 사용 패턴입니다.

자체 관리형 게이트웨이

단일 소유자가 애플리케이션 전용으로 게이트웨이와 경로를 배포하고 배타적으로 사용할 수 있습니다. 이러한 방식으로 배포된 게이트웨이와 경로는 인그레스와 비슷합니다. 다음 다이어그램에서는 자체 게이트웨이를 배포하고 관리하는 서비스 소유자 두 개를 보여줍니다. 인그레스와 마찬가지로 각 게이트웨이는 고유한 IP 주소와 부하 분산기에 해당합니다. 서비스 소유자가 TLS, 라우팅, 기타 정책을 완전히 제어합니다.

인그레스에 일반적인 사용 패턴이지만 공유 리소스가 없기 때문에 많은 팀으로 확장하기는 어렵습니다. 게이트웨이 API 리소스 모델은 다양한 분산 제어 및 소유권 옵션을 제공하는 다음과 같은 사용 패턴을 지원합니다.

네임스페이스별 플랫폼 관리형 게이트웨이

게이트웨이 리소스와 경로 리소스를 분리하면 플랫폼 관리자가 서비스 소유자를 대신하여 게이트웨이를 제어할 수 있습니다. 플랫폼 관리자는 네임스페이스나 팀별로 게이트웨이를 배포하여 해당 네임스페이스에 게이트웨이를 사용할 수 있는 전용 액세스 권한을 부여할 수 있습니다. 따라서 서비스 소유자는 다른 팀과 충돌할 위험 없이 라우팅 규칙을 완전히 제어할 수 있습니다. 이렇게 하면 플랫폼 관리자가 IP 할당, 포트 노출, 프로토콜, 도메인, TLS와 같은 측면을 제어할 수 있습니다. 플랫폼 관리자는 내부 또는 외부 게이트웨이와 같은 팀에서 사용할 수 있는 게이트웨이 종류를 결정할 수도 있습니다. 이 사용 패턴에서는 서로 다른 역할 간에 책임을 명확하게 구분합니다.

네임스페이스 간 라우팅을 사용하면 경로를 네임스페이스 경계의 게이트웨이에 연결할 수 있습니다. 게이트웨이가 경로를 연결할 수 있는 네임스페이스를 제한할 수 있습니다. 마찬가지로 경로에서 연결되는 게이트웨이를 지정하지만 경로는 해당 경로의 네임스페이스를 허용하는 게이트웨이에만 연결할 수 있습니다. 이 양방향 연결로 양측에 사용 패턴의 다양성을 지원하는 유연한 제어를 제공합니다.

다음 다이어그램에서 플랫폼 관리자는 네임스페이스마다 배타적 액세스를 사용되는 게이트웨이를 배포했습니다. 예를 들어 store 게이트웨이는 store 네임스페이스의 경로만 연결할 수 있도록 구성됩니다. 각 게이트웨이는 고유한 부하 분산 IP 주소를 나타내므로 각 팀에서 선택한 도메인이나 경로에 사용되는 게이트웨이에 개수에 관계없이 경로를 배포할 수 있습니다.

클러스터별 공유 게이트웨이

네임스페이스 간에 게이트웨이를 공유하면 플랫폼 관리자에게 더욱 중앙화된 형태의 소유권이 제공됩니다. 이를 통해 서로 다른 네임스페이스에서 실행되는 여러 서비스 소유자가 동일한 IP 주소, DNS 도메인, 인증서 또는 경로를 공유하여 서비스 간에 세분화된 라우팅을 수행할 수 있습니다. 게이트웨이를 사용하면 플랫폼 관리자가 특정 도메인으로 라우팅할 수 있는 네임스페이스를 제어할 수 있습니다. 게이트웨이가 둘 이상의 네임스페이스에서 경로 연결을 허용한다는 점을 제외하면 이전의 예시와 비슷합니다.

다음 다이어그램에서 플랫폼 관리자는 infra 네임스페이스에 게이트웨이 두 개를 배포했습니다. external 게이트웨이는 web 및 mobile 네임스페이스의 경로를 게이트웨이에 연결하도록 허용합니다. accounts 네임스페이스는 내부 서비스 전용이므로 accounts 네임스페이스의 경로에서 external 게이트웨이를 사용할 수 없습니다. internal 게이트웨이를 사용하면 내부 클라이언트가 비공개 IP 주소를 사용하여 VPC 내에서 비공개로 통신할 수 있습니다.

m.example.com 도메인은 mobile 네임스페이스로 위임되므로 모바일 서비스 소유자가 m.example.com 도메인에서 필요한 라우팅 규칙을 구성할 수 있습니다. 이를 통해 서비스 소유자가 새로운 API 엔드포인트를 도입하고 관리자 변경 요청 없이 트래픽을 제어할 수 있습니다.

Fleet별 공유 게이트웨이

멀티 클러스터 게이트웨이를 사용하면 네임스페이스, 클러스터, 리전 모두에서 게이트웨이를 공유할 수 있습니다. 지리적으로 분산된 앱이 있는 대규모 조직은 라우팅 소유권을 위임하는 동시에 전역 트래픽을 세밀하게 제어할 수 있으므로 멀티 클러스터 게이트웨이의 이점을 얻을 수 있습니다. 앞의 예시와 마찬가지로 플랫폼 관리자는 게이트웨이를 관리하고 라우팅을 위임합니다. 이 사용 사례의 주요 추가 사항은 경로가 클러스터 전체에 배포되는 멀티 클러스터 서비스를 참조한다는 점입니다. 트래픽은 명시적 방식으로 라우팅될 수 있고 store.example.com/us에 대한 트래픽은 gke-us 포드로 이동하거나 example.com/*에 대한 트래픽은 암시적 방식으로 클라이언트와 가장 가까운 클러스터로 라우팅됩니다. 이러한 유연성으로 서비스 소유자는 애플리케이션에 가장 적합한 라우팅 전략을 정의할 수 있습니다.

GKE 게이트웨이 컨트롤러

GKE 게이트웨이 컨트롤러는 Cloud Load Balancing을 위한 Google의 Gateway API 구현입니다. GKE 인그레스 컨트롤러와 비슷하게, 게이트웨이 컨트롤러는 Kubernetes API에서 Gateway API 리소스를 감시하고, Cloud Load Balancing 리소스를 조정하여 게이트웨이 리소스에서 지정된 네트워킹 동작을 구현합니다.

GKE 게이트웨이 컨트롤러는 두 가지 버전이 있습니다.

• 단일 클러스터: 단일 GKE 클러스터에 대한 단일 클러스터 게이트웨이를 관리합니다.
• 멀티 클러스터: GKE 클러스터 하나 이상에 대한 멀티 클러스터 게이트웨이를 관리합니다.

두 게이트웨이 컨트롤러 모두 Kubernetes API에서 GKE 클러스터를 감시하는 Google에서 호스팅되는 컨트롤러입니다. GKE 인그레스 컨트롤러와 달리 게이트웨이 컨트롤러는 GKE 제어 영역 또는 사용자 프로젝트에 호스팅되지 않으며, 확장성 및 강력한 성능을 지원합니다. 두 게이트웨이 컨트롤러 모두 정식 버전으로 제공됩니다.

게이트웨이 컨트롤러 자체는 네트워킹 데이터 영역이 아니며 트래픽을 처리하지 않습니다. 이는 트래픽을 대역 외로 배포하며 트래픽을 처리하는 다양한 데이터 영역을 관리합니다. 다음 다이어그램은 단일 클러스터 및 멀티 클러스터 GKE 게이트웨이 컨트롤러의 아키텍처를 보여줍니다. 사용되는 기본 컨트롤러는 배포된 게이트웨이의 GatewayClass에 따라 다릅니다.

Google에서 제공되지 않는 컨트롤러를 포함하여 여러 게이트웨이 컨트롤러를 GKE 클러스터에서 동시에 사용할 수 있습니다. 모든 GatewayClass는 단 하나의 게이트웨이 컨트롤러에서만 지원되며, 단일 및 멀티 클러스터 부하 분산을 동시에 사용하도록 지원합니다.

인그레스 및 게이트웨이

인그레스 및 게이트웨이 비교

게이트웨이와 인그레스는 둘 다 트래픽 라우팅을 위한 오픈소스 표준입니다. 게이트웨이는 인그레스 및 서비스 메시 에코시스템에서 얻은 교훈을 활용하여 Kubernetes 커뮤니티에 의해 설계되었습니다. 게이트웨이는 인그레스 기능의 상위 집합으로서 제공되는 것과 동일한 기능을 제공하는 인그레스의 발전된 형태입니다. 두 가지 모두 충돌 없이 동시에 사용될 수 있지만, 시간이 지날수록 게이트웨이 및 경로 리소스가 인그레스에서 제공되지 않는 더 많은 기능을 제공할 것입니다. 따라서 이전에 인그레스를 사용한 경우에도 사용자의 게이트웨이 사용이 늘어날 것으로 보입니다.

GKE에서 모든 인그레스 리소스는 게이트웨이 및 HTTPRoute 리소스로 직접 변환할 수 있습니다. 단일 인그레스는 게이트웨이(프런트엔드 구성) 및 HTTPRoute(라우팅 구성) 모두에 해당합니다. 다음 예시에서는 해당 게이트웨이 및 HTTPRoute 구성을 보여줍니다. 게이트웨이 및 HTTPRoute 리소스는 각기 다른 사용자에 의해 별도로 생성될 수 있습니다. 게이트웨이에는 여러 경로가 있을 수 있으며, 한 경로를 둘 이상의 게이트웨이에 연결할 수도 있습니다. 게이트웨이와 경로 간의 관계는 게이트웨이 사용 패턴에서 설명합니다.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
  annotations:
    kubernetes.io/ingress.class: "gce-internal"
spec:
  rules:
  - host: "example.com"
    http:
      paths:
      - pathType: Prefix
        path: /
        backend:
          service:
            name: site
            port:
              number: 80
      - pathType: Prefix
        path: /shop
        backend:
          service:
            name: store
            port:
              number: 80

apiVersion: gateway.networking.k8s.io/v1beta1
kind: Gateway
metadata:
  name: my-gateway
spec:
  gatewayClassName: gke-l7-rilb
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    allowedRoutes:
      kinds:
      - kind: HTTPRoute

apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: my-route
spec:
  parentRefs:
  - name: my-gateway
  hostnames:
  - "example.com"
  rules:
  - matches:
    - path:
        value: /
    backendRefs:
    - name: site
      port: 80
  - matches:
    - path:
        value: /shop
    backendRefs:
    - name: store
      port: 80

Gateway API와 서비스 메시 통합

Gateway API를 사용하여 Cloud Service Mesh 서비스 메시를 구성할 수 있습니다. 이렇게 하면 서비스 메시 사용 사례에 대한 서비스 간 통신, 트래픽 관리, 전역 부하 분산, 보안 정책 시행이 지원됩니다. 배포 설정 가이드를 포함하여 Gateway API에서 Cloud Service Mesh 사용에 관한 모든 정보는 Cloud Service Mesh GKE 서비스 메시 개요를 참조하세요.

가격 책정

게이트웨이 컨트롤러를 통해 배포되는 모든 Compute Engine 리소스는 GKE 클러스터가 있는 프로젝트에 따라 비용이 청구됩니다. 단일 클러스터 게이트웨이 컨트롤러는 GKE Standard 및 Autopilot 가격 책정에 따라 추가 비용 없이 제공됩니다. 멀티 클러스터 게이트웨이 가격 책정은 멀티 클러스터 인그레스 및 게이트웨이 가격 책정 페이지에 설명되어 있습니다.

다음 단계

• 정책을 사용하여 게이트웨이 리소스 구성 방법 알아보기
• 게이트웨이 배포 알아보기

• 멀티 클러스터 게이트웨이 배포 알아보기

• Gateway API에서 Cloud Service Mesh 사용에 관한 모든 정보는 Cloud Service Mesh GKE 서비스 메시 개요를 참조하세요.