Anthos Service Mesh 1.11 ha raggiunto la fine del ciclo di vita e non è più supportato. Vedi Upgrade da versioni precedenti.

Visualizza la documentazione più recente o seleziona un'altra versione disponibile:

Versioni disponibili

Configurazione di Anthos Service Mesh gestito

Panoramica

Anthos Service Mesh gestito è un piano di controllo gestito da Google e un piano dati facoltativo semplicemente da configurare. Google ne gestisce affidabilità, upgrade, scalabilità e sicurezza al posto tuo in modo compatibile con le versioni precedenti. Questa guida spiega come configurare o migrare le applicazioni in Anthos Service Mesh gestito in una configurazione a cluster singolo o multi-cluster.

Per scoprire di più sulle funzionalità supportate e sulle limitazioni di Anthos Service Mesh gestito, consulta l'articolo Funzionalità supportate di Anthos Service Mesh.

Prerequisiti

Come punto di partenza, questa guida presuppone che tu abbia:

Un progetto Cloud.
Un account di fatturazione Cloud.
Lo script di installazione kpt e altri strumenti specificati in Installazione degli strumenti richiesti.

Requisiti

Uno o più cluster con una versione supportata di GKE in una delle regioni supportate.
Nei cluster deve essere abilitata Workload Identity. Vedi Abilitare Workload Identity per il comando gcloud.
Il piano dati gestito da Google richiede l'abilitazione del plug-in Container Network Interface (CNI) Istio quando esegui il deployment del piano di controllo gestito da Google, come descritto più avanti in questa pagina.

Migrazioni

Le migrazioni e gli upgrade diretti dal piano di controllo nel cluster al piano di controllo gestito da Google sono supportati solo dalle versioni 1.9 e successive (installate con Mesh CA).
Le installazioni con una CA Istio devono prima eseguire la migrazione a una CA mesh di almeno 1,9 anni.
Le migrazioni e gli upgrade indiretti sono supportati, quindi puoi seguire i percorsi di upgrade standard di Anthos Service Mesh per ogni versione fino a raggiungere Anthos Service Mesh 1.11 con un piano di controllo nel cluster, quindi puoi eseguire la migrazione al piano di controllo gestito da Google.

Limitazioni

Ti consigliamo di esaminare l'elenco di funzionalità e limitazioni gestite di Anthos Service Mesh supportate. In particolare, tieni presente quanto segue:

Anthos Service Mesh gestito può utilizzare più cluster GKE in un singolo progetto Google Cloud.
L'API IstioOperator non è supportata.
Limitazioni del piano dati gestito:
- Questa release di anteprima del piano dati gestito è disponibile solo per i nuovi deployment del piano di controllo gestito. Se in precedenza hai eseguito il deployment del piano di controllo gestito e vuoi eseguire il deployment del piano dati gestito, devi eseguire nuovamente lo script di installazione come descritto in Applicare il piano di controllo gestito da Google.
- Il piano di date gestito è disponibile per i canali di rilascio regolare e rapido.

Abilita Workload Identity

Se Workload Identity non è abilitato, consulta Abilitazione di Workload Identity su un cluster per conoscere le autorizzazioni IAM richieste e gcloud CLI per abilitarle.

Scarica lo script di installazione

Scarica la versione più recente dello script che installa Anthos Service Mesh 1.11.8 nella directory di lavoro attuale:
```
curl https://storage.googleapis.com/csm-artifacts/asm/install_asm_1.11 > install_asm
```
Rendi eseguibile lo script:
```
chmod +x install_asm
```

Configura ciascun cluster

Segui questi passaggi per configurare Anthos Service Mesh gestito per ogni cluster nel tuo mesh.

Recupera le credenziali del cluster

Recupera le credenziali appropriate. Il seguente comando punterà anche il contesto kubectl al cluster di destinazione.

gcloud container clusters get-credentials  CLUSTER_NAME \
    --zone LOCATION \
    --project PROJECT_ID

Applicare il piano di controllo gestito da Google

