멀티 클러스터 서비스 구성

Autopilot Standard

---

이 페이지에서는 멀티 클러스터 서비스(MCS)를 사용 설정하고 사용하는 방법을 설명합니다. MCS의 작동 방식과 이점에 대한 자세한 내용은 멀티 클러스터 서비스를 참조하세요.

Google Kubernetes Engine(GKE) MCS 기능은 클러스터 경계를 넘어 Kubernetes 서비스의 범위를 확대하여 여러 GKE 클러스터 간에 서비스를 검색하고 호출할 수 있게 해줍니다. 기존 서비스 또는 새 서비스의 하위 집합을 내보낼 수 있습니다.

MCS를 사용하여 서비스를 내보내면 해당 Fleet에 있는 모든 클러스터 간에 이 서비스를 사용할 수 있습니다.

참고: MCS가 올바르게 작동할 수 있도록 GKE는 모든 배포, 서비스, 엔드포인트를 패치할 수 있는 기능과 같이 승격된 RBAC 권한이 있는 노드에 포드를 배포합니다. GKE에서 여러 GKE 클러스터 간에 엔드포인트를 전파하려면 이러한 권한이 필요합니다.

MCS로 관리되는 Google Cloud 리소스

MCS는 Google Cloud의 다음 구성요소를 관리합니다.

• Cloud DNS: MCS는 사용자의 Fleet 클러스터에 있는 각 내보낸 서비스에 대해 Cloud DNS 영역 및 레코드를 구성합니다. 이렇게 하면 다른 클러스터에서 실행 중인 서비스에 연결할 수 있습니다. 이러한 영역 및 레코드의 생성, 읽기, 업데이트, 삭제는 클러스터 간에 내보내도록 선택한 서비스를 기준으로 수행됩니다.

  참고: Cloud DNS를 사용하면 추가 요금이 발생합니다. Cloud DNS 가격 책정에 따라 요금이 청구됩니다.

• 방화벽 규칙: MCS는 포드가 Fleet 내의 클러스터 간에 서로 통신할 수 있게 해주는 방화벽 규칙을 구성합니다. 방화벽 규칙의 생성, 읽기, 업데이트, 삭제는 Fleet에 추가한 클러스터를 기준으로 수행됩니다. 이러한 규칙은 GKE 클러스터 내에서 포드 간 통신을 사용 설정하기 위해 GKE가 생성하는 규칙과 유사합니다.

• Traffic Director: MCS는 Traffic Director를 제어 영역으로 사용하여 클러스터 전체의 엔드포인트와 엔드포인트 상태를 추적합니다.

요구사항

MCS의 요구사항은 다음과 같습니다.

• MCS는 Google Cloud의 VPC 기반 GKE 클러스터에서만 서비스 내보내기를 지원합니다. 자세한 내용은 VPC 기반 클러스터 만들기를 참조하세요. VPC 기반이 아닌 GKE Standard 클러스터는 사용할 수 없습니다.

• 클러스터 간 연결은 동일한 VPC 네트워크 내부, 피어링된 VPC 네트워크 또는 공유된 VPC 네트워크에서 실행 중인 클러스터에 따라 다릅니다. 그렇지 않으면 외부 서비스 호출이 네트워크 경계를 벗어날 수 없습니다.

• Fleet이 여러 Google Cloud 프로젝트 및 VPC 네트워크에 걸쳐 있을 수 있지만 단일 프로젝트 및 단일 VPC 네트워크에서 단일 멀티 클러스터 서비스를 내보내야 합니다.

• MCS는 네트워크 정책으로 지원되지 않습니다.

• 클러스터에 사용 설정된 HttpLoadBalancing 부가기능이 있어야 합니다. HttpLoadBalancing 부가기능이 사용 설정되어 있는지 확인합니다. HttpLoadBalancing 부가기능은 기본적으로 사용 설정되어 있으며 사용 중지하지 않아야 합니다.

가격 책정

