Esegui il provisioning di Cloud Service Mesh gestito con asmcli
Panoramica
Managed Cloud Service Mesh con asmcli
è un piano di controllo gestito e
un piano dati gestito che puoi semplicemente configurare. Google ne gestisce l'affidabilità,
gli upgrade, la scalabilità e la sicurezza in modo compatibile con le versioni precedenti. Questo
spiega come configurare o migrare le applicazioni a Cloud Service Mesh gestito
in una configurazione a cluster singolo o multi-cluster con asmcli
.
Per scoprire le funzionalità supportate e le limitazioni della versione gestita di Cloud Service Mesh, consulta Funzionalità supportate da Managed Cloud Service Mesh.
Prerequisiti
Per iniziare, questa guida presuppone che tu abbia:
- Un progetto Cloud
- Un account di fatturazione Cloud
- Hai ottenuto le autorizzazioni richieste. per eseguire il provisioning di Cloud Service Mesh
- Lo strumento di installazione di
asmcli
,kpt
e altri gli strumenti specificati in Installa gli strumenti richiesti
Per un provisioning più rapido, i cluster devono avere Identità carico di lavoro in un bucket in cui è abilitato il controllo delle versioni. Se Workload Identity non è abilitato, il provisioning l'attivazione automatica.
Requisiti
- Uno o più cluster con un versione supportata di GKE, in una delle regioni supportate.
- Assicurati che il cluster abbia capacità sufficiente per i componenti richiesti
le installazioni Cloud Service Mesh
nel cluster.
- Il deployment
mdp-controller
nello spazio dei nomikube-system
richiede la CPU: 50 m, memoria: 128 Mi. - Il daemonset
istio-cni-node
nello spazio dei nomikube-system
richiede una CPU: 100m, memoria: 100 Mi su ciascun nodo.
- Il deployment
- Assicurati che il computer client da cui esegui il provisioning di Cloud Service Mesh gestito abbia la connettività di rete al server API.
- I cluster devono essere registrati in un parco risorse.
Questo passaggio può essere fatto separatamente prima del provisioning o nell'ambito della
eseguire il provisioning passando i flag
--enable-registration
e--fleet-id
. Nel tuo progetto deve essere abilitata la funzionalità del parco risorse Service Mesh. Potresti abilitarlo nell'ambito del provisioning passando
--enable-gcp-components
, oppure eseguendo questo comando:gcloud container fleet mesh enable --project=FLEET_PROJECT_ID
dove FLEET_PROJECT_ID è l'ID progetto del progetto host del parco risorse.
GKE Autopilot è supportato solo con la versione GKE 1.21.3+.
Cloud Service Mesh può utilizzare più cluster GKE in un ambiente con una singola rete a progetto singolo o una rete singola con più progetti completamente gestito di Google Cloud.
- Se unisci cluster che non si trovano nello stesso progetto, questi devono essere registrati con la stessa progetto host del parco risorse, e i cluster devono trovarsi in un VPC condiviso configurazione sulla stessa rete.
- Per un ambiente multi-cluster a progetto singolo, il progetto del parco risorse può essere come per il progetto del cluster. Per ulteriori informazioni sui parchi risorse, vedi Panoramica dei parchi risorse.
- Per un ambiente con più progetti, ti consigliamo di ospitare il parco risorse in un un progetto separato dai progetti del cluster. Se la tua organizzazione criteri e configurazione esistente lo consentono, ti consigliamo di utilizzare il progetto VPC condiviso come progetto host del parco risorse. Per ulteriori informazioni, vedi Configurazione di cluster con VPC condiviso
- Se la tua organizzazione utilizza Controlli di servizio VPC e stai eseguendo il provisioning
Cloud Service Mesh sui cluster GKE con una release
maggiore o uguale a 1.22.1-gke.10, potresti dover prendere
passaggi per la configurazione:
- Se esegui il provisioning di Cloud Service Mesh sulla
regolare o stabile
canale di rilascio,
devi utilizzare il flag
--use-vpcsc
aggiuntivo quando applichi il flag e segui le istruzioni del piano di controllo Guida ai Controlli di servizio VPC (anteprima). In caso contrario, il provisioning non supererà i controlli di sicurezza. - Se esegui il provisioning di Cloud Service Mesh in rapido
canale di rilascio,
non è necessario usare il flag
--use-vpcsc
aggiuntivo quando applicando il piano di controllo gestito, ma devi seguire le Guida ai Controlli di servizio VPC (GA).
- Se esegui il provisioning di Cloud Service Mesh sulla
regolare o stabile
canale di rilascio,
devi utilizzare il flag
Ruoli necessari per installare Cloud Service Mesh
La tabella seguente descrive i ruoli necessari per installare i ruoli Cloud Service Mesh.
Nome del ruolo | ID ruolo | Posizione concessione | Descrizione |
---|---|---|---|
Amministratore GKE Hub | roles/gkehub.admin | Progetto parco risorse | Accesso completo a GKE Hub e alle risorse correlate. |
Amministratore Service Usage | roles/serviceusage.serviceUsageAdmin | Progetto parco risorse | Possibilità di abilitare, disabilitare e controllare gli stati dei servizi, ispezionare e utilizzare quota e fatturazione per un progetto consumer. (Nota 1) |
Amministratore servizio CA beta | roles/privateca.admin | Progetto parco risorse | Accesso completo a tutte le risorse del servizio CA. (Nota 2) |
Limitazioni
Ti consigliamo di consultare l'elenco Funzionalità e limitazioni supportate da Cloud Service Mesh. In particolare, tieni presente quanto segue:
L'API
IstioOperator
non è supportata perché il suo scopo principale è controllare nel cluster.Per i cluster GKE Autopilot, la configurazione tra progetti è supportato con GKE 1.23 o versioni successive.
Per i cluster GKE Autopilot, per adattarsi Limite di risorse di GKE Autopilot, le richieste e i limiti di risorse proxy predefiniti sono impostati su 500 m CPU e 512 Mb la memoria. Puoi eseguire l'override dei valori predefiniti utilizzando iniezione personalizzata.
Durante il processo di provisioning per un piano di controllo gestito, i CRD di Istio di cui è stato eseguito il provisioning nel cluster specificato. Se sono presenti CRD Istio nella verranno sovrascritti nel tuo cluster
Istio CNI e Cloud Service Mesh non sono compatibili con GKE Sandbox. Pertanto, Cloud Service Mesh gestito con l'implementazione
TRAFFIC_DIRECTOR
non supporta i cluster con GKE Sandbox abilitata.Lo strumento
asmcli
deve avere accesso all'endpoint di Google Kubernetes Engine (GKE). Puoi configurare l'accesso tramite una "salto" server, ad esempio un VM di Compute Engine all'interno del Virtual Private Cloud (VPC) che fornisce l'accesso.
Prima di iniziare
Configura gcloud
Completa i passaggi seguenti anche se utilizzi Cloud Shell.
Esegui l'autenticazione con Google Cloud CLI:
gcloud auth login --project PROJECT_ID
dove PROJECT_ID è l'identificatore univoco del progetto del cluster. Esegui questo comando per recuperare PROJECT_ID:
gcloud projects list --filter="<PROJECT ID>" --format="value(PROJECT_NUMBER)" ```
Aggiorna i componenti:
gcloud components update
Configura
kubectl
in modo che punti al cluster.gcloud container clusters get-credentials CLUSTER_NAME \ --zone CLUSTER_LOCATION \ --project PROJECT_ID
Scarica lo strumento di installazione
Scarica l'ultima versione dello strumento nella directory di lavoro corrente:
curl https://storage.googleapis.com/csm-artifacts/asm/asmcli > asmcli
Rendi eseguibile lo strumento:
chmod +x asmcli
Configura ogni cluster
Utilizza i seguenti passaggi per configurare Cloud Service Mesh gestito per ciascun cluster in della tua rete mesh.
Applica il piano di controllo gestito
Prima di applicare il piano di controllo gestito, devi seleziona un canale di rilascio. Il canale Cloud Service Mesh è determinato dal canale del cluster GKE all'indirizzo per eseguire il provisioning di Cloud Service Mesh gestito. Tieni presente che più canali nello stesso cluster contemporaneamente non è supportata.
Esegui lo strumento di installazione per ciascun cluster che utilizzerà Cloud Service Mesh gestito. Ti consigliamo di includere entrambe le seguenti opzioni:
--enable-registration --fleet_id FLEET_PROJECT_ID
Questi due flag registrano il cluster in un parco risorse, dove FLEET_ID è l'ID progetto del progetto host del parco risorse. Se utilizzi un singolo progetto, FLEET_PROJECT_ID è uguale a PROJECT_ID, il parco risorse il progetto host e il progetto del cluster sono uguali. In più complessi ad esempio per più progetti, è consigliabile utilizzare un host del parco risorse separato progetto.--enable-all
. Questo flag abilita sia i componenti obbligatori sia la registrazione.
Lo strumento asmcli
configura direttamente il piano di controllo gestito utilizzando strumenti e
all'interno dello strumento dell'interfaccia a riga di comando. Segui le istruzioni riportate di seguito a seconda
la tua CA preferita.
Autorità di certificazione
Seleziona un'autorità di certificazione da utilizzare per la rete mesh.
CA mesh
Esegui questo comando per installare il piano di controllo con funzionalità predefinite e Mesh CA. Inserisci i valori negli appositi segnaposto.
./asmcli install \
-p PROJECT_ID \
-l LOCATION \
-n CLUSTER_NAME \
--fleet_id FLEET_PROJECT_ID \
--managed \
--verbose \
--output_dir DIR_PATH \
--enable-all
Servizio CA
- Segui i passaggi descritti in Configurare Certificate Authority Service.
- Esegui questo comando per installare il piano di controllo con impostazione e Certificate Authority Service. Inserisci i valori negli appositi segnaposto.
./asmcli install \
-p PROJECT_ID \
-l LOCATION \
-n CLUSTER_NAME \
--fleet_id FLEET_PROJECT_ID \
--managed \
--verbose \
--output_dir DIR_PATH \
--enable-all \
--ca gcp_cas \
--ca_pool pool_name
Lo strumento scarica tutti i file per la configurazione del piano di controllo gestito
al --output_dir
specificato, installando lo strumento istioctl
e
diverse applicazioni. I passaggi in questa guida presuppongono che istioctl
venga eseguito
--output_dir
località che hai specificato durante l'esecuzione di asmcli install
, con
istioctl
presente nella sua sottodirectory <Istio release dir>/bin
.
Se esegui nuovamente asmcli
sullo stesso cluster, questa sovrascriverà
alla configurazione esistente
del piano di controllo. Assicurati di specificare le stesse opzioni e
se vuoi la stessa configurazione.
Verifica che sia stato eseguito il provisioning del piano di controllo
Dopo qualche minuto, verifica che lo stato del piano di controllo sia ACTIVE
:
gcloud container fleet mesh describe --project FLEET_PROJECT_ID
L'output è simile a questo:
membershipStates: projects/746296320118/locations/us-central1/memberships/demo-cluster-1: servicemesh: controlPlaneManagement: details: - code: REVISION_READY details: 'Ready: asm-managed' state: ACTIVE ... state: code: OK description: 'Revision(s) ready for use: asm-managed.'
Se lo stato non raggiunge "ACTIVE
" entro pochi minuti, fai riferimento a
Verificare lo stato del piano di controllo gestito
per ulteriori informazioni sui possibili errori.
Upgrade zero-touch
Una volta installato il piano di controllo gestito, Google eseguirà automaticamente l'upgrade quando sono disponibili nuove release o patch.
Piano dati gestito
Se utilizzi Cloud Service Mesh gestito, Google gestisce completamente gli upgrade dei tuoi proxy a meno che non lo disattivi.
Con il piano dati gestito, i proxy sidecar e i gateway inseriti vengono aggiornate automaticamente in combinazione con il piano di controllo gestito il riavvio dei carichi di lavoro per reinserire nuove versioni del proxy. Questa operazione normalmente vengono completati 1-2 settimane dopo l'upgrade del piano di controllo gestito.
Se disabilitata, la gestione dei proxy è guidata dal ciclo di vita naturale dei pod in nel cluster e deve essere attivato manualmente dall'utente per controllare l'aggiornamento di conversione.
Il piano dati gestito esegue gli upgrade dei proxy eliminando i pod in esecuzione versioni precedenti del proxy. L'eliminazione avviene gradualmente, nel rispetto delle il budget per l'interruzione dei pod e il controllo della frequenza di modifica.
Il piano dati gestito non gestisce quanto segue:
- Pod non inseriti
- Pod inseriti manualmente
- Job
- StatefulSet
- DaemonSet
Se hai eseguito il provisioning di Cloud Service Mesh gestito su un cluster precedente, puoi abilita la gestione del piano dati per l'intero cluster:
kubectl annotate --overwrite controlplanerevision -n istio-system \
REVISION_LABEL \
mesh.cloud.google.com/proxy='{"managed":"true"}'
In alternativa, puoi abilitare il piano dati gestito in modo selettivo per un una revisione, uno spazio dei nomi o un pod specifici del piano di controllo mediante l'annotazione la stessa annotazione. Se controlli i singoli componenti in modo selettivo, l'ordine di precedenza è la revisione del piano di controllo, poi lo spazio dei nomi e infine il pod.
Potrebbero essere necessari fino a dieci minuti prima che il servizio sia pronto per gestire dei proxy nel cluster. Esegui questo comando per verificare lo stato:
gcloud container fleet mesh describe --project FLEET_PROJECT_ID
Output previsto
membershipStates:
projects/PROJECT_NUMBER/locations/global/memberships/CLUSTER_NAME:
servicemesh:
dataPlaneManagement:
details:
- code: OK
details: Service is running.
state: ACTIVE
state:
code: OK
description: 'Revision(s) ready for use: asm-managed-rapid.'
Se il servizio non diventa pronto entro dieci minuti, vedi Stato del piano dati gestito per i passaggi successivi.
(Facoltativo) Disabilita il piano dati gestito
Se esegui il provisioning di Cloud Service Mesh gestito su un nuovo cluster, puoi: disattivare completamente il piano dati gestito o per singoli spazi dei nomi o pod. Il piano dati gestito continuerà a essere disabilitato per i cluster esistenti in cui è stato disattivato per impostazione predefinita o manualmente.
Per disabilitare il piano dati gestito a livello di cluster e tornare a gestire autonomamente i proxy collaterali, modifica l'annotazione:
kubectl annotate --overwrite controlplanerevision -n istio-system \
mesh.cloud.google.com/proxy='{"managed":"false"}'
Per disabilitare il piano dati gestito per uno spazio dei nomi:
kubectl annotate --overwrite namespace NAMESPACE \
mesh.cloud.google.com/proxy='{"managed":"false"}'
Per disabilitare il piano dati gestito per un pod:
kubectl annotate --overwrite pod POD_NAME \
mesh.cloud.google.com/proxy='{"managed":"false"}'
Attiva le notifiche di manutenzione
Puoi richiedere di ricevere notifiche sull'imminente manutenzione del piano dati gestito alla settimana prima della pianificazione della manutenzione. Le notifiche di manutenzione non vengono inviate per impostazione predefinita. Devi inoltre Configura un periodo di manutenzione di GKE prima di poter ricevere le notifiche. Quando questa impostazione è attiva, le notifiche vengono inviate al almeno due giorni prima dell'operazione di upgrade.
Per attivare le notifiche di manutenzione del piano dati gestito:
Vai alla pagina Comunicazione.
Nella riga Cloud Service Mesh Upgrade, sotto la colonna Email, seleziona la pulsante di opzione per attivare le notifiche di manutenzione.
Ogni utente che vuole ricevere le notifiche deve attivare la funzionalità separatamente. Se vuoi per impostare un filtro email per queste notifiche, l'oggetto è:
Upcoming upgrade for your Cloud Service Mesh cluster "CLUSTER_LOCATION/CLUSTER_NAME"
.
L'esempio seguente mostra una tipica manutenzione del piano dati gestito notifica:
Oggetto: Upgrade imminente del cluster Cloud Service Mesh "
<location/cluster-name>
"Gentile utente di Cloud Service Mesh,
È programmato l'upgrade dei componenti Cloud Service Mesh nel cluster ${instance_id} (https://console.cloud.google.com/kubernetes/clusters/details/${instance_id}/details?project=${project_id}) per il giorno ${scheduled_date_human_Leggi} alle ore ${scheduled_time_human_ read}.
Per informazioni sul nuovo aggiornamento, consulta le note di rilascio (https://cloud.google.com/service-mesh/docs/release-notes).
Se questa manutenzione verrà annullata, riceverai un'altra email.
Cordiali saluti,
Il team di Cloud Service Mesh
(c) 2023 Google LLC 1600 Amphitheatre Parkway, Mountain View, CA 94043, USA Ti abbiamo inviato questo annuncio per informarti di importanti cambiamenti che interessano la Google Cloud Platform o il tuo account. Puoi disattivare le notifiche relative al periodo di manutenzione modificando le preferenze utente: https://console.cloud.google.com/user-preferences/communication?project=${project_id}
Configura il rilevamento degli endpoint (solo per le installazioni multi-cluster)
Se il mesh ha un solo cluster, salta questi passaggi per l'utilizzo di più cluster e procedi con Esegui il deployment delle applicazioni o Eseguire la migrazione delle applicazioni.
Prima di continuare, assicurati che Cloud Service Mesh sia configurato su ogni in un cluster Kubernetes.
Cluster pubblici
Configura il rilevamento degli endpoint tra cluster pubblici
Se utilizzi cluster pubblici (cluster non privati), puoi: Configura il rilevamento degli endpoint tra cluster pubblici o più semplicemente Abilita il rilevamento degli endpoint tra cluster pubblici.
Cluster privati
Configura il rilevamento degli endpoint tra cluster privati
Quando utilizzi i cluster privati GKE, devi configurare endpoint del piano di controllo del cluster in modo che sia l'endpoint pubblico e non privato. Fai riferimento a Configurare il rilevamento degli endpoint tra cluster privati.
Per un'applicazione di esempio con due cluster, vedi Esempio di servizio HelloWorld.
Esegue il deployment delle applicazioni
Abilita lo spazio dei nomi per l'inserimento. I passaggi dipendono dall'implementazione del piano di controllo.
Gestito (TD)
- Applica l'etichetta di inserimento predefinita allo spazio dei nomi:
kubectl label namespace NAMESPACE
istio.io/rev- istio-injection=enabled --overwrite
Gestito (Istiod)
Consigliato: esegui questo comando per applicare l'inserimento predefinito etichetta allo spazio dei nomi:
kubectl label namespace NAMESPACE \
istio.io/rev- istio-injection=enabled --overwrite
Se sei un utente esistente con il piano di controllo Managed Istiod: Ti consigliamo di usare l'inserimento predefinito, ma l'inserimento basato sulle revisioni supportati. Segui queste istruzioni:
Esegui questo comando per individuare i canali di rilascio disponibili:
kubectl -n istio-system get controlplanerevision
L'output è simile al seguente:
NAME AGE asm-managed-rapid 6d7h
NOTA: se nell'elenco precedente sono presenti due revisioni del piano di controllo, rimuovine una. La presenza di più canali del piano di controllo nel cluster non è supportata.
Nell'output, il valore sotto la colonna
NAME
è l'etichetta di revisione che corrisponde al canale di rilascio disponibile per la versione di Cloud Service Mesh.Applica l'etichetta di revisione allo spazio dei nomi:
kubectl label namespace NAMESPACE \ istio-injection- istio.io/rev=REVISION_LABEL --overwrite
A questo punto, hai configurato correttamente Cloud Service Mesh gestito. Se carichi di lavoro esistenti in spazi dei nomi etichettati, quindi riavviali sono stati inseriti i proxy.
Se esegui il deployment di un'applicazione in una configurazione multi-cluster, replica la configurazione di Kubernetes e del piano di controllo in tutti i cluster, a meno che prevedi di limitare quella particolare configurazione a un sottoinsieme di cluster. La di sicurezza applicata a un determinato cluster è la fonte di riferimento in un cluster Kubernetes.
(Facoltativo) Personalizza inserimento
Puoi ignorare i valori predefiniti e personalizzare le impostazioni di inserimento, ma causare errori di configurazione imprevisti e conseguenti problemi con il file collaterale containerizzati. Prima di personalizzare l'inserimento, leggi le informazioni dopo il per note su impostazioni e consigli specifici.
È disponibile la configurazione per pod per eseguire l'override di queste opzioni sui singoli pod.
Per farlo, devi aggiungere un container istio-proxy
al tuo pod. Il file collaterale
l'inserimento tratterà qualsiasi configurazione qui definita come un override del
predefinito del modello di inserimento.
Ad esempio, la seguente configurazione personalizza diverse impostazioni,
tra cui la riduzione delle richieste di CPU, l'aggiunta di un montaggio del volume e l'aggiunta di
Hook preStop
:
apiVersion: v1
kind: Pod
metadata:
name: example
spec:
containers:
- name: hello
image: alpine
- name: istio-proxy
image: auto
resources:
requests:
cpu: "200m"
memory: "256Mi"
limits:
cpu: "200m"
memory: "256Mi"
volumeMounts:
- mountPath: /etc/certs
name: certs
lifecycle:
preStop:
exec:
command: ["sleep", "10"]
volumes:
- name: certs
secret:
secretName: istio-certs
In generale, è possibile impostare qualsiasi campo di un pod. Tuttavia, occorre prestare attenzione campi specifici:
- Kubernetes richiede che il campo
image
sia impostato prima dell'esecuzione dell'inserimento. Puoi impostare un'immagine specifica in modo da sostituire quella predefinita, ma ti consigliamo di impostareimage
suauto
, il che comporterà l'inserimento dell'iniettore collaterale per selezionare automaticamente l'immagine da utilizzare. - Alcuni campi di
containers
dipendono dalle impostazioni correlate. Ad esempio: deve essere minore o uguale al limite di CPU. Se entrambi i campi non sono corretti configurato, il pod potrebbe non avviarsi. - Kubernetes consente di impostare sia
requests
sialimits
per le risorse Podspec
. GKE Autopilot prende in considerazione solorequests
. Per maggiori informazioni consulta Impostare i limiti per le risorse in Autopilot.
Inoltre, alcuni campi sono configurabili tramite annotazioni sul pod, anche se è consigliabile utilizzare il suddetto approccio per personalizzare le impostazioni. Presta particolare attenzione alle seguenti annotazioni:
- Per GKE Standard, se è impostato
sidecar.istio.io/proxyCPU
, imposta devi assicurarti di impostare esplicitamentesidecar.istio.io/proxyCPULimit
. In caso contrario, Il limite di CPU verrà impostato come illimitato. - Per GKE Standard, se è impostato
sidecar.istio.io/proxyMemory
, assicurati di impostare esplicitamentesidecar.istio.io/proxyMemoryLimit
. In caso contrario, il limite di memoria del file collaterale verrà impostato come illimitato. - Per GKE Autopilot, configurazione delle risorse
requests
elimits
l'uso delle annotazioni potrebbe comportare l'overprovisioning delle risorse. Utilizza l'approccio basato sui modelli di immagine da evitare. Consulta la sezione Esempi di modifica delle risorse in Autopilot.
Ad esempio, consulta la seguente annotazione per le risorse:
spec:
template:
metadata:
annotations:
sidecar.istio.io/proxyCPU: "200m"
sidecar.istio.io/proxyCPULimit: "200m"
sidecar.istio.io/proxyMemory: "256Mi"
sidecar.istio.io/proxyMemoryLimit: "256Mi"
Verifica le metriche del piano di controllo
Puoi visualizzare la versione del piano di controllo e del piano dati in Metrics Explorer.
Per verificare che la configurazione funzioni come previsto:
Nella console Google Cloud, visualizza le metriche del piano di controllo:
Scegli l'area di lavoro e aggiungi una query personalizzata utilizzando i seguenti parametri:
- Tipo di risorsa: container Kubernetes
- Metrica: Client proxy
- Filtro:
container_name="cr-REVISION_LABEL"
- Raggruppa per: etichetta
revision
eproxy_version
etichetta - Aggregatore: somma
- Periodo: 1 minuto
Quando esegui Cloud Service Mesh con un piano di controllo gestito da Google e in-cluster, puoi distinguere le metriche dal nome del container. Ad esempio, gestite le metriche hanno
container_name="cr-asm-managed"
, mentre quelle non gestite hannocontainer_name="discovery"
. Per visualizzare le metriche di entrambi, rimuovi il filtro sucontainer_name="cr-asm-managed"
.Verifica la versione del piano di controllo e la versione del proxy esaminando il server seguenti campi in Metrics Explorer:
- Il campo revision indica la versione del piano di controllo.
- Il campo proxy_version indica il
proxy_version
. - Il campo value indica il numero di proxy connessi.
Per la mappatura del canale attuale alla versione di Cloud Service Mesh, consulta Versioni di Cloud Service Mesh per canale.
Esegui la migrazione delle applicazioni a Cloud Service Mesh gestito
Preparati per la migrazione
Per prepararti alla migrazione delle applicazioni da Cloud Service Mesh nel cluster agli ambienti gestiti Cloud Service Mesh, segui questi passaggi:
Esegui lo strumento come indicato nella sezione Applicare il piano di controllo gestito da Google.
(Facoltativo) Se vuoi utilizzare il piano dati gestito da Google, abilita per la gestione dei piani:
kubectl annotate --overwrite controlplanerevision REVISION_TAG \ mesh.cloud.google.com/proxy='{"managed":"true"}'
Esegui la migrazione delle applicazioni
Per eseguire la migrazione delle applicazioni da Cloud Service Mesh nel cluster a Cloud Service Mesh gestito: segui questi passaggi:
- Sostituisci l'etichetta dello spazio dei nomi attuale. I passaggi dipendono dall'implementazione del piano di controllo.
Gestito (TD)
- Applica l'etichetta di inserimento predefinita allo spazio dei nomi:
kubectl label namespace NAMESPACE
istio.io/rev- istio-injection=enabled --overwrite
Gestito (Istiod)
Consigliato: esegui questo comando per applicare l'inserimento predefinito etichetta allo spazio dei nomi:
kubectl label namespace NAMESPACE \
istio.io/rev- istio-injection=enabled --overwrite
Se sei un utente esistente con il piano di controllo Managed Istiod: Ti consigliamo di usare l'inserimento predefinito, ma l'inserimento basato sulle revisioni supportati. Segui queste istruzioni:
Esegui questo comando per individuare i canali di rilascio disponibili:
kubectl -n istio-system get controlplanerevision
L'output è simile al seguente:
NAME AGE asm-managed-rapid 6d7h
NOTA: se nell'elenco precedente sono presenti due revisioni del piano di controllo, rimuovine una. La presenza di più canali del piano di controllo nel cluster non è supportata.
Nell'output, il valore sotto la colonna
NAME
è l'etichetta di revisione che corrisponde al canale di rilascio disponibile per la versione di Cloud Service Mesh.Applica l'etichetta di revisione allo spazio dei nomi:
kubectl label namespace NAMESPACE \ istio-injection- istio.io/rev=REVISION_LABEL --overwrite
Esegui un upgrade in sequenza dei deployment nello spazio dei nomi:
kubectl rollout restart deployment -n NAMESPACE
Testa l'applicazione per verificare che i carichi di lavoro funzionino correttamente.
Se hai carichi di lavoro in altri spazi dei nomi, ripeti i passaggi precedenti per per ogni spazio dei nomi.
Se hai eseguito il deployment dell'applicazione in una configurazione multi-cluster, replica Configurazione di Kubernetes e Istio in tutti i cluster, a meno che non sia presente un limitare la configurazione a un sottoinsieme di cluster. La applicata a un determinato cluster è la fonte attendibile per per quel cluster.
Se ritieni che l'applicazione funzioni come previsto, puoi rimuovere il
nel cluster istiod
dopo aver trasferito tutti gli spazi dei nomi al controllo gestito
o di mantenerli come backup: istiod
farà automaticamente fare lo scale down per utilizzare
meno risorse. Per rimuoverlo, vai a
Elimina il piano di controllo precedente.
Se riscontri problemi, puoi identificarli e risolverli utilizzando le informazioni in Risolvere i problemi relativi al piano di controllo gestito e, se necessario, esegui il rollback alla versione precedente.
Elimina piano di controllo precedente
Dopo l'installazione e la conferma che tutti gli spazi dei nomi utilizzino il controllo gestito da Google puoi eliminare quello precedente.
kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod -n istio-system --ignore-not-found=true
Se hai utilizzato istioctl kube-inject
al posto dell'inserimento automatico o se
hai installato gateway aggiuntivi, controlla le metriche per il piano di controllo
e verificare che il numero di endpoint connessi sia zero.
Rollback
Esegui i seguenti passaggi per eseguire il rollback al controllo precedente del piano di controllo:
Aggiorna i carichi di lavoro da inserire con la versione precedente del dal piano di controllo. Nel comando seguente, il valore della revisione
asm-191-1
è utilizzato solo come esempio. Sostituisci il valore di esempio con dell'etichetta di revisione del piano di controllo precedente.kubectl label namespace NAMESPACE istio-injection- istio.io/rev=asm-191-1 --overwrite
Riavvia i pod per attivare la reiniezione in modo che i proxy abbiano versione precedente:
kubectl rollout restart deployment -n NAMESPACE
Il piano di controllo gestito scalerà automaticamente fino a zero e non utilizzerà quando non è in uso. I webhook mutanti e il provisioning rimarranno e non influiscono sul comportamento del cluster.
Il gateway è ora impostato sulla revisione asm-managed
. Per eseguire il rollback, esegui di nuovo
il comando di installazione di Cloud Service Mesh, che rieseguirà il deployment del gateway puntando
al piano di controllo nel cluster:
kubectl -n istio-system rollout undo deploy istio-ingressgateway
Se l'operazione riesce, ipotizza questo output:
deployment.apps/istio-ingressgateway rolled back
Disinstalla
Il piano di controllo gestito scala automaticamente fino a zero quando non è utilizzato da nessuno spazio dei nomi. Per i passaggi dettagliati, vedi Disinstallare Cloud Service Mesh.
Risoluzione dei problemi
Per identificare e risolvere i problemi relativi all'utilizzo del piano di controllo gestito, consulta Risoluzione dei problemi relativi al piano di controllo gestito.
Passaggi successivi
- Scopri di più sui canali di rilascio.
- Esegui la migrazione da
IstioOperator
. - Esegui la migrazione di un gateway al piano di controllo gestito.
- Scopri come Abilita le funzionalità facoltative di Cloud Service Mesh gestite, quali: