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

asmcli로 Cloud Service Mesh 프로비저닝

개요

asmcli가 포함된 관리형 Cloud Service Mesh는 관리형 컨트롤 플레인이자 간단히 구성하는 관리형 데이터 영역입니다. Google은 이전 버전과 호환되는 방식으로 안정성, 업그레이드, 확장, 보안을 처리합니다. 이 가이드에서는 asmcli를 사용하여 애플리케이션을 단일 또는 멀티 클러스터 구성의 관리형 Cloud Service Mesh로 설정하거나 마이그레이션하는 방법을 설명합니다.

관리형 Cloud Service Mesh의 지원되는 기능 및 제한사항은 Cloud Service Mesh 지원 기능을 참조하세요.

기본 요건

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

Cloud 프로젝트
Cloud Billing 계정
Cloud Service Mesh를 프로비저닝하는 데 필요한 권한
필요한 도구 설치에 지정된 asmcli 설치 도구, kpt, 기타 도구

더 빠른 프로비저닝을 위해 클러스터에 워크로드 아이덴티티가 사용 설정되어 있어야 합니다. 워크로드 아이덴티티가 사용 설정되어 있지 않으면 프로비저닝 자동으로 사용 설정됩니다.

요구사항

지원되는 리전 중 하나에서 지원되는 GKE 버전이 있는 클러스터가 한 개 이상 있어야 합니다.
클러스터에 관리형 Cloud Service Mesh가 클러스터에 설치하는 필수 구성요소를 위한 충분한 용량이 있어야 합니다.
- kube-system 네임스페이스의 mdp-controller 배포에는 CPU: 50m, 메모리: 128Mi가 필요합니다.
- kube-system 네임스페이스의 istio-cni-node 데몬셋에는 각 노드에서 cpu: 100m, 메모리: 100Mi가 필요합니다.
조직 정책 constraints/compute.disableInternetNetworkEndpointGroup이 사용 중지되어 있어야 합니다. 정책을 사용 설정하면 ServiceEntry가 작동하지 않을 수 있습니다.
관리형 Cloud Service Mesh를 프로비저닝할 클라이언트 머신이 API 서버에 네트워크로 연결되어 있는지 확인합니다.
클러스터를 Fleet에 등록해야 합니다. 이 단계는 프로비저닝 전에 별도로 수행하거나 --enable-registration 및 --fleet-id 플래그를 전달하여 프로비저닝의 일부로 수행할 수 있습니다.
프로젝트에 서비스 메시 Fleet 기능이 사용 설정되어 있어야 합니다. 프로비저닝 중에 --enable-gcp-components를 전달하거나 다음 명령어를 실행하여 사용 설정할 수 있습니다.
```
gcloud container fleet mesh enable --project=FLEET_PROJECT_ID
```
여기서 FLEET_PROJECT_ID는 fleet 호스트 프로젝트의 프로젝트 ID입니다.
GKE Autopilot은 GKE 버전 1.21.3 이상에서만 지원됩니다.
Cloud Service Mesh는 단일 프로젝트 단일 네트워크 환경 또는 다중 프로젝트 단일 네트워크 환경에서 여러 GKE 클러스터를 사용할 수 있습니다.
- 동일한 프로젝트에 없는 클러스터를 조인하는 경우 클러스터는 동일한 Fleet 호스트 프로젝트에 등록되어야 하며 클러스터가 동일한 네트워크의 공유 VPC 구성에 함께 있어야 합니다.
- 단일 프로젝트 멀티 클러스터 환경에서는 Fleet 프로젝트가 클러스터 프로젝트와 같을 수 있습니다. Fleet에 대한 자세한 내용은 Fleet 개요를 참조하세요.
- 멀티 프로젝트 환경의 경우 클러스터 프로젝트와 별도의 프로젝트에서 Fleet을 호스팅하는 것이 좋습니다. 조직 정책과 기존 구성에서 허용하는 경우 공유 VPC 프로젝트를 Fleet 호스트 프로젝트로 사용하는 것이 좋습니다. 자세한 내용은 공유 VPC를 사용하여 클러스터 설정을 참조하세요.
- 조직에서 VPC 서비스 제어를 사용하고 출시 버전이 1.22.1-gke.10 이상인 GKE 클러스터에서 Cloud Service Mesh를 프로비저닝하는 경우 다음 추가 구성 단계를 수행해야 할 수 있습니다.
  - 일반 또는 안정적인 출시 채널에서 Cloud Service Mesh를 프로비저닝하는 경우 관리형 컨트롤 플레인을 적용할 때 추가 --use-vpcsc 플래그를 사용하고 VPC 서비스 제어(미리보기) 가이드를 따라야 합니다. 그렇지 않으면 프로비저닝 시 보안 제어에 실패합니다.
  - 신속 출시 채널에서 Cloud Service Mesh를 프로비저닝하는 경우 관리형 컨트롤 플레인을 적용할 때 추가 --use-vpcsc 플래그를 사용할 필요가 없지만 VPC 서비스 제어(GA) 가이드의 안내를 따라야 합니다.

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는 클러스터 내 구성요소를 제어하는 것이 주요 목적이므로 지원되지 않습니다.

