Anthos Service Mesh와 Traffic Director가 이제 Cloud Service Mesh로 통합되었습니다. 자세한 내용은 Cloud Service Mesh 개요를 참조하세요.

이 페이지는 Cloud Translation API를 통해 번역되었습니다.

GKE 클러스터의 고급 부하 분산

이 페이지에서는 Kubernetes API를 사용하여 관리형 Cloud Service Mesh (TD) 사용자를 위해 GKE 클러스터에서 고급 부하 분산을 구성하는 방법을 보여줍니다.Google Cloud API를 사용하여 고급 부하 분산을 구성하는 방법에 관한 상응하는 사용자 가이드는 고급 부하 분산 설정을 참고하세요.

고급 부하 분산을 사용하여 다음 작업을 할 수 있습니다.

로컬 용량이 소진될 때까지 서비스 영역으로 트래픽을 유지합니다.
기본 위치의 충분한 엔드포인트가 비정상적으로 되었을 때 보조 위치로 장애 조치하여 '기본' 위치의 서비스로 트래픽을 전송합니다.
장애 조치가 발생하는 시점을 제어합니다 (정상 호스트의 비율을 기준으로 함).

제한사항

Google Cloud 에서 고급 부하 분산을 사용하는 것과 관련된 일반적인 제한사항이 적용됩니다.
이 기능은 Traffic Director를 컨트롤 플레인으로 사용하는 관리형 Cloud Service Mesh 사용자만 사용할 수 있으며 데이터 영역 버전 1.19.10-asm.22 이상이 필요합니다.
GCPTrafficDistributionPolicy 및 GCPBackendPolicy의 일부 필드는 managedCloud Service Mesh (TD)에서 지원되지 않습니다. 지원되는 필드는 다음과 같습니다.
- GCPTrafficDistributionPolicy
  - ServiceLbAlgorithm
  - AutoCapacityDrain
  - FailoverConfig
- GCPBackendPolicy
  - MaxRatePerEndpoint
  - BackendPreference
고급 부하 분산은 Google Cloud에서 실행되는 워크로드로 지원되는 Kubernetes 서비스에만 적용할 수 있습니다. 외부 서비스 또는 워크로드 (예: ServiceEntry)는 지원되지 않습니다.
부하 분산 정책은 개별 Kubernetes 서비스에만 적용할 수 있습니다. 네임스페이스 전체/메시 전체 부하 분산 정책은 지원되지 않습니다.
QPS 용량만 지원됩니다.
GKE 버전 1.31.1 이상만 지원됩니다.
서비스 메시 고급 부하 분산 정책은 메시 트래픽만 제공하는 서비스에만 적용해야 합니다. GKE 게이트웨이 백엔드로 작동하는 서비스에는 적용하면 안 됩니다. 고급 부하 분산 트래픽이 메시 트래픽과 GKE 게이트웨이의 트래픽을 모두 제공하는 Kubernetes 서비스를 타겟팅하는 경우 트래픽 동작이 정의되지 않습니다.

고급 부하 분산 구성

다음 커스텀 리소스를 사용하여 GKE에서 고급 부하 분산을 구성할 수 있습니다. 자세한 리소스 정의는 gke-gateway-api 저장소에서 확인할 수 있습니다.

GCPTrafficDistributionPolicy

GCPTrafficDistributionPolicy는 Kubernetes 서비스의 서비스 수준 부하 분산 정책을 구성합니다. 이 도구를 사용하면 다음 작업을 할 수 있습니다.

맞춤 부하 분산 알고리즘을 선택합니다. 지원되는 알고리즘은 고급 부하 분산 표에 설명되어 있습니다.
자동 용량 드레이닝을 사용 설정합니다.
장애 조치 상태 기준을 조정합니다.

여러 GCPTrafficDistributionPolicies가 동일한 서비스를 타겟팅하는 경우 가장 오래된 정책이 적용됩니다.

GCPBackendPolicy

GCPBackendPolicy는 다음을 포함하여 부하 분산 동작에 영향을 미치는 서비스 백엔드 속성을 구성합니다.

서비스 백엔드 용량
선호 백엔드 지정

여러 GCPBackendPolicy가 클러스터에서 동일한 서비스를 타겟팅하는 경우 가장 오래된 정책이 적용됩니다.

정책 상태

GCPTrafficDistributionPolicy와 GCPBackendPolicy에는 모두 정책의 첨부 상태를 나타내는 상태 필드가 있습니다.

예를 들어 kubectl describe gcpbackendpolicies example-policy -n example을 실행하면 다음과 유사한 출력이 생성됩니다.

