Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

정책을 사용하여 게이트웨이 리소스 구성

이 페이지에서는 GKE 클러스터에 게이트웨이를 배포할 때 Google Kubernetes Engine(GKE)이 만드는 부하 분산기를 구성하는 방법을 보여줍니다.

게이트웨이를 배포할 때 GatewayClass 구성이 GKE에서 만드는 부하 분산기를 결정합니다. 이 관리형 부하 분산기는 정책을 사용하여 수정할 수 있는 기본 설정으로 사전 구성됩니다.

게이트웨이, 서비스 또는 ServiceImport에 정책을 연결하여 인프라 또는 애플리케이션 요구사항에 맞게 게이트웨이 리소스를 맞춤설정할 수 있습니다. 정책을 적용하거나 수정하면 게이트웨이 컨트롤러가 이를 처리하고 기본 부하 분산기 리소스를 자동으로 재구성합니다. 이렇게 하면 게이트웨이, 경로 또는 서비스 리소스를 삭제하거나 다시 만들 필요가 없습니다.

시작하기 전에

시작하기 전에 다음 태스크를 수행했는지 확인합니다.

Google Kubernetes Engine API를 사용 설정합니다.

Google Kubernetes Engine API 사용 설정

이 태스크에 Google Cloud CLI를 사용하려면 gcloud CLI를 설치한 후 초기화합니다. 이전에 gcloud CLI를 설치했으면 gcloud components update 명령어를 실행하여 최신 버전을 가져옵니다. 이전 gcloud CLI 버전에서는 이 문서의 명령어를 실행하지 못할 수 있습니다.
참고: 기존 gcloud CLI 설치의 경우 compute/region 속성을 설정해야 합니다. 주로 영역 클러스터를 사용하는 경우에는 대신 compute/zone을 설정합니다. 기본 위치를 설정하면 gcloud CLI에서 One of [--zone, --region] must be supplied: Please specify location과 같은 오류를 방지할 수 있습니다. 클러스터의 위치가 설정한 기본값과 다른 경우 특정 명령어에서 위치를 지정해야 할 수 있습니다.

기존 Autopilot 또는 Standard 클러스터가 있는지 확인합니다. 새 클러스터를 만들려면 Autopilot 클러스터 만들기를 참조하세요.

GKE Gateway Controller 요구사항

Gateway API는 VPC 기반 클러스터에서만 지원됩니다.
리전 또는 교차 리전 GatewayClass를 사용하는 경우 프록시 전용 서브넷을 사용 설정해야 합니다.
클러스터에 HttpLoadBalancing 부가기능이 사용 설정되어 있어야 합니다.
Istio를 사용하는 경우 Istio를 다음 버전 중 하나로 업그레이드해야 합니다.
- 1.15.2 이상
- 1.14.5 이상
- 1.13.9 이상
공유 VPC를 사용하는 경우 호스트 프로젝트에서 서비스 프로젝트에 대해 GKE 서비스 계정에 Compute Network User 역할을 할당해야 합니다.

제한 및 한도

GKE 게이트웨이 컨트롤러 제한 및 한도 외에도 다음 제한사항이 게이트웨이 리소스에 적용되는 정책에 적용됩니다.

GCPGatewayPolicy 리소스는 gateway.networking.k8s.io Gateway에만 연결할 수 있습니다.
GCPGatewayPolicy 리소스는 대상 Gateway와 동일한 네임스페이스에 있어야 합니다.
단일 클러스터 게이트웨이, GCPBackendPolicy, HealthCheckPolicy를 사용할 때 리소스는 Service 리소스를 참조해야 합니다.
멀티 클러스터 게이트웨이, GCPBackendPolicy, HealthCheckPolicy를 사용할 때 리소스는 ServiceImport 리소스를 참조해야 합니다.
한 번에 GCPBackendPolicy 하나만 서비스에 연결할 수 있습니다. 동일한 Service 또는 ServiceImport를 타겟팅하는 GCPBackendPolicy 정책이 2개 생성되면 가장 오래된 정책이 우선 적용되고 두 번째 정책은 연결되지 않습니다.
계층적 정책은 GKE 게이트웨이에서 지원되지 않습니다.
HealthCheckPolicy 및 GCPBackendPolicy 리소스는 대상 Service 또는 ServiceImport 리소스와 동일한 네임스페이스에 있어야 합니다.
GCPBackendPolicy 및 HealthCheckPolicy 리소스는 백엔드 서비스를 하나만 참조할 수 있는 방식으로 구성됩니다.
GCPBackendPolicy는 세션 어피니티에 HEADER_FIELD 또는 HTTP_COOKIE 옵션을 지원하지 않습니다. HEADER_FIELD 또는 HTTP_COOKIE 세션 어피니티의 경우 GCPTrafficDistributionPolicy 리소스를 사용합니다.
범위가 다른 게이트웨이 (예: 전역 외부 및 리전 내부)를 사용하는 경우 서로 다른 GCPBackendPolicy 구성이 필요한 경우 동일한 백엔드 Service을 사용할 수 없습니다. 예를 들어 전역 GCPBackendPolicy는 리전 범위 게이트웨이에 적용할 수 없으며 그 반대도 마찬가지입니다. 올바른 범위별 정책을 보장하려면 각 게이트웨이 범위에 대해 별도의 Service를 만드세요.
GCPTrafficDistributionPolicy를 사용하여 구성된 세션 어피니티는 단일 클러스터 게이트웨이에서만 지원됩니다.
GCPTrafficDistributionPolicy 세션 어피니티는 전용 위치 부하 분산 알고리즘을 사용하므로 InferencePool 리소스와 호환되지 않습니다.
GCPTrafficDistributionPolicy는 기본 애플리케이션 부하 분산기의 세션 어피니티 또는 지역 부하 분산 정책 구성을 지원하지 않습니다.

리전 내부 게이트웨이의 전역 액세스 구성

이 섹션에서는 버전 1.24 이상을 실행하는 GKE 클러스터에서 사용할 수 있는 기능을 설명합니다.

내부 게이트웨이를 사용하여 전역 액세스를 사용 설정하려면 게이트웨이 리소스에 정책을 연결합니다.

다음 GCPGatewayPolicy 매니페스트는 전역 액세스를 위해 리전별 내부 게이트웨이를 사용 설정합니다.

apiVersion: networking.gke.io/v1
kind: GCPGatewayPolicy
metadata:
  name: my-gateway-policy
  namespace: default
spec:
  default:
    # Enable global access for the regional internal Application Load Balancer.
    allowGlobalAccess: true
  targetRef:
    group: gateway.networking.k8s.io
    kind: Gateway
    name: my-gateway

멀티 클러스터 게이트웨이의 리전 구성

