GKE에서 관리형 Cloud Service Mesh 컨트롤 플레인 프로비저닝

Cloud Service Mesh는 간단히 사용 설정할 수 있는 Google 관리형 서비스 메시입니다. Google은 고객을 위해 안정성, 업그레이드, 확장, 보안을 처리합니다.

이 페이지에서는 Fleet API를 사용하여 Istio API를 통해 관리형 Cloud Service Mesh를 설정하는 방법을 보여줍니다.

기본 요건

이 가이드에서는 사용자에게 다음이 이미 있다고 가정합니다.

• Cloud 프로젝트
• Cloud Billing 계정
• Cloud Service Mesh를 프로비저닝하는 데 필요한 권한 획득
• 클러스터 및 노드 풀에서 워크로드 아이덴티티 사용 설정

요구사항

• 지원되는 리전 중 하나에서 지원되는 GKE 버전이 있는 클러스터가 한 개 이상 있어야 합니다.
• 클러스터에 관리형 Cloud Service Mesh가 클러스터에 설치하는 필수 구성요소를 위한 충분한 용량이 있어야 합니다.
  • kube-system 네임스페이스의 mdp-controller 배포에는 CPU 50m, 메모리 128Mi가 필요합니다.
  • kube-system 네임스페이스의 istio-cni-node DaemonSet에는 각 노드에서 cpu 100m, 메모리 100Mi가 필요합니다.
• 조직 정책 constraints/compute.disableInternetNetworkEndpointGroup이 사용 중지되어 있어야 합니다. 정책을 사용 설정하면 ServiceEntry가 작동하지 않을 수 있습니다.
• 관리형 Cloud Service Mesh를 프로비저닝할 클라이언트 머신이 API 서버에 네트워크로 연결되어 있는지 확인합니다.
• 클러스터를 Fleet에 등록해야 합니다. 이는 안내에 포함되거나 프로비저닝 전에 별도로 수행될 수 있습니다.
• 프로젝트에 서비스 메시 Fleet 기능이 사용 설정되어 있어야 합니다. 이는 안내에 포함되어 있거나 별도로 수행될 수 있습니다.

• GKE Autopilot은 GKE 버전 1.21.3 이상에서만 지원됩니다.

• Cloud Service Mesh는 단일 프로젝트 단일 네트워크 환경 또는 다중 프로젝트 단일 네트워크 환경에서 여러 GKE 클러스터를 사용할 수 있습니다.

  • 동일한 프로젝트에 없는 클러스터를 조인하는 경우 클러스터는 동일한 Fleet 호스트 프로젝트에 등록되어야 하며 클러스터가 동일한 네트워크의 공유 VPC 구성에 함께 있어야 합니다.
  • 단일 프로젝트 멀티 클러스터 환경에서는 Fleet 프로젝트가 클러스터 프로젝트와 같을 수 있습니다. Fleet에 대한 자세한 내용은 Fleet 개요를 참조하세요.
  • 멀티 프로젝트 환경의 경우 클러스터 프로젝트와 별도의 프로젝트에서 Fleet을 호스팅하는 것이 좋습니다. 조직 정책과 기존 구성에서 허용하는 경우 공유 VPC 프로젝트를 Fleet 호스트 프로젝트로 사용하는 것이 좋습니다. 자세한 내용은 공유 VPC를 사용하여 클러스터 설정을 참조하세요.

Cloud Service Mesh를 설치하는 데 필요한 역할

다음 표에서는 관리형 Cloud Service Mesh를 설치하는 데 필요한 역할을 설명합니다.

역할 이름	역할 ID	위치 부여	설명
GKE 허브 관리자	roles/gkehub.admin	Fleet 프로젝트	GKE 허브 및 관련 리소스에 대한 전체 액세스 권한입니다.
서비스 사용량 관리자	roles/serviceusage.serviceUsageAdmin	Fleet 프로젝트	서비스 상태를 사용 설정, 중지, 검사하고 작업을 검사하고 소비자 프로젝트의 할당량과 결제를 사용할 수 있습니다. (참고 1)
CA 서비스 관리자 베타	roles/privateca.admin	Fleet 프로젝트	CA 서비스 리소스에 대한 전체 액세스 권한입니다. (참고 2)

제한사항

Cloud Service Mesh 지원 기능 및 제한사항 목록을 검토하는 것이 좋습니다. 특히 다음 사항에 유의하세요.

• IstioOperator API는 클러스터 내 구성요소를 제어하는 것이 주요 목적이므로 지원되지 않습니다.

• Certificate Authority Service(CA 서비스)를 사용하려면 클러스터별로 Cloud Service Mesh를 구성해야 하며 GKE Enterprise에서 fleet-default 구성을 사용하는 경우에는 지원되지 않습니다.

• GKE Autopilot 클러스터의 경우 프로젝트 간 설정은 GKE 1.23 이상에서만 지원됩니다.