멀티 클러스터 서비스는 GKE 클러스터 관리 수수료에 포함되어 있으며 추가 사용 비용이 없습니다. Traffic Director API를 사용 설정해야 하지만 MCS에는 Traffic Director 엔드포인트 요금이 부과되지 않습니다. MCS를 사용하는 데 GKE Enterprise 라이선스는 필요하지 않습니다.

시작하기 전에

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

1. Google Cloud SDK를 설치합니다.

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

   Google Kubernetes Engine API 사용 설정

3. MCS, Fleet(허브), Resource Manager, Traffic Director, Cloud DNS API를 사용 설정합니다.

   gcloud services enable \
       multiclusterservicediscovery.googleapis.com \
       gkehub.googleapis.com \
       cloudresourcemanager.googleapis.com \
       trafficdirector.googleapis.com \
       dns.googleapis.com \
       --project=PROJECT_ID
   

   PROJECT_ID를 클러스터를 Fleet에 등록하려는 프로젝트의 프로젝트 ID로 바꿉니다.

   참고: 프로젝트 소유자가 아닌 사용자가 API를 사용 설정할 수 있으려면 먼저 serviceusage.services.enable 권한을 부여 받아야 합니다.

프로젝트에서 MCS 사용 설정

MCS를 사용하려면 참여하는 GKE 클러스터를 동일한 Fleet에 등록해야 합니다. MCS 기능이 사용 설정되면 모든 클러스터가 Fleet의 클러스터 간에 서비스를 내보낼 수 있습니다.

MCS는 Fleet에 대한 등록이 필요하지만 GKE Enterprise 플랫폼을 사용 설정할 필요가 없습니다.

GKE Enterprise

GKE Enterprise API가 Fleet 호스트 프로젝트에서 다른 GKE Enterprise 구성요소를 사용하기 위한 기본 요건으로 사용 설정된 경우 프로젝트의 Fleet에 등록된 모든 클러스터는 GKE Enterprise 가격 책정에 따라 요금이 청구됩니다. 이 가격 책정 모델에서는 단일 vCPU별 요금으로 등록된 클러스터에서 모든 GKE Enterprise 기능을 사용할 수 있습니다. 다음 명령어를 사용하여 GKE Enterprise API가 사용 설정되었는지 확인할 수 있습니다.

gcloud services list --project=PROJECT_ID | grep anthos.googleapis.com

출력이 다음과 비슷하면 전체 GKE Enterprise 플랫폼이 사용 설정된 것이고, Fleet에 등록된 모든 클러스터에 GKE Enterprise 요금이 부과됩니다.

anthos.googleapis.com                        Anthos API

예상된 결과가 아니라면 프로젝트 관리자에게 문의하세요.

빈 출력은 GKE Enterprise가 사용 설정되지 않았음을 나타냅니다.

경고: 프로젝트에서 사용 중인 다른 활성 상태의 GKE Enterprise 구성요소가 있으면 GKE Enterprise API를 중지하지 마세요. 그렇지 않으면 활성 구성요소에 중단이 발생할 수 있습니다.

GKE 클러스터에서 MCS 사용 설정

1. 프로젝트의 Fleet에 대해 MCS 기능을 사용 설정합니다.

   gcloud container fleet multi-cluster-services enable \
       --project PROJECT_ID
   

   PROJECT_ID를 클러스터를 Fleet에 등록하려는 프로젝트의 프로젝트 ID로 바꿉니다. 이것이 Fleet 호스트 프로젝트입니다.