참고: IstioOperator API를 사용하지 않고도 선택적 기능을 사용 설정할 수 있습니다. 관리형 Cloud Service Mesh에서 선택적 기능 사용 설정을 참조하세요. asmcli가 포함된 마이그레이션 도구를 사용하여 다른 IstioOperator 선택적 기능을 관리형 컨트롤 플레인과 호환되도록 자동 변환할 수도 있습니다. 자세한 내용은 IstioOperator에서 마이그레이션을 참조하세요.
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가 사용 설정된 클러스터를 지원하지 않습니다.
asmcli 도구는 Google Kubernetes Engine(GKE) 엔드포인트에 액세스할 수 있어야 합니다. Virtual Private Cloud(VPC) 내에서 특정 액세스 권한을 부여하는 Compute Engine VM과 같은 '점프' 서버를 통해 액세스를 구성할 수 있습니다.

시작하기 전에

gcloud 구성

Cloud Shell을 사용하는 경우에도 다음 단계를 완료합니다.

Google Cloud CLI로 인증합니다.
```
gcloud auth login --project PROJECT_ID
```
여기에서 PROJECT_ID는 프로젝트의 고유 식별자입니다. 다음 명령어를 실행하여 PROJECT_ID를 가져옵니다.
```
   gcloud projects list --filter="<PROJECT ID>" --format="value(PROJECT_NUMBER)"
   ```
```
구성요소를 업데이트합니다.
```
gcloud components update
```
kubectl에서 클러스터를 가리키도록 구성합니다.

참고: 클러스터가 리전별 클러스터인 경우 --zone 대신 --region을 사용합니다.
```
gcloud container clusters get-credentials CLUSTER_NAME \
     --zone CLUSTER_LOCATION \
     --project PROJECT_ID
