관리형 Anthos Service Mesh 프로비저닝

관리형 Anthos Service Mesh는 사용 설정만 하면 되는 Google 관리형 서비스 메시입니다. Google은 이전 버전과 호환되는 방식으로 안정성, 업그레이드, 확장, 보안을 처리합니다.

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

Fleet API를 사용하여 관리형 Anthos Service Mesh를 사용 설정하면 다음이 가능합니다.

Google에서 권장되는 제어 영역 구성을 적용합니다.
Google에서 자동 데이터 영역 관리를 지원합니다.
Google Kubernetes Engine(GKE) 클러스터의 출시 채널을 기반으로 클러스터가 Anthos Service Mesh 출시 채널에 등록되며 제어 영역과 데이터 영역이 각각의 새로운 출시를 통해 최신 상태로 유지됩니다.
방화벽 규칙을 생성해야 하지만 Google은 기본 설정을 사용하여 서비스 메시 전체에서 엔드포인트 검색 및 교차 클러스터 부하 분산을 사용 설정합니다.

원하는 경우 다음과 같은 온보딩 경로를 이용하세요.

gcloud를 사용하여 Google Cloud API 및 IAM을 사용하여 관리형 Anthos Service Mesh를 구성하려는 경우
다른 Fleet 기능과 동일한 API를 사용하여 Anthos Service Mesh를 구성하려는 경우
각 클러스터에 권장되는 Anthos Service Mesh 구성을 자동으로 가져오려는 경우

기본 요건

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

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

요구사항

지원되는 리전 중 하나에서 지원되는 GKE 버전이 있는 클러스터가 한 개 이상 있어야 합니다.
클러스터에 관리형 Anthos Service Mesh가 클러스터에 설치하는 필수 구성요소를 위한 충분한 용량이 있는지 확인합니다.
- kube-system 네임스페이스의 mdp-controller 배포는 cpu:50m, 메모리: 128Mi를 요청합니다.
- kube-system 네임스페이스의 istio-cni-node daemonset는 각 노드에서 cpu: 100m, 메모리: 100Mi를 요청합니다.
관리형 Anthos Service Mesh를 프로비저닝할 클라이언트 머신이 API 서버에 네트워크로 연결되어 있는지 확인합니다.
클러스터를 Fleet에 등록해야 합니다. 이는 안내에 포함되거나 프로비저닝 전에 별도로 수행될 수 있습니다.
프로젝트에 서비스 메시 Fleet 기능이 사용 설정되어 있어야 합니다. 이는 안내에 포함되어 있거나 별도로 수행될 수 있습니다.
GKE Autopilot은 GKE 버전 1.21.3 이상에서만 지원됩니다.
Istio CNI는 필수이며 관리형 Anthos Service Mesh를 프로비저닝할 때 기본적으로 설치됩니다.
관리형 Anthos Service Mesh는 단일 프로젝트 단일 네트워크 환경 또는 다중 프로젝트 단일 네트워크 환경에서 여러 GKE 클러스터를 사용할 수 있습니다.
- 동일한 프로젝트에 없는 클러스터를 조인하는 경우 클러스터는 동일한 Fleet 호스트 프로젝트에 등록되어야 하며 클러스터가 동일한 네트워크의 공유 VPC 구성에 함께 있어야 합니다.
- 단일 프로젝트 멀티 클러스터 환경에서는 Fleet 프로젝트가 클러스터 프로젝트와 같을 수 있습니다. Fleet에 대한 자세한 내용은 Fleet 개요를 참조하세요.
- 멀티 프로젝트 환경의 경우 클러스터 프로젝트와 별도의 프로젝트에서 Fleet을 호스팅하는 것이 좋습니다. 조직 정책과 기존 구성에서 허용하는 경우 공유 VPC 프로젝트를 Fleet 호스트 프로젝트로 사용하는 것이 좋습니다. 자세한 내용은 공유 VPC를 사용하여 클러스터 설정을 참조하세요.
- 조직에서 VPC 서비스 제어를 사용하고 GKE 클러스터에서 관리형 Anthos Service Mesh를 프로비저닝하는 경우 Anthos Service Mesh용 VPC 서비스 제어의 단계도 따라야 합니다.

제한사항

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

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