• GKE Autopilot 클러스터의 경우 GKE Autopilot 리소스 한도에 맞게 기본 프록시 리소스 요청 및 한도가 500m CPU 및 512MB 메모리로 설정됩니다. 커스텀 삽입을 사용하여 기본값을 재정의할 수 있습니다.

• 관리형 컨트롤 플레인의 프로비저닝 프로세스 중에 Istio CRD가 지정된 클러스터에 프로비저닝됩니다. 클러스터에 기존 Istio CRD가 있으면 덮어씁니다.

• Istio CNI 및 Cloud Service Mesh는 GKE Sandbox와 호환되지 않습니다. 따라서 TRAFFIC_DIRECTOR 구현을 사용하는 관리형 Cloud Service Mesh는 GKE Sandbox가 사용 설정된 클러스터를 지원하지 않습니다.

시작하기 전에

1. Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

2. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

   Go to project selector

3. Make sure that billing is enabled for your Google Cloud project.

4. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

   Go to project selector

5. Make sure that billing is enabled for your Google Cloud project.

6. Cloud Shell을 사용하는 경우에도 gcloud를 구성합니다.
1. Google Cloud CLI로 인증합니다. 여기서 FLEET_PROJECT_ID는 Fleet 호스트 프로젝트의 ID입니다. 일반적으로 FLEET_PROJECT_ID는 기본 생성되며 프로젝트와 이름이 동일합니다.

          gcloud auth login --project FLEET_PROJECT_ID
   

2. 구성요소를 업데이트합니다.

          gcloud components update
   

7. Fleet 호스트 프로젝트에서 필요한 API를 사용 설정합니다.

     gcloud services enable mesh.googleapis.com \
         --project=FLEET_PROJECT_ID
   

mesh.googleapis.com을 사용 설정하면 다음 API가 사용 설정됩니다.

일부 필수 API는 다른 API에 임시 종속 항목을 갖습니다.

API	목적	사용 중지할 수 있는가?
meshconfig.googleapis.com	Cloud Service Mesh는 Mesh 구성 API를 사용하여 메시의 구성 데이터를 Google Cloud로 릴레이합니다. 또한 Mesh Configuration API를 사용 설정하면 Google Cloud 콘솔에서 Cloud Service Mesh 페이지에 액세스하고 Cloud Service Mesh 인증 기관을 사용할 수 있습니다.	아니요
meshca.googleapis.com	관리형 Cloud Service Mesh에서 사용하는 Cloud Service Mesh 인증 기관과 관련이 있습니다.	아니요
container.googleapis.com	Google Kubernetes Engine(GKE) 클러스터를 만드는 데 필요합니다.	아니요
gkehub.googleapis.com	메시를 Fleet으로 관리하는 데 필요합니다.	아니요
monitoring.googleapis.com	메시 워크로드에 대한 원격 분석을 캡처하는 데 필요합니다.	아니요
stackdriver.googleapis.com	서비스 UI를 사용하는 데 필요합니다.	아니요
opsconfigmonitoring.googleapis.com	Google Cloud 외부 클러스터에 서비스 UI를 사용하는 데 필요합니다.	아니요
connectgateway.googleapis.com	관리형 Cloud Service Mesh 컨트롤 플레인에서 메시 워크로드에 액세스할 수 있도록 하는 데 필요합니다.	예*
trafficdirector.googleapis.com	가용성이 높고 확장 가능한 관리형 컨트롤 플레인을 사용 설정합니다.	예*
networkservices.googleapis.com	가용성이 높고 확장 가능한 관리형 컨트롤 플레인을 사용 설정합니다.	예*
networksecurity.googleapis.com	가용성이 높고 확장 가능한 관리형 컨트롤 플레인을 사용 설정합니다.	예*

관리형 Cloud Service Mesh 구성

Fleet API를 사용하여 관리형 Cloud Service Mesh를 프로비저닝하는 데 필요한 단계는 새 Fleet 클러스터에 대해 기본적으로 사용 설정할지 또는 클러스터별로 사용 설정할지 여부에 따라 다릅니다.

Fleet 구성

Google Kubernetes Engine(GKE) Enterprise 버전을 사용 설정한 경우 관리형 Cloud Service Mesh를 Fleet의 기본 구성으로 사용 설정할 수 있습니다. 즉, 클러스터 생성 중에 등록된 모든 새 Google Cloud 클러스터용 GKE는 클러스터에서 관리형 Cloud Service Mesh를 사용 설정합니다. Fleet 기본 구성에 대한 자세한 내용은 Fleet 수준 기능 관리를 참조하세요.

관리형 Cloud Service Mesh를 Fleet의 기본 구성으로 사용 설정하고 클러스터를 만드는 동안 클러스터를 Fleet에 등록하는 경우 Mesh CA만 지원됩니다. Certificate Authority Service를 사용하려면 클러스터별로 사용 설정하는 것이 좋습니다.

관리형 Cloud Service Mesh에 Fleet 수준 기본값을 사용 설정하려면 다음 단계를 완료합니다.