```

설치 도구 다운로드

최신 버전의 도구를 현재 작업 디렉터리에 다운로드합니다.
```
curl https://storage.googleapis.com/csm-artifacts/asm/asmcli > asmcli
```
도구를 실행 가능하도록 설정합니다.
```
chmod +x asmcli
```

각 클러스터 구성

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

관리형 컨트롤 플레인 적용

관리형 컨트롤 플레인을 적용하기 전에 출시 채널을 선택해야 합니다. Cloud Service Mesh 채널은 관리형 Cloud Service Mesh를 프로비저닝할 때 GKE 클러스터 채널에 따라 결정됩니다. 동일한 클러스터에 여러 채널을 동시에 사용하는 것은 지원되지 않습니다.

관리형 Cloud Service Mesh를 사용할 각 클러스터에 대해 설치 스크립트를 실행합니다. 다음 옵션을 모두 포함하는 것이 좋습니다.

--enable-registration --fleet_id FLEET_PROJECT_ID 이 두 플래그는 클러스터를 Fleet에 등록합니다. 여기서 FLEET_ID는 Fleet 호스트 프로젝트의 project-id입니다. 단일 프로젝트를 사용하는 경우 FLEET_PROJECT_ID가 PROJECT_ID와 동일하면, Fleet 호스트 프로젝트와 클러스터 프로젝트가 동일합니다. 멀티 프로젝트와 같은 더 복잡한 구성에서는 별도의 Fleet 호스트 프로젝트를 사용하는 것이 좋습니다.
--enable-all: 이 플래그는 필수 구성요소와 등록을 모두 사용 설정합니다.

asmcli 도구는 도구 및 CLI 도구 내부의 논리를 사용하여 관리형 컨트롤 플레인을 직접 구성합니다. 선호하는 CA에 따라 다음 안내를 수행합니다.

인증 기관

메시에 사용할 인증 기관을 선택합니다.

Mesh CA

다음 명령어를 실행하여 기본 기능 및 Mesh CA를 사용하는 컨트롤 플레인을 설치합니다. 제공된 자리표시자에 값을 입력합니다.

  ./asmcli install \
      -p PROJECT_ID \
      -l LOCATION \
      -n CLUSTER_NAME \
      --fleet_id FLEET_PROJECT_ID \
      --managed \
      --verbose \
      --output_dir DIR_PATH \
      --enable-all

CA 서비스

Certificate Authority Service 구성 단계를 따릅니다.
다음 명령어를 실행하여 기본 기능과 Certificate Authority Service가 있는 컨트롤 플레인을 설치합니다. 제공된 자리표시자에 값을 입력합니다.

  ./asmcli install \
      -p PROJECT_ID \
      -l LOCATION \
      -n CLUSTER_NAME \
      --fleet_id FLEET_PROJECT_ID \
      --managed \
      --verbose \
      --output_dir DIR_PATH \
      --enable-all \
      --ca gcp_cas \
      --ca_pool pool_name

이 도구는 관리형 컨트롤 플레인을 구성하기 위한 모든 파일을 지정된 --output_dir로 다운로드하고, istioctl 도구 및 샘플 애플리케이션을 설치합니다. 이 가이드의 단계에서는 asmcli install을 실행할 때 지정한 --output_dir 위치에서 istioctl을 실행하고 <Istio release dir>/bin 하위 디렉터리에 istioctl이 있다고 가정합니다.

동일한 클러스터에서 asmcli을 다시 실행하면 기존 컨트롤 플레인 구성을 덮어씁니다. 동일한 구성을 원하는 경우 동일한 옵션 및 플래그를 지정해야 합니다.

컨트롤 플레인이 프로비저닝되었는지 확인

몇 분 후 컨트롤 플레인 상태가 ACTIVE인지 확인합니다.

gcloud container fleet mesh describe --project FLEET_PROJECT_ID

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

membershipStates:
  projects/746296320118/locations/us-central1/memberships/demo-cluster-1:
    servicemesh:
      controlPlaneManagement:
        details:
        - code: REVISION_READY
          details: 'Ready: asm-managed'
        state: ACTIVE
      ...
    state:
      code: OK
      description: 'Revision(s) ready for use: asm-managed.'

몇 분 후에도 상태가 ACTIVE` 에 도달하지 않으면 관리형 컨트롤 플레인 상태 확인에서 발생할 수 있는 오류에 관해 자세히 알아보세요.

제로터치 업그레이드

관리형 컨트롤 플레인이 설치되면 Google에서는 새 출시 버전이나 패치가 사용 가능할 때 자동으로 업그레이드합니다.

관리형 데이터 영역

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

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

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

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

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

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

이전 클러스터에 관리형 Cloud Service Mesh를 프로비저닝한 경우 전체 클러스터에 데이터 영역 관리를 사용 설정할 수 있습니다.

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

또는 같은 주석으로 주석을 추가하여 특정 컨트롤 플레인 버전, 네임스페이스 또는 포드에 관리형 데이터 영역을 선택적으로 사용 설정할 수 있습니다. 개별 구성요소를 선택적으로 제어하는 경우 우선 순위는 컨트롤 플레인 버전, 네임스페이스, 포드 순입니다.

