Versione 1.18

Versioni disponibili

1.18 (più recente)
1.17
1.16
1.15
1.14
1.13
1.12
1.11
1
12.1 12.{17{/27.

Installazione e upgrade dei gateway

Anthos Service Mesh ti offre la possibilità di eseguire il deployment e la gestione dei gateway come parte del tuo mesh di servizi. Un gateway descrive un bilanciatore del carico a livello perimetrale del 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. I gateway vengono utilizzati principalmente per gestire il traffico in entrata, ma puoi anche configurarli per gestire altri tipi di traffico. Ecco alcuni esempi:

Gateway in uscita: un gateway in uscita ti consente di configurare un nodo di uscita dedicato per il traffico in uscita dal mesh, in modo da limitare i servizi che possono o devono accedere a reti esterne o di abilitare il controllo sicuro del traffico in uscita per aggiungere sicurezza alla tua rete mesh, ad esempio.
Gateway est-ovest: un proxy per il traffico est-ovest che consente ai carichi di lavoro di servizio di comunicare oltre i confini dei cluster in un mesh multi-principale su reti diverse. Per impostazione predefinita, questo gateway sarà pubblico su Internet.

In questa pagina vengono descritte le best practice per il deployment e l'upgrade dei proxy gateway, nonché esempi di configurazione dei proxy istio-ingressgateway e istio-egressgateway del gateway. Cose come la suddivisione del traffico, i reindirizzamenti e la logica per i nuovi tentativi sono possibili applicando una configurazione Gateway ai proxy gateway. Quindi, anziché aggiungere il routing del traffico a livello di applicazione (L7) alla stessa risorsa API, puoi associare un servizio virtuale al gateway. Questo consente di gestire il traffico del gateway come qualsiasi altro traffico del piano dati nel mesh di servizi.

Puoi eseguire il deployment dei gateway in modi diversi e puoi scegliere di utilizzare più di una topologia all'interno dello stesso cluster. Per scoprire di più su queste topologie, consulta la pagina relativa alle topologie di deployment del gateway.

Best practice per il deployment di gateway

Le best practice per il deployment di gateway dipendono dal fatto che tu stia utilizzando il piano dati gestito o il piano dati non gestito.

Best practice per il piano dati gestito

Attiva il piano dati gestito.
Aggiungi un'etichetta di revisione gestita a uno spazio dei nomi.
Esegui il deployment e gestisci separatamente il piano di controllo e i gateway.
Come best practice per la sicurezza, ti consigliamo di eseguire il deployment dei gateway in uno spazio dei nomi diverso dal piano di controllo.
Utilizza l'iniezione automatica di sidecar (inserimento automatico) per inserire la configurazione proxy per i gateway in modo simile a come inseriresti i proxy sidecar per i tuoi servizi.

Queste best practice:

Assicurati che i gateway gestiti vengano aggiornati automaticamente con gli ultimi miglioramenti e aggiornamenti della sicurezza.
Scarica la gestione e la manutenzione delle istanze del gateway sul piano dati gestito da Anthos Service Mesh.

Best practice per piano dati non gestito

Esegui il deployment e gestisci separatamente il piano di controllo e i gateway.
Come best practice per la sicurezza, ti consigliamo di eseguire il deployment dei gateway in uno spazio dei nomi diverso dal piano di controllo.
Utilizza l'iniezione automatica di sidecar (inserimento automatico) per inserire la configurazione proxy per i gateway in modo simile a come inseriresti i proxy sidecar per i tuoi servizi.

Queste best practice:

Consenti agli amministratori dello spazio dei nomi di gestire i gateway senza richiedere privilegi elevati all'intero cluster.
Consenti agli amministratori di utilizzare gli stessi strumenti o meccanismi di deployment utilizzati per gestire le applicazioni Kubernetes per il deployment e la gestione dei gateway.
Offri agli amministratori il controllo completo del deployment del gateway e semplifica le operazioni. Quando è disponibile un nuovo upgrade o viene modificata una configurazione, gli amministratori aggiornano i pod del gateway semplicemente riavviandoli. In questo modo, l'esperienza di utilizzo di un deployment del gateway è la stessa della gestione dei proxy sidecar per i servizi.

Deployment dei gateway

Per supportare gli utenti con strumenti di deployment esistenti, Anthos Service Mesh supporta gli stessi metodi di deployment di un gateway di Istio: IstioOperator, Helm e Kubernetes YAML. Ogni metodo produce lo stesso risultato. Anche se puoi scegliere il metodo che conosci meglio, ti consigliamo di utilizzare il metodo YAML Kubernetes perché è più facile da modificare e puoi archiviare i manifest idrati nel controllo del codice sorgente.

Crea uno spazio dei nomi per il gateway, se non ne hai già uno. Sostituisci GATEWAY_NAMESPACE con il nome dello spazio dei nomi.
```
kubectl create namespace GATEWAY_NAMESPACE
```
Per abilitare l'inserimento automatico, etichetta gli spazi dei nomi con le etichette di iniezione predefinite se è configurato il tag predefinito o con l'etichetta di revisione allo spazio dei nomi. L'etichetta da aggiungere dipende anche dal fatto che tu abbia eseguito il deployment di Anthos Service Mesh gestito o che tu abbia installato il piano di controllo nel cluster. L'etichetta viene utilizzata dal webhook iniettore del sidecar per associare le sidecar iniettate a una determinata revisione del piano di controllo.

Seleziona la scheda riportata di seguito in base al tuo tipo di installazione (gestita o in-cluster).
Gestita
Utilizza il seguente comando per individuare i canali di rilascio disponibili:
```
kubectl -n istio-system get controlplanerevision
```
L'output è simile al seguente:
```
NAME                AGE
asm-managed         6d7h
asm-managed-rapid   6d7h
```
Nell'output, il valore nella colonna NAME è l'etichetta di revisione che corrisponde al canale di rilascio disponibile per la versione di Anthos Service Mesh.
In-cluster
Per i piani di controllo nel cluster, il servizio e il deployment istiod hanno in genere un'etichetta di revisione simile a istio.io/rev=asm-1182-4, in cui asm-1182-4 identifica la versione di Anthos Service Mesh. La revisione diventa parte del nome del servizio istiod, ad esempio: istiod-asm-1182-4.istio-system

Utilizza il seguente comando per individuare l'etichetta di revisione su istiod per il piano di controllo nel cluster:
```
kubectl get deploy -n istio-system -l app=istiod \
  -o=jsonpath='{.items[*].metadata.labels.istio\.io\/rev}''{"\n"}'
```
Abilita lo spazio dei nomi per l'inserimento. Sostituisci e REVISION con il valore dell'etichetta di revisione.

Nota: puoi sostituire istio.io/rev con l'etichetta istio-injection=enabled se è configurato il tag predefinito. Verifica che il tag predefinito esista eseguendo istioctl tag list con istioctl da OUTPUT_DIR.
```
kubectl label namespace GATEWAY_NAMESPACE istio-injection- istio.io/rev=REVISION --overwrite
```
Se hai installato Anthos Service Mesh utilizzando asmcli, passa alla directory specificata in --output_dir, quindi cd alla directory samples.

Importante: per assicurarti di trovarti nella directory samples corretta, esegui il comando ls per elencare i contenuti della directory e verifica che esistano una directory gateways (a cui accederai nel passaggio successivo) e una directory online-boutique.

Se non hai eseguito l'installazione utilizzando asmcli, copia i file di configurazione per i gateway dal repository anthos-service-mesh.
Puoi eseguire il deployment della configurazione del gateway di esempio che si trova nella directory samples/gateways/ così com'è, o modificarla in base alle esigenze.
Ingress
```
kubectl apply -n GATEWAY_NAMESPACE -f samples/gateways/istio-ingressgateway
```
In uscita
```
kubectl apply -n GATEWAY_NAMESPACE -f samples/gateways/istio-egressgateway
```

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

kubectl get pod,service -n GATEWAY_NAMESPACE

Verifica che l'output sia 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

Selettori del gateway

Applichi una configurazione Gateway ai proxy istio-ingressgateway e istio-egressgateway per gestire il traffico in entrata e in uscita per il mesh, in modo da poter specificare il traffico da inserire o uscire dal mesh. Le etichette sui pod di un deployment del gateway vengono utilizzate dalle risorse di configurazione del gateway, quindi è importante che il selettore del gateway corrisponda a queste etichette.

Ad esempio, nei deployment descritti sopra, l'etichetta istio=ingressgateway è impostata sui pod del gateway. Per applicare una configurazione gateway a questi deployment, devi selezionare la stessa etichetta:

apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: gateway
spec:
  selector:
    istio: ingressgateway
...

Per un esempio di configurazione gateway e servizio virtuale, consulta frontend.yaml nell'applicazione di esempio Boutique online.

Upgrade dei gateway

Upgrade in loco

Per la maggior parte dei casi d'uso, devi eseguire l'upgrade dei gateway seguendo il pattern di upgrade esistente. Poiché i gateway utilizzano l'inserimento di pod, i nuovi pod di gateway creati vengono inseriti automaticamente con la configurazione più recente, che include la versione.

Se vuoi modificare la revisione del piano di controllo utilizzata dal gateway, puoi impostare l'etichetta istio.io/rev sul deployment del gateway, che attiverà anche il riavvio in sequenza.

Piano di controllo gestito

Poiché Google gestisce gli upgrade del piano di controllo per il piano di controllo gestito, puoi semplicemente riavviare il deployment del gateway e ai nuovi pod verranno inseriti automaticamente la configurazione e la versione più recenti.

kubectl rollout restart deployment istio-ingressgateway \
  -n GATEWAY_NAMESPACE

Piano di controllo in-cluster

Per applicare lo stesso pattern ai gateway quando hai il piano di controllo nel cluster, devi modificare la revisione del piano di controllo utilizzata dal gateway. Imposta l'etichetta istio.io/rev sul deployment del gateway che attiverà un riavvio in sequenza. I passaggi richiesti dipendono dall'aggiornamento dell'etichetta di revisione nello spazio dei nomi e/o nel pod del gateway.

Se hai etichettato lo spazio dei nomi per l'inserimento, imposta l'etichetta istio.io/rev nello spazio dei nomi sul nuovo valore di revisione:
```
  kubectl label namespace GATEWAY_NAMESPACE \
    istio-injection- istio.io/rev=REVISION \
    --overwrite
```

Se hai abilitato l'inserimento solo per il pod del gateway, imposta l'etichetta istio.io/rev sul deployment sul nuovo valore di revisione, come il seguente file YAML Kubernetes:

cat <<EOF > gateway-deployment.yaml
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: REVISION
    spec:
      containers:
      - name: istio-proxy
        image: auto # The image will automatically update each time the pod starts.
EOF

kubectl apply -f gateway-deployment.yaml

Upgrade canary (avanzati)

Se utilizzi il piano di controllo nel cluster e vuoi controllare più lentamente l'implementazione di una nuova revisione del piano di controllo, puoi seguire il pattern di upgrade canary. Puoi eseguire più versioni di un deployment del gateway e assicurarti che tutto funzioni come previsto con un sottoinsieme del tuo traffico. Ad esempio, se vuoi implementare una nuova revisione, canary, crea una copia del deployment del gateway con l'etichetta istio.io/rev=REVISION impostata sulla nuova revisione e un nuovo nome, ad esempio istio-ingressgateway-canary:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: istio-ingressgateway-canary
  namespace: GATEWAY_NAMESPACE
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  template:
    metadata:
      annotations:
        inject.istio.io/templates: gateway
      labels:
        istio: ingressgateway
        istio.io/rev: REVISION # Set to the control plane revision you want to deploy
    spec:
      containers:
      - name: istio-proxy
        image: auto

Una volta creato questo deployment, avrai due versioni del gateway, entrambe selezionate dallo stesso servizio:

kubectl get endpoints -o "custom-columns=NAME:.metadata.name,PODS:.subsets[*].addresses[*].targetRef.name"

NAME                   PODS
istio-ingressgateway   istio-ingressgateway-788854c955-8gv96,istio-ingressgateway-canary-b78944cbd-mq2qf

Se ritieni che le tue applicazioni funzionino come previsto, esegui questo comando per passare alla nuova versione eliminando il deployment con il vecchio insieme di etichette istio.io/rev:

kubectl delete deploy/istio-ingressgateway -n GATEWAY_NAMESPACE

Se hai riscontrato un problema durante il test della tua applicazione con la nuova versione del gateway, esegui questo comando per tornare alla versione precedente eliminando il deployment con il nuovo set di etichette istio.io/rev:

kubectl delete deploy/istio-ingressgateway-canary -n GATEWAY_NAMESPACE

Configurazione avanzata

Configura la versione TLS minima del gateway

Per Anthos Service Mesh versione 1.14 e successive, la versione TLS minima predefinita per i server gateway è 1.2. Puoi configurare la versione minima di TLS utilizzando il campo minProtocolVersion. Per ulteriori informazioni, consulta ServerTLSSettings.

Risolvere i problemi relativi ai gateway

Impossibile aggiornare l'immagine del gateway da `auto`

Quando esegui il deployment di un gateway o ne esegui l'upgrade, Anthos Service Mesh inserisce auto come segnaposto nel campo image. Dopo la chiamata al webhook mutante, Anthos Service Mesh sostituisce automaticamente questo segnaposto con l'immagine del proxy Anthos Service Mesh effettiva. Se la chiamata al webhook mutante non riesce, il segnaposto auto rimane e il container non viene trovato. Questo è generalmente causato da un'etichetta di spazio dei nomi non corretta. Assicurati di aver configurato lo spazio dei nomi corretto, quindi esegui il deployment del gateway o eseguine l'upgrade.