콘솔

1. Google Cloud 콘솔에서 기능 관리자 페이지로 이동합니다.

   기능 관리자로 이동

2. 서비스 메시 창에서 구성을 클릭합니다.

3. Google Cloud 콘솔에서 만든 모든 새 클러스터에 상속되는 설정을 검토하고 Fleet에 등록합니다.

4. 이러한 설정을 적용하려면 구성을 클릭합니다.

5. 확인 대화상자에서 확인을 클릭합니다.

6. 선택사항: 기존 클러스터를 기본 설정으로 동기화합니다.

   1. Fleet의 클러스터 목록에서 동기화할 클러스터를 선택합니다. Cloud Service Mesh가 설치된 클러스터만 선택할 수 있습니다.
   2. Fleet 설정과 동기화를 클릭하고 확인 대화상자가 나타나면 확인을 클릭합니다. 이 작업을 완료하는 데 몇 분 정도 걸릴 수 있습니다.

gcloud

Google Cloud CLI를 사용하여 Fleet 수준 기본값을 구성하려면 다음 설정을 지정해야 합니다.

• Fleet 수준 설정

  • 한 줄의 management: automatic만 포함된 mesh.yaml 파일을 만듭니다.

    echo "management: automatic" > mesh.yaml
    

  • Fleet에서 Cloud Service Mesh를 사용 설정합니다.

    gcloud container fleet mesh enable --project FLEET_PROJECT_ID \
        --fleet-default-member-config mesh.yaml
    

    다음 오류가 표시되면 GKE Enterprise를 사용 설정해야 합니다.

    ERROR: (gcloud.container.fleet.mesh.enable) FAILED_PRECONDITION: The
    [anthos.googleapis.com] service is required for this operation and is not
    enabled for the project [PROJECT_NUMBER]. Please use the Google Developers
    Console to enable it.: failed precondition
    

• 네트워크 수준 설정

  • 네트워크의 프로젝트가 Fleet 호스트 프로젝트와 다른 경우(예를 들어 공유 VPC를 사용하는 경우) Fleet 프로젝트의 Cloud Service Mesh 서비스 계정이 네트워크 프로젝트에 액세스하도록 허용해야 합니다. 이 작업은 네트워크 프로젝트에 대해 한 번만 수행하면 됩니다.

    Fleet 프로젝트의 서비스 계정에 네트워크 프로젝트에 액세스할 수 있는 권한을 부여합니다.

    gcloud projects add-iam-policy-binding "NETWORK_PROJECT_ID"  \
        --member "serviceAccount:service-FLEET_PROJECT_NUMBER@gcp-sa-servicemesh.iam.gserviceaccount.com" \
        --role roles/anthosservicemesh.serviceAgent
    

• 클러스터 수준 설정

  • Cloud Service Mesh에서 사용할 클러스터를 만들 준비가 되면 Google Cloud CLI를 통해 한 번에 클러스터를 만들고 등록하여 기본 구성을 사용합니다. 예를 들면 다음과 같습니다.

    gcloud container clusters create-auto CLUSTER_NAME \
        --fleet-project FLEET_PROJECT_ID \
        --location=LOCATION
    

    다음 명령어를 실행하여 Fleet 프로젝트의 프로젝트 번호를 가져올 수 있습니다.

    gcloud projects list --filter="FLEET_PROJECT_ID" --format="value(PROJECT_ID)"
    

    --location 플래그는 클러스터의 컴퓨팅 영역이나 리전(예: us-central1-a 또는 us-central1)입니다.

  • 클러스터의 프로젝트가 Fleet 호스트 프로젝트와 다른 경우, 클러스터 프로젝트의 Cloud Service Mesh 서비스 계정이 클러스터 프로젝트에 액세스하도록 허용하고 클러스터 프로젝트에서 필요한 API를 사용 설정해야 합니다. 이 작업은 각 클러스터 프로젝트에 대해 한 번만 수행하면 됩니다.

    Fleet 프로젝트의 서비스 계정에 클러스터 프로젝트에 액세스할 수 있는 권한을 부여합니다.

    gcloud projects add-iam-policy-binding "CLUSTER_PROJECT_ID"  \
        --member "serviceAccount:service-FLEET_PROJECT_NUMBER@gcp-sa-servicemesh.iam.gserviceaccount.com" \
        --role roles/anthosservicemesh.serviceAgent
    

    클러스터 프로젝트에서 Mesh API를 사용 설정합니다.

    gcloud services enable mesh.googleapis.com \
      --project=CLUSTER_PROJECT_ID
    

    CLUSTER_PROJECT_ID를 클러스터 프로젝트의 고유 식별자로 바꿉니다. Fleet과 동일한 프로젝트에 클러스터를 만든 경우 CLUSTER_PROJECT_ID는 FLEET_PROJECT_ID와 동일합니다.

계속해서 제어 영역이 프로비저닝되었는지 확인합니다.