2. Fleet에 GKE 클러스터를 등록합니다. GKE용 워크로드 아이덴티티 제휴를 사용 설정하여 클러스터를 등록하는 것이 좋습니다. GKE용 워크로드 아이덴티티 제휴를 사용 설정하지 않으면 인증을 위해 Google Cloud 서비스 계정에 클러스터를 등록하고 서비스 계정 인증의 추가 단계를 완료해야 합니다.

   GKE용 워크로드 아이덴티티 제휴에 클러스터를 등록하려면 다음 명령어를 실행합니다.

   gcloud container fleet memberships register MEMBERSHIP_NAME \
      --gke-cluster CLUSTER_LOCATION/CLUSTER_NAME \
      --enable-workload-identity \
      --project PROJECT_ID
   

   다음을 바꿉니다.

   • MEMBERSHIP_NAME: Fleet의 클러스터를 고유하게 나타내기 위해 선택한 멤버십 이름입니다. 일반적으로 클러스터의 Fleet 멤버십 이름은 클러스터 이름이지만 원래 이름을 가진 다른 클러스터가 이미 Fleet에 있는 경우 새 이름을 지정해야 할 수 있습니다.
   • CLUSTER_LOCATION: 클러스터가 있는 영역 또는 리전입니다.
   • CLUSTER_NAME: 클러스터의 이름입니다.

3. MCS 가져오기 작업자에 필요한 Identity and Access Management(IAM) 권한을 부여합니다.

   gcloud projects add-iam-policy-binding PROJECT_ID \
       --member "serviceAccount:PROJECT_ID.svc.id.goog[gke-mcs/gke-mcs-importer]" \
       --role "roles/compute.networkViewer"
   

   PROJECT_ID를 Fleet 호스 프로젝트의 프로젝트 ID로 바꿉니다.

4. Fleet의 각 클러스터에 서비스를 공유할 네임스페이스가 있는지 확인합니다. 필요한 경우 다음 명령어를 사용하여 네임스페이스를 만듭니다.

   kubectl create ns NAMESPACE
   

   NAMESPACE를 네임스페이스 이름으로 바꿉니다.

   참고: 내보내기 네임스페이스가 없는 클러스터로는 서비스를 가져오지 않기 때문에 서비스가 사용될 클러스터에 서비스의 네임스페이스를 만듭니다. 네임스페이스가 없으면 언제든지 네임스페이스를 추가할 수 있지만 이전에 내보낸 서비스를 새로 만든 네임스페이스로 가져오려면 최대 5분까지 걸릴 수 있습니다.

5. MCS가 사용 설정되었는지 확인하려면 다음 명령어를 실행합니다.

   gcloud container fleet multi-cluster-services describe \
       --project PROJECT_ID
   

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

   createTime: '2021-08-10T13:05:23.512044937Z'
   membershipStates:
     projects/PROJECT_ID/locations/global/memberships/MCS_NAME:
       state:
         code: OK
         description: Firewall successfully updated
         updateTime: '2021-08-10T13:14:45.173444870Z'
   name: projects/PROJECT_NAME/locations/global/features/multiclusterservicediscovery
   resourceState:
     state: ACTIVE
   spec: {}
   

   state 값이 ACTIVE가 아니면 문제 해결 섹션을 참조하세요.

서비스 계정 인증

유의사항: GKE용 워크로드 아이덴티티 제휴가 사용 설정된 상태에서 Fleet에 클러스터를 등록한 경우 이 섹션의 단계를 수행할 필요가 없습니다.

서비스 계정을 사용하여 Fleet에 GKE 클러스터를 등록한 경우 서비스 계정을 인증하기 위해 추가 단계를 수행해야 합니다. MCS는 gke-mcs-importer라는 구성요소를 배포합니다. 이 구성요소는 Traffic Director에서 엔드포인트 업데이트를 수신합니다. 따라서 MCS를 사용 설정할 때 Traffic Director에서 정보를 읽을 수 있는 권한을 서비스 계정에 부여해야 합니다.

서비스 계정을 사용할 때는 Compute Engine 기본 서비스 계정을 사용하거나 고유 노드 서비스 계정을 사용할 수 있습니다.

• Compute Engine 기본 서비스 계정을 사용하는 경우 다음 범위를 사용 설정합니다.

  • https://www.googleapis.com/auth/compute.readonly
  • https://www.googleapis.com/auth/cloud-platform

  범위 사용 설정에 대해 자세히 알아보려면 인스턴스의 서비스 계정 및 액세스 범위 변경을 참조하세요.

• 고유 노드 서비스 계정을 사용하는 경우 서비스 계정에 roles/compute.networkViewer 역할을 지정합니다.

