asmcli로 관리형 Anthos Service Mesh 프로비저닝

개요

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

참고: 관리형 Anthos Service Mesh를 구성하려면 Fleet 기능 API 옵션을 사용하는 것이 좋지만 이 가이드를 사용하여 asmcli 도구로 관리형 Anthos Service Mesh를 구성할 수도 있습니다.

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

기본 요건

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

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

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

요구사항

• 지원되는 리전 중 하나에서 지원되는 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에 등록해야 합니다. 이 단계는 프로비저닝 전에 별도로 수행하거나 --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 이상에서만 지원됩니다.

• 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를 사용하려면 항상 하나의 메시에 대한 모든 Anthos Service Mesh 클러스터를 동일한 Fleet에 등록해야 합니다. Anthos Service Mesh 클러스터의 프로젝트의 다른 클러스터는 다른 Fleet에 등록해서는 안 됩니다.

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

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

  참고: IstioOperator API를 사용하지 않고도 선택적 기능을 사용 설정할 수 있습니다. 관리형 Anthos Service Mesh에서 선택적 기능 사용 설정을 참조하세요. asmcli가 포함된 마이그레이션 도구를 사용하여 다른 IstioOperator 선택적 기능을 관리형 제어 영역과 호환되도록 자동 변환할 수도 있습니다. 자세한 내용은 IstioOperator에서 마이그레이션을 참조하세요.

• 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와 호환되지 않습니다.

• asmcli 도구는 Google Kubernetes Engine(GKE) 엔드포인트에 액세스할 수 있어야 합니다. Virtual Private Cloud(VPC) 내에서 특정 액세스 권한을 부여하는 Compute Engine VM과 같은 '점프' 서버를 통해 액세스를 구성할 수 있습니다.

시작하기 전에

경고: GitOps 도구(구성 동기화, Argo CD, Terraform, Jenkins 등)가 Anthos Service Mesh 설치, 마이그레이션 또는 업그레이드 프로세스를 방해할 수 있습니다. 최상의 결과를 얻으려면 Anthos Service Mesh를 설치, 마이그레이션 또는 업그레이드하기 전에 GitOps 도구를 사용 중지하세요.

gcloud 구성

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

1. Google Cloud CLI로 인증합니다.

   gcloud auth login --project PROJECT_ID
   

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

   gcloud components update
   

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

   참고: 클러스터가 리전별 클러스터인 경우 --zone 대신 --region을 사용합니다.

   gcloud container clusters get-credentials CLUSTER_NAME \
        --zone CLUSTER_LOCATION \
        --project PROJECT_ID
   

설치 도구 다운로드

중요: asmcli 도구는 Linux 운영체제만 지원합니다.

1. 최신 버전의 도구를 현재 작업 디렉터리에 다운로드합니다.

   curl https://storage.googleapis.com/csm-artifacts/asm/asmcli > asmcli
   

2. 도구를 실행 가능하도록 설정합니다.

   chmod +x asmcli
   

각 클러스터 구성

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

관리형 제어 영역 적용

참고: 또는 asmcli 대신 Fleet API 및 gcloud를 사용하여 관리형 Anthos Service Mesh를 설정할 수 있습니다. 자세한 내용은 Fleet API로 관리형 Anthos Service Mesh 구성을 참조하세요.

관리형 제어 영역을 적용하기 전에 출시 채널을 선택해야 합니다.

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

경고: 다음 옵션은 필수입니다. 옵션 전체 목록은 asmcli 참조 페이지를 참조하세요.

• --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에 따라 다음 안내를 수행합니다.

경고: Anthos Service Mesh가 올바르게 작동하기 위해서는 승격된 역할 기반 액세스 제어(RBAC) 권한(예: 모든 배포 수정 및 configmap 생성)으로 istio-cni-node DaemonSet를 노드에 배포합니다. istio-cni-node가 포드 수명 주기 및 구성을 관리하려면 이러한 권한이 필요합니다.

인증 기관

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

Mesh CA

다음 명령어를 실행하여 기본 기능 및 Mesh CA를 사용하는 제어 영역을 설치합니다. 제공된 자리표시자에 값을 입력합니다. RELEASE_CHANNEL을 regular, stable, rapid의 적합한 채널로 바꿉니다.

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

CA 서비스

1. Certificate Authority Service 구성 단계를 따릅니다.
2. 다음 명령어를 실행하여 기본 기능과 Certificate Authority Service가 있는 제어 영역을 설치합니다. 제공된 자리표시자에 값을 입력합니다. RELEASE_CHANNEL을 regular, stable, rapid의 적합한 채널로 바꿉니다.