클러스터에서 프록시 관리를 위해 서비스를 준비하려면 최대 10분까지 걸릴 수 있습니다. 다음 명령어를 실행하여 상태를 확인합니다.

gcloud container fleet mesh describe --project FLEET_PROJECT_ID

예상 출력

membershipStates:
  projects/PROJECT_NUMBER/locations/global/memberships/CLUSTER_NAME:
    servicemesh:
      dataPlaneManagement:
        details:
        - code: OK
          details: Service is running.
        state: ACTIVE
    state:
      code: OK
      description: 'Revision(s) ready for use: asm-managed-rapid.'

서비스가 10분 내에 준비되지 않으면 관리형 데이터 영역 상태에서 다음 단계를 참조하세요.

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

새 클러스터에서 관리형 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일 전에 알림이 전송됩니다.

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

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

커뮤니케이션 페이지로 이동
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가 구성되어 있는지 확인합니다.

공개 클러스터

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

공개 클러스터(비공개 클러스터 아님)에서 작업하는 경우 공개 클러스터 간 엔드포인트 검색을 구성하거나 더 간단하게 공개 클러스터 간 엔드포인트 검색을 사용 설정할 수 있습니다.

비공개 클러스터

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

GKE 비공개 클러스터를 사용할 때 클러스터 컨트롤 플레인 엔드포인트를 비공개 엔드포인트 대신 공개 엔드포인트로 구성해야 합니다. 비공개 클러스터 간 엔드포인트 검색 구성을 참조하세요.

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

애플리케이션 배포

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

관리형(TD)

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

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

관리형(Istiod)

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

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

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

다음 명령어를 실행하여 사용 가능한 출시 채널을 찾습니다.
```
kubectl -n istio-system get controlplanerevision
```
출력은 다음과 비슷합니다.
```
NAME                AGE
asm-managed-rapid   6d7h
```
참고: 위 목록에 두 개의 컨트롤 플레인 버전이 표시되면 하나를 삭제합니다. 클러스터에 여러 컨트롤 플레인 채널을 두는 방식은 지원되지 않습니다.

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

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

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"

컨트롤 플레인 측정항목 확인

측정항목 탐색기에서 컨트롤 플레인과 데이터 영역의 버전을 볼 수 있습니다.

구성이 예상대로 작동하는지 확인하려면 다음 단계를 따르세요.

Google Cloud 콘솔에서 컨트롤 플레인 측정항목을 열람하세요.

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

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

마이그레이션 준비

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

Google 관리형 컨트롤 플레인 적용 섹션의 설명대로 도구를 실행합니다.

(선택사항) Google 관리형 데이터 영역을 사용할 경우 데이터 영역 관리를 사용 설정합니다.

  kubectl annotate --overwrite controlplanerevision REVISION_TAG \
  mesh.cloud.google.com/proxy='{"managed":"true"}'

애플리케이션 마이그레이션

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

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

관리형(TD)

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

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

관리형(Istiod)

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

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

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

다음 명령어를 실행하여 사용 가능한 출시 채널을 찾습니다.
```
kubectl -n istio-system get controlplanerevision
```
출력은 다음과 비슷합니다.
```
NAME                AGE
asm-managed-rapid   6d7h
```
참고: 위 목록에 두 개의 컨트롤 플레인 버전이 표시되면 하나를 삭제합니다. 클러스터에 여러 컨트롤 플레인 채널을 두는 방식은 지원되지 않습니다.

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

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

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

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

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

deployment.apps/istio-ingressgateway rolled back

제거

관리형 컨트롤 플레인은 사용하는 네임스페이스가 없으면 0으로 자동 축소됩니다. 자세한 단계는 Cloud Service Mesh 제거를 참고하세요.

문제 해결

관리형 컨트롤 플레인을 사용할 때의 문제를 식별하고 해결하려면 관리형 컨트롤 플레인 문제 해결을 참조하세요.

다음 단계

출시 채널 알아보기
IstioOperator에서 마이그레이션
관리형 컨트롤 플레인으로 게이트웨이 마이그레이션
다음과 같은 선택적 관리형 Cloud Service Mesh 기능을 사용 설정하는 방법을 알아보세요.