Migrazione della CA in situ

Se il tuo mesh ha più cluster con carichi di lavoro che inviano richieste ai carichi di lavoro su un altro cluster, segui tutti i passaggi di questa guida per tutti i cluster.

Segui i passaggi descritti in questa guida per eseguire la migrazione di un control plane Cloud Service Mesh v1.13 o versioni successive in-cluster con l'autorità di certificazione Cloud Service Mesh a Certificate Authority Service.

Limitazioni

Le migrazioni e gli upgrade delle CA in-place sono supportati solo dalla versione 1.13 o successiva di Cloud Service Mesh.

Prerequisiti

Prima di seguire i passaggi descritti in questa guida, assicurati di avere:

Inoltre, assicurati di utilizzare Cloud Service Mesh 1.13 o versioni successive.

Strumenti richiesti

Durante la migrazione, esegui uno strumento fornito da Google, migrate_ca. Questo strumento ha le seguenti dipendenze:

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

Prima di scaricare lo strumento migrate_ca, segui i passaggi descritti in Preparazione della migrazione.

Panoramica della migrazione

Durante la procedura di migrazione, l'autenticazione e l'autorizzazione sono completamente operative tra i carichi di lavoro che utilizzano la CA precedente e quelli che utilizzano la nuova CA.

Lo strumento di migrazione migrate_ca creerà una mappa di configurazione Kubernetes per monitorare lo stato della migrazione della CA per revisione/canale Cloud Service Mesh installato. Si tratta di una risorsa privilegiata installata nello spazio dei nomi 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:

Lo strumento di migrazione eseguirà il backup della mappa di configurazione Istio MeshConfig prima di modificarla e tenterà di eseguire la migrazione della configurazione della CA utilizzando il CRD ProxyConfig se possibile.

Di seguito è riportato uno schema della migrazione della CA:

  1. Preparati alla migrazione.

  2. Inizializza la nuova CA.

  3. Aggiungi trustAnchors a livello di mesh per tutti i cluster del parco risorse.

  4. Esegui la migrazione della CA.

  5. Esegui un rollback.

Prepararsi per la migrazione

  1. Scarica lo strumento migrate_ca bash:

    curl  https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-service-mesh-packages/main/scripts/migration/ca-migration/migrate_ca > migrate_ca
    
  2. Rendi eseguibile lo strumento:

    chmod +x migrate_ca
    
  3. Configura la directory di lavoro:

    ./migrate_ca setup --output_dir OUTPUT_DIR
    
  4. Modifica la directory di lavoro in OUTPUT_DIR specificata nel passaggio precedente

    cd OUTPUT_DIR
    
  5. Esegui il seguente comando per assicurarti che tutti i prerequisiti siano soddisfatti:

    ./migrate_ca check-prerequisites
    
  6. Prendi nota della revisione (ASM_REVISION) del piano di controllo associato alla CA precedente di cui è in corso la migrazione.

    All'interno del cluster

    asm-revision=$(kubectl get deploy -n istio-system -l app=istiod -o \
     "jsonpath={.items[*].metadata.labels[istio\.io/rev']}{'\n'}")
    
  7. Poiché la migrazione in situ della CA richiede il riavvio dei carichi di lavoro, assicurati che il budget di interruzione dei pod sia configurato correttamente e che tutte le applicazioni di cui è necessaria la migrazione della CA abbiano più di un pod in esecuzione.

  8. Assicurati che il cluster sia già registrato a un parco risorse e che Workload Identity sia abilitato sul cluster. Poi, prendi nota dell'ID progetto del parco come (FLEET_ID) per i passaggi futuri.

  9. Lo strumento accetta kubeConfig e kubeContext per selezionare il cluster in cui vengono eseguite le operazioni. Se questi argomenti non vengono passati, vengono utilizzati il contesto/la configurazione predefiniti.

    • Per aggiungere le credenziali di un cluster GKE a kubeConfig, utilizza il seguente comando:

      gcloud container clusters get-credentials CLUSTER_NAME
      
    • Per modificare il contesto kubectl corrente o per passare il contesto allo strumento, utilizza il seguente comando:

      kubectl config get-contexts
      kubectl config use-context CLUSTER_NAME
      