Esegui lo script di installazione di install_asm per ogni cluster che utilizzerà Anthos Service Mesh gestito. Ti consigliamo di includere entrambe le seguenti opzioni quando esegui install_asm:

--option cni-managed Questa opzione attiva il plug-in CNI (Istio Container Network Interface). Il plug-in CNI configura il reindirizzamento del traffico di rete da e verso i proxy sidecar utilizzando l'interfaccia CNCF CNI anziché utilizzare un container init con privilegi elevati.
--enable-registration Questo flag registra il cluster nel parco risorse.

Queste opzioni sono necessarie se vuoi eseguire anche il deployment del piano dati gestito da Google. Per un elenco completo delle opzioni, consulta la pagina di riferimento sulle asmcli.

  ./install_asm --mode install --managed \
      -p PROJECT_ID \
      -l LOCATION \
      -n CLUSTER_NAME \
      --verbose \
      --output_dir CLUSTER_NAME \
      --enable-all \
      --enable-registration \
      --option cni-managed

Lo script scaricherà nel --output_dir specificato tutti i file per la configurazione del piano di controllo gestito, l'installazione di un gateway Istio, lo strumento istioctl e le applicazioni di esempio. I passaggi di questa guida presuppongono che tu esegua istioctl dalla directory principale della directory di installazione, con istioctl presente nella sottodirectory /bin.

Se esegui nuovamente install_asm sullo stesso cluster, la configurazione del piano di controllo esistente verrà sovrascritta. Assicurati di specificare le stesse opzioni e gli stessi flag se desideri la stessa configurazione.

Tieni presente che non viene eseguito automaticamente il deployment di un gateway in entrata 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 ha bisogno di un gateway in entrata, consulta Installare i gateway Istio.

Applicare il piano dati gestito da Google

Se vuoi che Google gestisca gli upgrade dei proxy, abilita il piano dati gestito da Google. Se questa opzione è abilitata, viene eseguito l'upgrade automatico dei proxy sidecar e dei gateway inseriti in combinazione con il piano di controllo gestito.

Nell'anteprima delle funzionalità, il piano dati gestito esegue l'upgrade dei proxy eliminando i pod che eseguono versioni precedenti del proxy. Le rimozioni vengono eseguite in modo ordinato, rispettando il budget per l'interruzione dei pod e controllando la frequenza di modifica.

Questa versione di anteprima del piano dati gestito non gestisce i seguenti elementi:

Pod non inseriti.
Pod inseriti manualmente utilizzando istioctl kube-inject.
Job
Set stateful
DaemonSet

Se non vuoi utilizzare il piano dati gestito o non vuoi abilitarlo per tutti gli spazi dei nomi, devi attivare un riavvio dei proxy per utilizzare l'immagine proxy più recente. Il piano di controllo continua a funzionare con i proxy esistenti.

Il piano dati gestito è disponibile sui canali di rilascio rapido e regolare.

Per abilitare il piano dati gestito da Google:

Attiva la gestione del piano dati:
```
kubectl annotate --overwrite namespace NAMESPACE \
mesh.cloud.google.com/proxy='{"managed":"true"}'
```
In alternativa, puoi abilitare il piano dati gestito da Google per un pod specifico annotandolo con la stessa annotazione. Quando annota un pod specifico, questo pod utilizza il proxy sidecar gestito da Google, mentre il resto dei carichi di lavoro utilizza i proxy sidecar non gestiti.
Ripeti il passaggio precedente per ogni spazio dei nomi che vuoi utilizzare per un piano dati gestito.

Attiva Anthos Service Mesh nel parco risorse:

gcloud alpha container hub mesh enable --project=PROJECT_ID

Potrebbero essere necessari fino a dieci minuti prima che il controller del piano dati sia pronto per gestire i proxy nel cluster. Esegui questo comando per verificare lo stato:

if kubectl get dataplanecontrols -o custom-columns=REV:.spec.revision,STATUS:.status.state | grep rapid | grep -v none > /dev/null; then echo "Managed Data Plane is ready."; else echo "Managed Data Plane is NOT ready."; fi