...
Status:
  Ancestors:
    Ancestor Ref:
      Group:
      Kind:       Service
      Name:       example-svc
      Namespace:  example
    Conditions:
      Last Transition Time:  2024-10-13T01:15:03Z
      Message:
      Observed Generation:   1
      Reason:                Attached
      Status:                True
      Type:                  Attached
    Controller Name:         gsmconfig.gke.io/controller

예비 설정

이 가이드를 완료하려면 먼저 GKE 클러스터에 Cloud Service Mesh를 프로비저닝해야 합니다.

CRD가 설치되었는지 확인합니다.

kubectl get crd

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

...
gcptrafficdistributionpolicies.networking.gke.io   2024-07-18T21:50:12Z
gcpbackendpolicies.networking.gke.io               2024-07-18T21:50:12Z
...

GCPBackendPolicy CRD가 아직 설치되어 있지 않으면 설치합니다.

kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-gateway-api/refs/heads/main/config/crd/networking.gke.io_gcpbackendpolicies.yaml

GCPTrafficDistributionPolicy CRD가 아직 설치되어 있지 않으면 설치합니다.

kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-gateway-api/refs/heads/main/config/crd/networking.gke.io_gcptrafficdistributionpolicies.yaml

이 사용자 가이드의 예시 정책은 데모 목적으로 foo 네임스페이스의 foo 서비스를 타겟팅합니다. 다음 명령어를 실행하여 테스트 서비스와 네임스페이스를 만들거나 원하는 경우 자체 서비스와 네임스페이스를 사용할 수 있습니다.

kubectl apply -f - <<EOF
kind: Namespace
apiVersion: v1
metadata:
  name: foo
  labels:
    istio-injection: enabled
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: foo
  namespace: foo
spec:
  replicas: 2
  selector:
    matchLabels:
      app: test-backend
  template:
    metadata:
      labels:
        app: test-backend
    spec:
      containers:
      - name: whereami
        image: gcr.io/google-samples/whereami:v1.2.23
        ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: foo
  namespace: foo
spec:
  selector:
    app: test-backend
  ports:
  - port: 8080
    targetPort: 8080
EOF

부하 분산 알고리즘 구성

기본적으로 서비스의 트래픽은 Cloud Service Mesh 서비스 메시의 모든 정상적인 서비스 백엔드에 균등하게 분산됩니다. 다음 GCPTrafficDistributionPolicy를 만들어 백엔드 용량에 따라 가장 가까운 영역에 트래픽이 분산되도록 할 수 있습니다.

kubectl apply -f - <<EOF
apiVersion: networking.gke.io/v1
kind: GCPTrafficDistributionPolicy
metadata:
  name: lb-policy
  namespace: foo
spec:
  targetRefs:
  - kind: Service
    group: ""
    name: foo-service
  default:
    serviceLbAlgorithm: WATERFALL_BY_ZONE
EOF

기본적으로 서비스 백엔드는 무한한 용량을 보유한 것처럼 취급됩니다. 로컬/가장 가까운 영역에 정상적인 호스트가 충분하면 특정 클라이언트 위치의 로컬/가장 가까운 영역 외부로 트래픽이 분산되지 않습니다. 원하는 경우 단일 영역이 과부하되지 않도록 GCPBackendPolicy를 사용하여 서비스 백엔드의 용량을 구성할 수 있습니다.

kubectl apply -f - <<EOF
apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: backend-policy
  namespace: foo
spec:
  targetRef:
    kind: Service
    group: ""
    name: foo-backend
  default:
    maxRatePerEndpoint: 5
EOF

장애 조치 동작 조정

기본적으로 기본 백엔드에서 충분한 비율의 호스트가 정상이면 장애 조치가 트리거되지 않습니다. 기본 백엔드 및 기타 용어에 관한 자세한 내용은 고급 부하 분산 개요를 참고하세요. GCPTrafficDistributionPolicy를 사용하면 트래픽이 기본 백엔드에서 장애 조치 백엔드로 전환될 때까지 정상 호스트 비율 기준점을 구성할 수 있습니다. 임계값이 클수록 장애 조치가 더 빨리 트리거됩니다. 예를 들어 기본 백엔드에서 정상 호스트의 비율이 90% 아래로 떨어지면 즉시 장애 조치가 트리거되도록 하려면 다음 GCPTrafficDistributionPolicy를 구성하면 됩니다.

kubectl apply -f - <<EOF
apiVersion: networking.gke.io/v1
kind: GCPTrafficDistributionPolicy
metadata:
  name: lb-policy
  namespace: foo
spec:
  targetRefs:
  - kind: Service
    group: ""
    name: foo-service
  default:
   failoverConfig:
     failoverHealthThreshold: 90
EOF