이 섹션에서는 버전 1.30.3-gke.1225000 이상을 실행하는 GKE 클러스터에서 사용할 수 있는 기능을 설명합니다.

여러 리전에 클러스터가 있는 경우 교차 리전 중복, 낮은 지연 시간, 데이터 주권과 같은 다양한 사용 사례를 위해 여러 리전에 리전별 게이트웨이를 배포해야 할 수 있습니다. 멀티 클러스터 게이트웨이 구성 클러스터에서 리전별 게이트웨이를 배포할 리전을 지정할 수 있습니다. 리전을 지정하지 않으면 기본 리전은 구성 클러스터의 리전입니다.

멀티 클러스터 게이트웨이의 리전을 구성하려면 GCPGatewayPolicy의 region 필드를 사용합니다. 다음 예에서는 게이트웨이가 us-central1 리전에 구성되어 있습니다.

apiVersion: networking.gke.io/v1
kind: GCPGatewayPolicy
metadata:
  name: my-gateway-policy
  namespace: default
spec:
  default:
    region: us-central1
  targetRef:
    group: gateway.networking.k8s.io
    kind: Gateway
    name: my-regional-gateway

클라이언트 및 부하 분산기 간 트래픽 보호를 위한 SSL 정책 구성

이 섹션에서는 버전 1.24 이상을 실행하는 GKE 클러스터에서 사용할 수 있는 기능을 설명합니다.

클라이언트 및 부하 분산기 간 트래픽을 보호하려면 정책 이름을 GCPGatewayPolicy에 추가하여 SSL 정책을 구성합니다. 기본적으로 게이트웨이에는 SSL 정책이 정의 및 연결되어 있지 않습니다.

GCPGatewayPolicy에서 정책을 참조하기 전에 SSL 정책 만들기를 수행해야 합니다.

다음 GCPGatewayPolicy 매니페스트는 gke-gateway-ssl-policy라는 보안 정책을 지정합니다.

apiVersion: networking.gke.io/v1
kind: GCPGatewayPolicy
metadata:
  name: my-gateway-policy
  namespace: team1
spec:
  default:
    sslPolicy: gke-gateway-ssl-policy
  targetRef:
    group: gateway.networking.k8s.io
    kind: Gateway
    name: my-gateway

상태 확인 구성

이 섹션에서는 버전 1.24 이상을 실행하는 GKE 클러스터에서 사용할 수 있는 기능을 설명합니다.

기본적으로 HTTP 또는 kubernetes.io/h2c 애플리케이션 프로토콜을 사용하는 백엔드 서비스의 경우 HealthCheck는 HTTP 유형입니다. HTTPS 프로토콜의 경우 기본 HealthCheck는 HTTPS 유형입니다. HTTP2 프로토콜의 경우 기본 HealthCheck는 HTTP2 유형입니다.

HealthCheckPolicy를 사용하여 부하 분산기 상태 점검 설정을 제어할 수 있습니다. 각 유형의 상태 점검 (http, https, grpc, http2, tcp)에는 정의할 수 있는 파라미터가 있습니다. Google Cloud는 각 GKE 서비스의 백엔드 서비스마다 고유한 상태 점검을 만듭니다.

부하 분산기가 정상적으로 작동하려면 상태 확인 경로가 표준 '/'이 아닌 경우 부하 분산기에 맞게 맞춤 HealthCheckPolicy를 구성해야 할 수 있습니다. 경로에 특수 헤더가 필요하거나 상태 확인 매개변수를 조정해야 하는 경우에도 이 구성이 필요합니다. 예를 들어 기본 요청 경로가 '/'이지만 해당 요청 경로에서 서비스에 액세스할 수 없고 대신 '/health'를 사용하여 상태를 보고하는 경우 적절하게 HealthCheckPolicy에서 requestPath를 구성해야 합니다.

다음 HealthCheckPolicy 매니페스트에서는 상태 점검 정책을 구성할 때 사용할 수 있는 모든 필드를 보여줍니다.

서비스

# Health check configuration for the load balancer. For more information
# about these fields, see https://cloud.google.com/compute/docs/reference/rest/v1/healthChecks.
apiVersion: networking.gke.io/v1
kind: HealthCheckPolicy
metadata:
  name: lb-healthcheck
  namespace: lb-service-namespace
spec:
  default:
    checkIntervalSec: INTERVAL  # The default value is 15 seconds.
    timeoutSec: TIMEOUT
    healthyThreshold: HEALTHY_THRESHOLD
    unhealthyThreshold: UNHEALTHY_THRESHOLD
    logConfig:
      enabled: true
    config:
      type: PROTOCOL
      httpHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      httpsHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      grpcHealthCheck:
        grpcServiceName: GRPC_SERVICE_NAME
        portSpecification: PORT_SPECIFICATION
        port: PORT
      http2HealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      tcpHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        portName: PORT_NAME
        request: REQUEST
        response: RESPONSE
        proxyHeader: PROXY_HEADER
  # Attach to a Service in the cluster.
  targetRef:
    group: ""
    kind: Service
    name: lb-service

멀티 클러스터 서비스

apiVersion: networking.gke.io/v1
kind: HealthCheckPolicy
metadata:
  name: lb-healthcheck
  namespace: lb-service-namespace
spec:
  # The default and config fields control the health check configuration for the
  # load balancer. For more information about these fields, see
  # https://cloud.google.com/compute/docs/reference/rest/v1/healthChecks.
  default:
    checkIntervalSec: INTERVAL
    timeoutSec: TIMEOUT
    healthyThreshold: HEALTHY_THRESHOLD
    unhealthyThreshold: UNHEALTHY_THRESHOLD
    logConfig:
      enabled: ENABLED
    config:
      type: PROTOCOL
      httpHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      httpsHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      grpcHealthCheck:
        grpcServiceName: GRPC_SERVICE_NAME
        portSpecification: PORT_SPECIFICATION
        port: PORT
      http2HealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      tcpHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        portName: PORT_NAME
        request: REQUEST
        response: RESPONSE
        proxyHeader: PROXY_HEADER
  # Attach to a multi-cluster Service by referencing the ServiceImport.
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

다음을 바꿉니다.