MCS 사용

다음 섹션에서는 MCS를 사용하는 방법을 보여줍니다. MCS는 Kubernetes 멀티 클러스터 서비스 API를 사용합니다.

내보낼 서비스 등록

Fleet 내의 다른 클러스터로 내보낼 서비스를 등록하려면 다음 단계를 완료합니다.

1. export.yaml이라는 ServiceExport 객체를 만듭니다.

   # export.yaml
   kind: ServiceExport
   apiVersion: net.gke.io/v1
   metadata:
    namespace: NAMESPACE
    name: SERVICE_EXPORT_NAME
   

   다음을 바꿉니다.

   • NAMESPACE: ServiceExport 객체의 네임스페이스입니다. 이 네임스페이스는 내보내려는 서비스의 네임스페이스와 일치해야 합니다.
   • SERVICE_EXPORT_NAME: Fleet 내에서 다른 클러스터로 내보내려는 클러스터의 서비스 이름입니다.

2. 다음 명령어를 실행하여 ServiceExport 리소스를 만듭니다.

   kubectl apply -f export.yaml
   

서비스를 처음 내보낼 때는 Fleet에 등록된 클러스터와 동기화하기 위해 약 5분 정도 걸립니다. 서비스를 내보낸 후에는 이후 엔드포인트 동기화가 즉시 수행됩니다.

여러 클러스터에서 동일한 서비스를 내보내서 클러스터 간 트래픽 분산으로 가용성이 높은 단일 클러스터 서비스 엔드포인트를 만들 수 있습니다. 이름과 네임스페이스가 동일한 서비스를 내보내려면 먼저 이 방식으로 그룹화해야 합니다. 의도하지 않은 이름 충돌 및 의도하지 않은 그룹화가 발생할 가능성이 높으므로 default 및 kube-system 네임스페이스에서 서비스를 내보내지 않는 것이 좋습니다. 동일한 이름 및 네임스페이스를 사용하여 서비스를 5개 넘게 내보내는 경우 가져온 서비스의 트래픽 분산은 내보낸 서비스 5개로 제한될 수 있습니다.

클러스터 간 서비스 소비

MCS는 ClusterSetIP 및 헤드리스 서비스만 지원합니다. DNS 'A' 레코드만 사용할 수 있습니다.

ServiceExport 객체를 만든 후에는 다음 도메인 이름이 Fleet 클러스터에 있는 포드에서 내보낸 서비스로 확인됩니다.

 SERVICE_EXPORT_NAME.NAMESPACE.svc.clusterset.local

출력에는 다음 값이 포함됩니다.

• SERVICE_EXPORT_NAME 및 NAMESPACE: ServiceExport 객체에서 정의한 값입니다.

ClusterSetIP 서비스의 경우 도메인이 ClusterSetIP로 확인됩니다. 이 값은 ServiceExport 객체가 생성된 네임스페이스에 있는 클러스터에서 ServiceImport 객체를 찾아서 확인할 수 있습니다. ServiceImport 객체는 자동으로 생성됩니다.

예를 들면 다음과 같습니다.

kind: ServiceImport
apiVersion: net.gke.io/v1
metadata:
 namespace: EXPORTED-SERVICE-NAMESPACE
 name: external-svc-SERVICE-EXPORT-TARGET
status:
 ports:
 - name: https
   port: 443
   protocol: TCP
   targetPort: 443
 ips: CLUSTER_SET_IP

MCS는 Service를 클러스터로 가져오는 동안 Endpoints 객체를 만듭니다. 이 객체를 조사하면 서비스 가져오기의 진행 상황을 모니터링할 수 있습니다. Endpoints 객체의 이름을 찾으려면 가져온 서비스에 해당하는 ServiceImport 객체에서 net.gke.io/derived-service 주석의 값을 찾으세요. 예를 들면 다음과 같습니다.

kind: ServiceImport
apiVersion: net.gke.io/v1
annotations: net.gke.io/derived-service: DERIVED_SERVICE_NAME
metadata:
 namespace: EXPORTED-SERVICE-NAMESPACE
 name: external-svc-SERVICE-EXPORT-TARGET

