Stai visualizzando la documentazione legacy di Service Mesh v1.19.

Versioni disponibili

Cloud Service Mesh
Archivio 1.20
Archivio 1.19
Archivio 1.18

Questa pagina è stata tradotta dall'API Cloud Translation.

Installazione e upgrade dei gateway

Cloud Service Mesh ti offre la possibilità di eseguire il deployment e gestire i gateway come parte dalla tua rete mesh di servizi. Un gateway descrive un bilanciatore del carico che opera sul perimetro il mesh che riceve le connessioni HTTP/TCP in entrata o in uscita. I gateway sono Envoy che forniscono un controllo granulare sul traffico in entrata e escono dalla rete. I gateway vengono utilizzati principalmente per gestire il traffico in entrata ma puoi anche configurare gateway per gestire altri tipi di traffico. Ad esempio:

Gateway in uscita: un gateway in uscita consente di configurare un nodo di uscita dedicato per il traffico che esce dal mesh, consentendoti di limitare i servizi che possono o devono accedere a reti esterne o consentire il controllo sicuro del traffico in uscita per aggiungere ad esempio per la tua rete mesh.
Gateway est-ovest: un proxy per Traffico east-west per consentire ai carichi di lavoro dei servizi di comunicare oltre i confini dei cluster in mesh multi-principale su reti diverse. Per impostazione predefinita, pubblicamente su internet.

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

Puoi eseguire il deployment dei gateway in diversi modi e scegliere di utilizzare più di di una topologia all'interno dello stesso cluster. Consulta Topologie di deployment del gateway nella documentazione di Istio, per saperne di più su queste topologie.

Best practice per il deployment dei gateway

Le best practice per il deployment dei gateway dipendono dall'uso o meno della piano dati gestito o piano dati non gestito.

Best practice per il piano dati gestito

Attiva il piano dati gestito.
Aggiungi un'etichetta di revisione gestita a una nello spazio dei nomi.
Esegui il deployment e gestisci il piano di controllo e i gateway separatamente.
Come best practice per la sicurezza, ti consigliamo di eseguire il deployment dei gateway in diverso rispetto a quello del piano di controllo.
Utilizza le funzionalità di iniezione automatica del file collaterale (inserimento automatico) per inserire la configurazione proxy per gateway simili a come inseriresti i proxy collaterali per i tuoi servizi.

Queste best practice:

Assicurati che i gateway gestiti siano automaticamente aggiornati con le ultime miglioramenti e aggiornamenti della sicurezza.
Riduce la gestione e la manutenzione delle istanze gateway in Cloud Service Mesh un piano dati gestito.

Best practice per il piano dati non gestito

Esegui il deployment e gestisci il piano di controllo e i gateway separatamente.
Come best practice per la sicurezza, ti consigliamo di eseguire il deployment dei gateway in diverso rispetto a quello del piano di controllo.
Utilizza le funzionalità di iniezione automatica del file collaterale (inserimento automatico) per inserire la configurazione proxy per gateway simili a come inseriresti i proxy collaterali per i tuoi servizi.

Queste best practice:

Consenti agli amministratori dello spazio dei nomi di gestire i gateway senza dover privilegi elevati per l'intero cluster.
Consenti agli amministratori di utilizzare gli stessi strumenti o meccanismi di deployment che usano per gestire le applicazioni Kubernetes, gateway VPN ad alta disponibilità.
Concedi agli amministratori il controllo completo sul deployment del gateway per semplificare le operazioni. Quando è disponibile un nuovo upgrade o viene è cambiata, gli amministratori aggiornano i pod del gateway semplicemente riavviandoli. Questo rende l'esperienza di gestione di un deployment gateway uguale che utilizzano proxy sidecar per i tuoi servizi.

Esegui il deployment dei gateway

Per supportare gli utenti con strumenti di deployment esistenti, Cloud Service Mesh supporta per eseguire il deployment di un gateway Istio: IstioOperator, Helm e Kubernetes YAML. Ogni metodo produce lo stesso o il risultato finale. Anche se puoi scegliere il metodo che conosci meglio, di utilizzare il metodo YAML Kubernetes perché è più facile modificare e archiviare i manifest idratati 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 del tuo nello spazio dei nomi.
```
kubectl create namespace GATEWAY_NAMESPACE
```
Per abilitare l'inserimento automatico, etichetta gli spazi dei nomi con il etichette di inserimento predefinite se è stato impostato il tag predefinito o con il revisiona l'etichetta al tuo spazio dei nomi. L'etichetta aggiunta dipende anche dal fatto che tu abbia eseguito o meno il deployment Cloud Service Mesh gestito o installato il piano di controllo nel cluster. L'etichetta è utilizzata dal file collaterale Webhook di injector per associare i sidecar inseriti a un particolare controllo la revisione del piano d'azione.