멀티 클러스터 서비스 메시에서 고급 부하 분산 구성

GCPTrafficDistributionPolicy 및 GCPBackendPolicy는 멀티 클러스터 서비스 메시의 서로 다른 범위에 적용됩니다.

GCPTrafficDistributionPolicy가 멀티 클러스터 서비스를 타겟팅하면 모든 클러스터에서 서비스 수준 부하 분산 동작을 정의합니다. 특정 멀티 클러스터 서비스에 대해 하나의 GCPTrafficDistributionPolicy만 만들어야 합니다. Istio API를 사용하여 서비스 메시를 구성하는 경우 Fleet의 모든 클러스터에서 GCPTrafficDistributionPolicy를 만들 수 있습니다. 정책 상태를 검사하여 정책이 다른 정책과 충돌하는지 확인할 수 있습니다.

GCPBackendPolicy가 멀티 클러스터 서비스를 타겟팅하면 로컬 클러스터에서 타겟팅 서비스에 의해 선택된 백엔드 팟의 백엔드 수준 설정 (예: 팟당 용량)을 정의합니다. 동일한 다중 클러스터 서비스의 경우 클러스터마다 다른 백엔드 수준 설정을 정의할 수 있습니다.

다음 예에서는 GCPTrafficDistributionPolicy가 클러스터 A에 생성되어 전체 서비스에서 사용할 부하 분산 알고리즘을 정의하고 GCPBackendPolicies는 각 클러스터에 있습니다. 두 GCPBackendPolicy 모두 로컬 클러스터의 백엔드 포드에 포드당 10qps의 용량을 구성하지만 클러스터 A의 GCPBackendPolicy는 클러스터 A의 백엔드 포드를 선호하는 백엔드로 구성합니다.

이러한 정책을 함께 사용하면 서비스 foo로 전송되는 메시 내 트래픽의 부하 분산 동작을 구성할 수 있습니다.

클러스터 A의 백엔드 포드가 포드당 10개 qps를 처리해야 할 때까지 어디서나 오는 트래픽은 클러스터 A의 백엔드를 선호합니다.
- 이 동작은 주로 클러스터 A에서 backendPreference를 PREFERRED로 설정하는 GCPBackendPolicy에 의해 정의됩니다.
클러스터 A의 백엔드에 구성된 용량을 초과하는 트래픽은 알고리즘 WATERFALL_BY_ZONE를 사용하여 클러스터 B로 라우팅됩니다. 기본 백엔드에 관한 자세한 설명은 고급 부하 분산 개요를 참고하세요.
- 이 동작은 주로 클러스터 A에서 알고리즘을 정의하는 GCPTrafficDistributionPolicy 및 클러스터 A와 B에서 모두 백엔드 용량을 정의하는 GCPBackendPolicy에 의해 정의됩니다.

고급 부하 분산 멀티 클러스터 서비스 메시

Istio에서 일반 Kubernetes 서비스는 서비스 메시에 여러 클러스터가 있고 서비스가 클러스터 경계를 넘어 생성되면 암시적으로 '멀티 클러스터'가 됩니다. 다음 GCPTrafficDistributionPolicy는 일반 Kubernetes 서비스 foo를 타겟팅하지만 두 클러스터의 상응하는 워크로드로 구성된 멀티 클러스터 서비스 foo에도 적용됩니다.

클러스터 A의 GCPTrafficDistributionPolicy를 만듭니다.

kubectl apply --context cluster-a-context -f - <<EOF
kind: GCPTrafficDistributionPolicy
apiVersion: networking.gke.io/v1
metadata:
name: foo-traffic-distribution-policy
namespace: foo
spec:
  targetRefs:
  - kind: Service
    group: ""
    name: foo-service
  default:
    serviceLbAlgorithm: WATERFALL_BY_ZONE

EOF

클러스터 A의 GCPBackendPolicy를 만듭니다.

kubectl apply --context cluster-a-context -f - <<EOF
kind: GCPBackendPolicy
apiVersion: networking.gke.io/v1
metadata:
name: foo-backend-policy
namespace: foo
spec:
  default:
    maxRatePerEndpoint: 100
    backendPreference: PREFERRED
  targetRef:
    group: ""
    kind: Service
    name: foo-service
EOF

클러스터 B의 GCPBackendPolicy를 만듭니다.

kubectl apply --context cluster-b-context -f - <<EOF
kind: GCPBackendPolicy
apiVersion: networking.gke.io/v1
metadata:
name: foo-backend-policy
namespace: foo
spec:
  default:
    maxRatePerEndpoint: 10
  targetRef:
    group: ""
    kind: Service
    name: foo-service
EOF

다음 단계

고급 부하 분산 자세히 알아보기