클러스터별 구성

메시의 각 클러스터에 관리형 Cloud Service Mesh를 개별적으로 구성하려면 다음 단계를 수행합니다.

Cloud Service Mesh Fleet 기능 사용 설정

Fleet 프로젝트에서 Cloud Service Mesh를 사용 설정합니다. 여러 클러스터를 등록하려는 경우 Cloud Service Mesh는 Fleet 수준에서 사용 설정되므로 이 명령어는 한 번만 실행하면 됩니다.

gcloud container fleet mesh enable --project FLEET_PROJECT_ID

Fleet에 클러스터 등록

1. Fleet 워크로드 아이덴티티로 GKE 클러스터를 등록합니다. --location 플래그는 클러스터의 컴퓨팅 영역이나 리전(예: us-central1-a 또는 us-central1)입니다.

   gcloud container clusters update CLUSTER_NAME \
     --location CLUSTER_LOCATION \
     --fleet-project FLEET_PROJECT_ID
   

2. 클러스터가 등록되었는지 확인합니다.

   gcloud container fleet memberships list --project FLEET_PROJECT_ID
   

   출력 예시:

   NAME                 EXTERNAL_ID                           LOCATION
   cluster-1            1d8e255d-2b55-4df9-8793-0435461a2cbc  us-central1
   

   자동 관리를 사용 설정할 때 필요하므로 MEMBERSHIP_NAME을 기록합니다.

3. 클러스터의 네트워크 프로젝트가 Fleet 호스트 프로젝트와 다른 경우(예: 공유 VPC 사용) Fleet 프로젝트의 Cloud Service Mesh 서비스 계정이 네트워크 프로젝트에 액세스하도록 허용해야 합니다. 이 작업은 네트워크 프로젝트에 대해 한 번만 수행하면 됩니다.

   Fleet 프로젝트의 서비스 계정에 네트워크 프로젝트에 액세스할 수 있는 권한을 부여합니다.

    gcloud projects add-iam-policy-binding "NETWORK_PROJECT_ID"  \
         --member "serviceAccount:service-FLEET_PROJECT_NUMBER@gcp-sa-servicemesh.iam.gserviceaccount.com" \
         --role roles/anthosservicemesh.serviceAgent
   

4. 클러스터의 프로젝트가 Fleet 호스트 프로젝트와 다른 경우, 클러스터 프로젝트의 Cloud Service Mesh 서비스 계정이 클러스터 프로젝트에 액세스하도록 허용하고 클러스터 프로젝트에서 필요한 API를 사용 설정해야 합니다.

   이 작업은 각 클러스터 프로젝트에 대해 한 번만 수행하면 됩니다. 이전에 이 클러스터와 Fleet 프로젝트 조합에 대해 관리형 Cloud Service Mesh를 구성했다면 이러한 변경사항이 이미 적용되었으므로 다음 명령어를 실행할 필요가 없습니다.

   Fleet 프로젝트의 서비스 계정에 클러스터 프로젝트에 액세스할 수 있는 권한을 부여합니다.

    gcloud projects add-iam-policy-binding "CLUSTER_PROJECT_ID" \
        --member "serviceAccount:service-FLEET_PROJECT_NUMBER@gcp-sa-servicemesh.iam.gserviceaccount.com" \
        --role roles/anthosservicemesh.serviceAgent
   

   클러스터 프로젝트에서 Mesh API를 사용 설정합니다.

    gcloud services enable mesh.googleapis.com \
        --project=CLUSTER_PROJECT_ID
   

Certificate Authority Service 구성(선택사항)

서비스 메시 배포에 Certificate Authority Service(CA Service)가 필요한 경우 관리형 Cloud Service Mesh용 Certificate Authority Service 구성에 따라 Fleet에 사용 설정하세요. 다음 섹션으로 진행하기 전에 모든 단계를 완료해야 합니다.

자동 관리 사용 설정

다음 명령어를 실행하여 자동 관리를 사용 설정합니다.

  gcloud container fleet mesh update \
     --management automatic \
     --memberships MEMBERSHIP_NAME \
     --project FLEET_PROJECT_ID \
     --location MEMBERSHIP_LOCATION

각 항목의 의미는 다음과 같습니다.

• MEMBERSHIP_NAME은 클러스터가 Fleet에 등록되었는지 확인할 때 나열된 멤버십 이름입니다.

• MEMBERSHIP_LOCATION은 멤버십 위치입니다(리전 또는 global).

  최근에 이 가이드의 명령어를 사용하여 멤버십을 만든 경우 클러스터의 리전이어야 합니다. 영역 클러스터가 있는 경우 클러스터의 영역에 해당하는 리전을 사용합니다. 예를 들어 us-central1-c에 영역 클러스터가 있는 경우 값 us-central1을 사용합니다.

  2023년 5월 이전에 등록했거나 멤버십을 등록할 때 global 위치를 지정한 경우 이 값은 global일 수 있습니다. gcloud container fleet memberships list --project FLEET_PROJECT_ID를 사용하여 멤버십의 위치를 확인할 수 있습니다.