다음으로 Endpoints 객체를 조회하여 MCS가 이미 엔드포인트를 가져오기 클러스터에 전파했는지 확인합니다. Endpoints 객체는 ServiceImport 객체와 동일한 네임스페이스에서 net.gke.io/derived-service 주석에 저장된 이름으로 생성됩니다. 예를 들면 다음과 같습니다.

kubectl get endpoints DERIVED_SERVICE_NAME -n NAMESPACE

다음을 바꿉니다.

• DERIVED_SERVICE_NAME: ServiceImport 객체의 net.gke.io/derived-service 주석 값입니다.
• NAMESPACE: ServiceExport 객체의 네임스페이스입니다.

Google Cloud 콘솔에서 Traffic Director 대시보드를 사용하여 엔드포인트의 상태에 대한 자세한 내용을 확인할 수 있습니다.

헤드리스 서비스의 경우 도메인이 내보내기 클러스터에 있는 엔드포인트의 IP 주소 목록으로 확인됩니다. 또한 호스트 이름이 있는 각 백엔드 포드는 다음 형식의 도메인 이름으로 독립적으로 주소를 지정할 수도 있습니다.

 HOSTNAME.MEMBERSHIP_NAME.LOCATION.SERVICE_EXPORT_NAME.NAMESPACE.svc.clusterset.local

출력에는 다음 값이 포함됩니다.

• SERVICE_EXPORT_NAME 및 NAMESPACE: ServiceExport 객체에서 정의한 값입니다.
• MEMBERSHIP_NAME: 포드가 있는 클러스터에 대해 Fleet에 있는 고유 식별자입니다.
• LOCATION: 멤버십의 위치입니다. 멤버십은 global이거나 해당 위치가 포드가 있는 리전 또는 영역 중 하나입니다(예: us-central1).
• HOSTNAME: 포드의 호스트 이름입니다.

다음 형식의 도메인 이름을 사용하여 전역 멤버십에 등록된 클러스터에서 내보낸 호스트 이름으로 백엔드 포드의 주소를 지정할 수도 있습니다.

HOSTNAME.MEMBERSHIP_NAME.SERVICE_EXPORT_NAME.NAMESPACE.svc.clusterset.local

MCS 사용 중지

MCS를 사용 중지하려면 다음 단계를 완료합니다.

1. Fleet의 각 클러스터에 대해 생성된 각 ServiceExport 객체를 삭제합니다.

   kubectl delete serviceexport SERVICE_EXPORT_NAME \
       -n NAMESPACE
   

   다음을 바꿉니다.

   • SERVICE_EXPORT_NAME: ServiceExport 객체의 이름입니다.
   • NAMESPACE: ServiceExport 객체의 네임스페이스입니다.

2. 다른 목적으로 등록할 필요가 없으면 Fleet에서 클러스터를 등록 취소합니다.

3. multiclusterservicediscovery 기능을 사용 중지합니다.

   gcloud container fleet multi-cluster-services disable \
       --project PROJECT_ID
   

   PROJECT_ID를 클러스터를 등록한 프로젝트의 프로젝트 ID로 바꿉니다.

4. MCS에 대해 API를 사용 중지합니다.

   gcloud services disable multiclusterservicediscovery.googleapis.com \
       --project PROJECT_ID
   

   PROJECT_ID를 클러스터를 등록한 프로젝트의 프로젝트 ID로 바꿉니다.

제한사항

다음 제한은 강제로 적용되지 않으며, 일부 경우에 따라 클러스터 또는 프로젝트에서의 부하 및 엔드포인트의 제거 속도에 따라 이러한 제한을 초과할 수 있습니다. 하지만 이러한 제한을 초과하면 성능 문제가 발생할 수 있습니다.