INTERVAL: 각 상태 점검 프로버의 check-interval을 초 단위로 지정합니다. 이 값은 한 프로버에서 확인을 시작한 후 다음 번에 확인을 시작할 때까지 걸리는 시간입니다. 이 매개변수를 생략하면 HealthCheckPolicy가 지정되지 않은 경우 Google Cloud 기본값은 15초이고 checkIntervalSec 값이 없는 HealthCheckPolicy가 지정된 경우 5초입니다. 자세한 내용은 여러 프로브 및 빈도를 참조하세요.
TIMEOUT:Google Cloud 가 프로브에 대한 응답을 대기하는 시간입니다. TIMEOUT 값은 INTERVAL 이하여야 합니다. 단위는 초입니다. 각 프로브에는 프로브 제한 시간 전에 HTTP 200 (OK) 응답 코드가 전달되어야 합니다.
HEALTHY_THRESHOLD 및 UNHEALTHY_THRESHOLD: 프로버 최소 하나 이상에서 상태가 정상에서 비정상으로 또는 정상에서 정상으로 변경되도록 성공하거나 실패해야 하는 순차적 연결 시도 수를 지정합니다. 이러한 매개변수 중 하나를 생략하면 Google Cloud 기본값은 2입니다.
PROTOCOL: 프로브 시스템에서 상태 점검에 사용되는 프로토콜을 지정합니다. 자세한 내용은 HTTP, HTTPS, HTTP/2의 성공 기준, gRPC의 성공 기준, TCP의 성공 기준을 참고하세요. 이 매개변수는 필수항목입니다.
ENABLED: 로깅이 사용 설정 또는 중지되었는지 여부를 지정합니다.
PORT_SPECIFICATION: 상태 점검에서 고정 포트(USE_FIXED_PORT), 이름이 지정된 포트(USE_NAMED_PORT) 또는 서빙 포트(USE_SERVING_PORT)를 사용하는지 지정합니다. 지정되지 않으면 상태 점검에서 port 필드에 지정된 동작을 수행합니다. port가 지정되지 않으면 이 필드의 기본값은 USE_SERVING_PORT입니다.
PORT: HealthCheckPolicy만 포트 번호를 사용하여 부하 분산기 상태 점검 포트 지정을 지원합니다. 이 매개변수를 생략하면 Google Cloud 기본값은 80입니다. 부하 분산기는 프로브를 포드의 IP 주소로 직접 전송하므로 서비스의 targetPort에서 containerPort를 참조하더라도 서빙 포드의 containerPort와 일치하는 포트를 선택해야 합니다. 서비스의 targetPort에서 참조하는 containerPorts로 제한되지 않습니다.
HOST: 상태 점검 요청의 호스트 헤더 값입니다. 숫자 IP 주소가 허용되지 않는 경우를 제외하고 이 값에는 호스트 이름의 RFC 1123 정의가 사용됩니다. 지정하지 않거나 비워 두면 값이 기본적으로 상태 점검의 IP 주소로 지정됩니다.
REQUEST: TCP 연결이 설정된 후 전송할 애플리케이션 데이터를 지정합니다. 지정하지 않으면 기본값은 비어 있습니다. 요청과 응답이 모두 비어 있으면 설정된 연결 자체가 정상임을 나타냅니다. 요청 데이터는 ASCII 형식만 가능합니다.
REQUEST_PATH: 상태 점검 요청의 요청 경로를 지정합니다. 지정하지 않거나 비워두면 기본값은 /입니다.
RESPONSE: 응답 데이터의 시작 부분과 비교할 바이트를 지정합니다. 값을 지정하지 않거나 비워두면 GKE에서 응답을 정상으로 해석합니다. 응답 데이터는 ASCII여야 합니다.
PROXY_HEADER: 프록시 헤더 유형을 지정합니다. NONE 또는 PROXY_V1을 사용할 수 있습니다. 기본값은 NONE입니다.
GRPC_SERVICE_NAME: gRPC 서비스의 선택적인 이름입니다. 모든 서비스를 지정하려면 이 필드를 생략합니다.

HealthCheckPolicy 필드에 대한 자세한 내용은 healthChecks 참조를 확인하세요.

Cloud Armor 백엔드 보안 정책을 구성하여 백엔드 서비스 보호

이 섹션에서는 버전 1.24 이상을 실행하는 GKE 클러스터에서 사용할 수 있는 기능을 설명합니다.

백엔드 서비스를 보호하기 위해 GCPBackendPolicy에 보안 정책 이름을 추가하여 Cloud Armor 백엔드 보안 정책을 구성합니다. 기본적으로 게이트웨이에는 Cloud Armor 백엔드 보안 정책이 정의 및 연결되어 있지 않습니다.

GCPBackendPolicy에서 정책을 참조하기 전에 Cloud Armor 백엔드 보안 정책을 만들어야 합니다. 리전별 게이트웨이를 사용 설정하는 경우 리전별 Cloud Armor 백엔드 보안 정책을 만들어야 합니다.

다음 GCPBackendPolicy 매니페스트는 example-security-policy라는 백엔드 보안 정책을 지정합니다.

서비스

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    # Apply a Cloud Armor security policy.
    securityPolicy: example-security-policy
  # Attach to a Service in the cluster.
  targetRef:
    group: ""
    kind: Service
    name: lb-service

멀티 클러스터 서비스

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    # Apply a Cloud Armor security policy.
    securityPolicy: example-security-policy
  # Attach to a multi-cluster Service by referencing the ServiceImport.
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

IAP 구성

IAP(Identity-Aware Proxy)는 HTTPRoute와 연결된 백엔드 서비스에 대해 액세스 제어 정책을 적용합니다. 이 시행을 통해 올바른 Identity and Access Management(IAM) 역할이 할당된 인증된 사용자 또는 애플리케이션만 이러한 백엔드 서비스에 액세스할 수 있습니다.

기본적으로 백엔드 서비스에 적용된 IAP가 없으므로 GCPBackendPolicy에서 IAP를 명시적으로 구성해야 합니다.

게이트웨이로 IAP를 구성하려면 다음을 수행합니다.

OAuth 클라이언트의 클라이언트 ID와 클라이언트 보안 비밀번호를 가져옵니다. 클라이언트 보안 비밀번호는 OAuth 클라이언트를 만들 때만 사용할 수 있습니다. 자세한 내용은 OAuth 클라이언트 관리를 참고하세요.
GKE용 IAP를 사용 설정합니다.

BackendConfig는 인그레스 구성 리소스이므로 BackendConfig를 만들지 않아도 됩니다.

보안 비밀을 참조하는 IAP 정책을 지정하려면 다음 안내를 따르세요.

다음 GCPBackendPolicy 매니페스트를 backend-policy.yaml로 저장합니다.

서비스

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: backend-policy
spec:
  default:
    # IAP OAuth2 settings. For more information about these fields,
    # see https://cloud.google.com/iap/docs/reference/rest/v1/IapSettings#oauth2.
    iap:
      enabled: true
      oauth2ClientSecret:
        name: CLIENT_SECRET
      clientID: CLIENT_ID
  # Attach to a Service in the cluster.
  targetRef:
    group: ""
    kind: Service
    name: SERVICE_NAME

다음을 바꿉니다.

CLIENT_SECRET: OAuth 클라이언트 보안 비밀번호입니다.
CLIENT_ID: OAuth 클라이언트 ID입니다.
SERVICE_NAME: GCPBackendPolicy에서 타겟팅할 서비스의 이름입니다.