Inizializza la nuova CA

  1. I passaggi necessari per inizializzare la nuova CA dipendono dalla nuova CA di cui stai eseguendo la migrazione. Esegui questi passaggi in ogni cluster del parco risorse in cui vuoi eseguire la migrazione della CA.

    Mesh CA

    Chiama il sottocomando dello strumento di utilità initialize.

    • Se specifichi configurazioni Kubernetes personalizzate:

      ./migrate_ca initialize --kubeconfig KUBECONFIG --kubecontext KUBECONTEXT --ca mesh_ca --old_ca OLD_CA_TYPE \
      --fleet_id FLEET_ID --revision ASM_REVISION
      
    • Altrimenti:

      ./migrate_ca initialize --ca mesh_ca --old_ca OLD_CA_TYPE \
      --fleet_id FLEET_ID --revision ASM_REVISION
      

    Servizio CA

    a. Segui i passaggi necessari per inizializzare Certificate Authority Service. Prendi nota del valore CA_POOL.

    b. Chiama il sottocomando dello strumento di utilità initialize:

    • Se specifichi configurazioni Kubernetes personalizzate:

      ./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
      
    • Altrimenti:

      ./migrate_ca initialize --ca gcp_cas --ca-pool CA_POOL --ca-old OLD_CA_TYPE \
      --fleet-id FLEET_ID --revision ASM_REVISION
      

Aggiungi trustAnchors a livello di mesh per tutti i cluster del parco risorse

  1. Ripeti i seguenti passaggi sia per il nuovo CA sia per il vecchio CA per tutti i cluster che fanno parte del parco risorse.

  2. Scarica i trustAnchors della CA:

    Mesh CA

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

    Servizio CA

    Memorizza il certificato CA in un file:

    gcloud privateca pools get-ca-certs POOL_NAME --location=POOL_REGION --project=POOL_PROJECT--output-file ROOT_CERT.pem
    
  3. Aggiungi trustAnchors della CA:

    ./migrate-ca add-trust-anchor --ca_cert ROOT_CERT.pem
    
  4. Verifica che gli elementi trustAnchor siano stati ricevuti da tutti i carichi di lavoro nel fleet. Nell'argomento namespaces, passa tutti gli spazi dei nomi in cui vengono eseguiti i deployment dei carichi di lavoro:

    ./migrate-ca check-trust-anchor --ca_cert ROOT_CERT.pem --namespaces NAMESPACES
    

    Risultato previsto:

    Check the CA cert in namespace nsa-1-24232                                                                                                                               
    a-v1-597f875788-52c5t.nsa-1-24232 trusts root-cert.pem
    

Esegui la migrazione della CA

  1. Esegui la migrazione della configurazione della CA. Il comando richiesto dipende dalla nuova CA a cui stai eseguendo la migrazione.

    Mesh CA

    ./migrate_ca migrate-ca --ca mesh_ca
    

    Servizio CA

    ./migrate_ca migrate-ca --ca gcp_cas --ca_pool CA_POOL
    
  2. Riavviare tutti i carichi di lavoro.

    Per ridurre al minimo il rischio di tempi di inattività del traffico TLS, questo passaggio dovrebbe influire in primo luogo sul numero più ridotto di workload. Riavviare solo i workload associati alla revisione del piano di controllo ASM_REVISION. Ad esempio, se tutti i carichi di lavoro nello spazio dei nomi KubernetesNAMESPACE sono associati allo stesso piano di controllo Cloud Service Mesh.

    kubectl rollout restart deployment -n NAMESPACE
    
  3. Verifica che le connessioni mTLS funzionino tra i workload nello spazio dei nomi riavviato e altri workload prima di ripetere i passaggi 1 e 2 per tutti gli spazi dei nomi e per tutti i cluster che fanno parte del parco. Se sono in arrivo nuovi carichi di lavoro e il traffico del mesh non viene interrotto, ripeti i passaggi 1 e 2 per tutti gli spazi dei nomi e i cluster che fanno parte del parco risorse. In caso contrario, procedi con l'esecuzione di un rollback per eseguire il rollback della configurazione della CA più recente.

  4. Verifica che la nuova configurazione della CA venga utilizzata da tutti i carichi di lavoro:

    ./migrate_ca verify-ca --ca_cert ROOT_CERT.pem --namespaces NAMESPACES
    

    Risultato previsto:

    Check the CA configuration in namespace nsb-2-76095
    b-v1-8ff557759-pds69.nsb-2-76095 is signed by root-cert.pem
    

Eseguire un rollback

  1. Esegui il rollback della configurazione della CA e rimuovi gli elementi trustAnchors appena configurati:

    ./migrate-ca rollback
    
  2. Riavviare tutti i carichi di lavoro. Assicurati di riavviare solo i carichi di lavoro associati alla revisione del piano di controllo ASM_REVISION. Ad esempio, se tutti i carichi di lavoro nello spazio dei nomi KubernetesNAMESPACES sono associati allo stesso piano di controllo Cloud Service Mesh.

    kubectl rollout restart deployment -n NAMESPACES
    
  3. (Facoltativo) Verifica che la configurazione della CA precedente venga utilizzata da tutti i carichi di lavoro.

    ./migrate-ca verify-ca --ca_cert older-root-cert.pem
    
  4. Ripeti i passaggi 1-3 per tutti i cluster del parco risorse in cui i workload utilizzano il piano di controlloASM_REVISION.

Complimenti! Hai eseguito correttamente una migrazione in situ della CA.