참고: IstioOperator API를 사용하지 않고도 선택적 기능을 사용 설정할 수 있습니다. 관리형 Anthos Service Mesh에서 선택적 기능 사용 설정을 참조하세요. asmcli가 포함된 마이그레이션 도구를 사용하여 다른 IstioOperator 선택적 기능을 관리형 제어 영역과 호환되도록 자동 변환할 수도 있습니다. 자세한 내용은 IstioOperator에서 마이그레이션을 참조하세요.
Fleet API로 관리형 Anthos Service Mesh를 사용 설정하면 Mesh CA가 사용됩니다. 서비스 메시 배포에 규제 대상 워크로드가 포함되어 있거나 Certificate Authority Service(CA 서비스)가 필요한 경우 asmcli를 사용하여 관리형 Anthos Service Mesh 프로비저닝을 따르세요.
asmcli가 포함된 관리형 Anthos Service Mesh에서 Fleet API가 있는 Anthos Service Mesh로 마이그레이션할 수 없습니다. 마찬가지로 --management manual에서 --management automatic까지의 Fleet API를 사용하여 관리형 Anthos Service Mesh를 구성할 수 없습니다.
GKE Autopilot 클러스터의 경우 프로젝트 간 설정은 GKE 1.23 이상에서만 지원됩니다.
GKE Autopilot 클러스터의 경우 GKE Autopilot 리소스 한도에 맞게 기본 프록시 리소스 요청 및 한도가 500m CPU 및 512MB 메모리로 설정됩니다. 커스텀 삽입을 사용하여 기본값을 재정의할 수 있습니다.
관리형 Anthos Service Mesh에서 사용할 수 있는 실제 기능은 출시 채널에 따라 다릅니다. 자세한 내용은 관리형 Anthos Service Mesh 지원 기능 및 제한사항의 전체 목록을 참조하세요.
관리형 제어 영역의 프로비저닝 프로세스 중에 선택한 채널에 해당하는 Istio CRD가 지정된 클러스터에 프로비저닝됩니다. 클러스터에 기존 Istio CRD가 있으면 덮어씁니다.
Istio CNI는 GKE Sandbox와 호환되지 않습니다. 관리형 Istio CNI가 필요하므로 Autopilot의 관리형 Anthos Service Mesh가 GKE Sandbox와 호환되지 않습니다.

시작하기 전에

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.

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

Go to project selector

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

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

Go to project selector

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

Cloud Shell을 사용하는 경우에도 gcloud를 구성합니다.

Google Cloud CLI로 인증합니다. 여기서 FLEET_PROJECT_ID는 Fleet 호스트 프로젝트의 ID입니다. 일반적으로 FLEET_PROJECT_ID는 기본 생성되며 프로젝트와 이름이 동일합니다.
```
       gcloud auth login --project FLEET_PROJECT_ID
```
구성요소를 업데이트합니다.
```
       gcloud components update
```

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

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

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

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

API	목적	사용 중지할 수 있는가?
`meshconfig.googleapis.com`	Anthos Service Mesh는 Mesh Configuration API를 사용하여 메시의 구성 데이터를 Google Cloud로 릴레이합니다. 또한 Mesh Configuration API를 사용 설정하면 Google Cloud 콘솔에서 Anthos Service Mesh 페이지에 액세스하고 Anthos Service Mesh 인증 기관(Mesh CA)을 사용할 수 있습니다.	아니요
`meshca.googleapis.com`	관리형 Anthos Service Mesh에서 사용하는 Anthos 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`	관리형 Anthos Service Mesh 제어 영역에서 메시 워크로드에 액세스할 수 있도록 하는 데 필요합니다.	예*
`trafficdirector.googleapis.com`	가용성이 높고 확장 가능한 관리형 제어 영역을 사용 설정합니다.	예*
`networkservices.googleapis.com`	가용성이 높고 확장 가능한 관리형 제어 영역을 사용 설정합니다.	예*
`networksecurity.googleapis.com`	가용성이 높고 확장 가능한 관리형 제어 영역을 사용 설정합니다.	예*

경고: connectgateway.googleapis.com, trafficdirector.googleapis.com, networkservices.googleapis.com 및/또는 networksecurity.googleapis.com을 사용 중지하면 관리형 Anthos Service Mesh 제어 영역이 작동을 중지합니다. Fleet이 클러스터에서 관리형 Anthos Service Mesh를 사용하지 않는 경우 이러한 API를 사용 중지할 수 있습니다.

관리형 Anthos Service Mesh 구성

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

Fleet 구성

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

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

Console

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

기능 관리자로 이동
서비스 메시 창에서 구성을 클릭합니다.
Google Cloud 콘솔에서 만든 모든 새 클러스터에 상속되는 설정을 검토하고 Fleet에 등록합니다.

참고: 이러한 설정은 Anthos Service Mesh를 사용하기 위한 기본 요건인 GKE 설정입니다.
이러한 설정을 적용하려면 구성을 클릭합니다.
확인 대화상자에서 확인을 클릭합니다.
선택사항: 기존 클러스터를 기본 설정으로 동기화합니다.
1. Fleet의 클러스터 목록에서 동기화할 클러스터를 선택합니다. Anthos Service Mesh가 설치된 클러스터만 선택할 수 있습니다.
2. Fleet 설정과 동기화를 클릭하고 확인 대화상자가 나타나면 확인을 클릭합니다. 이 작업을 완료하는 데 몇 분 정도 걸릴 수 있습니다.

gcloud

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

Fleet 수준 설정

한 줄의 management: automatic만 포함된 mesh.yaml 파일을 만듭니다.
```
echo "management: automatic" > mesh.yaml
```

Fleet에 Anthos 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

클러스터 수준 설정
- Anthos 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 호스트 프로젝트와 다른 경우, 클러스터 프로젝트의 Anthos 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와 동일합니다.

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

클러스터별 구성

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

Anthos Service Mesh Fleet 기능 사용 설정

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

gcloud container fleet mesh enable --project FLEET_PROJECT_ID

Fleet에 클러스터 등록

Fleet 워크로드 아이덴티티로 GKE 클러스터를 등록합니다. --location 플래그는 클러스터의 컴퓨팅 영역이나 리전(예: us-central1-a 또는 us-central1)입니다.
```
gcloud container clusters update CLUSTER_NAME \
  --location CLUSTER_LOCATION \
  --fleet-project FLEET_PROJECT_ID
```

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

gcloud container fleet memberships list --project FLEET_PROJECT_ID

출력 예시:

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

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

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

이전에 asmcli를 사용하여 이 클러스터와 Fleet 프로젝트의 조합에 대해 관리형 Anthos 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
```

자동 관리 사용 설정

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

  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
      dataPlaneManagement:
        details:
        - code: OK
          details: Service is running.
        state: ACTIVE
    state:
      code: OK
      description: 'Revision(s) ready for use: asm-managed.'
...

제공된 출력에서 details 필드의 버전 라벨(예: asm-managed)을 기록해 둡니다. 버전 라벨을 사용하는 경우 애플리케이션을 배포하기 전에 이 라벨을 설정해야 합니다. 기본 삽입 라벨을 사용하는 경우 이 라벨을 설정할 필요가 없습니다.

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

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

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

인그레스 게이트웨이는 제어 영역과 함께 자동으로 배포되지 않습니다. 인그레스 게이트웨이와 제어 영역의 배포를 분리하면 프로덕션 환경에서 게이트웨이를 보다 쉽게 관리할 수 있습니다. 클러스터에 인그레스 게이트웨이 또는 이그레스 게이트웨이가 필요한 경우 게이트웨이 배포를 참조하세요. 다른 선택적인 기능을 사용 설정하려면 관리형 Anthos Service Mesh에서 선택적 기능 사용 설정을 참조하세요.

관리형 데이터 영역

관리형 Anthos Service Mesh를 사용하는 경우 네임스페이스, 워크로드 또는 버전 수준에서 중지하지 않는 한 Google에서 프록시 업그레이드를 완전히 관리합니다.

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

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

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

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

삽입되지 않은 포드
수동으로 삽입된 포드
작업
StatefulSet
DaemonSet

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

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

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

kubectl annotate --overwrite controlplanerevision -n istio-system \
REVISION_LABEL \
  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일 전에 알림이 전송됩니다.

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

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