멀티 클러스터 서비스

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: backend-policy
spec:
  default:
    # IAP OAuth2 settings. For more information about these fields,
    # see https://cloud.google.com/iap/docs/reference/rest/v1/IapSettings#oauth2.
    iap:
      enabled: true
      oauth2ClientSecret:
        name: CLIENT_SECRET
      clientID: CLIENT_ID
  # Attach to a multi-cluster Service by referencing the ServiceImport.
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: SERVICEIMPORT_NAME

다음을 바꿉니다.

CLIENT_SECRET: OAuth 클라이언트 보안 비밀번호입니다.
CLIENT_ID: OAuth 클라이언트 ID입니다.
SERVICEIMPORT_NAME: GCPBackendPolicy에서 타겟팅할 ServiceImport의 이름입니다.

backend-policy.yaml 매니페스트를 적용합니다.
```
kubectl apply -f backend-policy.yaml
```

구성을 확인합니다

IAP로 GCPBackendPolicy를 만든 후 정책이 적용되었는지 확인합니다.
```
kubectl get gcpbackendpolicy
```
출력은 다음과 비슷합니다.
```
NAME             AGE
backend-policy   45m
```

더 많은 세부정보를 확인하려면 describe 명령어를 사용합니다.

kubectl describe gcpbackendpolicy

출력은 다음과 비슷합니다.

Name:         backend-policy
Namespace:    default
Labels:       <none>
Annotations:  <none>
API Version:  networking.gke.io/v1
Kind:         GCPBackendPolicy
Metadata:
  Creation Timestamp:  2023-05-27T06:45:32Z
  Generation:          2
  Resource Version:    19780077
  UID:                 f4f60a3b-4bb2-4e12-8748-d3b310d9c8e5
Spec:
  Default:
    Iap:
      Client ID:  441323991697-luotsrnpboij65ebfr13hlcpm5a4heke.apps.googleusercontent.com
      Enabled:    true
      oauth2ClientSecret:
        Name:  my-iap-secret
  Target Ref:
    Group:
    Kind:   Service
    Name:   lb-service
Status:
  Conditions:
    Last Transition Time:  2023-05-27T06:48:25Z
    Message:
    Reason:                Attached
    Status:                True
    Type:                  Attached
Events:
  Type     Reason  Age                 From                   Message
  ----     ------  ----                ----                   -------
  Normal   ADD     46m                 sc-gateway-controller  default/backend-policy
  Normal   SYNC    44s (x15 over 43m)  sc-gateway-controller  Application of GCPBackendPolicy "default/backend-policy" was a success

백엔드 서비스 제한 시간 구성

이 섹션에서는 버전 1.24 이상을 실행하는 GKE 클러스터에서 사용할 수 있는 기능을 설명합니다.

다음 GCPBackendPolicy 매니페스트는 백엔드 서비스 제한 시간을 40초로 지정합니다. timeoutSec 필드의 기본값은 30초입니다.

서비스

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    # Backend service timeout, in seconds, for the load balancer. The default
    # value is 30.
    timeoutSec: 40
  # Attach to a Service in the cluster.
  targetRef:
    group: ""
    kind: Service
    name: lb-service

멀티 클러스터 서비스

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    timeoutSec: 40
  # Attach to a multi-cluster Service by referencing the ServiceImport.
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

`GCPBackendPolicy`를 사용하여 백엔드 선택 구성

GCPBackendPolicy 내의 CUSTOM_METRICS 분산 모드를 사용하면 부하 분산기의 백엔드 서비스가 트래픽을 분산하는 방식에 영향을 미치는 특정 맞춤 측정항목을 구성할 수 있습니다. 이 분산 모드를 사용하면 정의하고 애플리케이션 백엔드에서 보고하는 커스텀 측정항목을 기반으로 부하 분산을 사용할 수 있습니다.

자세한 내용은 커스텀 측정항목 기반 부하 분산을 사용한 트래픽 관리를 참고하세요.

backends[] 필드의 customMetrics[] 배열에는 다음 필드가 포함됩니다.

name: 맞춤 측정항목의 사용자 정의 이름을 지정합니다.
maxUtilization: 이 측정항목의 타겟 또는 최대 사용률을 설정합니다. 유효한 범위는 [0, 100]입니다.
dryRun: 불리언 필드입니다. 이 속성이 true이면 측정항목 데이터가 Cloud Monitoring에 보고되지만 부하 분산 결정에는 영향을 미치지 않습니다.

예시

다음 예는 백엔드 선택 및 엔드포인트 수준 라우팅을 위한 맞춤 측정항목을 구성하는 GCPBackendPolicy 매니페스트를 보여줍니다.

다음 매니페스트를 my-backend-policy.yaml로 저장합니다.

kind: GCPBackendPolicy
apiVersion: networking.gke.io/v1
metadata:
  name: my-backend-policy
  namespace: team-awesome
spec:
  # Attach to the super-service Service.
  targetRef:
    kind: Service
    name: super-service
  default:
    backends:
    # Configuration for all locations.
    - location: "*"
      # Use the rate balancing mode for the load balancer.
      balancingMode: RATE
      # Maximum number of requests per second for each endpoint.
      maxRatePerEndpoint: 9000
    # Configuration for us-central1-a
    - location: us-central1-a
      # maxRatePerEndpoint: 9000 inherited from the * configuration.
      # Use the custom metrics balancing mode for the load balancer.
      balancingMode: CUSTOM_METRICS
      # Configure the custom metrics for the load balancer to use.
      customMetrics:
      - name: gpu-load
        maxUtilizationPercent: 100 # value ranges from 0 to 100 and maps to the floating point range [0.0, 1.0]
        dryRun: false

매니페스트를 클러스터에 적용합니다.
```
kubectl apply -f my-backend-policy.yaml
```

부하 분산기는 RATE 부하 분산 모드 및 맞춤 gpu-load 측정항목을 기반으로 트래픽을 분산합니다.

GCPTrafficDistributionPolicy로 엔드포인트 수준 라우팅 구성

Google Kubernetes Engine (GKE) Gateway의 GCPTrafficDistributionPolicy API는 트래픽이 애플리케이션 포드에 분산되는 방식을 정확하게 제어할 수 있는 고급 트래픽 관리 기능을 제공합니다. 이 통합된 GKE 네이티브 리소스를 사용하면 부하 분산 알고리즘과 세션 어피니티 설정을 간편하게 관리할 수 있습니다.

GCPTrafficDistributionPolicy를 사용하면 다음을 구성할 수 있습니다.

