클러스터 내에서 관리형 표준 서비스 컨트롤러로 마이그레이션
참고: 표준 서비스는 Cloud Service Mesh 버전 1.6.8 이상에서 자동으로 지원됩니다.
이 가이드에서는 클러스터 내 표준 서비스 컨트롤러에서 관리형 표준 서비스 컨트롤러로 마이그레이션하는 단계를 설명합니다.
클러스터 내 표준 서비스 컨트롤러가 지원 중단되었으며 더 이상 업데이트되지 않습니다. 클러스터 내 컨트롤러의 기존 배포는 계속 작동하지만 향후 출시와의 호환성, 최신 기능 액세스, 지속적인 지원을 보장하려면 관리형 표준 서비스 컨트롤러로 마이그레이션하는 것이 좋습니다. 버전 1.25부터 asmcli를 사용하는 모든 클러스터 내 Cloud Service Mesh 설치는 관리형 표준 서비스 컨트롤러를 통해 프로비저닝됩니다.
1. Cloud Service Mesh Fleet 기능 사용 설정
관리형 표준 서비스 컨트롤러는 다음 명령어를 사용하여 사용 설정되는 Cloud Service Mesh Fleet 기능의 일부로 설치됩니다.
gcloud container fleet mesh enable --project FLEET_PROJECT_ID
FLEET_PROJECT_ID
를 Fleet 호스트 프로젝트의 ID로 바꿉니다. 일반적으로 FLEET_PROJECT_ID는 프로젝트와 이름이 동일합니다.
여러 클러스터를 등록하려는 경우 Cloud Service Mesh는 Fleet 수준에서 사용 설정되므로 이 명령어는 한 번만 실행하면 됩니다.
Cloud Service Mesh 서비스 계정에 권한 부여
클러스터의 프로젝트가 Fleet 호스트 프로젝트와 다른 경우 Fleet 프로젝트의 Cloud Service Mesh 서비스 계정이 클러스터 프로젝트에 액세스하도록 허용해야 합니다.
이 작업은 각 클러스터 프로젝트에 대해 한 번만 수행하면 됩니다. 이전에 이 클러스터와 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
CLUSTER_PROJECT_ID를 클러스터의 프로젝트 ID로, FLEET_PROJECT_NUMBER를 Fleet의 프로젝트 번호로 바꿉니다.
Fleet의 프로젝트 번호를 확인하려면 Google Cloud 프로젝트 문서의 안내를 참조하세요.
2. 클러스터 내 표준 서비스 컨트롤러 사용 중지
관리형 표준 서비스 컨트롤러는 클러스터 내 표준 서비스 컨트롤러와 함께 작동할 수 없습니다. 따라서 클러스터 내 컨트롤러를 사용 중지해야 합니다.
클러스터 내 컨트롤러 확인: 클러스터 내 표준 컨트롤러가 있는지 확인합니다.
kubectl get deployment canonical-service-controller-manager -n asm-system
클러스터 내 컨트롤러 삭제: 배포가 있으면 다음 명령어를 실행하여 배포와 전체 asm-system 네임스페이스를 삭제할 수 있습니다.
kubectl delete namespace asm-system
3. 관리형 표준 컨트롤러의 작동 여부 확인
관리형 표준 서비스 컨트롤러는 기능 상태로 상태를 보고하므로 기능 상태를 확인하여 설치가 올바르게 작동하는지 확인할 수 있습니다.
기능 상태 확인: 다음 명령어를 사용하여 기능 상태를 검색합니다.
gcloud container fleet mesh describe --project FLEET_PROJECT_ID
상태 확인: 클러스터 상태를 확인하고
state.code
가OK
인지 확인합니다.- 중요: 상태가
OK
로 전환되는 데 최대 15분이 걸릴 수 있습니다. 기다렸다가 명령어를 다시 실행합니다. state.code
가OK
인 경우에만 다음 단계를 진행합니다.- 15분이 지나도
state.code
가OK
로 변경되지 않으면 관리형 표준 서비스 컨트롤러 문제 해결에서 문제 해결 안내를 참조하세요.
출력 예시:
membershipStates: projects/<project-number>/locations/<location>/memberships/<membership-name>: state: code: OK description: Revision(s) ready for use: istiod-asm-183-2.
- 중요: 상태가
관리형 표준 컨트롤러 작동 여부 확인: 사이드카가 삽입된 Pod를 배포하여 관리형 표준 컨트롤러가 올바르게 작동하는지 확인하고 컨트롤러가 상응하는 표준 서비스를 자동으로 생성하는지 확인합니다.
자동 사이드카 삽입이 사용 설정된 네임스페이스를 만듭니다.
kubectl create namespace NAMESPACE_NAME
자동 사이드카 삽입 사용 설정 섹션에 따라 새로 만든 네임스페이스에서 자동 사이드카 삽입을 사용 설정합니다.
다음 콘텐츠로
simple_pod.yaml
이라는 YAML 파일을 만듭니다.apiVersion: v1 kind: Pod metadata: name: simple-pod labels: app: my-app spec: containers: - name: my-container image: nginx:latest ports: - containerPort: 80
app
라벨은 표준 서비스의 이름을 결정합니다. 자세한 내용은 표준 서비스 정의를 참조하세요.다음 명령어를 사용하여 포드를 배포합니다. NAMESPACE_NAME을 자동 사이드카 삽입을 사용 설정한 네임스페이스의 이름으로 바꿉니다.
kubectl apply -f simple_pod.yaml -n NAMESPACE_NAME
포드가 생성되었는지 확인합니다.
kubectl get pods -n NAMESPACE_NAME
출력 예시:
NAME READY STATUS RESTARTS AGE simple-pod 2/2 Running 0 9s
Note
: READY 열에2/2
가 표시되는지 확인합니다. 이는 기본 컨테이너와 사이드카 프록시가 모두 올바르게 실행 중임을 나타냅니다. 다른 값이 표시되면 네임스페이스에 자동 사이드카 삽입이 사용 설정되지 않은 것일 수 있습니다.표준 서비스 생성 확인: 다음 명령어를 실행하여 네임스페이스의 모든 표준 서비스를 나열합니다. 표준 서비스
my-app
이 만들어졌는지 확인합니다.kubectl get canonicalservices -n NAMESPACE_NAME
출력 예시:
NAME AGE my-app 3s
정리: 포드, 표준 서비스, 네임스페이스를 삭제합니다.
kubectl delete -f simple_pod.yaml -n NAMESPACE_NAME kubectl delete canonicalservices my-app -n NAMESPACE_NAME kubectl delete namespace NAMESPACE_NAME
문제 해결:
- 필요한 표준 서비스가 생성되지 않으면 Cloud Service Mesh에서 표준 서비스 문제 해결을 참조하세요.
- 문제가 지속되면 클러스터 내 컨트롤러로 되돌릴 수 있습니다. 클러스터 내 표준 서비스 컨트롤러로 되돌리기를 참조하세요.
클러스터 내 표준 서비스 컨트롤러로 되돌리기
관리형 표준 서비스 컨트롤러에 문제가 발생하면 다음 명령어를 사용하여 클러스터 내 컨트롤러를 재설치할 수 있습니다.
kubectl apply -f \
https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-service-mesh-packages/release-1.25/asm/canonical-service/controller.yaml
다음 단계
다음 사항에 대해 알아보세요.