커뮤니케이션 페이지로 이동
Anthos Service Mesh 업그레이드 행의 이메일 열에서 라디오 버튼을 사용 설정하여 유지보수 알림을 사용 설정하세요.

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

Upcoming upgrade for your Anthos Service Mesh cluster "CLUSTER_LOCATION/CLUSTER_NAME"

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

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

Anthos Service Mesh 사용자님께,

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

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

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

감사합니다.

Anthos Service Mesh팀

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

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

계속하기 전에 이전 단계에 설명된 대로 각 클러스터에 관리형 Anthos Service Mesh가 이미 구성되어 있어야 합니다. 기본 동작이므로 클러스터가 기본 클러스터임을 나타낼 필요는 없습니다.

또한 asmcli를 다운로드하고(샘플 애플리케이션으로 구성을 확인하려는 경우에만) 프로젝트와 클러스터 변수를 설정했는지 확인합니다.

공개 클러스터

공개 클러스터 간 엔드포인트 검색 구성

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

비공개 클러스터

비공개 클러스터 간 엔드포인트 디스커버리 구성

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

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

애플리케이션 배포

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

애플리케이션을 배포하려면 설치 중에 구성한 채널에 해당하는 라벨을 사용하거나 기본 삽입 라벨을 사용하는 경우 istio-injection=enabled를 사용합니다.

기본 삽입 라벨

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

버전 라벨

애플리케이션을 배포하기 전 해당 네임스페이스에서 모든 이전 istio-injection 라벨을 삭제하고 대신 istio.io/rev=REVISION_LABEL 라벨을 설정합니다.

이는 제어 영역을 확인할 때 식별된 버전 라벨입니다. 특정 버전 라벨로 변경하려면 REVISION_LABEL을 클릭하고 해당 라벨로 바꿉니다(신속의 경우 asm-managed-rapid, 일반의 경우 asm-managed, 정식의 경우 asm-managed-stable).

버전 라벨은 출시 채널을 따릅니다.

버전 라벨	채널
`asm-managed`	일반
`asm-managed-rapid`	신속
`asm-managed-stable`	정식

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

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

이제 애플리케이션을 배포할 수 있거나 Bookinfo 샘플 애플리케이션을 배포할 수 있습니다.

멀티 클러스터 설정으로 애플리케이션을 배포할 경우 특정 구성을 클러스터 하위 집합으로 제한할 계획이 아닌 한 모든 클러스터에서 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"
      limites:
        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 요청은 CPU 한도보다 작아야 합니다. 두 필드가 모두 올바르게 구성되지 않으면 포드 시작이 실패할 수 있습니다.
Kubernetes를 사용하면 PodSpec의 리소스에 requests 및 limits를 모두 설정할 수 있습니다. GKE Autopilot에서는 requests만 고려합니다. 자세한 내용은 Autopilot에서 리소스 한도 설정을 참조하세요.

또한 pod의 주석으로 특정 필드를 구성할 수 있지만 위의 방식을 사용하여 설정을 맞춤설정하는 것이 좋습니다. 특정 주석에는 더욱 주의해야 합니다.

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"

제어 영역 측정항목 확인

측정항목 탐색기에서 제어 영역과 데이터 영역의 버전을 볼 수 있습니다.

구성이 제대로 작동하는지 확인하려면 다음 안내를 따르세요.

Google Cloud 콘솔에서 제어 영역 측정항목을 열람하세요.

측정항목 탐색기로 이동
작업공간을 선택하고 다음 매개변수를 사용하여 커스텀 쿼리를 추가합니다.
- 리소스 유형: Kubernetes 컨테이너
- 측정항목: 프록시 클라이언트
- 필터: container_name="cr-REVISION_LABEL"
- 그룹화 기준: revision 라벨 및 proxy_version 라벨
- 애그리게이터: 합계
- 기간: 1분
Google 관리형 및 클러스터 내 제어 영역을 모두 사용해서 Anthos Service Mesh를 실행할 때는 측정항목을 해당 컨테이너 이름과 구분할 수 있습니다. 예를 들어 관리형 측정항목은 container_name="cr-asm-managed"를 포함하고 비관리형 측정항목은 container_name="discovery"를 포함합니다. 두 가지 측정항목을 모두 표시하려면 container_name="cr-asm-managed"에 대한 필터를 삭제합니다.
측정항목 탐색기에서 다음 필드를 검사하여 제어 영역 버전과 프록시 버전을 확인합니다.
- revision 필드는 제어 영역 버전을 나타냅니다.
- proxy_version 필드는 proxy_version을 나타냅니다.
- value 필드는 연결된 프록시 수를 나타냅니다.
현재 채널에서 Anthos Service Mesh로의 버전 매핑은 채널별 Anthos Service Mesh 버전을 참조하세요.

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

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