Quando il controller del piano dati è pronto, il comando restituirà: Managed Data Plane is ready.

Se lo stato del controller del piano dati non diventa pronto dopo aver atteso più di dieci minuti, consulta Stato del piano dati gestito per suggerimenti sulla risoluzione dei problemi.

Se vuoi disabilitare il piano dati gestito da Google e tornare alla gestione autonoma dei proxy sidecar, modifica l'annotazione:

kubectl annotate --overwrite namespace NAMESPACE \
  mesh.cloud.google.com/proxy='{"managed":"false"}'

(Facoltativo) Installa i gateway Istio

Anthos Service Mesh ti offre la possibilità di eseguire il deployment e gestire gateway come parte del tuo mesh di servizi. Un gateway descrive un bilanciatore del carico che opera sul perimetro della rete mesh che riceve connessioni HTTP/TCP in entrata o in uscita. I gateway sono proxy Envoy che ti forniscono un controllo granulare sul traffico in entrata e in uscita dal mesh.

Come best practice, ti consigliamo di creare uno spazio dei nomi separato per i gateway. Non eseguire il deployment dei gateway nello spazio dei nomi istio-system.

Puoi installare uno o più gateway Istio nel tuo cluster per gestire il tipico traffico in entrata seguendo questi passaggi:

Scegli una di queste due opzioni per configurare lo spazio dei nomi in cui eseguirai il deployment del gateway nei passaggi successivi.
- Abilita lo spazio dei nomi per l'inserimento:
```
kubectl label namespace GATEWAY_NAMESPACE istio-injection- istio.io/rev=asm-managed-rapid --overwrite
```
OR
- Abilita l'inserimento solo per il pod del gateway, ma non per tutti i pod nello spazio dei nomi. Questo comando rimuove tutte le etichette di injection e in un secondo momento abiliterai l'inserimento sul pod stesso:
```
kubectl label namespace GATEWAY_NAMESPACE istio-injection- istio.io/rev-
```

Crea un deployment e un servizio per il gateway, utilizzando questo esempio minimo:

kubectl apply -f - << EOF
apiVersion: v1
kind: Service
metadata:
  name: istio-ingressgateway
  namespace: GATEWAY_NAMESPACE
spec:
  type: LoadBalancer
  selector:
    istio: ingressgateway
  ports:
  - port: 80
    name: http
  - port: 443
    name: https
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: istio-ingressgateway
  namespace: GATEWAY_NAMESPACE
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  template:
    metadata:
      annotations:
        # This is required to tell Anthos Service Mesh to inject the gateway with the
        # required configuration.
        inject.istio.io/templates: gateway
      labels:
        istio: ingressgateway
        istio.io/rev: asm-managed-rapid # This is required only if the namespace is not labeled.
    spec:
      containers:
      - name: istio-proxy
        image: auto # The image will automatically update each time the pod starts.
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: istio-ingressgateway-sds
  namespace: GATEWAY_NAMESPACE
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: istio-ingressgateway-sds
  namespace: GATEWAY_NAMESPACE
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: istio-ingressgateway-sds
subjects:
- kind: ServiceAccount
  name: default
EOF

Dopo aver creato il deployment, verifica che i nuovi servizi funzionino correttamente:

kubectl get pod,service -n GATEWAY_NAMESPACE

Verifica l'output in modo simile al seguente:

NAME                                      READY   STATUS    RESTARTS   AGE
pod/istio-ingressgateway-856b7c77-bdb77   1/1     Running   0          3s

NAME                           TYPE           CLUSTER-IP     EXTERNAL-IP      PORT(S)        AGE
service/istio-ingressgateway   LoadBalancer   10.24.5.129    34.82.157.6      80:31904/TCP   3s

Puoi scegliere di consentire al controller del piano dati gestito di gestire i proxy per i gateway esattamente come per i servizi. Se hai eseguito il deployment del piano dati gestito e vuoi che i proxy gateway siano gestiti, etichetta e annota lo spazio dei nomi del gateway come descritto in Applicare il piano dati gestito da Google.