• 클러스터 내보내기: 네임스페이스 이름으로 식별되는 단일 서비스를 동시에 최대 5개의 클러스터로 안전하게 내보낼 수 있습니다. 이 제한을 넘을 경우 엔드포인트의 하위 집합만 소비 클러스터로 내보낼 수 있습니다. 클러스터의 서로 다른 하위 집합에서 서로 다른 서비스를 내보낼 수 있습니다.

• 단일 서비스 이면의 포드 수: 단일 서비스 이면에서 안전하게 유지할 수 있는 포드 개수는 250개 미만입니다. 이는 단일 클러스터 서비스의 제한사항과 동일합니다. 비교적 정적인 워크로드와 소규모 멀티 클러스터 서비스의 경우, 서비스당 수천 개의 엔드포인트까지 이 숫자를 크게 초과할 수도 있습니다. 단일 클러스터 서비스에서와 같이 모든 엔드포인트가 모든 노드에서 kube-proxy로 감시됩니다. 이 제한을 벗어날 때, 특히 여러 클러스터에서 동시에 내보내기를 수행할 때는 더 많은 노드가 필요할 수 있습니다.

• 동시에 내보낸 멀티 클러스터 서비스 수: 서비스의 네임스페이스가 지정된 이름과 선언된 포트로 식별되는 고유한 서비스 포트를 50개 이하로 동시에 내보내는 것이 좋습니다. 예를 들어 포트 80 및 443을 노출하는 서비스를 내보내면 고유한 서비스 포트 한도 50개 중 2개로 계산됩니다. 여러 클러스터에서 내보낸 네임스페이스 이름이 동일한 서비스는 단일 고유 서비스로 계산됩니다. 앞에서 언급한 2개의 포트 서비스는 5개의 클러스터에서 동시에 내보낸 경우에만 2개의 포트로 계산됩니다. 각 멀티 클러스터 서비스가 백엔드 서비스 할당량으로 계산되고 클러스터 또는 영역을 내보낼 때마다 네트워크 엔드포인트 그룹(NEG)이 생성됩니다.

• 서비스 유형: MCS는 ClusterSetIP 및 헤드리스 서비스만 지원합니다. NodePort 및 LoadBalancer 서비스는 지원되지 않으며 예기치 않은 동작이 발생할 수 있습니다.

• MCS에서 IPmasq 에이전트 사용: 기본 또는 다른 비매스커레이드 포드 IP 범위를 사용할 때 MCS가 예상대로 작동합니다.

  커스텀 포드 IP 범위나 커스텀 IPmasq 에이전트 ConfigMap을 사용하는 경우 MCS 트래픽이 매스커레이드될 수 있습니다. 이렇게 하면 방화벽 규칙에서 포드 IP의 트래픽만 허용하므로 MCS가 작동하지 않습니다.

  이 문제를 방지하려면 기본 포드 IP 범위를 사용하거나 IPmasq 에이전트 ConfigMap의 nonMasqueradeCIDRs 필드에 모든 포드 IP 범위를 지정해야 합니다. Autopilot을 사용하거나 기본이 아닌 포드 IP 범위를 사용해야 하고 ConfigMap에서 모든 포드 IP 범위를 지정할 수 없으면 이그레스 NAT 정책을 사용하여 IP 매스커레이드를 구성해야 합니다.

여러 프로젝트의 클러스터가 있는 MCS

이름과 네임스페이스가 동일한 Fleet의 다른 프로젝트에 있는 다른 클러스터에서 이미 서비스를 내보내는 경우에는 서비스를 내보낼 수 없습니다. 다른 프로젝트의 Fleet에 있는 다른 클러스터의 서비스에 액세스할 수 있지만 클러스터가 동일한 네임스페이스에서 동일한 서비스를 내보낼 수는 없습니다.

문제 해결

다음 섹션에서는 MCS를 위한 문제 해결 팁을 보여줍니다.

featureState 보기

기능 상태를 확인하면 MCS가 성공적으로 구성되었는지 확인하는 데 도움이 됩니다. 다음 명령어를 사용하여 MCS 기능 상태를 확인할 수 있습니다.

gcloud container fleet multi-cluster-services describe

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

