Migrazione CA in loco
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 in questa guida per tutti i cluster.
Utilizza la procedura descritta in questa guida per il seguente caso d'uso:
- Esegui la migrazione di un piano di controllo nel cluster Anthos Service Mesh v1.13 o versione successiva con Mesh CA a Certificate Authority Service.
- Esegui la migrazione di un piano di controllo Anthos Service Mesh gestito su un canale di rilascio che viene mappato alla versione 1.13 o successiva con Mesh CA al Certificate Authority Service.
Limitazioni
Le migrazioni e gli upgrade a livello di CA in loco sono supportati solo da Anthos Service Mesh 1.13 o versioni successive. Per le migrazioni con piano di controllo gestito, assicurati che il canale scelto venga mappato alla versione 1.13 o successiva.
Prerequisiti
Prima di seguire i passaggi descritti in questa guida, assicurati di avere:
Inoltre, assicurati di utilizzare Anthos Service Mesh 1.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 pienamente funzionali tra i carichi di lavoro che utilizzano la CA precedente e i carichi di lavoro 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 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 modificarla e tenta, se possibile, di eseguire la migrazione della configurazione della CA utilizzando il CRD di ProxyConfig
.
Di seguito viene descritto uno schema della migrazione della CA:
Prepararsi per la migrazione
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
Rendi lo strumento eseguibile:
chmod +x migrate_ca
Configura la directory di lavoro:
./migrate_ca setup --output_dir OUTPUT_DIR
Modifica la directory di lavoro nel valore OUTPUT_DIR specificato nel passaggio precedente
cd OUTPUT_DIR
Esegui il comando seguente per assicurarti che tutti i prerequisiti siano soddisfatti:
./migrate_ca check-prerequisites
Prendi nota della revisione (
ASM_REVISION
) del piano di controllo associato alla CA precedente in fase di migrazione. I passaggi necessari dipendono dal tipo di piano di controllo, cluster-gestito 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.
Dal momento che 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 la cui CA deve essere sottoposta a migrazione abbia più di un pod in esecuzione.
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.Lo strumento accetta
kubeConfig
ekubeContext
per selezionare il cluster in cui vengono eseguite le operazioni. Se questi argomenti non vengono trasmessi, viene utilizzato il contesto/configurazione predefinito.Per aggiungere le credenziali di un cluster GKE a
kubeConfig
, utilizza il seguente comando:gcloud container clusters get-credentials CLUSTER_NAME
Per cambiare il contesto
kubectl
corrente o passare il contesto allo strumento, utilizza il seguente comando:kubectl config get-contexts kubectl config use-context CLUSTER_NAME
Inizializza la nuova CA
I passaggi necessari per inizializzare la nuova CA dipendono dalla nuova CA in cui esegui la migrazione. Esegui questi passaggi in ogni cluster del parco risorse in cui vuoi eseguire la migrazione della CA.
CA mesh
Chiama lo strumento secondario
initialize
dello strumento di utilità.Se specifichi le configurazioni personalizzate di Kubernetes:
./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 Certificate Authority Service. Prendi nota di
CA_POOL
.b. Chiama lo strumento secondario
initialize
dello strumento di utilità:Se specifichi le configurazioni personalizzate di 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
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 del parco risorse
Ripeti i passaggi seguenti per la nuova CA e la vecchia CA per tutti i cluster che fanno parte del parco risorse.
Scarica i trust anchor 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
Aggiungi trust anchor della CA:
./migrate-ca add-trust-anchor --ca_cert ROOT_CERT.pem
Verifica che i trust anchor siano stati ricevuti da tutti i carichi di lavoro della flotta. 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
Migrazione della CA
Esegui la migrazione della configurazione CA. Il comando richiesto dipende dalla nuova CA in cui esegui la migrazione.
CA mesh
./migrate_ca migrate-ca --ca mesh_ca
Servizio CA
./migrate_ca migrate-ca --ca gcp_cas --ca_pool CA_POOL
Riavvia tutti i carichi di lavoro.
Per ridurre al minimo il rischio di inattività del traffico TLS, questo passaggio deve avere un impatto minimo sul numero minimo 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
Verifica che le connessioni mTLS funzionino tra i carichi di lavoro nello spazio dei nomi riavvio 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 verificando 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 alternativa, procedi per eseguire un rollback per eseguire il rollback della nuova configurazione CA.
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
Esegui un rollback
Esegui il rollback della configurazione CA e rimuovi i trust anchor appena configurati:
./migrate-ca rollback
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
(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
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 in loco.