현재 네임스페이스 라벨을 바꿉니다. 필요한 단계는 기본 삽입 라벨(예: istio-injection enabled) 또는 버전 라벨을 사용할지 여부에 따라 다릅니다.
기본 삽입 라벨
1. 다음 명령어를 실행하여 기본 태그를 관리형 버전으로 이동하세요.
```
istioctl tag set default --revision REVISION_LABEL
```
2. 아직 사용하지 않은 경우 다음 명령어를 실행하여 istio-injection=enabled를 사용해 네임스페이스에 라벨을 지정합니다.
```
kubectl label namespace NAMESPACE istio-injection=enabled istio.io/rev- \
--overwrite
```
버전 라벨
istio.io/rev=REVISION_LABEL 라벨을 사용한 경우 다음 명령어를 실행합니다.
```
kubectl label namespace NAMESPACE istio-injection- istio.io/rev=REVISION_LABEL \
    --overwrite
```
네임스페이스에서 배포를 순차적으로 업그레이드합니다.
```
kubectl rollout restart deployment -n NAMESPACE
```
애플리케이션을 테스트하여 워크로드가 올바르게 작동하는지 확인합니다.
다른 네임스페이스에 워크로드가 있으면 각 네임스페이스에 이전 단계를 반복합니다.
멀티 클러스터 설정에서 애플리케이션을 배포한 경우 구성을 클러스터 하위 집합으로 제한하려는 경우를 제외하고 모든 클러스터에서 Kubernetes 및 Istio 구성을 복제합니다. 특정 클러스터에 적용되는 구성은 해당 클러스터에 대한 정보 소스입니다.
제어 영역 측정항목 확인의 단계를 수행하여 측정항목이 예상한 대로 표시되는지 확인합니다.

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

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

이전 제어 영역 삭제

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

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

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

롤백

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

제어 영역의 이전 버전에 삽입할 워크로드를 업데이트합니다. 다음 명령어에서 버전 값 asm-191-1은 예시로만 사용되었습니다. 예시 값을 이전 제어 영역의 버전 라벨로 바꾸세요.
```
kubectl label namespace NAMESPACE istio-injection- istio.io/rev=asm-191-1 --overwrite
```
프록시에 이전 버전이 지정되도록 재삽입을 트리거하는 포드를 다시 시작합니다.
```
kubectl rollout restart deployment -n NAMESPACE
```

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

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

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

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

deployment.apps/istio-ingressgateway rolled back

Anthos Service Mesh 제거

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

문제 해결

관리형 제어 영역을 사용할 때의 문제를 식별하고 해결하려면 관리형 제어 영역 문제 해결을 참조하세요.

다음 단계

다음과 같은 선택적 관리형 Anthos Service Mesh 기능을 사용 설정하는 방법을 알아보세요.
메시를 보호하도록 전송 보안 구성

관리형 Anthos Service Mesh 프로비저닝

기본 요건

요구사항

제한사항

시작하기 전에

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

관리형 Anthos Service Mesh 구성

Fleet 구성

Console

gcloud

클러스터별 구성

Anthos Service Mesh Fleet 기능 사용 설정

Fleet에 클러스터 등록

자동 관리 사용 설정

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

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

관리형 데이터 영역

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

유지보수 알림 사용 설정

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

공개 클러스터

공개 클러스터 간 엔드포인트 검색 구성

비공개 클러스터

비공개 클러스터 간 엔드포인트 디스커버리 구성

애플리케이션 배포

기본 삽입 라벨

버전 라벨

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

제어 영역 측정항목 확인

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

기본 삽입 라벨

버전 라벨

이전 제어 영역 삭제

롤백

Anthos Service Mesh 제거

문제 해결

다음 단계

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