Esegui il provisioning di un piano di controllo Cloud Service Mesh gestito su GKE
Per ulteriori informazioni, consulta la panoramica di Cloud Service Mesh.Cloud Service Mesh è un mesh di servizi gestito da Google che devi semplicemente attivare. Google ne gestisce affidabilità, upgrade, scalabilità e sicurezza al posto tuo.
Questa pagina mostra come utilizzare l'API fleet per configurare Cloud Service Mesh gestito utilizzando le API Istio.
Prerequisiti
Come punto di partenza, questa guida presuppone che tu abbia:
- Un progetto Cloud
- Un account Cloud Billing
- Hai ottenuto le autorizzazioni richieste per eseguire il provisioning di Cloud Service Mesh
- Workload Identity attivo su cluster e pool di nodi.
Requisiti
- Uno o più cluster con una versione supportata di GKE, in una delle regioni supportate.
Tieni presente che Cloud Service Mesh gestito utilizza i canali di rilascio GKE per trovare il giusto equilibrio tra stabilità e velocità di upgrade. Le nuove modifiche ai componenti in-cluster di Cloud Service Mesh (inclusi CNI, MDPC, proxy e CRD Istio) verranno implementate per primi nei cluster che si iscrivono al canale GKE Rapid. Una volta dimostrata sufficiente stabilità, verranno promosse al canale GKE regolare e infine al canale GKE stabile.
- Cloud Service Mesh gestito non supporta la modifica sicura dei canali di rilascio GKE.
- Se modifichi il canale di rilascio GKE, Cloud Service Mesh esegue automaticamente l'upgrade/il downgrade dei componenti all'interno del cluster (CNI, MDPC, versione del proxy iniettata predefinita e CRD di Istio) in modo che siano in linea con l'attuale canale di rilascio GKE.
Assicurati che il cluster abbia una capacità sufficiente per i componenti richiesti che Cloud Service Mesh gestito installa nel cluster.
- Il deployment
mdp-controller
nel namespacekube-system
richiede cpu: 50m, memory: 128Mi. - Il daemonset
istio-cni-node
nello spazio dei nomikube-system
richiede cpu: 100m, memory: 100 Mi su ogni nodo.
- Il deployment
Assicurati che il criterio dell'organizzazione
constraints/compute.disableInternetNetworkEndpointGroup
sia disattivato. Se il criterio è attivato, ServiceEntry potrebbe non funzionare.Assicurati che il computer client da cui esegui il provisioning di Cloud Service Mesh gestito abbia connettività di rete al server API.
I cluster devono essere registrati a un parco risorse. Questa operazione è inclusa nelle istruzioni o può essere eseguita separatamente prima della provisioning.
Nel progetto deve essere abilitata la funzionalità del parco risorse Service Mesh. Questa operazione è inclusa nelle istruzioni o può essere eseguita separatamente.
GKE Autopilot è supportato solo con GKE versione 1.21.3 e successive.
Cloud Service Mesh può utilizzare più cluster GKE in un ambiente con una rete e un progetto oppure in un ambiente con più progetti e una rete.
- Se colleghi cluster che non si trovano nello stesso progetto, questi devono essere registrati allo stesso progetto host del parco risorse e devono essere configurati in un VPC condiviso sulla stessa rete.
- Per un ambiente multi-cluster con un solo progetto, il progetto del parco risorse può essere uguale al progetto del cluster. Per saperne di più sui parchi risorse, consulta la panoramica dei parchi risorse.
- Per un ambiente multi-progetto, ti consigliamo di ospitare il parco risorse in un progetto distinto dai progetti del cluster. Se i criteri della tua organizzazione e la configurazione esistente lo consentono, ti consigliamo di utilizzare il progetto VPC condiviso come progetto host del parco. Per ulteriori informazioni, consulta Configurare i cluster con VPC condiviso.
Ruoli richiesti per installare Cloud Service Mesh
La tabella seguente descrive i ruoli necessari per installare Cloud Service Mesh gestito.
Nome del ruolo | ID ruolo | Concedere l'accesso alla posizione | 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 | Può abilitare, disabilitare e analizzare gli stati dei servizi, analizzare le operazioni e utilizzare la quota e la fatturazione per un progetto consumer. (Nota 1) |
CA Service Admin 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 delle 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 i componenti all'interno del cluster.L'utilizzo del servizio di autorità di certificazione (CA) richiede la configurazione di Cloud Service Mesh per cluster e non è supportato se si utilizza la configurazione predefinita del parco risorse in GKE Enterprise.
Per i cluster GKE Autopilot, la configurazione tra progetti è supportata solo con GKE 1.23 o versioni successive.
Per i cluster GKE Autopilot, per adattarsi al limite di risorse di GKE Autopilot, le richieste e i limiti di risorse proxy predefiniti sono impostati su 500 m di CPU e 512 Mb di memoria. Puoi sostituire i valori predefiniti utilizzando l'inserimento personalizzato.
Durante la procedura di provisioning di un piano di controllo gestito, vengono eseguiti il provisioning delle risorse CRD di Istio nel cluster specificato. Se nel cluster sono presenti CRD Istio esistenti, verranno sovrascritte.
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
- Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Make sure that billing is enabled for your Google Cloud project.
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Make sure that billing is enabled for your Google Cloud project.
- 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, il
FLEET_PROJECT_ID viene creato per impostazione predefinita e ha lo stesso nome
del 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 Gestione funzionalità.
Nel riquadro Service Mesh, fai clic su Configura.
Esamina le impostazioni che vengono ereditate da tutti i nuovi cluster che crei nella console Google Cloud e registri 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 vuoi sincronizzare. Puoi selezionare solo i cluster su cui è installato Cloud Service Mesh.
- Fai clic su Sincronizza con le impostazioni del parco e poi su Conferma nella finestra di dialogo di conferma visualizzata. Il completamento dell'operazione può richiedere alcuni minuti.
Impostazioni a livello di parco risorse
Crea un file
mesh.yaml
contenente solo la singola rigamanagement: automatic
:echo "management: automatic" > mesh.yaml
Attiva Cloud Service Mesh per il tuo parco risorse:
gcloud container fleet mesh enable --project FLEET_PROJECT_ID \ --fleet-default-member-config mesh.yaml
Se viene visualizzato 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 rete è diverso dal progetto host del parco risorse (ad esempio se utilizzi un VPC condiviso), devi consentire agli account di servizio Cloud Service Mesh nel progetto del parco risorse di accedere al progetto della 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 per accedere al 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 i cluster da utilizzare con Cloud Service Mesh, creane e registrali in un unico passaggio con Google Cloud CLI per utilizzare la configurazione predefinita. Ad esempio:
gcloud container clusters create-auto CLUSTER_NAME \ --fleet-project FLEET_PROJECT_ID \ --location=LOCATION
Puoi ottenere il numero di progetto per il tuo progetto di flotta eseguendo il seguente comando:
gcloud projects list --filter="FLEET_PROJECT_ID" --format="value(PROJECT_ID)"
Il flag
--location
è la zona o la regione di calcolo (ad esempious-central1-a
ous-central1
) per il cluster.Se il progetto del cluster è diverso dal progetto host del parco risorse, devi consentire agli account di servizio Cloud Service Mesh nel progetto del parco risorse di accedere al progetto del cluster e attivare le API richieste nel progetto del cluster. Devi eseguire questa operazione solo una volta per ogni progetto cluster.
Concedi agli account di servizio nel progetto del parco risorse l'autorizzazione per accedere al progetto del 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 nel progetto del cluster:
gcloud services enable mesh.googleapis.com \ --project=CLUSTER_PROJECT_ID
Sostituisci CLUSTER_PROJECT_ID con l'identificatore univoco del progetto del tuo cluster. Se hai creato il cluster nello stesso progetto del parco risorse, CLUSTER_PROJECT_ID corrisponde a FLEET_PROJECT_ID.
Registra un cluster GKE utilizzando l'identità del carico di lavoro del parco risorse. Il flag
--location
è la zona di computing o la regione (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 del codice MEMBERSHIP_NAME, ti servirà quando attiverai la gestione automatica.
Se il progetto della rete del cluster è diverso dal progetto host del parco risorse (ad esempio, utilizzi un VPC condiviso), devi consentire agli account di servizio Cloud Service Mesh nel progetto del parco risorse di accedere al progetto della 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 per accedere al 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 agli account di servizio Cloud Service Mesh nel progetto del parco risorse di accedere al progetto del cluster e abilitare le API richieste nel progetto del cluster.
Devi eseguire questa operazione una sola volta per ogni progetto cluster. Se in precedenza hai configurato Cloud Service Mesh gestito per questa combinazione di progetti di cluster e parchi risorse, queste modifiche sono già state applicate e non devi eseguire i seguenti comandi.
Concedi agli account di servizio nel progetto del parco risorse l'autorizzazione per accedere al progetto del 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 nel progetto del cluster:
gcloud services enable mesh.googleapis.com \ --project=CLUSTER_PROJECT_ID
- MEMBERSHIP_NAME è il nome dell'appartenenza elencato quando hai verificato che il tuo cluster è stato registrato nel parco risorse.
MEMBERSHIP_LOCATION è la località del tuo abbonamento (una regione o
global
).Se di recente hai creato l'abbonamento utilizzando il comando in questa guida, dovrebbe essere la regione del tuo cluster. Se hai un cluster di zona, utilizza la regione corrispondente alla zona del cluster. Ad esempio, se hai un cluster in
us-central1-c
, utilizza il valoreus-central1
.Questo valore può essere
global
se hai effettuato la registrazione prima di maggio 2023 o se hai specificato la localitàglobal
durante la registrazione dell'abbonamento. Puoi controllare la posizione del tuo abbonamento congcloud container fleet memberships list --project FLEET_PROJECT_ID
.- Pod non iniettati
- Pod iniettati manualmente
- Job
- StatefulSet
- DaemonSet
Vai alla pagina Comunicazione.
Nella riga Upgrade di Cloud Service Mesh, nella colonna Email, seleziona il pulsante di opzione per attivare le notifiche di manutenzione ON.
- Applica l'etichetta di inserimento predefinita allo spazio dei nomi:
Esegui il comando seguente 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 riportato sopra sono presenti due revisioni del piano di controllo, rimuovine una. La presenza di più canali del control plane nel cluster non è supportata.
Nell'output, il valore nella colonna
NAME
è l'etichetta di revisione corrispondente 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
venga impostato prima dell'esecuzione dell'iniezione. Sebbene tu possa impostare un'immagine specifica per sostituire quella predefinita, ti consigliamo di impostareimage
suauto
, in modo che l'iniettore sidecar selezioni automaticamente l'immagine da utilizzare. - Alcuni campi in
containers
dipendono dalle impostazioni correlate. Ad esempio, deve essere inferiore o uguale al limite della CPU. Se entrambi i campi non sono configurati correttamente, l'avvio del pod potrebbe non riuscire. - Kubernetes ti consente di impostare sia
requests
chelimits
per le risorse nel tuospec
pod. GKE Autopilot prende in considerazione solorequests
. Per ulteriori informazioni, consulta Impostare i limiti di risorse in Autopilot. - Per GKE Standard, se è impostato
sidecar.istio.io/proxyCPU
, assicurati di impostare esplicitamentesidecar.istio.io/proxyCPULimit
. In caso contrario, il limite della CPU del sidecar 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 sidecar verrà impostato come illimitato. - Per GKE Autopilot, la configurazione delle risorse
requests
elimits
con le annotazioni potrebbe comportare un overprovisioning delle risorse. Utilizza l'approccio del modello di immagine per evitare. Consulta gli esempi di modifica delle risorse in Autopilot. - Sostituisci l'etichetta dello spazio dei nomi corrente. I passaggi dipendono dall'implementazione del piano di controllo.
- Applica l'etichetta di inserimento predefinita allo spazio dei nomi:
Esegui il comando seguente 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 riportato sopra sono presenti due revisioni del piano di controllo, rimuovine una. La presenza di più canali del control plane nel cluster non è supportata.
Nell'output, il valore nella colonna
NAME
è l'etichetta di revisione corrispondente 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 graduale 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 ciascun spazio dei nomi.
Se hai eseguito il deployment dell'applicazione in una configurazione multi-cluster, replica la configurazione di Kubernetes e Istio in tutti i cluster, a meno che non sia necessario limitare la configurazione solo a un sottoinsieme di cluster. La configurazione applicata a un determinato cluster è la fonte attendibile per quel cluster.
Aggiorna i workload da iniettare con la versione precedente del control plane. Nel seguente comando, il valore di revisione
asm-191-1
viene utilizzato solo come esempio. Sostituisci il valore di esempio con l'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 re-iniezione in modo che i proxy abbiano la versione precedente:
kubectl rollout restart deployment -n NAMESPACE
L'abilitazione di mesh.googleapis.com consente le seguenti API:
API | Finalità | Può essere disattivato |
---|---|---|
meshconfig.googleapis.com |
Cloud Service Mesh utilizza l'API Mesh Configuration per inoltrare i dati di configurazione dal tuo mesh a Google Cloud. Inoltre, l'attivazione dell'API Mesh Configuration ti consente di accedere alle pagine di Cloud Service Mesh nella console Google Cloud e di utilizzare la CA di Cloud Service Mesh. | No |
meshca.googleapis.com |
Relativa all'autorità di certificazione Cloud Service Mesh utilizzata da Cloud Service Mesh gestito. | No |
container.googleapis.com |
Obbligatorio per creare cluster Google Kubernetes Engine (GKE). | No |
gkehub.googleapis.com |
Obbligatorio per gestire la mesh come parco risorse. | No |
monitoring.googleapis.com |
Obbligatorio per acquisire la telemetria per i carichi di lavoro mesh. | No |
stackdriver.googleapis.com |
Obbligatorio per utilizzare l'interfaccia utente dei servizi. | No |
opsconfigmonitoring.googleapis.com |
Obbligatorio per utilizzare l'interfaccia utente dei servizi per i cluster al di fuori di Google Cloud. | No |
connectgateway.googleapis.com |
Obbligatorio affinché il control plane di Cloud Service Mesh gestito possa accedere ai carichi di lavoro di mesh. | Sì* |
trafficdirector.googleapis.com |
Consente un piano di controllo gestito altamente disponibile e scalabile. | Sì* |
networkservices.googleapis.com |
Consente un piano di controllo gestito altamente disponibile e scalabile. | Sì* |
networksecurity.googleapis.com |
Consente un piano di controllo gestito altamente disponibile e scalabile. | Sì* |
Configurare Cloud Service Mesh gestito
I passaggi necessari per eseguire il provisioning di Cloud Service Mesh gestito utilizzando l'API Fleet dipendono dal fatto che tu preferisca attivarlo per impostazione predefinita per i nuovi cluster di parchi risorse o per ogni cluster.
Configurazione per il tuo parco risorse
Se hai abilitato la versione Enterprise di Google Kubernetes Engine (GKE), puoi attivare Cloud Service Mesh gestito come configurazione predefinita per il tuo parco risorse. Ciò significa che su ogni nuovo cluster GKE su Google Cloud registrato durante la creazione del cluster sarà abilitato Cloud Service Mesh gestito. Puoi scoprire di più sulla configurazione predefinita del parco risorse in Gestire le funzionalità a livello di parco risorse.
L'abilitazione di Cloud Service Mesh gestito come configurazione predefinita per il parco risorse e la registrazione dei cluster al parco risorse durante la creazione del cluster supporta solo Mesh CA. Se vuoi utilizzare Certificate Authority Service, ti consigliamo di attivarlo per cluster.
Per attivare i valori predefiniti a livello di parco risorse per Cloud Service Mesh gestito, completa i seguenti passaggi:
Console
gcloud
Per configurare i valori predefiniti a livello di parco risorse utilizzando Google Cloud CLI, devi impostare le seguenti impostazioni:
Procedi con la verifica del provisioning del piano di controllo.
Configura per cluster
Per configurare Cloud Service Mesh gestito per ogni singolo cluster nel tuo mesh, segui i passaggi che seguono.
Attivare la funzionalità del parco risorse Cloud Service Mesh
Abilita Cloud Service Mesh nel progetto del parco risorse. Tieni presente che se prevedi di registrare più cluster, l'attivazione di Cloud Service Mesh avviene a livello di parco risorse, quindi devi eseguire questo comando una sola volta.
gcloud container fleet mesh enable --project FLEET_PROJECT_ID
Registra i cluster in un parco risorse
(Facoltativo) Configura Certificate Authority Service
Se il deployment del tuo mesh di servizi richiede Certificate Authority Service (CA Service), segui la procedura descritta in Configurare Certificate Authority Service per Cloud Service Mesh gestito per attivarlo per il tuo parco risorse. Assicurati di completare tutti i passaggi prima di procedere alla sezione successiva.
Attiva la gestione automatica
Esegui il comando seguente 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 alcuni minuti, verifica che lo stato del piano di controllo sia ACTIVE
:
gcloud container fleet mesh describe --project FLEET_PROJECT_ID
L'output è simile al seguente:
...
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 la sezione Funzionalità supportate di Cloud Service Mesh per informazioni sulle differenze del piano di controllo e sulle configurazioni supportate, nonché su come viene selezionata l'implementazione del piano di controllo.
Configura kubectl
in modo che punti al cluster
Le sezioni seguenti richiedono l'esecuzione di comandi kubectl
su ciascuno dei tuoi cluster. Prima di procedere con le sezioni seguenti, esegui il seguente comando per ciascun cluster per configurare kubectl
in modo che punti al cluster.
gcloud container clusters get-credentials CLUSTER_NAME \
--location CLUSTER_LOCATION \
--project CLUSTER_PROJECT_ID
Tieni presente che un gateway di ingresso non viene implementato automaticamente con il piano di controllo. Il disaccoppiamento del deployment del gateway in entrata e del piano di controllo consente di gestire i gateway in un ambiente di produzione. Se vuoi utilizzare un gateway di ingresso o di uscita Istio, consulta Eseguire il deployment dei gateway. Se vuoi utilizzare l'API Kubernetes Gateway, consulta Preparare il gateway per il mesh. Per attivare altre funzionalità facoltative, consulta Attivare le funzionalità facoltative su Cloud Service Mesh.
Piano dati gestito
Se utilizzi Cloud Service Mesh gestito, Google gestisce completamente gli upgrade dei proxy.
Con la funzionalità del piano di dati gestito abilitata, i proxy sidecar e i gateway iniettati vengono aggiornati attivamente e automaticamente in combinazione con il piano di controllo gestito riavviando i carichi di lavoro per iniettare nuovamente nuove versioni del proxy. Questo processo inizia dopo l'upgrade del piano di controllo e di solito viene completato entro due settimane dall'avvio.
Tieni presente che il piano dati gestito si basa sul canale di release GKE. Se modifichi il canale di rilascio di GKE mentre il piano dati gestito è abilitato, Cloud Service Mesh gestito aggiornerà i proxy di tutti i carichi di lavoro esistenti, ad esempio un'implementazione del piano dati gestito.
Se l'opzione è disattivata, la gestione dei proxy avviene in modo passivo, in base al ciclo di vita naturale dei pod nel cluster e deve essere attivata manualmente dall'utente per controllare la frequenza di aggiornamento.
Il piano di dati gestito esegue l'upgrade dei proxy espellendo i pod che eseguono versioni precedenti del proxy. Gli espulsioni vengono eseguite gradualmente, rispettando il budget per le interruzioni dei pod e controllando la frequenza delle modifiche.
Il piano dati gestito non gestisce quanto segue:
(Facoltativo) Disattiva il piano di 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 namespace o pod. Il piano dati gestito continuerà a essere disattivato per i cluster esistenti in cui è stato disattivato per impostazione predefinita o manualmente.
Per disattivare il piano dati gestito a livello di cluster e tornare alla gestione autonoma dei proxy sidecar, modifica l'annotazione:
kubectl annotate --overwrite controlplanerevision -n istio-system \
mesh.cloud.google.com/proxy='{"managed":"false"}'
Per disattivare il piano di dati gestito per uno spazio dei nomi:
kubectl annotate --overwrite namespace NAMESPACE \
mesh.cloud.google.com/proxy='{"managed":"false"}'
Per disattivare il piano di 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 una notifica relativa alla manutenzione imminente del piano di dati gestito fino a una settimana prima della pianificazione della manutenzione. Le notifiche relative alla manutenzione non vengono inviate per impostazione predefinita. Inoltre, devi configurare una finestra di manutenzione GKE prima di poter ricevere le notifiche. Se questa opzione è attivata, le notifiche vengono inviate almeno due giorni prima dell'operazione di upgrade.
Per attivare le notifiche relative alla manutenzione del piano di dati gestito:
Ogni utente che vuole ricevere notifiche deve attivarle separatamente. Se vuoi 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 notifica di manutenzione del piano di dati gestito:
Oggetto: Upgrade imminente per il cluster Cloud Service Mesh "
<location/cluster-name>
"Gentile utente di Cloud Service Mesh,
L'upgrade dei componenti di Cloud Service Mesh nel tuo cluster ${instance_id} (https://console.cloud.google.com/kubernetes/clusters/details/${instance_id}/details?project=${project_id}) è pianificato per il giorno ${scheduled_date_human_readable} alle ore ${scheduled_time_human_readable}.
Per informazioni sul nuovo aggiornamento, consulta le note di rilascio (https://cloud.google.com/service-mesh/docs/release-notes).
Se questo intervento di manutenzione verrà annullato, riceverai un'altra email.
Cordiali saluti,
Il team di Cloud Service Mesh
(c) 2023 Google LLC 1600 Amphitheater Parkway, Mountain View, CA 94043, USA Ti abbiamo inviato questa comunicazione per informarti di importanti cambiamenti che riguardano Google Cloud Platform o il tuo account. Puoi disattivare le notifiche relative al periodo di manutenzione modificando le tue preferenze utente: https://console.cloud.google.com/user-preferences/communication?project=${project_id}
Configura il rilevamento degli endpoint (solo per le installazioni su più cluster)
Se il tuo mesh ha un solo cluster, salta questi passaggi per più cluster e vai a Eseguire il deployment delle applicazioni o Eseguire la migrazione delle applicazioni.
Prima di continuare, assicurati che Cloud Service Mesh sia configurato su ogni cluster.
L'abilitazione di Cloud Service Mesh con l'API Fleet abiliterà il rilevamento degli endpoint per questo cluster. Tuttavia, devi aprire le porte del firewall. Per disattivare il rilevamento degli endpoint per uno o più cluster, consulta le istruzioni per disattivarlo in Rilevamento degli endpoint tra i cluster con API declarative.
Per un'applicazione di esempio con due cluster, consulta Esempio di servizio HelloWorld.
Esegue il deployment delle applicazioni
Se hai più di un cluster nel parco risorse che utilizza Cloud Service Mesh gestito, assicurati che la rilevamento degli endpoint o le porte del firewall siano configurate come previsto prima di procedere ed eseguire il deployment delle applicazioni.Attiva lo spazio dei nomi per l'iniezione. 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 il seguente comando per applicare l'etichetta di inserimento predefinita allo spazio dei nomi:
kubectl label namespace NAMESPACE \
istio.io/rev- istio-injection=enabled --overwrite
Se sei già un utente con il piano di controllo Istiod gestito: consigliamo di utilizzare l'iniezione predefinita, ma è supportata anche l'iniezione basata su revisione. Segui le istruzioni riportate di seguito:
Verifica che l'etichetta dello spazio dei nomi sia applicata correttamente utilizzando il seguente comando.
kubectl get namespace -L istio-injection
Output di esempio:
NAME STATUS AGE ISTIO-INJECTION
default Active 5m9s enabled
A questo punto, hai configurato Cloud Service Mesh gestito. Se hai carichi di lavoro esistenti negli spazi dei nomi etichettati, riavviali in modo che i proxy vengano iniettati.
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 non prevedi di limitare questa particolare configurazione a un sottoinsieme di cluster. La configurazione applicata a un determinato cluster è la fonte attendibile per quel cluster.
Personalizza l'iniezione (facoltativo)
Puoi eseguire l'override dei valori predefiniti e personalizzare le impostazioni di inserimento, ma questo può portare a errori di configurazione imprevisti e conseguenti problemi con i contenitori sidecar. Prima di personalizzare l'iniezione, leggi le informazioni riportate dopo il sample per trovare note su impostazioni e consigli specifici.
La configurazione per pod è disponibile per eseguire l'override di queste opzioni sui singoli pod.
Aggiungi un contenitore istio-proxy
al pod. L'iniezione sidecar considererà qualsiasi configurazione definita qui come una sostituzione del modello di iniezione predefinito.
Ad esempio, la seguente configurazione personalizza una serie di impostazioni, tra cui la riduzione delle richieste di CPU, l'aggiunta di un montaggio del volume e l'aggiunta di un 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 in un pod. Tuttavia, è necessario prestare attenzione per alcuni campi:
Inoltre, alcuni campi sono configurabili tramite annotazioni nel pod, anche se è consigliabile utilizzare l'approccio sopra indicato per personalizzare le impostazioni. Presta particolare attenzione alle seguenti annotazioni:
Ad esempio, consulta l'annotazione delle risorse riportata di seguito:
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 all'interno del cluster a Cloud Service Mesh gestito, esegui i seguenti passaggi:
Gestito (TD)
kubectl label namespace NAMESPACE \
istio.io/rev- istio-injection=enabled --overwrite
Gestito (Istiod)
Consigliato:esegui il seguente comando per applicare l'etichetta di inserimento predefinita allo spazio dei nomi:
kubectl label namespace NAMESPACE \
istio.io/rev- istio-injection=enabled --overwrite
Se sei già un utente con il piano di controllo Istiod gestito: consigliamo di utilizzare l'iniezione predefinita, ma è supportata anche l'iniezione basata su revisione. Segui le istruzioni riportate di seguito:
Se ritieni che la tua applicazione funzioni come previsto, puoi rimuovere istiod
nel cluster dopo aver impostato tutti gli spazi dei nomi nel piano di controllo gestito o conservarli come backup. istiod
verrà fare lo scale down automaticamente per utilizzare meno risorse. Per rimuoverlo, vai a
Eliminare il vecchio piano di controllo.
Se riscontri problemi, puoi identificarli e risolverli utilizzando le informazioni riportate nell'articolo Risolvere i problemi del piano di controllo gestito e, se necessario, eseguendo il rollback alla versione precedente.
Eliminare il vecchio piano di controllo
Dopo aver installato e verificato che tutti gli spazi dei nomi utilizzino il piano di controllo gestito da Google, puoi eliminare il vecchio piano di controllo.
kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod -n istio-system --ignore-not-found=true
Se hai utilizzato istioctl kube-inject
anziché l'iniezione automatica o se hai installato gateway aggiuntivi, controlla le metriche per il piano di controllo e verifica che il numero di endpoint connessi sia pari a zero.
Rollback
Se devi eseguire il rollback alla versione precedente del piano di controllo, svolgi i seguenti passaggi:
Il piano di controllo gestito si ridurrà automaticamente a zero e non utilizzerà alcuna risorsa quando non è in uso. I webhook e il provisioning con mutazioni rimarranno e non influiscono sul comportamento del cluster.
Il gateway è ora impostato sulla revisione asm-managed
. Per eseguire il rollback, esegui nuovamente il comando di installazione di Cloud Service Mesh, che eseguirà nuovamente il deployment del gateway che rimanda al tuo piano di controllo in cluster:
kubectl -n istio-system rollout undo deploy istio-ingressgateway
In caso di esito positivo, dovresti visualizzare questo output:
deployment.apps/istio-ingressgateway rolled back
Disinstalla Cloud Service Mesh
Il control plane gestito si ridimensiona automaticamente a zero quando non viene utilizzato da nessun namespace. Per la procedura dettagliata, vedi Disinstallare Cloud Service Mesh.