제어 영역이 프로비저닝되었는지 확인

몇 분 후 제어 영역 상태가 ACTIVE인지 확인합니다.

gcloud container fleet mesh describe --project FLEET_PROJECT_ID

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

...
membershipSpecs:
  projects/746296320118/locations/us-central1/memberships/demo-cluster-1:
    mesh:
      management: MANAGEMENT_AUTOMATIC
membershipStates:
  projects/746296320118/locations/us-central1/memberships/demo-cluster-1:
    servicemesh:
      controlPlaneManagement:
        details:
        - code: REVISION_READY
          details: 'Ready: asm-managed'
        state: ACTIVE
        implementation: ISTIOD | TRAFFIC_DIRECTOR
      dataPlaneManagement:
        details:
        - code: OK
          details: Service is running.
        state: ACTIVE
    state:
      code: OK
      description: 'Revision(s) ready for use: asm-managed.'
...

implementation 필드에 표시된 컨트롤 플레인(ISTIOD 또는 TRAFFIC_DIRECTOR)을 기록해 둡니다. 컨트롤 플레인 차이점, 지원되는 구성, 컨트롤 플레인 구현 선택 방법은 Cloud Service Mesh 지원 기능을 참조하세요.

kubectl에서 클러스터를 가리키도록 구성합니다.

다음 섹션에서는 각 클러스터에 대해 kubectl 명령어를 실행합니다. 다음 섹션을 진행하기 전에 각 클러스터에 다음 명령어를 실행하여 클러스터를 가리키도록 kubectl을 구성합니다.

gcloud container clusters get-credentials CLUSTER_NAME \
      --location CLUSTER_LOCATION \
      --project CLUSTER_PROJECT_ID

인그레스 게이트웨이는 제어 영역과 함께 자동으로 배포되지 않습니다. 인그레스 게이트웨이와 컨트롤 플레인의 배포를 분리하면 프로덕션 환경에서 게이트웨이를 관리할 수 있습니다. Istio 인그레스 게이트웨이 또는 이그레스 게이트웨이를 사용하려면 게이트웨이 배포를 참조하세요. Kubernetes Gateway API를 사용하려면 메시용 게이트웨이 준비를 참조하세요. 다른 선택적 기능을 사용 설정하려면 Cloud Service Mesh에서 선택적 기능 사용 설정을 참조하세요.

관리형 데이터 영역

관리형 Cloud Service Mesh를 사용하는 경우 사용 중지하지 않는 한 Google에서 프록시 업그레이드를 완전히 관리합니다.

관리형 데이터 영역을 사용하면 프록시의 새 버전을 다시 삽입하도록 워크로드를 재시작하여 사이드카 프록시 및 삽입된 게이트웨이가 관리형 제어 영역과 함께 자동으로 업데이트됩니다. 일반적으로 관리형 제어 영역이 업그레이드된 후 1~2주 이내에 완료됩니다.

사용 중지된 경우 프록시 관리는 클러스터에서 포드의 자연 수명 주기에 따라 수행되고 업데이트 비율 제어를 위해 사용자가 수동으로 트리거해야 합니다.

관리형 데이터 영역은 이전 버전의 프록시를 실행 중인 포드를 삭제하여 프록시를 업그레이드합니다. 제거는 점진적으로 수행되어 포드 중단 예산을 따르고 변경 속도를 제어합니다.

관리형 데이터 영역에서는 다음을 관리하지 않습니다.

• 삽입되지 않은 포드
• 수동으로 삽입된 포드
• 작업
• StatefulSets
• DaemonSets

관리형 데이터 영역 사용 중지(선택사항)

새 클러스터에서 관리형 Cloud Service Mesh를 프로비저닝하는 경우 관리형 데이터 영역을 완전히 또는 개별 네임스페이스 또는 포드에 대해 사용 중지할 수 있습니다. 기본적으로 또는 수동으로 중지된 기존 클러스터에 대해 관리형 데이터 영역이 계속 사용 중지됩니다.

클러스터 수준에서 관리형 데이터 영역을 사용 중지하고 사이드카 프록시를 직접 관리하도록 되돌리려면 주석을 변경합니다.

kubectl annotate --overwrite controlplanerevision -n istio-system \
  mesh.cloud.google.com/proxy='{"managed":"false"}'

네임스페이스의 관리형 데이터 영역을 사용 중지하려면 다음 안내를 따르세요.

kubectl annotate --overwrite namespace NAMESPACE \
  mesh.cloud.google.com/proxy='{"managed":"false"}'

포드의 관리형 데이터 영역을 사용 중지하려면 다음 안내를 따르세요.

kubectl annotate --overwrite pod POD_NAME \
  mesh.cloud.google.com/proxy='{"managed":"false"}'

유지보수 알림 사용 설정