부하 분산 알고리즘: 백엔드 내 엔드포인트 간에 트래픽이 분산되는 방식을 지정합니다.
- WEIGHTED_ROUND_ROBIN: 이 알고리즘을 선택하면 부하 분산기가 맞춤 측정항목을 사용하여 가중치를 계산하고 보고된 측정항목을 기반으로 트래픽을 분산합니다. GCPTrafficDistributionPolicy 구성 내의 customMetrics[] 배열에는 다음 필드가 포함됩니다.
  - name: 맞춤 측정항목의 사용자 정의 이름을 지정합니다.
  - dryRun: true인 경우 측정항목 데이터가 Cloud Monitoring에 보고되지만 부하 분산에는 영향을 미치지 않습니다.
  참고: GCPTrafficDistributionPolicy 내에 정의된 맞춤 측정항목은 WEIGHTED_ROUND_ROBIN localityLbPolicy에만 적용되며 GCPBackendPolicy의 backends[].customMetrics[]에서 상속되지 않습니다.
RING_HASH: 이 알고리즘은 캐시 성능에 민감한 서비스에 유용합니다. 일관된 해싱을 사용하여 백엔드 포드가 추가되거나 삭제될 때 요청 재매핑을 최소화하므로 확장 이벤트 중에 안정성을 유지하는 데 도움이 됩니다. minimumHashRingSize를 구성하면 더 세부적인 부하 분산이 가능합니다.
세션 어피니티: 동일한 클라이언트의 요청이 일관되게 동일한 백엔드 포드로 라우팅되도록 지원합니다. 이는 전자상거래 장바구니나 게임 세션과 같은 상태 저장 워크로드에 매우 중요합니다. GKE Gateway는Google Cloud 애플리케이션 부하 분산기 인스턴스에서 사용할 수 있는 모든 세션 어피니티 유형(HEADER_FIELD 및 HTTP_COOKIE 포함)을 지원합니다.

자세한 내용은 커스텀 측정항목 기반 부하 분산을 사용한 트래픽 관리를 참고하세요.

예시

다음 예는 WEIGHTED_ROUND_ROBIN 부하 분산 알고리즘과 맞춤 측정항목을 모두 사용하여 엔드포인트 수준 라우팅을 구성하는 GCPTrafficDistributionPolicy 매니페스트를 보여줍니다.

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

apiVersion: networking.gke.io/v1
kind: GCPTrafficDistributionPolicy
metadata:
  name: echoserver-v2
  namespace: team1
spec:
  targetRefs:
  # Attach to the echoserver-v2 Service in the cluster.
  - kind: Service
    group: ""
    name: echoserver-v2
  default:
    # Use custom metrics to distribute traffic across endpoints.
    localityLbAlgorithm: WEIGHTED_ROUND_ROBIN
    # Configure metrics from an ORCA load report to use for traffic
    # distribution.
    customMetrics:
    - name: orca.named_metrics.bescm11
      dryRun: false
    - name: orca.named_metrics.bescm12
      dryRun: true

매니페스트를 클러스터에 적용합니다.

kubectl apply -f GCPTrafficDistributionPolicy.yaml

부하 분산기는 WEIGHTED_ROUND_ROBIN 알고리즘과 제공된 맞춤 측정항목을 기반으로 엔드포인트에 트래픽을 분산합니다.

해시 링 크기 구성

캐시 누락을 최소화하는 것이 중요한 서비스의 경우 RING_HASH 알고리즘을 사용합니다. minimumHashRingSize를 조정하면 백엔드 간에 더 세분화된 부하 분산이 가능합니다. 부하 분산기는 링 크기를 자동으로 관리하지만 최솟값을 높게 설정하면 더 큰 백엔드 세트의 요청을 더 균등하게 분산할 수 있습니다.

apiVersion: networking.gke.io/v1
kind: GCPTrafficDistributionPolicy
metadata:
  name: ring-hash-policy
  namespace: default
spec:
  default:
    localityLbAlgorithm: RING_HASH
    # Defaults to 1024. Larger ring sizes result in more granular
    # load distributions. Supported range is 1 to 2048.
    minimumHashRingSize: 1024
  targetRefs:
  -   group: ""
    kind: Service
    name: my-cache-heavy-service

세션 어피니티 구성

이 섹션에서는 버전 1.24 이상을 실행하는 GKE 클러스터에서 사용할 수 있는 기능을 설명합니다.

다음 기준에 따라 세션 어피니티를 구성할 수 있습니다.

클라이언트 IP 주소
생성된 쿠키

서비스에 세션 어피니티를 구성하면 게이트웨이의 localityLbPolicy 설정이 MAGLEV로 설정됩니다.

GCPBackendPolicy에서 세션 어피니티 구성을 삭제하면 게이트웨이가 localityLbPolicy 설정을 기본값 ROUND_ROBIN으로 되돌립니다.

다음 GCPBackendPolicy 매니페스트는 클라이언트 IP 주소에 따라 세션 어피니티를 지정합니다.

서비스

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    # On a best-effort basis, send requests from a specific client IP address
    # to the same backend. This field also sets the load balancer locality
    # policy to MAGLEV. For more information, see
    # https://cloud.google.com/load-balancing/docs/backend-service#lb-locality-policy
    sessionAffinity:
      type: CLIENT_IP
  targetRef:
    group: ""
    kind: Service
    name: lb-service

멀티 클러스터 서비스

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    # On a best-effort basis, send requests from a specific client IP address
    # to the same backend. This field also sets the load balancer locality
    # policy to MAGLEV. For more information, see
    # https://cloud.google.com/load-balancing/docs/backend-service#lb-locality-policy
    sessionAffinity:
      type: CLIENT_IP
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

다음 GCPBackendPolicy 매니페스트는 생성된 쿠키에 따라 세션 어피니티를 지정하고 쿠키 TTL을 50초로 구성합니다.

서비스

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    # Include an HTTP cookie in the Set-Cookie header of the response.
    # This field also sets the load balancer locality policy to MAGLEV. For more
    # information, see
    # https://cloud.google.com/load-balancing/docs/l7-internal#generated_cookie_affinity.
    sessionAffinity:
      type: GENERATED_COOKIE
      cookieTtlSec: 50  # The cookie expires in 50 seconds.
  targetRef:
    group: ""
    kind: Service
    name: lb-service

멀티 클러스터 서비스

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    # Include an HTTP cookie in the Set-Cookie header of the response.
    # This field also sets the load balancer locality policy to MAGLEV. For more
    # information, see
    # https://cloud.google.com/load-balancing/docs/l7-internal#generated_cookie_affinity.
    sessionAffinity:
      type: GENERATED_COOKIE
      cookieTtlSec: 50  # The cookie expires in 50 seconds.
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

sessionAffinity.type 필드에는 다음 값을 사용할 수 있습니다.

CLIENT_IP
GENERATED_COOKIE
NONE

