Panoramica
Anthos Service Mesh gestito è un mesh di servizi gestito da Google che devi solo abilitare. Google gestisce affidabilità, upgrade, scalabilità e sicurezza per te in modo compatibile con le versioni precedenti.
Questa pagina mostra come utilizzare l'API della funzionalità del parco risorse per configurare Anthos Service Mesh gestito.
Quando abiliti Anthos Service Mesh gestito utilizzando l'API del parco risorse:
- Google applica la configurazione del piano di controllo consigliata
- Google consente la gestione automatica del piano dati
- Il cluster è registrato in un canale di rilascio Anthos Service Mesh basato sul canale di rilascio del cluster Google Kubernetes Engine (GKE). Inoltre, il piano di controllo e il piano dati vengono mantenuti aggiornati a ogni nuova release.
- Google consente il rilevamento degli endpoint e il bilanciamento del carico tra cluster in tutto il mesh di servizi con impostazioni predefinite, anche se è necessario creare regole firewall.
Utilizza questo percorso di onboarding se vuoi:
- Per utilizzare
gcloud
per configurare Anthos Service Mesh gestito utilizzando le API e IAM di Google Cloud. - Per configurare Anthos Service Mesh utilizzando le stesse API delle altre funzionalità del parco risorse.
- Per ottenere automaticamente la configurazione consigliata di Anthos Service Mesh per ciascuno dei tuoi cluster.
Prerequisiti
Per iniziare, questa guida presuppone che tu abbia:
- Un progetto Cloud
- Un account di fatturazione Cloud
- Ottime autorizzazioni richieste per il provisioning di Anthos Service Mesh gestito
- Abilitazione di Workload Identity sui tuoi cluster.
Requisiti
- Uno o più cluster con una versione supportata di GKE, in una delle aree geografiche supportate.
- Assicurati che il cluster abbia capacità sufficiente per i componenti richiesti
che hanno gestito Anthos Service Mesh nel cluster.
- Il deployment
mdp-controller
nello spazio dei nomikube-system
richiede una CPU: 50 m, memoria: 128 Mi. - Il daemonset
istio-cni-node
nello spazio dei nomikube-system
richiede una CPU: 100 m, memoria: 100 Mi su ciascun nodo.
- Il deployment
- Assicurati che il computer client da cui esegui il provisioning di Anthos Service Mesh gestito disponga di una 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 provisioning.
- Nel progetto deve essere abilitata la funzionalità del parco risorse mesh di servizi. Questa operazione è inclusa nelle istruzioni o può essere eseguita separatamente.
GKE Autopilot è supportato solo con GKE versione 1.21.3 e successive. CNI verrà installato e gestito da Google.
Anthos Service Mesh gestito può utilizzare più cluster GKE in un ambiente con rete singola o in un ambiente multiprogetto.
- Se unisci cluster che non si trovano nello stesso progetto, devono essere registrati nello stesso progetto host del parco risorse e i cluster devono trovarsi insieme in una configurazione di VPC condiviso sulla stessa rete.
- Per un ambiente multi-cluster a progetto singolo, il progetto del parco risorse può essere uguale al progetto di cluster. Per ulteriori informazioni sui parchi risorse, consulta la panoramica sui parchi risorse.
- Per un ambiente con più progetti, ti consigliamo di ospitare il parco risorse in un progetto separato dai progetti del cluster. Se i criteri dell'organizzazione e la configurazione esistente lo consentono, ti consigliamo di utilizzare il progetto VPC condiviso come progetto host del parco risorse. Per ulteriori informazioni, consulta Configurazione dei cluster con VPC condiviso.
Limitazioni
Ti consigliamo di esaminare l'elenco delle funzionalità e limitazioni supportate per Anthos Service Mesh gestiti. In particolare, tieni presente quanto segue:
L'API
IstioOperator
non è supportata poiché il suo scopo principale è controllare i componenti nel cluster.L'abilitazione di Anthos Service Mesh gestito con l'API del parco risorse utilizzerà Mesh CA. Se il deployment mesh di servizi comporta carichi di lavoro regolamentati o richiede Certificate Authority Service (CA Service), segui le istruzioni riportate in Provisioning di Anthos Service Mesh gestito utilizzando
asmcli
.Le migrazioni da Anthos Service Mesh gestito con
asmcli
a Anthos Service Mesh con API del parco risorse non sono supportate. Allo stesso modo, la configurazione di Anthos Service Mesh gestito con l'API del parco risorse da--management manual
a--management automatic
non è supportata.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 delle risorse di GKE Autopilot, i limiti e le richieste di risorse proxy predefiniti sono impostati su 500 m di CPU e 512 Mb di memoria. Puoi eseguire l'override dei valori predefiniti utilizzando l'inserimento personalizzato.
Le funzionalità effettive disponibili per Anthos Service Mesh gestito dipendono dal canale di rilascio. Per ulteriori informazioni, consulta l'elenco completo delle funzionalità e limitazioni supportate per Anthos Service Mesh gestiti.
Durante il processo di provisioning per un piano di controllo gestito, viene eseguito il provisioning dei CRD Istio corrispondenti al canale selezionato nel cluster specificato. Se nel cluster sono già presenti CRD Istio, verranno sovrascritti.
Istio CNI non è compatibile con GKE Sandbox. Anthos Service Mesh gestito su Autopilot, quindi, non funziona con GKE Sandbox, poiché è richiesto il CNI di Istio gestito.
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.
-
Nella console di Google Cloud Console, nella pagina del selettore dei progetti, seleziona o crea un progetto Google Cloud.
-
Assicurati che la fatturazione sia attivata per il tuo progetto Google Cloud.
-
Nella console di Google Cloud Console, nella pagina del selettore dei progetti, seleziona o crea un progetto Google Cloud.
-
Assicurati che la fatturazione sia attivata per il tuo progetto Google Cloud.
-
Abilita le API richieste nel progetto host del parco risorse.
gcloud services enable mesh.googleapis.com \ --project=FLEET_PROJECT_ID
dove:
- FLEET_PROJECT_ID è l'ID del tuo progetto Fleet Host.
L'abilitazione di mesh.googleapis.com abilita le API seguenti:
API | Finalità | Disabilitabile |
---|---|---|
meshconfig.googleapis.com |
Anthos Service Mesh utilizza l'API Mesh Configuration per inoltrare i dati di configurazione dal mesh a Google Cloud. Inoltre, l'attivazione dell'API Mesh Configuration consente di accedere alle pagine Anthos Service Mesh nella console Google Cloud e di utilizzare l'autorità di certificazione Anthos Service Mesh (Mesh CA). | No |
meshca.googleapis.com |
Correlato all'autorità di certificazione Anthos Service Mesh utilizzata da Anthos Service Mesh gestito. | No |
container.googleapis.com |
Necessaria per creare cluster Google Kubernetes Engine (GKE). | No |
gkehub.googleapis.com |
Necessaria per gestire il mesh come un flotta. | No |
monitoring.googleapis.com |
Necessaria per acquisire la telemetria per i carichi di lavoro mesh. | No |
stackdriver.googleapis.com |
Necessaria per utilizzare l'UI dei servizi. | No |
opsconfigmonitoring.googleapis.com |
Necessaria per utilizzare la UI dei servizi per i cluster esterni a Google Cloud. | No |
connectgateway.googleapis.com |
Necessario per consentire al piano di controllo Anthos Service Mesh gestito di 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 gcloud
Segui questi passaggi anche se utilizzi Cloud Shell.
Autenticazione con Google Cloud CLI:
gcloud auth login --project FLEET_PROJECT_ID
Aggiorna i componenti:
gcloud components update
Configurazione di Anthos Service Mesh gestito
I passaggi necessari per eseguire il provisioning di Anthos Service Mesh gestito utilizzando l'API del parco risorse dipendono dal fatto che tu preferisca abilitare questa funzionalità per impostazione predefinita per i nuovi cluster del parco risorse o abilitarla per cluster.
Configura per il tuo parco risorse
Se hai abilitato Google Kubernetes Engine (GKE) Enterprise Edition, puoi abilitare Anthos Service Mesh gestito come configurazione predefinita del parco risorse. Ciò significa che per ogni nuovo cluster GKE su Google Cloud registrato durante la creazione del cluster sarà abilitato Anthos Service Mesh gestito sul cluster. Puoi scoprire di più sulla configurazione predefinita del parco risorse in Gestire le funzionalità a livello di parco risorse.
Per configurare Anthos Service Mesh gestito per il tuo parco risorse, devi definire le seguenti impostazioni:
Impostazioni a livello di parco risorse
Crea un file
mesh.yaml
contenente solo la singola rigamanagement: automatic
:echo "management: automatic" > mesh.yaml
Abilita Anthos Service Mesh per il tuo parco risorse:
gcloud container fleet mesh enable --project FLEET_PROJECT_ID \ --fleet-default-member-config mesh.yaml
Impostazioni a livello di cluster
Quando è tutto pronto per creare cluster da utilizzare con Anthos Service Mesh, creali e registrali in un unico passaggio con Google Cloud CLI per utilizzare la configurazione predefinita. Inoltre, assicurati che il cluster appena creato e registrato abbia l'etichetta
mesh_id
. Ad esempio:gcloud container clusters create CLUSTER_NAME \ --fleet-project FLEET_PROJECT_ID \ --labels="mesh_id=proj-FLEET_PROJECT_NUMBER"
Puoi ottenere il numero di progetto per il tuo progetto del parco risorse eseguendo questo comando:
gcloud projects list --filter="FLEET_PROJECT_ID" --format="value(PROJECT_ID)" ```
Se il progetto del cluster è diverso dal progetto host del parco risorse, devi consentire agli account di servizio Anthos 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 di cluster.
Concedi agli account di servizio nel progetto del parco risorse l'autorizzazione per accedere al 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 nel progetto del cluster:
gcloud services enable mesh.googleapis.com \ --project=CLUSTER_PROJECT_ID
dove:
- CLUSTER_PROJECT_ID è l'identificatore univoco del progetto del cluster.
Procedi con la verifica dell'esecuzione del provisioning del piano di controllo.
Configura per cluster
Segui questi passaggi per configurare Anthos Service Mesh gestito per ogni cluster nel tuo mesh individualmente.
Attiva la funzionalità del parco risorse Anthos Service Mesh
Abilita Anthos Service Mesh nel progetto del parco risorse. Tieni presente che se prevedi di registrare più cluster, l'attivazione di Anthos 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
Registra un cluster GKE utilizzando Identity dei carichi di lavoro del parco risorse. Utilizza
--region
anziché--zone
, se il cluster è a livello di regione.gcloud container clusters update CLUSTER_NAME \ --zone 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 MEMBERSHIP_NAME, poiché ti servirà quando attivi la gestione automatica.
Se il progetto del cluster è diverso da quello dell'host del parco risorse, devi consentire agli account di servizio Anthos 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 solo una volta per ogni progetto di cluster.
Se in precedenza hai utilizzato
asmcli
per configurare Anthos Service Mesh gestito per questa combinazione di progetti di cluster e parco risorse, le modifiche sono già state applicate e non è necessario 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
Applica l'etichetta mesh_id
Per utilizzare le dashboard di Anthos Service Mesh, devi applicare un'etichetta mesh_id
ai cluster nel tuo parco risorse. Il comando dipende dal tipo di cluster, a livello di zona o di regione.
Cluster di zona
gcloud container clusters update CLUSTER_NAME --project CLUSTER_PROJECT_ID \
--zone CLUSTER_LOCATION --update-labels mesh_id=proj-FLEET_PROJECT_NUMBER
Cluster a livello di regione
gcloud container clusters update CLUSTER_NAME --project CLUSTER_PROJECT_ID \
--region CLUSTER_LOCATION --update-labels mesh_id=proj-FLEET_PROJECT_NUMBER
dove:
- CLUSTER_NAME è il nome del tuo cluster.
- CLUSTER_LOCATION è la zona o la regione di computing del tuo cluster.
- FLEET_PROJECT_NUMBER è il numero di progetto per il progetto host del parco risorse.
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:
- MEMBERSHIP_NAME è il nome dell'appartenenza elencato quando hai verificato che il cluster è stato registrato nel parco risorse.
MEMBERSHIP_LOCATION è la località in cui hai sottoscritto l'abbonamento (una regione o
global
).Se hai creato l'appartenenza di recente utilizzando il comando in questa guida, questa dovrebbe essere la regione del tuo cluster. Se hai un cluster di zona, utilizza l'area geografica corrispondente alla zona del cluster. Ad esempio, se disponi di un cluster di zona 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
al momento della registrazione dell'abbonamento. Puoi verificare la località del tuo abbonamento congcloud container fleet memberships list --project FLEET_PROJECT_ID
.
Verificare 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 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
dataPlaneManagement:
details:
- code: OK
details: Service is running.
state: ACTIVE
state:
code: OK
description: 'Revision(s) ready for use: asm-managed.'
...
Prendi nota dell'etichetta di revisione nel campo details
, ad esempio asm-managed
, nell'output fornito. Se utilizzi etichette di revisione, devi impostarla prima di eseguire il deployment delle applicazioni. Se utilizzi etichette di iniezione predefinite, non è necessario impostare questa etichetta.
Configura kubectl
in modo che rimandi al cluster
Le seguenti sezioni prevedono l'esecuzione dei comandi kubectl
su ciascuno dei tuoi cluster. Prima di procedere con le sezioni seguenti, esegui questo comando per ciascuno dei tuoi cluster per configurare kubectl
in modo che rimandi al cluster. Utilizza --region
anziché --zone
, se il cluster è a livello di regione.
gcloud container clusters get-credentials CLUSTER_NAME \
--zone CLUSTER_LOCATION \
--project CLUSTER_PROJECT_ID
Tieni presente che il deployment di un gateway in entrata non viene eseguito automaticamente con il piano di controllo. La 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 Eseguire il deployment dei gateway. Per abilitare altre funzionalità facoltative, consulta Abilitazione di funzionalità facoltative su Anthos Service Mesh gestito.
Piano dati gestito
Se utilizzi Anthos Service Mesh gestito, Google gestisce completamente gli upgrade dei proxy a meno che non li disattivi a livello di spazio dei nomi, carico di lavoro o revisione. Si applica solo ai nuovi cluster. Nei cluster esistenti potrebbe non essere abilitato il piano dati gestito.
Con il piano dati gestito, i proxy sidecar e i gateway inseriti vengono aggiornati automaticamente in combinazione con il piano di controllo gestito, riavviando i carichi di lavoro per reinserire nuove versioni del proxy. Questa operazione in genere viene completata 1-2 settimane dopo l'upgrade del piano di controllo gestito.
Se disabilitata, la gestione dei proxy dipende dal ciclo di vita naturale dei pod nel cluster e deve essere attivata manualmente dall'utente per controllare la frequenza di aggiornamento.
Il piano dati gestito esegue l'upgrade dei proxy rimuovendo i pod che eseguono versioni precedenti del proxy. Le eliminazioni vengono eseguite gradualmente, rispettando il budget per l'interruzione dei pod e controllando la frequenza di modifica.
Tieni presente che il piano dati gestito richiede il plug-in CNN (Container Network Interface) Istio, che viene abilitato per impostazione predefinita quando esegui il deployment del piano di controllo gestito.
Il piano dati gestito non gestisce quanto segue:
- Pod non inseriti
- Pod inseriti manualmente
- Job
- StatefulSets
- DaemonSets
(Facoltativo) Disabilitare il piano dati gestito
Se esegui il provisioning di Anthos Service Mesh gestito su un nuovo cluster, puoi disabilitare 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 era stato disabilitato per impostazione predefinita o manualmente.
Per disabilitare 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 \
REVISION_LABEL \
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 sulla manutenzione imminente del piano dati gestito fino a una settimana prima della pianificazione della manutenzione. Le notifiche di manutenzione non vengono inviate per impostazione predefinita. Devi anche configurare un periodo di manutenzione di GKE prima di poter ricevere le notifiche.
Per attivare le notifiche di manutenzione del piano dati gestito:
Vai alla pagina Comunicazione.
Nella riga Anthos Service Mesh Upgrade, nella colonna Email, seleziona il pulsante di opzione per attivare le notifiche di manutenzione.
Ogni utente che vuole ricevere le notifiche deve attivarla separatamente. Se vuoi impostare un filtro email per queste notifiche, la riga dell'oggetto è:
Upcoming upgrade for your Anthos Service Mesh cluster "CLUSTER_LOCATION/CLUSTER_NAME"
.
L'esempio seguente mostra una tipica notifica di manutenzione del piano dati gestito:
Oggetto: Upgrade imminente per il cluster ASM "
<location/cluster-name>
"Gentile utente di Anthos Service Mesh,
L'upgrade dei componenti Anthos Service Mesh nel tuo cluster ${instance_id} (https://console.cloud.google.com/kubernetes/clusters/details/${instance_id}/details?project=${project_id}) è pianificato per l'upgrade il giorno ${scheduled_date_human_read} alle ore ${scheduled_time_human_READ}.
Puoi consultare le note di rilascio (https://cloud.google.com/service-mesh/docs/release-notes) per scoprire di più sul nuovo aggiornamento.
Nel caso in cui questa manutenzione venga annullata, riceverai un'altra email.
Cordiali saluti,
Il team di Anthos Service Mesh
(c) 2022 Google LLC 1600 Amphitheatre Parkway, Mountain View, CA 94043, USA Ti abbiamo inviato questo annuncio per informarti di importanti cambiamenti che interessano 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}
Configurare il rilevamento degli endpoint (solo per le installazioni multi-cluster)
Prima di continuare, dovresti aver già configurato Anthos Service Mesh gestito su ogni cluster come descritto nei passaggi precedenti. Non è necessario indicare che un cluster è primario, questo è il comportamento predefinito.
Inoltre, assicurati di aver scaricato asmcli
(solo se vuoi verificare la configurazione con l'applicazione di esempio) e di impostare le variabili di progetto e cluster.
Cluster pubblici
Configura il rilevamento degli endpoint tra cluster pubblici
L'abilitazione di Anthos Service Mesh gestito con l'API del parco risorse abilita il rilevamento degli endpoint per questo cluster. Tuttavia, devi aprire le porte firewall. Per disabilitare il rilevamento degli endpoint per uno o più cluster, consulta le istruzioni per disabilitarlo in Individuazione degli endpoint tra cluster pubblici con API dichiarativa.
Cluster privati
Configura il rilevamento degli endpoint tra cluster privati
L'abilitazione di Anthos Service Mesh gestito con l'API del parco risorse abilita il rilevamento degli endpoint per questo cluster. Tuttavia, devi aprire le porte firewall. Per disabilitare il rilevamento degli endpoint per uno o più cluster, consulta le istruzioni per disabilitarlo in Rilevamento degli endpoint tra cluster privati con API dichiarativa.
Per un'applicazione di esempio con due cluster, vedi Esempio di servizio HelloWorld.
Esegue il deployment delle applicazioni
Se hai più di un cluster nel parco risorse che utilizza Anthos Service Mesh gestito, assicurati che le porte di rilevamento degli endpoint o firewall siano configurate come previsto prima di procedere ed eseguire il deployment delle applicazioni.Per eseguire il deployment delle applicazioni, utilizza l'etichetta corrispondente al canale configurato durante l'installazione oppure istio-injection=enabled
se utilizzi etichette di inserimento predefinite.
Etichetta di iniezione predefinita
kubectl label namespace NAMESPACE istio-injection=enabled istio.io/rev- --overwrite
Etichetta revisione
Prima di eseguire il deployment delle applicazioni, rimuovi eventuali etichette istio-injection
precedenti dagli spazi dei nomi e imposta l'etichetta istio.io/rev=REVISION_LABEL
.
Questa è l'etichetta di revisione che hai identificato quando hai verificato il piano di controllo.
Per sostituirla con un'etichetta di revisione specifica, fai clic su REVISION_LABEL
e sostituiscila con l'etichetta applicabile: asm-managed-rapid
per Rapida, asm-managed
per
Regolare o asm-managed-stable
per Stabile.
L'etichetta di revisione corrisponde a un canale di rilascio:
Etichetta revisione | Canale |
---|---|
asm-managed |
Normale |
asm-managed-rapid |
Rapida |
asm-managed-stable |
Stabile |
kubectl label namespace NAMESPACE istio-injection- istio.io/rev=REVISION_LABEL --overwrite
A questo punto, hai configurato correttamente Anthos Service Mesh gestito. Se disponi di carichi di lavoro esistenti in spazi dei nomi etichettati, riavviali in modo che vengano inseriti i proxy.
Ora puoi eseguire il deployment delle tue applicazioni oppure puoi eseguire il deployment dell'applicazione di esempio Bookinfo.
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 tu non intenda limitare quella particolare configurazione a un sottoinsieme di cluster. La configurazione applicata a un particolare cluster rappresenta la fonte attendibile per il cluster.
Personalizza l'inserimento (facoltativo)
È 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. L'inserimento collaterale
tratterà qualsiasi configurazione qui definita come un override del
modello di inserimento 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"
limites:
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, devi prestare attenzione a determinati campi:
- Kubernetes richiede che il campo
image
sia impostato prima dell'esecuzione dell'iniezione. Sebbene sia possibile impostare un'immagine specifica per sostituire quella predefinita, ti consigliamo di impostareimage
suauto
; in questo modo, l'iniettore sidecar selezionerà automaticamente l'immagine da utilizzare. - Alcuni campi in
containers
dipendono dalle impostazioni correlate. Ad esempio, la richiesta di CPU deve essere inferiore al limite di CPU. Se entrambi i campi non sono configurati correttamente, il pod potrebbe non essere avviato. - Kubernetes consente di impostare sia
requests
chelimits
per le risorse inPodSpec
. GKE Autopilot prende in considerazione solorequests
. Per ulteriori informazioni, consulta Impostare i limiti delle risorse in Autopilot.
Inoltre, alcuni campi sono configurabili tramite annotazioni sul pod, anche se consigliamo di utilizzare l'approccio precedente per la personalizzazione delle impostazioni. Presta particolare attenzione a determinate annotazioni:
- Per GKE Standard, se
sidecar.istio.io/proxyCPU
è impostato, assicurati di impostare esplicitamentesidecar.istio.io/proxyCPULimit
. In caso contrario, il limite di CPU del file collaterale verrà impostato su illimitato. - Per GKE Standard, se il criterio
sidecar.istio.io/proxyMemory
è impostato, assicurati di impostare esplicitamentesidecar.istio.io/proxyMemoryLimit
. In caso contrario, il limite di memoria del file collaterale verrà impostato su illimitato. - Per GKE Autopilot, la configurazione delle risorse
requests
elimits
tramite annotazioni potrebbe eseguire l'overprovisioning delle risorse. Usa l'approccio basato sul modello di immagine per evitare. Vedi Esempi di modifica delle risorse in Autopilot.
Ad esempio, consulta la seguente configurazione delle annotazioni delle 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"
Verificare 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 correttamente:
Nella console Google Cloud, visualizza le metriche del piano di controllo:
Scegli la tua 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
ed etichettaproxy_version
- Aggregatore: somma
- Ciclo: 1 minuto
Quando esegui Anthos Service Mesh con un piano di controllo gestito da Google e nel cluster, puoi distinguere le metriche in base al nome del container. Ad esempio, le metriche gestite hanno
container_name="cr-asm-managed"
, mentre le metriche 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 ispezionando i seguenti campi in Metrics Explorer:
- Il campo revisione indica la versione del piano di controllo.
- Il campo proxy_version indica il valore
proxy_version
. - Il campo value indica il numero di proxy connessi.
Per il canale attuale con la mappatura delle versioni di Anthos Service Mesh, consulta Versioni di Anthos Service Mesh per canale.
Esegui la migrazione delle applicazioni in Anthos Service Mesh gestito
Per eseguire la migrazione delle applicazioni da Anthos Service Mesh nel cluster ad Anthos Service Mesh gestito, segui questi passaggi:
Sostituisci l'etichetta dello spazio dei nomi attuale. I passaggi richiesti variano a seconda che tu voglia utilizzare le etichette di inserimento predefinite (ad esempio
istio-injection enabled
) o l'etichetta di revisione.Etichetta di iniezione predefinita
Esegui questo comando per spostare il tag predefinito nella revisione gestita:
istioctl tag set default --revision REVISION_LABEL
Esegui il comando seguente per etichettare lo spazio dei nomi utilizzando
istio-injection=enabled
, se non lo è già:kubectl label namespace NAMESPACE istio-injection=enabled istio.io/rev- \ --overwrite
Etichetta revisione
Se hai utilizzato l'etichetta
istio.io/rev=REVISION_LABEL
, esegui questo comando: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 ogni 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 tu non voglia limitare la configurazione solo a un sottoinsieme di cluster. La configurazione applicata a un determinato cluster rappresenta la fonte attendibile per il cluster.
Verifica che le metriche vengano visualizzate come previsto seguendo i passaggi descritti in Verificare le metriche del piano di controllo.
Se ritieni che la tua applicazione funzioni come previsto, puoi rimuovere istiod
nel cluster dopo aver spostato tutti gli spazi dei nomi sul piano di controllo gestito oppure conservarli come backup: istiod
farà automaticamente fare lo scale down per utilizzare meno risorse. Per rimuoverlo, vai a Elimina piano di controllo precedente.
In caso di problemi, puoi identificarli e risolverli utilizzando le informazioni riportate in Risolvere i problemi del piano di controllo gestito e, se necessario, eseguire il rollback alla versione precedente.
Elimina piano di controllo precedente
Dopo aver installato e verificato che tutti gli spazi dei nomi utilizzino il piano di controllo gestito da Google, puoi eliminare il piano di controllo precedente.
kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod -n istio-system --ignore-not-found=true
Se hai utilizzato istioctl kube-inject
anziché l'inserimento automatico o se hai installato gateway aggiuntivi, controlla le metriche per il piano di controllo e verifica che il numero di endpoint connessi sia zero.
Rollback
Segui questi passaggi se devi eseguire il rollback alla versione precedente del piano di controllo:
Aggiorna i carichi di lavoro da inserire con la versione precedente del piano di controllo. Nel comando seguente, 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 reinserimento in modo che i proxy abbiano la versione precedente:
kubectl rollout restart deployment -n NAMESPACE
Il piano di controllo gestito scala automaticamente fino a zero e non utilizza alcuna risorsa quando non è in uso. I webhook modificabili e il provisioning rimarranno invariati e non influiscono sul comportamento del cluster.
Ora il gateway è impostato sulla revisione asm-managed
. Per eseguire il rollback, esegui nuovamente il comando di installazione di Anthos Service Mesh, che eseguirà nuovamente il deployment del gateway puntando al piano di controllo nel cluster:
kubectl -n istio-system rollout undo deploy istio-ingressgateway
In caso di successo, aspettati questo output:
deployment.apps/istio-ingressgateway rolled back
Disinstallazione di Anthos Service Mesh
Il piano di controllo gestito scala automaticamente fino a zero quando non viene utilizzato da nessuno spazio dei nomi. Per la procedura dettagliata, consulta Disinstallare Anthos Service Mesh.
Risoluzione dei problemi
Per identificare e risolvere i problemi relativi all'utilizzo del piano di controllo gestito, vedi Risoluzione dei problemi del piano di controllo gestito.
Passaggi successivi
- Scopri come abilitare le funzionalità facoltative di Anthos Service Mesh gestite, ad esempio:
- Configurazione della sicurezza dei trasporti per proteggere il mesh.