Seleziona la scheda qui sotto in base al tipo di installazione (gestita o nel cluster).
Gestito
Usa 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 sotto la colonna NAME è l'etichetta di revisione che corrisponde alla disponibilità canale di rilascio per la versione Cloud Service Mesh.
Nel cluster
Per i piani di controllo nel cluster, il servizio e il deployment istiod in genere hanno un'etichetta di revisione simile a istio.io/rev=asm-11910-9, dove asm-11910-9 identifica la versione di Cloud Service Mesh. La revisione diventa parte del nome del servizio istiod, ad esempio: istiod-asm-11910-9.istio-system

Utilizza questo comando per individuare l'etichetta di revisione su istiod per dal 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 il metodo istio-injection=enabled se tag predefinito è configurata. Verifica che il tag predefinito esista eseguendo istioctl tag list con istioctl di OUTPUT_DIR.
```
kubectl label namespace GATEWAY_NAMESPACE istio-injection- istio.io/rev=REVISION --overwrite
```
Se hai installato Cloud Service Mesh utilizzando asmcli, passa alla directory specificato in --output_dir, quindi cd alla directory samples.

Importante: per assicurarti di essere nella directory samples corretta, esegui ls comando per elencare i contenuti della directory e verificare che sia presente un gateways (a cui accederai nel passaggio successivo) e una online-boutique .

Se non è stata installata utilizzando asmcli, copia i file di configurazione per i gateway dal Repository anthos-service-mesh.
Puoi eseguire il deployment della configurazione di esempio del gateway che si trova samples/gateways/ così com'è o modificala in base alle tue esigenze.
In entrata
```
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 dei gateway

Applichi un Gateway configurazione ai proxy istio-ingressgateway e istio-egressgateway gestire il traffico in entrata e in uscita per il tuo mesh, consentendoti di specificare quale il traffico che vuoi che entri o escano dalla rete. Le etichette su un gateway dei pod del deployment vengono utilizzati dalle risorse di configurazione del gateway, che il selettore del gateway corrisponda a queste etichette.

Ad esempio, nei deployment precedenti, l'etichetta istio=ingressgateway è impostata sui pod del gateway. Per applicare una configurazione del 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 del gateway e di un servizio virtuale, vedi frontend.yaml nell'applicazione di esempio Online Boutique.

Esegui l'upgrade dei gateway

Upgrade in loco

Per la maggior parte dei casi d'uso, devi eseguire l'upgrade dei gateway seguendo le istruzioni in loco pattern di upgrade. Poiché i gateway utilizzano l'inserimento di pod, i nuovi pod gateway vengono automaticamente inserite la configurazione più recente, include la versione.

Se vuoi cambiare la revisione del piano di controllo in uso dal gateway, puoi impostare l'etichetta istio.io/rev sul deployment del gateway, che attivare un riavvio in sequenza.

Piano di controllo gestito

Poiché Google gestisce gli upgrade per il piano di controllo gestito, basta riavviare il deployment del gateway e i nuovi pod automaticamente l'ultima configurazione e la versione più recente.

kubectl rollout restart deployment istio-ingressgateway \
  -n GATEWAY_NAMESPACE

Piano di controllo in-cluster

Per applicare lo stesso pattern ai gateway quando hai il 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à una il riavvio in sequenza. I passaggi richiesti variano a seconda che sia necessario aggiornare o meno il l'etichetta di revisione sullo spazio dei nomi e/o sul pod del gateway.

Se hai etichettato lo spazio dei nomi per l'inserimento, imposta l'etichetta istio.io/rev su lo spazio dei nomi al 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 gateway, imposta istio.io/rev etichetta sul deployment al nuovo valore di revisione come la 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 rallentare controllare l'implementazione di una nuova revisione del piano di controllo, puoi seguire pattern di upgrade. Puoi eseguire più versioni di un deployment 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 gateway Deployment con l'etichetta istio.io/rev=REVISION impostata su 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 Gateway, entrambi selezionati 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 per passare alla nuova versione eliminando il deployment con il precedente Set di etichette istio.io/rev:

kubectl delete deploy/istio-ingressgateway -n GATEWAY_NAMESPACE

Se hai riscontrato un problema durante il test dell'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 Cloud Service Mesh 1.14 e versioni successive, la versione TLS minima predefinita per è la versione 1.2. Puoi configurare la versione TLS minima utilizzando campo minProtocolVersion. Per ulteriori informazioni, vedi ServerTLSSettings.

Risolvi i problemi relativi ai gateway

Impossibile aggiornare l'immagine del gateway da `auto`

Quando esegui il deployment o l'upgrade di un gateway, Cloud Service Mesh inserisce auto come nel campo image. Dopo la chiamata al webhook mutante, Cloud Service Mesh sostituisce automaticamente questo segnaposto con il valore Immagine proxy Cloud Service Mesh. Se la chiamata al webhook mutante non va a buon fine, auto rimane e il container non sarà trovato. In genere si tratta di una situazione a causa di un'etichetta dello spazio dei nomi errata. Assicurati di aver configurato il corretto e quindi eseguire di nuovo il deployment o l'upgrade del gateway.