Migrazione CA in loco

Se la tua rete mesh ha più cluster con carichi di lavoro che inviano richieste a 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 il seguente caso d'uso:

  • Esegui la migrazione di un piano di controllo Anthos Service Mesh v1.13 o successivo nel cluster con Mesh CA a Certificate Authority Service.
  • Esegui la migrazione di un piano di controllo Anthos Service Mesh gestito su un canale di rilascio mappato alla versione 1.13 o successiva con Mesh CA a Certificate Authority Service.

Limitazioni

Le migrazioni e gli upgrade di CA in loco sono supportati solo da Anthos Service Mesh v1.13 o versioni successive. Per le migrazioni del piano di controllo gestito, assicurati che il canale scelto sia mappato alla versione 1.13 o successiva.

Prerequisiti

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

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

Strumenti obbligatori

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 i passaggi descritti in Preparare 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 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 ogni revisione/canale Anthos Service Mesh installati. 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 Istio MeshConfig prima di modificarla e tenterà di eseguire la migrazione della configurazione della CA utilizzando la CRD di ProxyConfig, se possibile.

Ecco una panoramica della migrazione di CA:

  1. Preparati per la migrazione.

  2. Inizializza la nuova CA.

  3. Aggiungi trustAnchor 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. Configura la directory di lavoro:

    ./migrate_ca setup --output_dir OUTPUT_DIR

  4. Cambia la directory di lavoro in OUTPUT_DIR, specificata nel passaggio precedente

    cd OUTPUT_DIR

  5. Esegui questo comando per assicurarti che vengano soddisfatti tutti i prerequisiti:

    ./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, in-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 della CA in loco richiede il riavvio dei carichi di lavoro, assicurati che il budget per l'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 in un parco risorse e che Workload-identity sia abilitato nel cluster. Quindi, prendi nota dell'ID progetto del parco risorse 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/config predefinito.

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

      gcloud container clusters get-credentials CLUSTER_NAME

    • Per modificare il contesto corrente di kubectl o per passarlo 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 da quella in 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 initialize dello strumento di utilità.

    Se stai specificando 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 Certificate Authority Service. Prendi nota del CA_POOL.

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

    Se stai specificando 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 vecchia CA per tutti i cluster che fanno parte del parco risorse.

  2. Scarica i trustAnchor dell'autorità di certificazione:

    Mesh CA

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

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

  4. Verifica che i trustAnchor 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 vengono distribuiti i 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

Eseguire la migrazione della CA

  1. Esegui la migrazione della configurazione della CA. Il comando richiesto dipende dalla nuova CA su 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. Riavvia tutti i carichi di lavoro.

    Per ridurre al minimo il rischio di tempi di inattività del traffico TLS, questo passaggio dovrebbe influire prima 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 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 sono in arrivo carichi di lavoro più recenti 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, esegui un rollback per eseguire il rollback della configurazione della 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 della 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 Anthos Service Mesh.

    kubectl rollout restart deployment -n NAMESPACES

  3. (Facoltativo) Verifica che la configurazione 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 nel parco risorse in cui i carichi di lavoro utilizzano il piano di controllo ASM_REVISION.

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