버전 1.14

인플레이스 CA 마이그레이션

메시에 다른 클러스터의 워크로드에 요청을 보내는 워크로드가 있는 클러스터가 여러 개 있는 경우, 모든 클러스터에 대해 이 가이드의 모든 단계를 수행하세요.

다음 사용 사례에 대해 이 가이드의 단계를 따르세요.

  • Mesh CA가 있는 클러스터 내 Anthos Service Mesh v1.13 이상 제어 영역을 Certificate Authority Service로 마이그레이션하는 경우
  • Mesh CA를 사용하여 v1.13 이상으로 매핑되는 출시 채널에서 관리형 Anthos Service Mesh 제어 영역을 Certificate Authority Service으로 마이그레이션하는 경우

제한사항

인플레이스 CA 마이그레이션 및 업그레이드는 Anthos Service Mesh v1.13 이상에서만 지원됩니다. 관리형 제어 영역 마이그레이션의 경우 선택한 채널이 v1.13 이상으로 매핑되어야 합니다.

기본 요건

이 가이드의 단계를 수행하기 전에 다음을 요건을 충족해야 합니다.

또한 현재 Anthos Service Mesh v1.13 이상을 사용하고 있어야 합니다.

필수 도구

마이그레이션 중에 Google에서 제공하는 migrate_ca 도구를 실행하게 됩니다. 이 도구에는 다음과 같은 종속 항목이 있습니다.

  • awk
  • grep
  • jq
  • kubectl
  • head
  • sed
  • tr
  • yq

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 마이그레이션의 개요입니다.

  1. 마이그레이션 준비

  2. 새 CA 초기화

  3. Fleet의 모든 클러스터에 대해 메시 전체 trustAnchor 추가

  4. CA 마이그레이션

  5. 롤백을 수행합니다.

마이그레이션 준비

  1. migrate_ca bash 도구를 다운로드합니다.

    curl  https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-service-mesh-packages/main/scripts/migration/ca-migration/migrate_ca > migrate_ca
    
  2. 도구를 실행 가능하도록 설정합니다.

    chmod +x migrate_ca
    
  3. 작업 디렉터리를 설정합니다.

    ./migrate_ca setup --output_dir OUTPUT_DIR
    
  4. 작업 디렉터리를 이전 단계에서 지정한 OUTPUT_DIR로 변경합니다.

    cd OUTPUT_DIR
    
  5. 다음 명령어를 실행하여 모든 기본 요건을 충족하는지 확인합니다.

    ./migrate_ca check-prerequisites
    
  6. 마이그레이션되는 이전 CA와 연결된 제어 영역의 버전(ASM_REVISION)을 메모해 둡니다. 필요한 단계는 클러스터 내 또는 관리형 제어 영역의 유형에 따라 다릅니다.

    클러스터 내

    asm-revision=$(kubectl get deploy -n istio-system -l app=istiod -o \
     "jsonpath={.items[*].metadata.labels[istio\.io/rev']}{'\n'}")
    

    관리형

    이미 설치된 채널을 참조하세요.

  7. 인플레이스(In-Place) CA 마이그레이션을 수행하려면 워크로드를 다시 시작해야 하므로 포드 중단 예산이 올바르게 구성되고 CA를 마이그레이션해야 하는 모든 애플리케이션에 두 개 이상의 포드가 실행 중인지 확인합니다.

  8. 클러스터가 이미 Fleet에 등록되었고 클러스터에서 워크로드 아이덴티티가 사용 설정되어 있는지 확인합니다. 이후 단계를 위해 전체 프로젝트 ID를 (FLEET_ID)로 메모하세요.

  9. 이 도구는 kubeConfigkubeContext를 수락하여 작업이 수행되는 클러스터를 선택합니다. 이러한 인수가 전달되지 않으면 기본 컨텍스트/구성이 사용됩니다.

    • GKE 클러스터의 사용자 인증 정보를 kubeConfig에 추가하려면 다음 명령어를 사용합니다.

      gcloud container clusters get-credentials CLUSTER_NAME
      
    • 현재 kubectl 컨텍스트를 변경하거나 컨텍스트에 도구를 전달하려면 다음 명령어를 사용하세요.

      kubectl config get-contexts
      kubectl config use-context CLUSTER_NAME
      