`GCPTrafficDistributionPolicy`를 사용한 확장된 세션 어피니티

이 섹션에서는 버전 1.35.2-gke.1269001 이상을 실행하는 GKE 클러스터에서 사용할 수 있는 기능을 설명합니다.

GKE 게이트웨이는 GCPTrafficDistributionPolicy 리소스를 사용하여 확장된 세션 어피니티 유형을 지원합니다. 이렇게 하면 부하 분산기에서 생성된 맞춤 HTTP 헤더 또는 쿠키를 기반으로 라우팅하는 등 보다 세부적인 제어가 가능합니다.

참고: 고급 세션 어피니티의 경우 GCPTrafficDistributionPolicy를 사용하세요. GCPBackendPolicy는 특정 유형의 세션 어피니티도 지원하지만 이 구성에서는 기존 옵션으로 간주됩니다. 두 정책이 동일한 서비스를 타겟팅하는 경우 GCPTrafficDistributionPolicy 구성이 우선 적용됩니다.

다음 표에서는 GCPTrafficDistributionPolicy를 사용할 때 지원되는 선호도 유형을 설명합니다.

관심분야 유형	설명
`HEADER_FIELD`	특정 HTTP 헤더를 기반으로 하는 어피니티입니다. `localityLbAlgorithm`이 `MAGLEV` 또는 `RING_HASH`로 설정되어야 합니다.
`HTTP_COOKIE`	HTTP 쿠키를 기반으로 하는 어피니티입니다. 첫 번째 요청에 응답할 때 부하 분산기는 쿠키를 생성하여 `Set-Cookie` 응답 헤더에 제공합니다. 후속 요청에서 클라이언트는 부하 분산기에서 제공한 쿠키를 반환하고 부하 분산기는 이를 사용하여 요청을 동일한 포드로 일관되게 라우팅합니다. `cookie.name`를 구성해야 하며, 선택적으로 `cookie.path` 및 `cookie.ttl`를 구성할 수 있습니다. `localityLbAlgorithm`이 `MAGLEV` 또는 `RING_HASH`로 설정되어야 합니다.
`GENERATED_COOKIE`	부하 분산기는 세션을 추적하기 위해 쿠키를 생성합니다. 전역 외부 애플리케이션 부하 분산기의 쿠키 이름은 `GCLB`이고, 리전 내부 애플리케이션 부하 분산기 및 리전 외부 애플리케이션 부하 분산기의 쿠키 이름은 `GCILB`이며, 쿠키 경로는 `/`입니다. 원하는 경우 최대 2주까지 `cookie.ttl`를 구성할 수 있습니다. 이 유형에서는 `cookie.name` 및 `cookie.path`를 구성할 수 없습니다. `localityLbAlgorithm`이 `MAGLEV` 또는 `RING_HASH`로 설정되어야 합니다.
`CLIENT_IP`	클라이언트의 IP 주소를 기반으로 하는 어피니티입니다. `localityLbAlgorithm`이 `MAGLEV` 또는 `RING_HASH`로 설정되어야 합니다.

확장된 세션 어피니티 예

GCPTrafficDistributionPolicy는 여러 세션 어피니티 유형을 지원하며 각 유형에는 고유한 구성 요구사항이 있습니다.

HTTP 쿠키 기반 세션 어피니티 구성

장바구니나 게임 서버와 같은 스테이트풀(Stateful) 애플리케이션의 경우 사용자 세션 데이터를 보유한 특정 포드로 요청을 라우팅합니다. 이 구성은 HTTP_COOKIE 어피니티를 사용합니다. 이 어피니티는 부하 분산기에 의해 생성되고 Set-Cookie 헤더에서 클라이언트에 반환되는 특정 쿠키를 기반으로 세션 어피니티를 사용합니다.

다음 매니페스트를 policy.yaml로 저장합니다.

apiVersion: networking.gke.io/v1
kind: GCPTrafficDistributionPolicy
metadata:
  name: http-cookie-affinity-policy
  namespace: default
spec:
  default:
    sessionAffinity:
      type: HTTP_COOKIE
      cookie:
        name: "my-app-session-id"
        ttl: "1h"
        path: "/"
    # HTTP_COOKIE affinity requires localityLbAlgorithm to be MAGLEV or RING_HASH.
    localityLbAlgorithm: MAGLEV
  targetRefs:
  -   group: ""
    kind: Service
    name: my-stateful-service

클러스터에 정책을 적용합니다.
```
kubectl apply -f policy.yaml
```

쿠키 기반 세션 어피니티 TTL 0의 동작:

GENERATED_COOKIE 및 HTTP_COOKIE 어피니티와 같은 모든 쿠키 기반 세션 어피니티에는 ttl 속성이 있습니다.

TTL이 0초이면 부하 분산기가 쿠키에 Expires 속성을 할당하지 않습니다. 이 경우 클라이언트는 쿠키를 세션 쿠키로 취급합니다. 세션의 정의는 클라이언트에 따라 다릅니다.

웹브라우저와 같은 일부 클라이언트는 전체 탐색 세션 동안 쿠키를 유지합니다. 즉, 애플리케이션이 닫힐 때까지 여러 요청에 걸쳐 쿠키가 유지됩니다.
세션을 단일 HTTP 요청으로 취급하여 쿠키를 즉시 삭제하는 클라이언트도 있습니다.

헤더 기반 세션 어피니티 구성

쿠키가 적합하지 않은 A/B 테스트 또는 전문 클라이언트 라우팅과 같은 시나리오에서 특정 HTTP 헤더를 기반으로 트래픽을 라우팅합니다. NONE 이외의 세션 어피니티 유형을 사용하려면 localityLbAlgorithm을 MAGLEV 또는 RING_HASH로 설정해야 합니다. 기본 ROUND_ROBIN와 달리 이러한 알고리즘은 HTTP 헤더와 같은 맞춤 필드를 기반으로 일관된 해싱을 지원합니다.

다음 매니페스트를 policy.yaml로 저장합니다.

apiVersion: networking.gke.io/v1
kind: GCPTrafficDistributionPolicy
metadata:
  name: header-affinity-policy
  namespace: default
spec:
  default:
    sessionAffinity:
      type: HEADER_FIELD
      httpHeaderName: "X-User-Group-ID"
    localityLbAlgorithm: MAGLEV
  targetRefs:
  -   group: ""
    kind: Service
    name: SERVICE_NAME

클러스터에 정책을 적용합니다.
```
kubectl apply -f policy.yaml
```

정책 확인

GCPTrafficDistributionPolicy이 올바르게 구성되어 있고 활성 상태인지 확인하려면 적용 후 상태를 확인하세요.