createTime: '2021-08-10T13:05:23.512044937Z'
membershipStates:
 projects/PROJECT_ID/locations/global/memberships/MCS_NAME:
   state:
     code: OK
     description: Firewall successfully updated
     updateTime: '2021-08-10T13:14:45.173444870Z'
name: projects/PROJECT_NAME/locations/global/features/multiclusterservicediscovery
resourceState:
 state: ACTIVE
spec: {}

문제 해결에 가장 유용한 필드는 code 및 description입니다.

featureState의 코드

코드는 MCS와 관련된 구성원의 일반 상태를 나타냅니다. 이러한 필드는 state.code 필드에서 찾을 수 있습니다. 가능한 세 가지 코드는 다음과 같습니다.

• OK: 멤버십이 MCS에 성공적으로 추가되었고, 사용할 준비가 되었습니다.

• WARNING: MCS가 멤버십 설정을 조정하는 중입니다. 설명 필드는 이 코드를 유발한 원인에 대해 자세한 정보를 제공할 수 있습니다.

• FAILED: 이 멤버십이 MCS에 추가되지 않았습니다. Fleet에서 OK 코드를 포함하는 다른 멤버십은 이 FAILED 멤버십의 영향을 받지 않습니다. 설명 필드는 이 코드를 유발한 원인에 대해 자세한 정보를 제공할 수 있습니다.

• ERROR: 이 멤버십에는 리소스가 없습니다. Fleet에서 OK 코드를 포함하는 다른 멤버십은 이 ERROR 멤버십의 영향을 받지 않습니다. 설명 필드는 이 코드를 유발한 원인에 대해 자세한 정보를 제공할 수 있습니다.

featureState의 설명

설명은 MCS에서 멤버십의 상태에 대한 추가 정보를 제공합니다. state.description 필드에서 이러한 설명을 찾고 다음 설명을 참조할 수 있습니다.

• Firewall successfully created: 이 메시지는 구성원의 방화벽 규칙이 성공적으로 생성 또는 업데이트되었는지를 나타냅니다. 멤버십의 코드는 OK입니다.

• Firewall creation pending: 이 메시지는 구성원의 방화벽 규칙으로 생성 또는 업데이트가 보류되었는지를 나타냅니다. 멤버십의 코드는 WARNING입니다. 이 멤버십은 방화벽 규칙이 보류 중인 동안 추가된 새 멀티 클러스터 서비스 및 멤버십에 대해 업데이트 및 연결을 수행할 때 문제가 발생할 수 있습니다.

• GKE Cluster missing: 이 메시지는 등록된 GKE 클러스터가 사용할 수 없거나 삭제되었음을 나타냅니다. 멤버십의 코드는 ERROR입니다. GKE 클러스터를 삭제한 후 이 멤버십을 수동으로 Fleet에서 등록 취소해야 합니다.

• Project that member lives in is missing required permissions and/or has not enabled all required APIs - additional setup steps are required: 이 메시지는 내부 StatusForbidden(403) 오류가 있음을 나타내며, 멤버십의 코드는 FAILED입니다. 이 오류는 다음 시나리오에서 발생합니다.

  • 구성원의 프로젝트에서 필요한 API를 사용 설정하지 않았습니다.

    구성원의 클러스터가 Fleet과 다른 프로젝트에 있는 경우, 모든 필수 단계를 완료했는지 확인하려면 프로젝트 간 설정을 확인하세요. 모든 단계를 완료했으면 다음 명령어를 사용해서 등록 프로젝트에 다음 API가 사용 설정되었는지 확인합니다.

    gcloud services enable multiclusterservicediscovery.googleapis.com --project PROJECT_ID
    gcloud services enable dns.googleapis.com --project PROJECT_ID
    gcloud services enable trafficdirector.googleapis.com --project PROJECT_ID
    gcloud services enable cloudresourcemanager.googleapis.com --project PROJECT_ID
    

    PROJECT_ID를 클러스터를 등록한 프로젝트의 프로젝트 ID로 바꿉니다.

  • mcsd 또는 gkehub 서비스 계정에는 구성원의 프로젝트에서 추가 권한이 필요합니다.

    mcsd 및 gkehub 서비스 계정은 Fleet 호스트 프로젝트에서 필요한 모든 권한으로 자동으로 생성되었습니다. 서비스 계정이 존재하는지 확인하려면 다음 명령어를 실행합니다.

    gcloud projects get-iam-policy PROJECT_ID | grep gcp-sa-mcsd
    gcloud projects get-iam-policy PROJECT_ID | grep gcp-sa-gkehub
    

    PROJECT_ID를 Fleet 호스 프로젝트의 프로젝트 ID로 바꿉니다.

  이러한 명령어는 mcsd 및 gkehub 서비스 계정의 전체 이름을 표시합니다.

