Migrazione delle CA in loco

Nota: questa guida descrive come eseguire la migrazione dell'autorità di certificazione (CA) senza migrare i carichi di lavoro a un nuovo piano di controllo (in loco) con il usando uno strumento basato su bash. Per eseguire la migrazione da Istio CA a Mesh CA con una basato su canary e che prevede tempi di inattività minimi o nulli, consulta Migrazione basata su canary a Mesh CA.

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

Segui la procedura descritta in questa guida per il seguente caso d'uso:

• Esegui la migrazione di un piano di controllo Cloud Service Mesh v1.13 o versioni successive nel cluster con Mesh da CA a Certificate Authority Service.
• Esegui la migrazione di un piano di controllo gestito di Cloud Service Mesh su un canale di rilascio che viene mappato alla versione 1.13 o successiva con Mesh CA collegato a Certificate Authority Service.

Limitazioni

Le migrazioni e gli upgrade delle CA in loco sono supportati solo da Cloud Service Mesh v1.13 o in un secondo momento. Per le migrazioni gestite dal piano di controllo, assicurati che il canale scelto viene mappato alla versione 1.13 o successiva.

Prerequisiti

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

• Autorizzazioni di amministratore del cluster concesse
• Configurazione di gcloud

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

Strumenti richiesti

Durante la migrazione, esegui lo 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 la procedura descritta in Preparati per la migrazione.

Panoramica della migrazione

Durante il processo di migrazione, l'autenticazione e l'autorizzazione funzionale tra carichi di lavoro con la CA precedente e carichi di lavoro con il nuovo Canada.

Lo strumento di migrazione migrate_ca creerà una mappa di configurazione di Kubernetes su Monitorare lo stato della migrazione delle CA in base alla revisione/canale di Cloud Service Mesh installato. Questa è una risorsa con privilegi 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 di Istio MeshConfig prima della modifica e tenta di eseguire la migrazione della configurazione CA utilizzando ProxyConfig CRD quando possibile.

Di seguito è riportato un riepilogo della migrazione della CA:

Nota: devi eseguire la procedura di migrazione su ciascun cluster nel tuo mesh.

1. Preparati per la migrazione.

2. Inizializza la nuova CA.

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

4. Esegui la migrazione della CA.

5. Esegui un rollback.

Preparati per la migrazione

1. Scarica lo strumento bash migrate_ca:

   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. Imposta la directory di lavoro:

   ./migrate_ca setup --output_dir OUTPUT_DIR
   

   Nota: se non specifichi una directory di lavoro, ne verrà creata una temporanea è stato creato. Dovrai utilizzarla come directory di lavoro per tutte le successive passaggi.

4. Cambia la directory di lavoro con il valore OUTPUT_DIR specificato nel passaggio precedente

   cd OUTPUT_DIR
   

5. Esegui questo comando per assicurarti che tutte le prerequisiti:

   ./migrate_ca check-prerequisites
   

6. Prendi nota della revisione (ASM_REVISION) di al piano di controllo associato alla CA precedente di cui viene eseguita la migrazione. La I passaggi richiesti dipendono dal tipo di piano di controllo: nel cluster gestito.

   Nel cluster

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

   Gestito

   Fai riferimento al canale è già installata.

7. Poiché la migrazione delle CA in loco richiede il riavvio dei carichi di lavoro, devi assicurarti che Budget di interruzione dei pod sia configurata correttamente e per tutte le applicazioni per le quali è necessario eseguire la migrazione della CA 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 ID progetto del parco risorse come (FLEET_ID) per il futuro passaggi.

9. Lo strumento accetta kubeConfig e kubeContext per selezionare il cluster in cui dell'esecuzione delle operazioni. Se questi argomenti non vengono passati, il contesto e la configurazione predefiniti.

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

     gcloud container clusters get-credentials CLUSTER_NAME
     

   • Per cambiare il contesto corrente di kubectl o per passare il contesto allo strumento: utilizza questo 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 a cui stanno eseguendo la migrazione. Esegui questi passaggi in ogni cluster del parco risorse in cui vuoi eseguire la migrazione della CA.

   CA mesh

   Chiama il sottocomando initialize dello strumento di utilità.

   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
   

   In caso contrario:

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

   Servizio CA

   a. Segui i passaggi richiesti per inizializzare Certificate Authority Service. Prendi nota di CA_POOL.

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

   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
   

   In caso contrario:

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

Aggiungi trust anchor a livello di mesh per tutti i cluster nel parco risorse

1. Ripeti i passaggi seguenti sia per la nuova CA sia per la CA precedente per tutti i cluster della flotta.

2. Scarica i trustanchor della CA:

   CA mesh

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

   Servizio CA

   Archivia 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 trust anchor della CA:

   ./migrate-ca add-trust-anchor --ca_cert ROOT_CERT.pem
   

4. Verifica che i trustAnchor siano stati ricevuti da tutti i carichi di lavoro in parco risorse. Nell'argomento spazi dei nomi, passa tutti gli spazi dei nomi in cui i carichi di lavoro di cui viene eseguito il deployment:

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

   Output 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. Eseguire la migrazione della configurazione CA. Il comando richiesto dipende dalla nuova CA di cui stai eseguendo la migrazione.

   CA mesh

   ./migrate_ca migrate-ca --ca mesh_ca
   

   Servizio CA

   ./migrate_ca migrate-ca --ca gcp_cas --ca_pool CA_POOL
   

2. Riavvia tutti i carichi di lavoro.

   Nota: questo passaggio è facoltativo se hai installato piano dati gestito. Questo perché Google gestisce la durata dei proxy ed esegue automaticamente questo passaggio durante un upgrade gestito.

   Per ridurre al minimo il rischio di inattività del traffico TLS, questo passaggio dovrebbe influire sulle con il minor numero di carichi di lavoro. Riavvia solo i carichi di lavoro che associata alla revisione del piano di controllo ASM_REVISION. Ad esempio, se tutti i carichi di lavoro nello spazio dei nomi Kubernetes NAMESPACE sono associati allo stesso Cloud Service Mesh dal piano di controllo.

   kubectl rollout restart deployment -n NAMESPACE
   

3. Verifica che le connessioni mTLS funzionino tra i carichi di lavoro nell'istanza riavviata e altri carichi di lavoro prima di ripetere i passaggi 1 e 2 per tutti spazi dei nomi e per tutti i cluster che fanno parte del parco risorse. Se più recente sono previsti carichi di lavoro e il traffico 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 il rollback la configurazione della CA più recente.

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

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

   Output previsto:

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

Esegui un rollback

1. Esegui il rollback della configurazione CA e rimuovi i trust anchor appena configurati:

   ./migrate-ca rollback
   

2. Riavvia tutti i carichi di lavoro. Assicurati di riavviare solo i carichi di lavoro associata alla revisione del piano di controllo ASM_REVISION. Ad esempio, se tutti i carichi di lavoro nello spazio dei nomi Kubernetes NAMESPACES sono associati allo stesso Cloud Service Mesh dal piano di controllo.

   kubectl rollout restart deployment -n NAMESPACES
   

3. (Facoltativo) Verifica che la configurazione CA precedente sia utilizzata da tutti carichi di lavoro con scale out impegnativi.

   ./migrate-ca verify-ca --ca_cert older-root-cert.pem
   

4. Ripeti i passaggi da 1 a 3 per tutti i cluster nel parco risorse in cui i carichi di lavoro utilizzano ASM_REVISION.

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