정책의 상태를 확인하려면 정책을 설명합니다.
```
kubectl describe gcptrafficdistributionpolicy POLICY_NAME
```
POLICY_NAME을 정책 이름으로 바꿉니다.
출력에서 Conditions 섹션을 찾습니다. Attached 이유와 함께 True 상태는 구성이 유효하고 적용되었음을 나타냅니다.

연결 드레이닝 제한 시간 구성

이 섹션에서는 버전 1.24 이상을 실행하는 GKE 클러스터에서 사용할 수 있는 기능을 설명합니다.

GCPBackendPolicy를 사용하여 연결 드레이닝 제한 시간을 구성할 수 있습니다. 연결 드레이닝 제한 시간은 연결이 드레이닝될 때까지 기다리는 시간(초)입니다. 제한 시간을 0~3600초로 지정할 수 있습니다. 기본값은 0이며 이 경우 연결 드레이닝이 중지됩니다.

다음 GCPBackendPolicy 매니페스트는 연결 드레이닝 제한 시간을 60초로 지정합니다.

서비스

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    connectionDraining:
      drainingTimeoutSec: 60
  targetRef:
    group: ""
    kind: Service
    name: lb-service

멀티 클러스터 서비스

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    connectionDraining:
      drainingTimeoutSec: 60
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

지정된 제한 시간 동안 GKE는 삭제된 백엔드에 대한 기존 요청이 완료될 때까지 기다립니다. 부하 분산기는 새로운 요청을 삭제된 백엔드에 보내지 않습니다. 제한 시간에 도달하면 GKE는 백엔드에 남아있는 모든 연결을 닫습니다.

HTTP 액세스 로깅

이 섹션에서는 버전 1.24 이상을 실행하는 GKE 클러스터에서 사용할 수 있는 기능을 설명합니다.

기본적으로

게이트웨이 컨트롤러는 클라이언트의 모든 HTTP 요청을 Cloud Logging에 로깅합니다.
샘플링 레이트는 1,000,000이며, 이는 모든 요청이 로깅됨을 의미합니다.
선택적 필드는 로깅되지 않습니다.

다음 세 가지 방법으로 GCPBackendPolicy를 사용하여 게이트웨이에서 액세스 로깅을 사용 중지할 수 있습니다.

logging 섹션 없이 GCPBackendPolicy를 그대로 둘 수 있습니다.
logging.enabled를 false로 설정할 수 있습니다.
logging.enabled를 true로, logging.sampleRate를 0으로 설정할 수 있습니다.

액세스 로깅 샘플링 레이트와 선택적 필드 목록(예: 'tls.cipher' 또는 'orca_load_report')을 구성할 수도 있습니다.

선택적 필드의 로깅을 사용 설정하려면 다음 단계를 따르세요.

logging.OptionalMode를 CUSTOM으로 설정합니다.
logging.optionalFields에 로깅할 선택적 필드 목록을 제공합니다. 지원되는 필드 목록은 로깅 및 모니터링을 참고하세요.

다음 두 가지 방법으로 선택적 필드의 로깅을 사용 중지할 수 있습니다.

logging.optionalFields에서 모든 항목을 삭제할 수 있습니다.
logging.OptionalMode를 EXCLUDE_ALL_OPTIONAL로 설정할 수 있습니다.

다음 GCPBackendPolicy 매니페스트는 액세스 로깅의 기본 샘플링 레이트를 수정하고 이를 HTTP 요청의 50%로 설정합니다. 또한 매니페스트는 지정된 서비스 리소스의 두 가지 선택적 필드의 로깅을 사용 설정합니다.

서비스

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    # Access logging configuration for the load balancer.
    logging:
      enabled: true
      # Log 50% of the requests. The value must be an integer between 0 and
      # 1000000. To get the proportion of requests to log, GKE
      # divides this value by 1000000.
      sampleRate: 500000
      # Log specific optional fields.
      optionalMode: CUSTOM
      optionalFields:
      - tls.cipher
      - orca_load_report.cpu_utilization
  targetRef:
    group: ""
    kind: Service
    name: lb-service

멀티 클러스터 서비스

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    # Access logging configuration for the load balancer.
    logging:
      enabled: true
      # Log 50% of the requests. The value must be an integer between 0 and
      # 1000000. To get the proportion of requests to log, GKE
      # divides this value by 1000000.
      sampleRate: 500000
      # Log specific optional fields.
      optionalMode: CUSTOM
      optionalFields:
      - tls.cipher
      - orca_load_report.cpu_utilization
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

이 매니페스트에는 다음과 같은 필드가 있습니다.

enable: true: 액세스 로깅을 명시적으로 사용 설정합니다. Logging에서 로그를 사용할 수 있습니다.
sampleRate: 500000: 패킷의 50%가 로깅되도록 지정합니다. 0~1,000,000 사이의 값을 사용할 수 있습니다. GKE는 1,000,000으로 나누어 [0,1] 범위의 부동 소수점 값으로 변환합니다. 이 필드는 enable이 true로 설정된 경우에만 관련이 있습니다. sampleRate는 선택적 필드이지만 구성되는 경우 enable: true도 설정해야 합니다. enable이 true로 설정되었지만 sampleRate가 제공되지 않으면 GKE에서 enable을 false로 설정합니다.
optionalMode: CUSTOM: 로그 항목에 optionalFields 집합을 포함해야 함을 지정합니다.
optionalFields: tls.cipher, orca_load_report.cpu_utilization: 로그 항목에 TLS 핸드셰이크에 사용된 암호화 알고리즘의 이름과 서비스의 CPU 사용률을 모두 포함해야 한다고 지정합니다(가능한 경우).

단일 클러스터 게이트웨이에 트래픽 기반 자동 확장 구성

GKE 클러스터가 버전 1.31.1-gke.2008000 이상을 실행하는지 확인합니다.

단일 클러스터 게이트웨이에서 트래픽 기반 자동 확장 및 용량 기반 부하 분산을 사용 설정하려면 서비스 용량을 구성하면 됩니다. 서비스 용량이란 포드가 자동 확장되거나 트래픽이 다른 사용 가능한 클러스터로 오버플로되기 전에 서비스가 받을 수 있는 트래픽 용량을 지정하는 기능입니다.

서비스 용량을 구성하려면 서비스와 연결된 GCPBackendPolicy를 만듭니다. GCPBackendPolicy 매니페스트는 서비스의 포드별 최대 초당 요청(RPS) 값을 정의하는 maxRatePerEndpoint 필드를 사용합니다. 다음 GCPBackendPolicy 매니페스트는 최대 RPS를 10으로 정의합니다.

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: store
spec:
  default:
    maxRatePerEndpoint: 10
  targetRef:
    group: ""
    kind: Service
    name: store

트래픽 기반 자동 확장에 대한 자세한 내용은 부하 분산기 트래픽 기반 자동 확장을 참고하세요.