• Multiple VPCs detected in the hub - VPC must be peered with other VPCs for successful connectivity: 이 메시지는 다른 VPC에 호스팅된 클러스터가 동일한 Fleet에 등록되었을 때 발생합니다. 멤버십 상태는 OK입니다. 클러스터의 VPC 네트워크는 해당 NetworkConfig의 네트워크로 정의됩니다. 멀티 클러스터 서비스에는 플랫 네트워크가 필요하며, 이러한 VPC는 서로 올바르게 연결할 수 있도록 멀티 클러스터 서비스에 대해 적극적으로 피어링되어야 합니다. 자세한 내용은 VPC 네트워크 피어링 설정 예시를 참조하세요.

• Member does not exist in the same project as hub - additional setup steps are required, errors may occur if not completed.: 이 메시지는 프로젝트 간 클러스터에 추가 설정 단계가 필요하다는 것을 다시 알려줍니다. 멤버십 상태는 OK입니다. 프로젝트 간 멤버십은 Fleet과 동일한 프로젝트에 없는 구성원의 클러스터로 정의됩니다. 자세한 내용은 프로젝트 간 설정을 참조하세요.

• Non-GKE clusters are currently not supported: 이 메시지는 MCS에서 GKE 클러스터만 지원된다는 것을 다시 알려줍니다. 비GKE 클러스터는 MCS에 추가할 수 없습니다. 멤버십 상태는 FAILED입니다.

알려진 문제

여러 포트가 있는 MCS 서비스

일부 엔드포인트가 데이터 영역에 프로그래밍되지 않은 GKE Dataplane V2에 여러(TCP/UDP) 포트가 있는 멀티 클러스터 서비스에 대해 알려진 문제가 있습니다. 이 문제는 1.26.3-gke.400 이전의 GKE 버전에 영향을 줍니다.

이 문제를 해결하려면 GKE Dataplane V2를 사용할 때 포트가 여러 개인 하나의 MCS 대신 단일 포트가 있는 여러 MCS를 사용합니다.

공유 VPC가 있는 MCS

현재 MCS 구현을 사용하면 동일한 공유 VPC에 2개 이상의 Fleet을 배포할 경우 메타데이터가 Fleet 간에 공유됩니다. 서비스가 한 Fleet에서 생성되면 서비스 메타데이터는 동일한 공유 VPC에 속하고 사용자에게 표시되는 다른 모든 Fleet으로 내보내거나 가져옵니다.

이 동작은 예정된 MCS 출시 버전에서 해결될 예정입니다.

상태 점검에서 containerPort 대신 기본 포트를 사용합니다.

배포에서 이름이 지정된 포트를 참조하는 targetPort 필드로 서비스를 배포하면 MCS가 지정된 containerPort 대신 상태 점검의 기본 포트를 구성합니다.

이 문제를 방지하려면 서비스 필드 ports.targetPort 및 배포 필드 readinessProbe.httpGet.port에 이름이 지정된 값 대신 숫자 값을 사용하세요.

이 동작은 예정된 MCS 출시 버전에서 해결될 예정입니다.

다음 단계

• 서비스 자세히 알아보기
• 서비스를 사용하여 앱 노출 방법 알아보기
• 기본 멀티 클러스터 서비스 예시 구현