Se scegli di gestire i gateway autonomamente, devi riavviare i pod in GATEWAY_NAMESPACE quando viene rilasciata una nuova versione di Anthos Service Mesh, in modo che prendano in considerazione la nuova configurazione del piano di controllo. Prima di riavviare i pod, devi verificare che il nuovo piano di controllo sia stato implementato nel cluster controllando la versione del piano di controllo utilizzando la query personalizzata di Metrics Explorer fornita in Verificare le metriche del piano di controllo.

Configurare il rilevamento degli endpoint (solo per le installazioni multi-cluster)

Il piano di controllo gestito di Anthos Service Mesh supporta una configurazione con un solo progetto, su rete singola e multi-primaria, con la differenza che il piano di controllo non è installato nel cluster.

Prima di continuare, dovresti aver già eseguito lo script di installazione su ciascun cluster come descritto nei passaggi precedenti. Non è necessario indicare che un cluster è un cluster primario, questo è il comportamento predefinito.

Per ogni cluster, abilita il rilevamento degli endpoint eseguendo questi comandi una volta per ogni altro cluster i=1..N nel mesh:

Per ogni cluster, assicurati che il contesto di kubectl config punti al cluster attuale:
```
export CTX=gke_PROJECT_ID_LOCATION_CLUSTER_NAME
```

Abilita il rilevamento degli endpoint eseguendo i comandi seguenti una volta per ogni altro cluster i=1..N nel mesh:

export CTX_i=gke_PROJECT_ID_LOCATION_i_CLUSTER_NAME_i

./bin/istioctl x create-remote-secret --context=${CTX_i} --name=CLUSTER_NAME_i | \
  kubectl apply -f - --context=${CTX}

Verifica che il secret sia stato creato eseguendo il comando:

kubectl get secret istio-remote-secret-CLUSTER_NAME_i -n istio-system

Verifica l'output previsto:

NAME                                   TYPE     DATA   AGE
istio-remote-secret-CLUSTER_NAME_i   Opaque   1      44s

Se il cluster attuale viene aggiunto a un mesh multi-cluster esistente, consenti a tutti gli altri cluster di scoprire i propri endpoint creando un secret corrispondente al cluster attuale in tutti gli altri cluster:
```
./bin/istioctl x create-remote-secret --context=${CTX} --name=CLUSTER_NAME | \
  kubectl apply -f - --context=${CTX_i}
```

Inoltre, puoi verificare il secret per l'altro cluster:

kubectl get secret istio-remote-secret-CLUSTER_NAME -n istio-system --context ${CTX_i}

Verifica l'output previsto:

NAME                            TYPE     DATA   AGE
istio-remote-secret-CLUSTER_NAME   Opaque   1      44s

Per ulteriori dettagli e un esempio con due cluster, consulta Abilitare il rilevamento degli endpoint.

Esegue il deployment delle applicazioni

Prima di eseguire il deployment delle applicazioni, rimuovi eventuali etichette istio-injection precedenti dai rispettivi spazi dei nomi e imposta invece l'etichetta istio.io/rev:asm-managed-rapid:

kubectl label namespace NAMESPACE istio-injection- istio.io/rev=asm-managed-rapid --overwrite

A questo punto, hai configurato correttamente il piano di controllo gestito di Anthos Service Mesh. 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 preveda di limitare la configurazione specifica a un sottoinsieme di cluster. La configurazione applicata a un determinato cluster è la fonte attendibile per il cluster. Inoltre, se il cluster esegue anche Anthos Service Mesh 1.7, 1.8 o versioni successive con Mesh CA in altri spazi dei nomi, verifica che l'applicazione possa comunicare con le altre applicazioni controllate dal piano di controllo nel cluster.

Verifica le metriche del piano di controllo

Puoi visualizzare la versione del piano di controllo e del piano dati in Metrics Explorer.

Per verificare che la configurazione funzioni correttamente:

Nella console Google Cloud, visualizza le metriche del piano di controllo:

