이 페이지에서는 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 버전에서는 이 문서의 명령어를 실행하지 못할 수 있습니다.
- 기존 Autopilot 또는 Standard 클러스터가 있는지 확인합니다. 새 클러스터를 만들려면 Autopilot 클러스터 만들기를 참조하세요.
GKE Gateway Controller 요구사항
- Gateway API는 VPC 기반 클러스터에서만 지원됩니다.
- 리전 또는 교차 리전 GatewayClasses를 사용하는 경우 프록시 전용 서브넷을 사용 설정해야 합니다.
- 클러스터에
HttpLoadBalancing부가기능이 사용 설정되어 있어야 합니다. - Istio를 사용하는 경우 Istio를 다음 버전 중 하나로 업그레이드해야 합니다.
- 1.15.2 이상
- 1.14.5 이상
- 1.13.9 이상
- 공유 VPC를 사용하는 경우 호스트 프로젝트에서 서비스 프로젝트에 대해 GKE 서비스 계정에
Compute Network User역할을 할당해야 합니다.
제한 및 한도
GKE 게이트웨이 컨트롤러 제한 및 한도 외에도 다음 제한사항이 게이트웨이 리소스에 적용되는 정책에 적용됩니다.
GCPGatewayPolicy리소스는gateway.networking.k8s.ioGateway에만 연결할 수 있습니다.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옵션을 지원하지 않습니다.
리전 내부 게이트웨이의 전역 액세스 구성
이 섹션에서는 버전 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: 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 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 구성
이 섹션에서는 버전 1.24 이상을 실행하는 GKE 클러스터에서 사용할 수 있는 기능을 설명합니다.
IAP(Identity-Aware Proxy)는 HTTPRoute와 연결된 백엔드 서비스에 대해 액세스 제어 정책을 적용합니다. 이 시행을 통해 올바른 Identity and Access Management(IAM) 역할이 할당된 인증된 사용자 또는 애플리케이션만 이러한 백엔드 서비스에 액세스할 수 있습니다.
기본적으로 백엔드 서비스에 적용된 IAP가 없으므로 GCPBackendPolicy에서 IAP를 명시적으로 구성해야 합니다.
게이트웨이로 IAP를 구성하려면 다음을 수행합니다.
GKE에 IAP 사용 설정:
BackendConfig는 인그레스 배포의 경우에만 유효하므로 백엔드를 구성하지 마세요(BackendConfig 구성).IAP의 보안 비밀을 만듭니다.
Google Cloud 콘솔에서 사용자 인증 정보 페이지로 이동합니다.
클라이언트 이름을 클릭하고 OAuth 클라이언트 파일을 다운로드합니다.
OAuth 클라이언트 파일에서 클립보드에 OAuth 보안 비밀을 복사합니다.
iap-secret.txt라는 파일을 만듭니다.다음 명령어를 사용하여
iap-secret.txt파일에 OAuth 보안 비밀을 붙여넣습니다.echo -n CLIENT_SECRET > iap-secret.txt kubectl create secret generic SECRET_NAME --from-file=key=iap-secret.txt
보안 비밀을 참조하는 IAP 정책을 지정하려면 다음 안내를 따르세요.
다음
GCPBackendPolicy매니페스트를 만들고 각각SECRET_NAME및CLIENT_ID를 바꿉니다. 매니페스트를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: SECRET_NAME clientID: CLIENT_ID # Attach to a Service in the cluster. targetRef: group: "" kind: Service name: lb-service멀티 클러스터 서비스
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: SECRET_NAME clientID: CLIENT_ID # Attach to a multi-cluster Service by referencing the ServiceImport. targetRef: group: net.gke.io kind: ServiceImport name: lb-servicebackend-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 maxUtilization: 100 # value ranges from 0 to 100 and maps to the floating pointrange [0.0, 1.0] dryRun: false매니페스트를 클러스터에 적용합니다.
kubectl apply -f my-backend-policy.yaml
부하 분산기는 RATE 부하 분산 모드 및 맞춤 gpu-load 측정항목을 기반으로 트래픽을 분산합니다.
GCPTrafficDistributionPolicy로 엔드포인트 수준 라우팅 구성
GCPTrafficDistributionPolicy는 백엔드 내 엔드포인트 선택을 위한 부하 분산 알고리즘을 구성합니다. WEIGHTED_ROUND_ROBIN을 선택하면 부하 분산기는 보고된 측정항목(맞춤 측정항목 포함)에서 파생된 가중치를 사용하여 개별 인스턴스 또는 엔드포인트에 트래픽을 분산합니다.
GCPTrafficDistributionPolicy 리소스의 WEIGHTED_ROUND_ROBIN localityLbPolicy 필드는 백엔드 내에서 개별 인스턴스 또는 엔드포인트를 선택하기 위한 부하 분산 알고리즘을 지정합니다. 이 알고리즘을 사용하면 정책에서 커스텀 측정항목을 활용하여 부하 할당의 가중치를 계산합니다.
GCPTrafficDistributionPolicy 구성 내의 customMetrics[] 배열에는 다음 필드가 포함됩니다.
name: 맞춤 측정항목의 사용자 정의 이름을 지정합니다.dryRun: 불리언 필드입니다. 이 속성이 true이면 측정항목 데이터가 Cloud Monitoring에 보고되지만 부하 분산에는 영향을 미치지 않습니다.
자세한 내용은 커스텀 측정항목 기반 부하 분산을 사용한 트래픽 관리를 참고하세요.
예시
다음 예는 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 알고리즘을 기반으로 제공된 맞춤 측정항목을 사용하여 엔드포인트에 트래픽을 분산합니다.
세션 어피니티 구성
이 섹션에서는 버전 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_IPGENERATED_COOKIENONE
연결 드레이닝 제한 시간 구성
이 섹션에서는 버전 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
트래픽 기반 자동 확장에 대한 자세한 내용은 부하 분산기 트래픽 기반 자동 확장을 참고하세요.
문제 해결
동일한 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에 연결합니다.
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 유형 정의 확인하기