Esegui il provisioning di un piano di controllo Cloud Service Mesh gestito su GKE
Cloud Service Mesh è un mesh di servizi gestito da Google che puoi semplicemente abilitare. Google si occupa di affidabilità, upgrade, scalabilità e sicurezza al posto tuo.
In questa pagina viene illustrato come utilizzare l'API fleet per configurare i servizi Cloud Service Mesh utilizzando le API Istio.
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
- Attivato Identità carico di lavoro sui tuoi cluster.
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. Questa operazione è inclusa nelle istruzioni o può essere eseguita separatamente prima del del provisioning.
- Nel tuo progetto deve essere abilitata la funzionalità del parco risorse Service Mesh. Questo è incluse nelle istruzioni o possono essere eseguite separatamente.
GKE Autopilot è supportato solo con la versione GKE 1.21.3+.
Cloud Service Mesh può utilizzare più cluster GKE in un un ambiente con una singola rete a progetto 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
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 ispezionare 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.L'utilizzo di Certificate Authority Service (CA Service) richiede la configurazione di Cloud Service Mesh per cluster. e non è supportato quando si utilizza la configurazione predefinita del parco risorse in GKE Enterprise.
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.
Prima di iniziare
- Accedi al tuo account Google Cloud. Se non conosci Google Cloud, crea un account per valutare le prestazioni dei nostri prodotti in scenari reali. I nuovi clienti ricevono anche 300 $di crediti gratuiti per l'esecuzione, il test e il deployment dei carichi di lavoro.
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Assicurati che la fatturazione sia attivata per il tuo progetto Google Cloud.
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Assicurati che la fatturazione sia attivata per il tuo progetto Google Cloud.
- Configura
gcloud
(anche se utilizzi Cloud Shell). -
Esegui l'autenticazione con Google Cloud CLI, dove FLEET_PROJECT_ID
è l'ID del progetto host del parco risorse. In genere,
FLEET_PROJECT_ID viene creato per impostazione predefinita e ha lo stesso nome
come progetto.
gcloud auth login --project FLEET_PROJECT_ID
- Aggiorna i componenti:
gcloud components update
-
Abilita le API richieste nel progetto host del parco risorse.
gcloud services enable mesh.googleapis.com \ --project=FLEET_PROJECT_ID
Nella console Google Cloud, vai alla pagina Gestore funzionalità.
Nel riquadro Mesh di servizi, fai clic su Configura.
Rivedi le impostazioni ereditate da tutti i nuovi cluster che creali nella console Google Cloud e registrati nel parco risorse.
Per applicare queste impostazioni, fai clic su Configura.
Nella finestra di dialogo di conferma, fai clic su Conferma.
(Facoltativo) Sincronizza i cluster esistenti con le impostazioni predefinite:
- Nell'elenco Cluster nel parco risorse, seleziona i cluster che ti interessano da sincronizzare. Puoi selezionare solo cluster in cui è installato Cloud Service Mesh.
- Fai clic su Sincronizza con le impostazioni del parco risorse e fai clic su Conferma nella finestra di dialogo di conferma visualizzata. Questa operazione può richiedere alcuni minuti per completare l'operazione.
Impostazioni a livello di parco risorse
Crea un file
mesh.yaml
che contenga solo la singola rigamanagement: automatic
:echo "management: automatic" > mesh.yaml
Abilita Cloud Service Mesh per il tuo parco risorse:
gcloud container fleet mesh enable --project FLEET_PROJECT_ID \ --fleet-default-member-config mesh.yaml
Se visualizzi il seguente errore, devi abilitare GKE Enterprise.
ERROR: (gcloud.container.fleet.mesh.enable) FAILED_PRECONDITION: The [anthos.googleapis.com] service is required for this operation and is not enabled for the project [PROJECT_NUMBER]. Please use the Google Developers Console to enable it.: failed precondition
Impostazioni a livello di rete
Se il progetto della tua rete è diverso dal progetto host del parco risorse (ad esempio stai utilizzando un VPC condiviso), devi consentire per accedere agli account di servizio Cloud Service Mesh nel progetto del parco risorse. progetto di rete. Dovrai eseguire questa operazione una sola volta per il progetto di rete.
Concedi agli account di servizio nel progetto del parco risorse l'autorizzazione ad accedere a progetto di rete:
gcloud projects add-iam-policy-binding "NETWORK_PROJECT_ID" \ --member "serviceAccount:service-FLEET_PROJECT_NUMBER@gcp-sa-servicemesh.iam.gserviceaccount.com" \ --role roles/anthosservicemesh.serviceAgent
Impostazioni a livello di cluster
Quando è tutto pronto per creare cluster da utilizzare con Cloud Service Mesh, crea registrale in un unico passaggio con Google Cloud CLI per utilizzare il valore predefinito configurazione. Ad esempio:
gcloud container clusters create-auto CLUSTER_NAME \ --fleet-project FLEET_PROJECT_ID \ --location=LOCATION
Puoi ottenere il numero del progetto del parco risorse eseguendo seguente comando:
gcloud projects list --filter="FLEET_PROJECT_ID" --format="value(PROJECT_ID)"
Il flag
--location
indica la zona o la regione di computing (ad esempious-central1-a
ous-central1
) per il cluster.Se il progetto del cluster è diverso dal progetto host del parco risorse, devi Consenti agli account di servizio Cloud Service Mesh nel progetto del parco risorse di accedere nel progetto cluster e abilitare le API richieste nel progetto cluster. Devi eseguire devi eseguire questa operazione una volta per ogni progetto del cluster.
Concedi agli account di servizio nel progetto del parco risorse l'autorizzazione ad accedere a progetto cluster:
gcloud projects add-iam-policy-binding "CLUSTER_PROJECT_ID" \ --member "serviceAccount:service-FLEET_PROJECT_NUMBER@gcp-sa-servicemesh.iam.gserviceaccount.com" \ --role roles/anthosservicemesh.serviceAgent
Abilita l'API Mesh sul progetto del cluster:
gcloud services enable mesh.googleapis.com \ --project=CLUSTER_PROJECT_ID
Sostituisci CLUSTER_PROJECT_ID con l'identificatore univoco di del progetto di cluster. Se hai creato il cluster nello stesso progetto del tuo parco risorse, il valore CLUSTER_PROJECT_ID sarà uguale a FLEET_PROJECT_ID.
Registra un cluster GKE utilizzando l'identità dei carichi di lavoro del parco risorse. Il flag
--location
indica la zona di computing (ad esempious-central1-a
ous-central1
) per il cluster.gcloud container clusters update CLUSTER_NAME \ --location CLUSTER_LOCATION \ --fleet-project FLEET_PROJECT_ID
Verifica che il cluster sia registrato:
gcloud container fleet memberships list --project FLEET_PROJECT_ID
Output di esempio:
NAME EXTERNAL_ID LOCATION cluster-1 1d8e255d-2b55-4df9-8793-0435461a2cbc us-central1
Prendi nota di MEMBERSHIP_NAME, che ti servirà quando abilita la gestione automatica.
Se il progetto di rete del cluster è diverso dal progetto host del parco risorse (ad esempio, stai utilizzando un VPC condiviso), devi consentire per accedere agli account di servizio Cloud Service Mesh nel progetto del parco risorse. progetto di rete. Dovrai eseguire questa operazione una sola volta per il progetto di rete.
Concedi agli account di servizio nel progetto del parco risorse l'autorizzazione ad accedere a progetto di rete:
gcloud projects add-iam-policy-binding "NETWORK_PROJECT_ID" \ --member "serviceAccount:service-FLEET_PROJECT_NUMBER@gcp-sa-servicemesh.iam.gserviceaccount.com" \ --role roles/anthosservicemesh.serviceAgent
Se il progetto del cluster è diverso dal progetto host del parco risorse, devi consentire Account di servizio Cloud Service Mesh nel progetto del parco risorse per accedere al cluster e abilitare le API richieste nel progetto del cluster.
Devi eseguire questa operazione una sola volta per ogni progetto del cluster. Se in precedenza configurato Cloud Service Mesh gestito per questa combinazione di cluster e progetti del parco risorse, queste modifiche sono già state applicate devi eseguire questi comandi.
Concedi agli account di servizio nel progetto del parco risorse l'autorizzazione ad accedere al cluster progetto:
gcloud projects add-iam-policy-binding "CLUSTER_PROJECT_ID" \ --member "serviceAccount:service-FLEET_PROJECT_NUMBER@gcp-sa-servicemesh.iam.gserviceaccount.com" \ --role roles/anthosservicemesh.serviceAgent
Abilita l'API Mesh sul progetto del cluster:
gcloud services enable mesh.googleapis.com \ --project=CLUSTER_PROJECT_ID
- MEMBERSHIP_NAME è il nome dell'abbonamento indicato al momento della verifica che il cluster sia stato registrato nel parco risorse.
MEMBERSHIP_LOCATION è la località del tuo abbonamento (una regione o
global
).Se di recente hai creato l'appartenenza utilizzando il comando in questa guida, dovrebbe essere la regione del tuo cluster. Se hai un cluster a livello di zona, utilizza corrispondente alla zona del cluster. Ad esempio, se disponi di un'infrastruttura cluster in
us-central1-c
, quindi utilizza il valoreus-central1
.Questo valore può essere
global
se hai effettuato la registrazione prima di maggio 2023 o se la località diglobal
specificata durante la registrazione dell'abbonamento. Puoi controlla la località dell'abbonamento congcloud container fleet memberships list --project FLEET_PROJECT_ID
.- Pod non inseriti
- Pod inseriti manualmente
- Job
- StatefulSet
- DaemonSet
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.
- Applica l'etichetta di inserimento predefinita allo spazio dei nomi:
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
- 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 ulteriori informazioni consulta Impostare i limiti per le risorse in Autopilot. - 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. - Sostituisci l'etichetta dello spazio dei nomi attuale. I passaggi dipendono dall'implementazione del piano di controllo.
- Applica l'etichetta di inserimento predefinita allo spazio dei nomi:
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 di riferimento per per quel cluster.
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
L'abilitazione di mesh.googleapis.com abilita le seguenti API:
API | Finalità | Può essere disattivato |
---|---|---|
meshconfig.googleapis.com |
Cloud Service Mesh utilizza l'API di configurazione mesh per inoltrare di configurazione automatica dal mesh a Google Cloud. Inoltre, l'abilitazione dell'API Mesh Configuration ti consente di accedere ai alle pagine Cloud Service Mesh nella console Google Cloud e per utilizzare dell'autorità di certificazione Cloud Service Mesh. | No |
meshca.googleapis.com |
Contenuti correlati all'autorità di certificazione Cloud Service Mesh utilizzata da Cloud Service Mesh gestito. | No |
container.googleapis.com |
Necessaria per creare cluster Google Kubernetes Engine (GKE). | No |
gkehub.googleapis.com |
Necessaria per gestire la rete mesh come flotta. | No |
monitoring.googleapis.com |
Necessaria per acquisire dati di telemetria per i carichi di lavoro mesh. | No |
stackdriver.googleapis.com |
Necessaria per utilizzare l'UI dei Servizi. | No |
opsconfigmonitoring.googleapis.com |
Richiesta per utilizzare l'interfaccia utente dei servizi al di fuori di Google Cloud cluster. | No |
connectgateway.googleapis.com |
Obbligatorio per il piano di controllo Cloud Service Mesh gestito possono accedere ai carichi di lavoro mesh. | Sì* |
trafficdirector.googleapis.com |
Abilita un piano di controllo gestito scalabile e a disponibilità elevata. | Sì* |
networkservices.googleapis.com |
Abilita un piano di controllo gestito scalabile e a disponibilità elevata. | Sì* |
networksecurity.googleapis.com |
Abilita un piano di controllo gestito scalabile e a disponibilità elevata. | Sì* |
Configura Cloud Service Mesh gestito
I passaggi necessari per eseguire il provisioning di Cloud Service Mesh gestito utilizzando l'API del parco risorse dipendono sulla tua preferenza per l'attivazione valore predefinito per i nuovi cluster del parco risorse o per cluster.
Configura per il tuo parco risorse
Se hai attivato Google Kubernetes Engine (GKE) Enterprise, puoi abilita Cloud Service Mesh gestito come configurazione predefinita per il tuo parco risorse. Questo significa che ogni nuovo cluster GKE su Google Cloud registrato durante il cluster della creatività in cui è abilitato Cloud Service Mesh gestito sul cluster. Puoi scoprire di più su configurazione predefinita del parco risorse in Gestisci a livello di parco risorse funzionalità.
Abilitazione di Cloud Service Mesh gestito come configurazione predefinita per il parco risorse e registrazione cluster al parco risorse durante la creazione del cluster supporta solo Mesh CA. Se vuoi utilizzare Certificate Authority Service, ti consigliamo di abilitarlo per cluster.
Per abilitare i valori predefiniti a livello di parco risorse per Cloud Service Mesh gestito, completa la seguenti passaggi:
Console
gcloud
Per configurare valori predefiniti a livello di parco risorse utilizzando Google Cloud CLI, devi definire le seguenti impostazioni:
Procedi a Verifica che sia stato eseguito il provisioning del piano di controllo.
Configura per cluster
Utilizza i seguenti passaggi per configurare Cloud Service Mesh gestito per ciascun cluster in il mesh di prodotti singolarmente.
Abilita la funzionalità del parco risorse Cloud Service Mesh
Abilita Cloud Service Mesh nel progetto del parco risorse. Tieni presente che se prevedi di registrarti in più cluster, l'abilitazione di Cloud Service Mesh avviene a livello di parco risorse, quindi eseguire il comando una volta sola.
gcloud container fleet mesh enable --project FLEET_PROJECT_ID
Registra i cluster in un parco risorse
Configura Certificate Authority Service (facoltativo)
Se il deployment del mesh di servizi richiede Certificate Authority Service (CA Service), Poi, segui Configura Certificate Authority Service per Cloud Service Mesh gestito. per abilitarlo per il tuo parco risorse. Assicurati di completare tutti i passaggi prima di procedere alla prossima sezione.
Abilita gestione automatica
Esegui questo comando per abilitare la gestione automatica:
gcloud container fleet mesh update \
--management automatic \
--memberships MEMBERSHIP_NAME \
--project FLEET_PROJECT_ID \
--location MEMBERSHIP_LOCATION
dove:
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:
...
membershipSpecs:
projects/746296320118/locations/us-central1/memberships/demo-cluster-1:
mesh:
management: MANAGEMENT_AUTOMATIC
membershipStates:
projects/746296320118/locations/us-central1/memberships/demo-cluster-1:
servicemesh:
controlPlaneManagement:
details:
- code: REVISION_READY
details: 'Ready: asm-managed'
state: ACTIVE
implementation: ISTIOD | TRAFFIC_DIRECTOR
dataPlaneManagement:
details:
- code: OK
details: Service is running.
state: ACTIVE
state:
code: OK
description: 'Revision(s) ready for use: asm-managed.'
...
Prendi nota del piano di controllo visualizzato nel campo implementation
:
ISTIOD
o TRAFFIC_DIRECTOR
. Consulta
Funzionalità supportate da Cloud Service Mesh
per scoprire le differenze del piano di controllo e le configurazioni supportate,
è selezionata l'implementazione del piano di controllo.
Configura kubectl
in modo che punti al cluster
Le seguenti sezioni prevedono l'esecuzione di comandi kubectl
su ciascuno dei
nei cluster. Prima di procedere con le sezioni seguenti, esegui
il seguente comando per ciascuno dei tuoi cluster per configurare kubectl
in modo che punti a
nel cluster.
gcloud container clusters get-credentials CLUSTER_NAME \
--location CLUSTER_LOCATION \
--project CLUSTER_PROJECT_ID
Tieni presente che non viene eseguito automaticamente il deployment di un gateway in entrata con il controllo aereo. Disaccoppiamento del deployment del gateway in entrata e del piano di controllo consente di gestire più facilmente i gateway in un ambiente di produzione. Se il cluster richiede un gateway in entrata o in uscita, consulta Esegui il deployment dei gateway. Per attivare altre funzioni facoltative, consulta Abilitare funzionalità facoltative su Cloud Service Mesh.
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:
(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:
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.
L'abilitazione di Cloud Service Mesh con l'API del parco risorse abiliterà il rilevamento degli endpoint per in questo cluster. Tuttavia, devi aprire le porte del firewall. Per disabilitare il rilevamento degli endpoint per uno o più cluster, consulta le istruzioni per disattivarlo Rilevamento degli endpoint tra i cluster con API dichiarativa.
Per un'applicazione di esempio con due cluster, vedi Esempio di servizio HelloWorld.
Esegue il deployment delle applicazioni
Se nel parco risorse sono presenti più cluster che utilizzano Cloud Service Mesh gestito, assicurati che le porte di rilevamento degli endpoint o del firewall siano configurate come previsto prima e il deployment delle applicazioni.Abilita lo spazio dei nomi per l'inserimento. I passaggi dipendono dall'implementazione del piano di controllo.
Gestito (TD)
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:
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.
Personalizza inserimento (facoltativo)
Puoi ignorare i valori predefiniti e personalizzare le impostazioni di inserimento, ma causare errori di configurazione imprevisti e conseguenti problemi con il file collaterale containers. 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:
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:
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"
Esegui la migrazione delle applicazioni a Cloud Service Mesh gestito
Per eseguire la migrazione delle applicazioni da Cloud Service Mesh nel cluster a Cloud Service Mesh gestito: segui questi passaggi:
Gestito (TD)
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:
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:
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 Cloud Service Mesh
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.