유지보수가 예약되기 최대 1주일 전에 예정된 관리형 데이터 영역 유지보수에 대한 알림을 요청할 수 있습니다. 유지보수 알림은 기본적으로 전송되지 않습니다. 알림을 받으려면 먼저 GKE 유지보수 기간도 구성해야 합니다. 사용 설정하면 업그레이드 작업 최소 2일 전에 알림이 전송됩니다.

관리형 데이터 영역 유지보수 알림을 받으려면 다음 안내를 따르세요.

1. 커뮤니케이션 페이지로 이동합니다.

   커뮤니케이션 페이지로 이동

2. Cloud Service Mesh 업그레이드 행의 이메일 열에서 라디오 버튼을 사용 설정하여 유지보수 알림을 사용 설정하세요.

알림을 받으려는 각 사용자가 개별적으로 선택해야 합니다. 이러한 알림에 대한 이메일 필터를 설정하려는 경우 제목 줄은 다음과 같습니다.

Upcoming upgrade for your Cloud Service Mesh cluster "CLUSTER_LOCATION/CLUSTER_NAME".

다음 예시에서는 일반적인 관리형 데이터 영역 유지보수 알림을 보여줍니다.

제목 줄: Cloud Service Mesh 클러스터 '<location/cluster-name>' 업그레이드 예정

Cloud Service Mesh 사용자님,

${instance_id}(https://console.cloud.google.com/kubernetes/clusters/details/${instance_id}/details?project=${project_id}) 클러스터의 Cloud Service Mesh 구성요소가 ${scheduled_date_human_readable} ${scheduled_time_human_readable}에 업그레이드될 예정입니다.

출시 노트 (https://cloud.google.com/service-mesh/docs/release-notes)를 확인하여 새로운 업데이트에 대해 알아볼 수 있습니다.

이 유지보수가 취소되면 이메일을 다시 보내드리겠습니다.

감사합니다.

Cloud Service Mesh팀

(c) 2023 Google LLC 1600 Amphithoter Parkway, Mountain View, CA 94043 Google Cloud Platform 또는 계정의 중요 변경사항에 대한 업데이트를 알리기 위해 전송되는 공지입니다. 사용자 환경설정(https://console.cloud.google.com/user-preferences/communication?project=${project_id})을 수정하면 유지보수 기간 알림 수신을 해제할 수 있습니다.

엔드포인트 검색 구성(멀티 클러스터 설치만 해당)

메시에 클러스터가 하나만 있으면 이러한 멀티 클러스터 단계를 건너뛰고 애플리케이션 배포 또는 애플리케이션 마이그레이션으로 이동합니다.

계속하기 전에 각 클러스터에 Cloud Service Mesh가 구성되어 있는지 확인합니다.

Fleet API로 Cloud Service Mesh를 사용 설정하면 이 클러스터에 엔드포인트 검색이 사용 설정됩니다. 그러나 방화벽 포트를 열어야 합니다. 하나 이상의 클러스터에 대해 엔드포인트 검색을 중지하려면 선언적 API로 클러스터 간 엔드포인트 검색에서 엔드포인트 검색을 중지하는 안내를 참조하세요.

두 개의 클러스터가 있는 애플리케이션 예시는 HelloWorld 서비스 예시를 참조하세요.

애플리케이션 배포

관리형 Cloud Service Mesh를 사용하는 Fleet에 클러스터가 두 개 이상 있는 경우 애플리케이션을 진행하고 배포하기 전에 엔드포인트 검색 또는 방화벽 포트가 의도한 대로 구성되어 있는지 확인합니다.

네임스페이스의 삽입을 사용 설정합니다. 이 단계는 컨트롤 플레인 구현에 따라 다릅니다.

관리형(TD)

1. 기본 삽입 라벨을 네임스페이스에 적용합니다.

kubectl label namespace NAMESPACE \
    istio.io/rev- istio-injection=enabled --overwrite

관리형(Istiod)

권장: 다음 명령어를 실행하여 네임스페이스에 기본 삽입 라벨을 적용합니다.

  kubectl label namespace NAMESPACE \
      istio.io/rev- istio-injection=enabled --overwrite

관리형 Istiod 컨트롤 플레인이 있는 기존 사용자: 기본 삽입을 사용하는 것이 좋지만 버전 기반 삽입은 지원됩니다. 다음 안내를 따르세요.

1. 다음 명령어를 실행하여 사용 가능한 출시 채널을 찾습니다.

   kubectl -n istio-system get controlplanerevision
   

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

   NAME                AGE
   asm-managed-rapid   6d7h
   

   참고: 위 목록에 두 개의 컨트롤 플레인 버전이 표시되면 하나를 삭제합니다. 클러스터에 여러 컨트롤 플레인 채널을 두는 방식은 지원되지 않습니다.

   출력에서 NAME 열 아래의 값은 Cloud Service Mesh 버전에 사용 가능한 출시 채널에 해당하는 버전 라벨입니다.

2. 네임스페이스에 버전 라벨을 적용합니다.

   kubectl label namespace NAMESPACE \
       istio-injection- istio.io/rev=REVISION_LABEL --overwrite
   

이제 관리형 Cloud Service Mesh가 구성되었습니다. 라벨이 지정된 네임스페이스에 기존 워크로드가 있으면 프록시가 삽입되도록 워크로드를 다시 시작합니다.

멀티 클러스터 설정으로 애플리케이션을 배포할 경우 특정 구성을 클러스터 하위 집합으로 제한할 계획이 아닌 한 모든 클러스터에서 Kubernetes 및 제어 영역 구성을 복제합니다. 특정 클러스터에 적용되는 구성은 해당 클러스터에 대한 정보 소스입니다.

삽입 맞춤설정(선택사항)

기본값을 재정의하고 삽입 설정을 맞춤설정할 수 있지만, 이 경우 예기치 않은 구성 오류가 발생하여 사이드카 컨테이너에 문제가 발생할 수 있습니다. 삽입을 맞춤설정하기 전에 샘플 뒤의 정보에서 특정 설정 및 권장사항에 관한 노트를 읽어보세요.

개별 포드에서 포드별 구성을 사용하여 이러한 옵션을 재정의할 수 있습니다. 이렇게 하려면 istio-proxy 컨테이너를 포드에 추가합니다. 사이드카 삽입은 여기에 정의된 모든 구성을 기본 삽입 템플릿에 대한 재정의로 취급합니다.

예를 들어 다음 구성은 CPU 요청 낮추기, 볼륨 마운트 추가, preStop 후크 추가를 포함한 다양한 설정을 맞춤설정합니다.

apiVersion: v1
kind: Pod
metadata:
  name: example
spec:
  containers:
  - name: hello
    image: alpine
  - name: istio-proxy
    image: auto
    resources:
      requests:
        cpu: "200m"
        memory: "256Mi"
      limits:
        cpu: "200m"
        memory: "256Mi"
    volumeMounts:
    - mountPath: /etc/certs
      name: certs
    lifecycle:
      preStop:
        exec:
          command: ["sleep", "10"]
  volumes:
  - name: certs
    secret:
      secretName: istio-certs

일반적으로 포드에 있는 모든 필드를 설정할 수 있습니다. 하지만 일부 필드에는 주의해야 합니다.

• Kubernetes에서는 삽입을 실행하기 전에 image 필드를 설정해야 합니다. 특정 이미지를 설정하여 기본 이미지를 재정의할 수 있지만, image를 auto로 설정하는 것이 좋습니다. 그러면 사이드카 인젝터가 자동으로 사용할 이미지를 선택합니다.
• containers의 일부 필드는 관련 설정에 따라 달라집니다. 예를 들어 CPU 한도보다 작거나 같아야 합니다. 두 필드가 모두 올바르게 구성되지 않으면 포드 시작이 실패할 수 있습니다.
• Kubernetes를 사용하면 spec 포드의 리소스에 requests 및 limits를 둘 다 설정할 수 있습니다. GKE Autopilot에서는 requests만 고려합니다. 자세한 내용은 Autopilot에서 리소스 한도 설정을 참조하세요.

또한 포드의 주석으로 특정 필드를 구성할 수 있지만 위의 방식을 사용하여 설정을 맞춤설정하는 것이 좋습니다. 다음 주석에는 특히 주의하세요.

• GKE Standard의 경우 sidecar.istio.io/proxyCPU가 설정되면 sidecar.istio.io/proxyCPULimit을 명시적으로 설정해야 합니다. 그렇지 않으면 사이드카의 CPU 한도가 무제한으로 설정됩니다.
• GKE Standard의 경우 sidecar.istio.io/proxyMemory가 설정되면 sidecar.istio.io/proxyMemoryLimit을 명시적으로 설정해야 합니다. 그렇지 않으면 사이드카의 메모리 한도가 무제한으로 설정됩니다.
• GKE Autopilot의 경우 주석을 사용하여 requests 및 limits 리소스를 구성하면 리소스가 초과 프로비저닝될 수 있습니다. 이를 방지하려면 이미지 템플릿 방식을 사용하세요. Autopilot의 리소스 수정 예시를 참조하세요.

예를 들어 아래 리소스 주석을 참조하세요.

spec:
  template:
    metadata:
      annotations:
        sidecar.istio.io/proxyCPU: "200m"
        sidecar.istio.io/proxyCPULimit: "200m"
        sidecar.istio.io/proxyMemory: "256Mi"
        sidecar.istio.io/proxyMemoryLimit: "256Mi"

관리형 Cloud Service Mesh로 애플리케이션 마이그레이션

클러스터 내 Cloud Service Mesh에서 관리형 Cloud Service Mesh로 애플리케이션을 마이그레이션하려면 다음 단계를 수행합니다.

1. 현재 네임스페이스 라벨을 바꿉니다. 이 단계는 컨트롤 플레인 구현에 따라 다릅니다.

관리형(TD)

1. 기본 삽입 라벨을 네임스페이스에 적용합니다.

kubectl label namespace NAMESPACE \
    istio.io/rev- istio-injection=enabled --overwrite

관리형(Istiod)

권장: 다음 명령어를 실행하여 네임스페이스에 기본 삽입 라벨을 적용합니다.

  kubectl label namespace NAMESPACE \
      istio.io/rev- istio-injection=enabled --overwrite

관리형 Istiod 컨트롤 플레인이 있는 기존 사용자: 기본 삽입을 사용하는 것이 좋지만 버전 기반 삽입은 지원됩니다. 다음 안내를 따르세요.

1. 다음 명령어를 실행하여 사용 가능한 출시 채널을 찾습니다.

   kubectl -n istio-system get controlplanerevision
   

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

   NAME                AGE
   asm-managed-rapid   6d7h
   

   참고: 위 목록에 두 개의 컨트롤 플레인 버전이 표시되면 하나를 삭제합니다. 클러스터에 여러 컨트롤 플레인 채널을 두는 방식은 지원되지 않습니다.

   출력에서 NAME 열 아래의 값은 Cloud Service Mesh 버전에 사용 가능한 출시 채널에 해당하는 버전 라벨입니다.

2. 네임스페이스에 버전 라벨을 적용합니다.

   kubectl label namespace NAMESPACE \
       istio-injection- istio.io/rev=REVISION_LABEL --overwrite
   

1. 네임스페이스에서 배포를 순차적으로 업그레이드합니다.

   kubectl rollout restart deployment -n NAMESPACE
   

2. 애플리케이션을 테스트하여 워크로드가 올바르게 작동하는지 확인합니다.

3. 다른 네임스페이스에 워크로드가 있으면 각 네임스페이스에 이전 단계를 반복합니다.

4. 멀티 클러스터 설정에서 애플리케이션을 배포한 경우 구성을 클러스터 하위 집합으로 제한하려는 경우를 제외하고 모든 클러스터에서 Kubernetes 및 Istio 구성을 복제합니다. 특정 클러스터에 적용되는 구성은 해당 클러스터에 대한 정보 소스입니다.

애플리케이션이 예상한 대로 작동하면 모든 네임스페이스를 관리형 제어 영역으로 전환한 후 클러스터 내 istiod를 삭제하거나 백업으로 보존할 수 있습니다. istiod는 더 적은 리소스를 사용하도록 자동으로 축소됩니다. 삭제하려면 이전 제어 영역 삭제로 건너뜁니다.

문제가 발생하면 관리형 제어 영역 문제 해결의 정보에 따라 식별하고 해결할 수 있고, 필요한 경우 이전 버전으로 롤백할 수 있습니다.

이전 제어 영역 삭제

설치를 수행하고 모든 네임스페이스에 Google 관리형 제어 영역이 사용되는지 확인한 후 이전 제어 영역을 삭제할 수 있습니다.

kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod -n istio-system --ignore-not-found=true

자동 삽입 대신 istioctl kube-inject를 사용한 경우 또는 추가적인 게이트웨이를 설치한 경우, 제어 영역에 대해 측정항목을 확인하고 연결된 엔드포인트 수가 0인지 확인합니다.

롤백

이전 제어 영역 버전으로 롤백해야 할 경우 다음 단계를 수행합니다.

1. 제어 영역의 이전 버전에 삽입할 워크로드를 업데이트합니다. 다음 명령어에서 버전 값 asm-191-1은 예시로만 사용되었습니다. 예시 값을 이전 제어 영역의 버전 라벨로 바꾸세요.

   kubectl label namespace NAMESPACE istio-injection- istio.io/rev=asm-191-1 --overwrite
   

2. 프록시에 이전 버전이 지정되도록 재삽입을 트리거하는 포드를 다시 시작합니다.

   kubectl rollout restart deployment -n NAMESPACE
   

관리형 제어 영역이 자동으로 0으로 축소되고 사용 중이 아닐 때는 리소스를 사용하지 않습니다. 변형 웹훅 및 프로비저닝은 그대로 유지되고 클러스터 동작에 영향을 주지 않습니다.

이제 게이트웨이가 asm-managed 버전으로 설정되었습니다. 롤백하려면 Cloud Service Mesh install 명령어를 다시 실행합니다. 그러면 클러스터 내 컨트롤 플레인을 다시 가리키는 게이트웨이가 다시 배포됩니다.

kubectl -n istio-system rollout undo deploy istio-ingressgateway

성공하면 다음 출력이 표시됩니다.

deployment.apps/istio-ingressgateway rolled back

Cloud Service Mesh 제거

관리형 제어 영역은 사용하는 네임스페이스가 없으면 0으로 자동 축소됩니다. 자세한 단계는 Cloud Service Mesh 제거를 참조하세요.