Vai a Metrics Explorer
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-asm-managed-rapid"
- Raggruppa per: etichetta di revisione ed etichetta proxy_version
- Somma aggregatore
- Ciclo: 1 minuto
Quando esegui Anthos Service Mesh con un piano di controllo sia gestito da Google che 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 hanno container_name="discovery". Per visualizzare le metriche di entrambi, rimuovi il filtro su container_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 revision 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 la mappatura della versione dal canale attuale alla mappatura di Anthos Service Mesh, vedi Versioni di Anthos Service Mesh per canale.

Esegui la migrazione delle applicazioni ad Anthos Service Mesh gestito

Anthos Service Mesh gestito supporta solo la migrazione da Anthos Service Mesh 1.9 che utilizza mesh CA.

Per eseguire la migrazione ad Anthos Service Mesh gestito, segui questi passaggi:

Esegui lo script come indicato nella sezione Applicazione del piano di controllo gestito da Google.
Se hai eseguito il deployment sia del piano di controllo sia del piano dati gestiti da Google:
1. Attiva la gestione del piano dati:
```
kubectl annotate --overwrite namespace NAMESPACE \
mesh.cloud.google.com/proxy='{"managed":"true"}'
```
2. Attiva Anthos Service Mesh nel parco risorse:
```
gcloud alpha container hub mesh enable --project=PROJECT_ID
```

Sostituisci l'etichetta dello spazio dei nomi attuale con l'etichetta istio.io/rev:asm-managed-rapid:

kubectl label namespace NAMESPACE istio-injection- istio.io/rev=asm-managed-rapid \
    --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 disponi di 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 a un solo 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.

Un cluster può avere una combinazione di revisioni, ad esempio Anthos Service Mesh 1.7 e 1.8, e un piano di controllo nel cluster. Puoi combinare gli spazi dei nomi utilizzando diverse revisioni del piano di controllo Anthos Service Mesh a tempo indeterminato.

Se ritieni che la tua applicazione funzioni come previsto, puoi rimuovere istiod nel cluster dopo aver impostato tutti gli spazi dei nomi sul piano di controllo nel cluster oppure mantenerli 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 confermato che tutti gli spazi dei nomi utilizzano 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

Esegui i passaggi seguenti se devi eseguire il rollback alla versione del piano di controllo precedente:

Aggiorna i carichi di lavoro in modo che vengano inseriti con la versione precedente del piano di controllo. Nel seguente comando, il valore di revisione asm-191-1 viene utilizzato solo come esempio. Sostituisci il valore di esempio con l'etichetta 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 la versione precedente:
```
kubectl rollout restart deployment -n NAMESPACE
```

Il piano di controllo gestito scala automaticamente fino a zero e non utilizzerà alcuna risorsa quando non è in uso. I webhook e il provisioning mutanti rimarranno invariati e non influiranno 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

Aspettati questo output in caso di esito positivo:

deployment.apps/istio-ingressgateway rolled back

Esegui la migrazione di un gateway al piano di controllo gestito da Google

Crea un deployment Kubernetes per la nuova versione del gateway utilizzando la documentazione. Devi configurare il servizio gateway Kubernetes esistente per selezionare sia la versione precedente che quella nuova utilizzando il campo selector nella configurazione del servizio.
Con questi comandi kubectl scale, fai lo scale up graduale del nuovo deployment, con lo fare lo scale down del vecchio deployment e la verifica della presenza di segni di interruzione o inattività del servizio. Se la migrazione ha esito positivo, dovresti raggiungere zero istanze precedenti senza alcuna interruzione del servizio.

Disinstalla

Il piano di controllo gestito da Google scala automaticamente fino a zero quando non è utilizzato da nessuno spazio dei nomi, pertanto non è necessaria alcuna disinstallazione.

Risoluzione dei problemi

Per identificare e risolvere i problemi relativi al piano di controllo gestito, vedi Risoluzione dei problemi del piano di controllo gestito.

Che cosa succede dopo?

Scopri di più sui canali di rilascio