참고: Certificate Authority Service를 MCP 멀티 클러스터 메시의 일부로 사용하는 경우 모든 클러스터에 동일한 루트 CA 풀에 연결된 각각의 하위 CA 풀이 있어야 합니다. 그렇지 않으면 모두 동일한 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 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에서는 새 출시 버전이나 패치가 사용 가능할 때 자동으로 업그레이드합니다.

관리형 데이터 영역

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

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

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

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

참고: 클러스터에 GKE 유지보수 기간이 정의되어 있으면 다음 가능한 유지보수 기간이 시작될 때 포드 제거가 시작되고 모든 관리형 포드의 업데이트가 완료될 때까지 중단 없이 계속 진행됩니다. 유지보수 기간은 CVE 관련 출시에서 관찰되지 않습니다.

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

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

이전 클러스터에 관리형 Anthos 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분 내에 준비되지 않으면 관리형 데이터 영역 상태에서 다음 단계를 참조하세요.

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

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

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

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

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

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

참고: 엔드포인트 검색에 대한 자세한 내용은 여러 제어 영역이 있는 엔드포인트 검색을 참조하세요.

공개 클러스터

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

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

비공개 클러스터

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

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

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

참고: HelloWorld 서비스 예시에서는 Docker Hub를 사용합니다. 비공개 클러스터에서 컨테이너 런타임은 기본적으로 Artifact Registry에서 컨테이너 이미지를 가져올 수 있습니다. 컨테이너 런타임은 인터넷의 다른 컨테이너 이미지 레지스트리에서 이미지를 가져올 수 없습니다. 이미지를 다운로드하고 Artifact Registry로 푸시하거나 Cloud NAT를 사용하여 특정 비공개 노드에 아웃바운드 인터넷 액세스 권한을 제공할 수 있습니다. 자세한 내용은 외부 컨테이너 마이그레이션 및 비공개 클러스터 만들기를 참조하세요.

애플리케이션 배포

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

기본 삽입 라벨

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

참고: label "istio.io/rev" not found 오류는 무시해도 됩니다.

버전 라벨

애플리케이션을 배포하기 전 해당 네임스페이스에서 모든 이전 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

참고: label "istio-injection" not found 오류는 무시해도 됩니다.

이제 관리형 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"

제어 영역 측정항목 확인

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

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

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

   측정항목 탐색기로 이동

2. 작업공간을 선택하고 다음 매개변수를 사용하여 커스텀 쿼리를 추가합니다.

   • 리소스 유형: 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"에 대한 필터를 삭제합니다.

3. 측정항목 탐색기에서 다음 필드를 검사하여 제어 영역 버전과 프록시 버전을 확인합니다.

   • revision 필드는 제어 영역 버전을 나타냅니다.
   • proxy_version 필드는 proxy_version을 나타냅니다.
   • value 필드는 연결된 프록시 수를 나타냅니다.

   현재 채널에서 Anthos Service Mesh로의 버전 매핑은 채널별 Anthos Service Mesh 버전을 참조하세요.

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

경고: 마이그레이션 프로세스 중에 선택한 채널에 해당하는 Istio CRD가 지정된 클러스터에 설치됩니다. 클러스터에 기존 Istio CRD가 있으면 덮어씁니다.

마이그레이션 준비

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

1. Google 관리형 제어 영역 적용 섹션의 설명대로 도구를 실행합니다.

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

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

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

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

1. 현재 네임스페이스 라벨을 바꿉니다. 필요한 단계는 기본 삽입 라벨(예: 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
   

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

   kubectl rollout restart deployment -n NAMESPACE
   

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

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

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

6. 제어 영역 측정항목 확인의 단계를 수행하여 측정항목이 예상한 대로 표시되는지 확인합니다.

애플리케이션이 예상한 대로 작동하면 모든 네임스페이스를 관리형 제어 영역으로 전환한 후 클러스터 내 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 버전으로 설정되었습니다. 롤백하려면 Anthos Service Mesh install 명령어를 다시 실행합니다. 그러면 클러스터 내 제어 영역을 다시 가리키는 게이트웨이가 다시 배포됩니다.

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

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

deployment.apps/istio-ingressgateway rolled back

제거

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

문제 해결

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

다음 단계

• 출시 채널 알아보기
• IstioOperator에서 마이그레이션
• 관리형 제어 영역으로 게이트웨이 마이그레이션
• 다음과 같은 선택적 관리형 Anthos Service Mesh 기능을 사용 설정하는 방법을 알아보세요.
  • Envoy 액세스 로그
  • 추적
  • Distroless 이미지
  • 최종 사용자 인증