Migrazione CA esistente

Anteprima — In-place CA migration

Questa funzionalità è regolata dai Termini delle offerte pre-GA dei Termini di servizio di Google Cloud. Le funzionalità pre-GA potrebbero avere supporto limitato e le modifiche a queste funzionalità potrebbero non essere compatibili con altre versioni pre-GA. Per ulteriori informazioni, consulta le descrizioni della fase di lancio.

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

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 illustrati in questa guida per il seguente caso d'uso:

• Esegui la migrazione di un piano di controllo di Anthos Service Mesh v1.13 o versioni successive con Mesh CA a Certificate Authority Service.
• Esegui la migrazione di un piano di controllo gestito di Anthos Service Mesh su un canale di rilascio che mappa alla versione 1.13 o successive con Mesh CA al Certificate Authority Service.

Limitazioni

Le migrazioni e gli upgrade delle autorità di certificazione esistenti sono supportati solo da Anthos Service Mesh 1.13 o versioni successive. Per le migrazioni del piano di controllo gestito, assicurati che il canale scelto venga mappato alla v1.13 o a una successiva.

Prerequisiti

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

• Autorizzazioni concesse all'amministratore del cluster
• Configurato gcloud

Assicurati inoltre di utilizzare Anthos Service Mesh v1.13 o versioni successive.

Strumenti obbligatori

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 Prepararsi per la migrazione.

Panoramica della migrazione

Durante il processo di migrazione, l'autenticazione e l'autorizzazione sono completamente funzionali tra i carichi di lavoro che utilizzano la CA precedente e i carichi di lavoro con la nuova CA.

Lo strumento di migrazione migrate_ca creerà una mappa di configurazione di Kubernetes per monitorare lo stato della migrazione della CA per ogni revisione/canale di Anthos 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 di correggerlo e tenta di eseguire la migrazione della configurazione CA utilizzando il CRD di ProxyConfig, quando possibile.

Di seguito viene descritto lo schema della migrazione dell'autorità di certificazione:

Nota: devi eseguire i passaggi di migrazione su ciascun cluster nel tuo mesh.

1. Prepararsi per la migrazione

2. Inizializza la nuova CA.

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

4. Eseguire la migrazione della CA.

5. Esegui un rollback.

Prepararsi 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 lo strumento eseguibile:

   chmod +x migrate_ca
   

3. Configurare la directory di lavoro:

   ./migrate_ca setup --output_dir OUTPUT_DIR
   

   Nota: se non specifichi una directory di lavoro, ne verrà creata una temporanea. Dovrai utilizzarlo come directory di lavoro per tutti i passaggi successivi.

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

   cd OUTPUT_DIR
   

5. Esegui il comando seguente 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 viene eseguita la migrazione. I passaggi richiesti dipendono dal tipo di piano di controllo, nel cluster o gestito.

   Nel cluster

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

   Gestita

   Fai riferimento al canale già installato.

7. Poiché la migrazione in loco 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 per le quali è necessario eseguire la migrazione della CA abbiano più di un pod in esecuzione.

8. Assicurati che il cluster sia già registrato in un parco risorse e che l'identità del carico di lavoro sia abilitata nel cluster. Successivamente, prendi nota dell'ID progetto della flotta 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 o la configurazione predefiniti.

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

     gcloud container clusters get-credentials CLUSTER_NAME
     

   • Per modificare il contesto kubectl corrente o per passare il contesto allo strumento, utilizza il comando seguente:

     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 in cui stai 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 necessari per inizializzare il servizio autorità di certificazione. Prendi nota di CA_POOL.

   b. Chiama 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 trustAnchor a livello di mesh per tutti i cluster del parco risorse

1. Ripeti i passaggi seguenti per la nuova CA e per la nuova CA per tutti i cluster che fanno parte del parco risorse.

2. Scarica i trust anchor della CA:

   CA mesh

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

   Servizio CA

   Conserva 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 trustAnchor dell'autorità di certificazione:

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

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

   ./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. Esegui la migrazione della configurazione CA. Il comando richiesto dipende dalla nuova CA in 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 il piano dati gestito. Questo perché Google gestisce la durata del proxy ed esegue automaticamente questo passaggio durante un upgrade gestito.

   Per ridurre al minimo il rischio di tempi di inattività del traffico TLS, questo passaggio dovrebbe prima avere un impatto sul minor numero di carichi di lavoro. Riavvia 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 Kubernetes NAMESPACE sono associati allo stesso piano di controllo di Anthos Service Mesh.

   kubectl rollout restart deployment -n NAMESPACE
   

3. Verifica che le connessioni mTLS funzionino tra i carichi di lavoro nello spazio dei nomi riavviato e altri carichi di lavoro prima di ripetere i passaggi 1 e 2 per tutti gli spazi dei nomi e per tutti i cluster che fanno parte del parco risorse. Se si stanno creando carichi di lavoro più recenti e il traffico del mesh non viene interrotto, ripeti i passaggi 1 e 2 per tutti gli spazi dei nomi e cluster che fanno parte del parco risorse. In caso contrario, esegui un rollback per eseguire il rollback della configurazione CA più recente.

4. Verifica che la nuova configurazione 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
   

Eseguire un rollback

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

   ./migrate-ca rollback
   

2. Riavvia 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 Kubernetes NAMESPACES sono associati allo stesso piano di controllo di Anthos Service Mesh.

   kubectl rollout restart deployment -n NAMESPACES
   

3. (Facoltativo) Verifica che la configurazione della CA precedente sia 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 carichi di lavoro utilizzano il piano di controllo ASM_REVISION.

Complimenti! Hai eseguito correttamente una migrazione della CA.