문제 해결

이 섹션에서는 정책을 사용하여 게이트웨이 리소스를 구성할 때 발생하는 일반적인 문제를 해결하기 위한 안내를 제공합니다.

`GCPTrafficDistributionPolicy`이 적용되지 않음

증상: 트래픽이 정책에 정의된 세션 어피니티 또는 지역 설정에 따라 분산되지 않습니다.

이유: 일반적으로 정책이 서비스에 올바르게 바인딩되지 않았거나 게이트웨이 컨트롤러가 구성을 부하 분산기에 동기화하려고 할 때 검증 오류가 발생한 경우에 발생합니다.

해결 방법:

정책 상태 확인: 정책이 서비스에 연결되었는지 확인합니다.
```
kubectl describe gcptrafficdistributionpolicy POLICY_NAME
```
POLICY_NAME을 정책 이름으로 바꿉니다.

출력에서 Conditions 섹션을 찾습니다. 이유가 Attached인 True 상태는 구성이 유효하고 적용되었음을 나타냅니다. 상태가 False인 경우 Reason 및 Message 필드에서 검증 오류 (예: 선택한 어필리티 유형에 지원되지 않는 알고리즘)를 확인합니다.
게이트웨이 구성 동기화 확인: 트래픽을 관리하는 게이트웨이가 이러한 설정을 클라우드 인프라와 성공적으로 동기화했는지 확인합니다.

Status 섹션에서 Programmed 조건의 Status이 True인지 확인합니다. False인 경우 게이트웨이 컨트롤러에 오류가 발생했음을 나타내며, 이는 GCPTrafficDistributionPolicy와 관련이 있을 수 있습니다.

Programmed 조건 옆에 있는 Reason 및 Message 필드에서 자세한 내용을 즉시 확인할 수 있습니다. 더 세부적인 오류 메시지 또는 동기화 실패 기록을 확인하려면 출력 하단의 Events를 확인하세요.

동일한 `Service`에 연결된 여러 `GCPBackendPolicy`

증상:

Service 또는 ServiceImport에 GCPBackendPolicy를 연결할 때 다음 상태 조건이 발생할 수 있습니다.

status:
  conditions:
    - lastTransitionTime: "2023-09-26T20:18:03Z"
      message: conflicted with GCPBackendPolicy "[POLICY_NAME]" of higher precedence, hence not applied
      reason: Conflicted
      status: "False"
      type: Attached

이유:

이 상태 조건은 이미 GCPBackendPolicy가 연결된 Service 또는 ServiceImport에 두 번째 GCPBackendPolicy를 적용하려고 함을 나타냅니다.

동일한 Service 또는 ServiceImport에 연결된 여러 GCPBackendPolicy는 GKE 게이트웨이에서 지원되지 않습니다. 자세한 내용은 제한 및 한도를 참조하세요.

해결 방법:

모든 커스텀 구성을 포함하는 단일 GCPBackendPolicy를 구성하고 이를 Service 또는 ServiceImport에 연결합니다.

트래픽 분할 중에 세션 어피니티가 무시됨

증상:

세션 어피니티가 구성되어 있는데도 요청이 동일한 백엔드 포드로 일관되게 라우팅되지 않습니다.

이유:

가중치가 적용된 트래픽 분할은 세션 어피니티보다 우선 적용됩니다. HTTPRoute가 여러 백엔드의 가중치를 정의하는 경우 부하 분산기는 어피니티 로직을 적용하기 전에 가중치를 기반으로 백엔드를 먼저 선택합니다.

해결 방법:

세션 고정성이 필요한 동일한 HTTPRoute 규칙에서 가중치가 적용된 트래픽 분할을 사용하지 마세요.

Cloud Armor 보안 정책을 찾을 수 없음

증상:

리전별 게이트웨이에서 Cloud Armor를 사용 설정하면 다음 오류 메시지가 표시될 수 있습니다.

Invalid value for field 'resource': '{
"securityPolicy":"projects/123456789/regions/us-central1/securityPolicies/<policy_name>"}'.
The given security policy does not exist.

이유:

이 오류 메시지는 지정된 리전별 Cloud Armor 보안 정책이 Google Cloud 프로젝트에 없음을 나타냅니다.

해결 방법:

프로젝트에서 리전별 Cloud Armor 보안 정책을 만들고 GCPBackendPolicy에서 이 정책을 참조합니다.

다음 단계

게이트웨이를 배포하는 방법 알아보기
게이트웨이 컨트롤러 자세히 알아보기
리소스에서 게이트웨이를 참조하는 방법 알아보기
정책 유형 API 참조 확인하기
API 유형 정의 확인하기

정책을 사용하여 게이트웨이 리소스 구성 컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.

시작하기 전에

GKE Gateway Controller 요구사항

제한 및 한도

리전 내부 게이트웨이의 전역 액세스 구성

멀티 클러스터 게이트웨이의 리전 구성

클라이언트 및 부하 분산기 간 트래픽 보호를 위한 SSL 정책 구성

상태 확인 구성

서비스

멀티 클러스터 서비스

Cloud Armor 백엔드 보안 정책을 구성하여 백엔드 서비스 보호

서비스

멀티 클러스터 서비스

IAP 구성

서비스

멀티 클러스터 서비스

백엔드 서비스 제한 시간 구성

서비스

멀티 클러스터 서비스

GCPBackendPolicy를 사용하여 백엔드 선택 구성

GCPTrafficDistributionPolicy로 엔드포인트 수준 라우팅 구성

해시 링 크기 구성

세션 어피니티 구성

서비스

멀티 클러스터 서비스

서비스

멀티 클러스터 서비스

GCPTrafficDistributionPolicy를 사용한 확장된 세션 어피니티

확장된 세션 어피니티 예

HTTP 쿠키 기반 세션 어피니티 구성

헤더 기반 세션 어피니티 구성

정책 확인

연결 드레이닝 제한 시간 구성

서비스

멀티 클러스터 서비스

HTTP 액세스 로깅

서비스

멀티 클러스터 서비스

단일 클러스터 게이트웨이에 트래픽 기반 자동 확장 구성

문제 해결

GCPTrafficDistributionPolicy이 적용되지 않음

동일한 Service에 연결된 여러 GCPBackendPolicy

트래픽 분할 중에 세션 어피니티가 무시됨

Cloud Armor 보안 정책을 찾을 수 없음

다음 단계

정책을 사용하여 게이트웨이 리소스 구성

`GCPBackendPolicy`를 사용하여 백엔드 선택 구성

`GCPTrafficDistributionPolicy`를 사용한 확장된 세션 어피니티

`GCPTrafficDistributionPolicy`이 적용되지 않음

동일한 `Service`에 연결된 여러 `GCPBackendPolicy`