새 CA 초기화

  1. 새 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. 인증 기관 서비스를 초기화하는 데 필요한 단계를 따릅니다. 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 추가

  1. 그룹에 속한 모든 클러스터에서 새 CA와 이전 CA에 대해 아래 단계를 반복합니다.

  2. CA의 trustAnchor를 다운로드합니다.

    Mesh CA

    ./migrate_ca download-trust-anchor --ca mesh_ca --ca_cert ROOT_CERT.pem
    

    CA 서비스

    CA 인증서를 파일에 저장합니다.

    gcloud privateca pools get-ca-certs POOL_NAME --location=POOL_REGION --project=POOL_PROJECT--output-file ROOT_CERT.pem
    
  3. CA의 trustAnchor를 추가합니다.

    ./migrate-ca add-trust-anchor --ca_cert ROOT_CERT.pem
    
  4. trustAnchor가 제품군의 모든 워크로드에서 수신되었는지 확인합니다. 네임스페이스 인수에서 워크로드가 배포된 모든 네임스페이스를 전달합니다.

    ./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 마이그레이션

  1. CA 구성을 마이그레이션합니다. 필요한 명령어는 마이그레이션하려는 새 CA에 따라 다릅니다.

    Mesh CA

    ./migrate_ca migrate-ca --ca mesh_ca
    

    CA 서비스

    ./migrate_ca migrate-ca --ca gcp_cas --ca_pool CA_POOL
    
  2. 모든 워크로드를 다시 시작합니다.

    TLS 트래픽 다운타임의 위험을 최소화하기 위해 이 단계는 먼저 가장 적은 수의 작업 부하에 영향을 미칩니다. 제어 영역 버전 ASM_REVISION과 연결된 워크로드만 다시 시작합니다. 예를 들어 kubernetes 네임스페이스 NAMESPACE의 모든 워크로드가 동일한 Anthos Service Mesh 제어 영역과 연결됩니다.

    kubectl rollout restart deployment -n NAMESPACE
    
  3. 모든 네임스페이스와 그룹에 포함된 모든 클러스터에 대해 1단계와 2단계를 반복하기 전에 mTLS 연결이 다시 시작된 네임스페이스와 다른 워크로드에서 작동하는지 확인합니다. 최신 워크로드가 발생하고 메시 트래픽이 중단되지 않으면 그룹에 포함된 모든 네임스페이스 및 클러스터에 1단계와 2단계를 반복합니다. 그렇지 않으면 롤백을 수행하여 최신 CA 구성을 롤백합니다.

  4. 새 워크로드가 모든 워크로드에서 사용되고 있는지 확인합니다.

    ./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
    

롤백 수행

  1. CA 구성을 롤백하고 새로 구성된 trustAnchor를 삭제합니다.

    ./migrate-ca rollback
    
  2. 모든 워크로드를 다시 시작합니다. 제어 영역 버전 ASM_REVISION과 연결된 워크로드만 다시 시작해야 합니다. 예를 들어 kubernetes 네임스페이스 NAMESPACES의 모든 워크로드가 동일한 Anthos Service Mesh 제어 영역과 연결됩니다.

    kubectl rollout restart deployment -n NAMESPACES
    
  3. (선택사항) 이전 워크로드가 모든 워크로드에서 사용되고 있는지 확인합니다.

    ./migrate-ca verify-ca --ca_cert older-root-cert.pem
    
  4. 워크로드가 ASM_REVISION 제어 영역을 사용하는 Fleet의 모든 클러스터에 1~3단계를 반복합니다.

축하합니다. 인플레이스(In-Place) CA 마이그레이션을 성공적으로 수행했습니다.