인플레이스(In-Place) CA 마이그레이션
메시에 다른 클러스터의 워크로드에 요청을 보내는 워크로드가 있는 클러스터가 여러 개 있는 경우, 모든 클러스터에 대해 이 가이드의 모든 단계를 수행하세요.
다음 사용 사례에 대해 이 가이드의 단계를 따르세요.
- Mesh CA가 있는 클러스터 내 Anthos Service Mesh v1.13 이상 제어 영역을 Certificate Authority Service로 마이그레이션하는 경우
- Mesh CA를 사용하여 v1.13 이상으로 매핑되는 출시 채널에서 관리형 Anthos Service Mesh 제어 영역을 Certificate Authority Service으로 마이그레이션하는 경우
제한사항
인플레이스(In-Place) CA 마이그레이션 및 업그레이드는 Anthos Service Mesh v1.13 이상에서만 지원됩니다. 관리형 제어 영역 마이그레이션의 경우 선택한 채널은 반드시 v1.13 이상에 매핑되어야 합니다.
기본 요건
이 가이드의 단계를 수행하기 전에 다음을 요건을 충족해야 합니다.
또한 현재 Anthos Service Mesh v1.13 이상을 사용하고 있어야 합니다.
필수 도구
마이그레이션 중에 Google에서 제공하는 migrate_ca 도구를 실행하게 됩니다. 이 도구에는 다음과 같은 종속 항목이 있습니다.
awkgrepjqkubectlheadsedtryq
migrate_ca 도구를 다운로드하기 전에 마이그레이션 준비 단계를 수행하세요.
마이그레이션 개요
마이그레이션 프로세스를 진행하는 동안 이전 CA를 사용하는 워크로드와 새 CA를 사용하는 워크로드 간에 인증 및 승인이 완전히 작동합니다.
migrate_ca 마이그레이션 도구는 설치된 Anthos Service Mesh 버전/채널별로 CA 마이그레이션 상태를 추적하기 위한 Kubernetes 구성 맵을 만듭니다.
이 도구는 istio-system 네임스페이스에 설치된 권한 있는 리소스입니다.
apiVersion: v1
kind: ConfigMap
metadata:
Name: asm-ca-migration-<revision>
Data:
revision:
start_time:
state_update_time:
current_state: TRUSTANCHOR_INJECT | MIGRATE_CA | ROLLBACK
old_ca:
target_ca:
마이그레이션 도구는 Istio MeshConfig 맵을 수정하기 전에 우선 백업하며, 가능한 경우 ProxyConfig CRD를 사용하여 CA 구성을 마이그레이션하려고 시도합니다.
다음은 CA 마이그레이션 개요입니다.
마이그레이션 준비
migrate_cabash 도구를 다운로드합니다.curl https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-service-mesh-packages/main/scripts/migration/ca-migration/migrate_ca > migrate_ca도구를 실행 가능하도록 설정합니다.
chmod +x migrate_ca작업 디렉터리를 설정합니다.
./migrate_ca setup --output_dir OUTPUT_DIR작업 디렉터리를 이전 단계에서 지정한 OUTPUT_DIR로 변경하세요.
cd OUTPUT_DIR다음 명령어를 실행하여 모든 기본 요건이 충족되었는지 확인합니다.
./migrate_ca check-prerequisites마이그레이션 중인 이전 CA와 연관된 제어 영역의 버전(
ASM_REVISION)을 기록해 둡니다. 필요한 단계는 클러스터 내부 또는 관리형의 제어 영역 유형에 따라 달라집니다.클러스터 내
asm-revision=$(kubectl get deploy -n istio-system -l app=istiod -o \ "jsonpath={.items[*].metadata.labels[istio\.io/rev']}{'\n'}")관리형
이미 설치된 채널을 참조하세요.
인플레이스(In-Place) CA 마이그레이션을 수행하려면 워크로드를 다시 시작해야 하므로 포드 중단 예산이 올바르게 구성되고 CA를 마이그레이션해야 하는 모든 애플리케이션에 두 개 이상의 포드가 실행 중인지 확인합니다.
클러스터가 이미 Fleet에 등록되었고 클러스터에서 워크로드 아이덴티티가 사용 설정되어 있는지 확인합니다. 이후 단계를 위해 전체 프로젝트 ID를 (
FLEET_ID)로 메모하세요.이 도구는
kubeConfig및kubeContext를 허용하여 작업이 수행되는 클러스터를 선택합니다. 이러한 인수가 전달되지 않으면 기본 컨텍스트/구성이 사용됩니다.GKE 클러스터의 사용자 인증 정보를
kubeConfig에 추가하려면 다음 명령어를 사용합니다.gcloud container clusters get-credentials CLUSTER_NAME현재
kubectl컨텍스트를 변경하거나 컨텍스트를 도구에 제공하려면 다음 명령어를 사용합니다.kubectl config get-contexts kubectl config use-context CLUSTER_NAME
새 CA 초기화
새 CA를 초기화하는 데 필요한 단계는 마이그레이션하려는 새 CA에 따라 달라집니다. CA를 마이그레이션하려는 모든 fleet 클러스터에서 이 단계를 수행합니다.
Mesh CA
유틸리티 도구
initialize하위 명령어를 호출합니다.커스텀 Kubernetes 구성을 지정하는 경우:
./migrate_ca initialize --kubeconfig KUBECONFIG --kubecontext KUBECONTEXT --ca mesh_ca --old_ca OLD_CA_TYPE \ --fleet_id FLEET_ID --revision ASM_REVISION그 외의 경우에는 다음 안내를 따르세요.
./migrate_ca initialize --ca mesh_ca --old_ca OLD_CA_TYPE \ --fleet_id FLEET_ID --revision ASM_REVISION ```CA 서비스
a. Certificate Authority Service를 초기화하는 데 필요한 단계를 따릅니다.
CA_POOL을 기록합니다.b. 유틸리티 도구
initialize하위 명령어를 호출합니다.커스텀 Kubernetes 구성을 지정하는 경우:
./migrate_ca initialize --kubeconfig KUBECONFIG --context KUBECONTEXT --ca gcp_cas --ca-pool CA_POOL --ca-old OLD_CA_TYPE \ --fleet-id FLEET_ID --revision ASM_REVISION그 외의 경우에는 다음 안내를 따르세요.
./migrate_ca initialize --ca gcp_cas --ca-pool CA_POOL --ca-old OLD_CA_TYPE \ --fleet-id FLEET_ID --revision ASM_REVISION
제품군의 모든 클러스터에 메시 전체 trustAnchors 추가
Fleet의 일부인 모든 클러스터에서 새 CA와 이전 CA에 대해 아래 단계를 반복합니다.
CA의 trustAnchor를 다운로드합니다.
Mesh CA
./migrate_ca download-trust-anchor --ca mesh_ca --ca_cert ROOT_CERT.pemCA 서비스
CA 인증서를 파일에 저장합니다.
gcloud privateca pools get-ca-certs POOL_NAME --location=POOL_REGION --project=POOL_PROJECT--output-file ROOT_CERT.pemCA의 trustAnchor를 추가합니다.
./migrate-ca add-trust-anchor --ca_cert ROOT_CERT.pemFleet의 모든 워크로드에서 trustAnchors를 수신했는지 확인합니다. 네임스페이스 인수에서 워크로드가 배포되는 모든 네임스페이스를 전달합니다.
./migrate-ca check-trust-anchor --ca_cert ROOT_CERT.pem --namespaces NAMESPACES예상 출력:
Check the CA cert in namespace nsa-1-24232 a-v1-597f875788-52c5t.nsa-1-24232 trusts root-cert.pem
CA 마이그레이션
CA 구성을 마이그레이션합니다. 필요한 명령어는 마이그레이션하려는 새 CA에 따라 달라집니다.
Mesh CA
./migrate_ca migrate-ca --ca mesh_caCA 서비스
./migrate_ca migrate-ca --ca gcp_cas --ca_pool CA_POOL모든 워크로드를 다시 시작하세요.
TLS 트래픽 다운타임의 위험을 최소화하려면 이 단계에서 먼저 가장 적은 수의 워크로드에 영향을 주어야 합니다. 제어 영역 버전 ASM_REVISION과 연관된 워크로드만 다시 시작합니다. 예를 들어 kubernetes 네임스페이스 NAMESPACE의 모든 워크로드가 동일한 Anthos Service Mesh 제어 영역과 연결된 경우입니다.
kubectl rollout restart deployment -n NAMESPACE모든 네임스페이스와 Fleet의 일부인 모든 클러스터에 대해 1단계와 2단계를 반복하기 전에 mTLS 연결이 다시 시작된 네임스페이스와 다른 워크로드 간에 작동하는지 확인합니다. 최신 워크로드가 발생하고 메시 트래픽이 중단되지 않으면 Fleet의 일부인 모든 네임스페이스 및 클러스터에 대해 1단계와 2단계를 반복합니다. 그렇지 않은 경우 롤백 수행으로 넘어가 최신 CA 구성을 롤백합니다.
새 CA 구성이 모든 워크로드에서 사용되고 있는지 확인합니다.
./migrate_ca verify-ca --ca_cert ROOT_CERT.pem --namespaces NAMESPACES예상 출력:
Check the CA configuration in namespace nsb-2-76095 b-v1-8ff557759-pds69.nsb-2-76095 is signed by root-cert.pem
롤백 수행
CA 구성을 롤백하고 새로 구성된 trustAnchor를 삭제합니다.
./migrate-ca rollback모든 워크로드를 다시 시작하세요. 제어 영역 버전 ASM_REVISION과 연관된 워크로드만 다시 시작해야 합니다. 예를 들면 kubernetes 네임스페이스 NAMESPACES의 모든 워크로드가 동일한 Anthos Service Mesh 제어 영역과 연결됩니다.
kubectl rollout restart deployment -n NAMESPACES(선택사항) 이전 CA 구성이 모든 워크로드에서 사용되고 있는지 확인합니다.
./migrate-ca verify-ca --ca_cert older-root-cert.pem워크로드가 ASM_REVISION 제어 영역을 사용하는 Fleet의 모든 클러스터에 1~3단계를 반복합니다.
수고하셨습니다. 인플레이스(In-Place) CA 마이그레이션을 성공적으로 수행했습니다.