Installazione e upgrade dei gateway

Cloud Service Mesh ti offre la possibilità di eseguire il deployment dei gateway e di gestirli all'interno del mesh di servizi. Un gateway descrive un bilanciatore del carico che opera al limite del mesh e riceve connessioni HTTP/TCP in entrata o in uscita. I gateway sono proxy Envoy che offrono 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. Ad esempio:

• Gateway di uscita: un gateway di uscita consente di configurare un nodo di uscita dedicato per il traffico che esce dal mesh, consentendo di limitare i servizi che possono o devono accedere a reti esterne o di attivare il controllo sicuro del traffico in uscita per aggiungere sicurezza al mesh, ad esempio.

• Gateway est-ovest: un proxy per il traffico est-ovest per consentire ai workload di servizio di comunicare tra i confini del cluster in un mesh multi-primario su reti diverse. Per impostazione predefinita, questo gateway sarà pubblico su internet.

Questa pagina descrive le best practice per il deployment e l'upgrade dei proxy gateway, nonché esempi di configurazione dei tuoi proxy gateway istio-ingressgateway e istio-egressgateway. Operazioni come la suddivisione del traffico, i reindirizzamenti e la logica di ripetizione sono possibili applicando una configurazione del gateway ai proxy del gateway. Poi, anziché aggiungere il routing del traffico a livello di applicazione (L7) alla stessa risorsa API, associ un servizio virtuale al gateway. In questo modo puoi gestire il traffico del gateway come qualsiasi altro traffico del data plane nelmesh di servizih.

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

Best practice per l'implementazione dei gateway

Le best practice per il deployment dei gateway variano a seconda che tu stia utilizzando il data plane gestito o il data plane non gestito.

Best practice per il piano dati gestito

1. Attiva il piano dati gestito.
2. Aggiungi un'etichetta di revisione gestita a uno spazio dei nomi.
3. Esegui il deployment e gestisci separatamente il control plane e i gateway.
4. Come best practice di sicurezza, ti consigliamo di eseguire il deployment dei gateway in uno spazio dei nomi diverso dal control plane.
5. Utilizza l'inserimento automatico di sidecar per inserire la configurazione del 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 i miglioramenti e gli aggiornamenti della sicurezza più recenti.
• Delega la gestione e la manutenzione delle istanze gateway al piano dati gestito di Cloud Service Mesh.

Best practice per il piano dati non gestito

1. Esegui il deployment e gestisci separatamente il control plane e i gateway.
2. Come best practice di sicurezza, ti consigliamo di eseguire il deployment dei gateway in uno spazio dei nomi diverso dal control plane.
3. Utilizza l'inserimento automatico di sidecar per inserire la configurazione del 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 bisogno di privilegi elevati per l'intero cluster.
• Consenti agli amministratori di utilizzare lo stesso strumento o meccanismo di deployment che utilizzano per gestire le applicazioni Kubernetes per eseguire 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 una configurazione è cambiata, gli amministratori aggiornano i pod del gateway semplicemente riavviandoli. In questo modo, l'esperienza di gestione di un deployment del gateway è la stessa di quella dei proxy sidecar per i tuoi servizi.

Esegui il deployment dei gateway

Per supportare gli utenti con strumenti di deployment esistenti, Cloud Service Mesh supporta gli stessi modi per eseguire il deployment di un gateway di Istio: IstioOperator, Helm e Kubernetes YAML. Ogni metodo produce lo stesso risultato. Anche se puoi scegliere il metodo con cui hai più familiarità, ti consigliamo di utilizzare il metodo Kubernetes YAML perché è più facile da modificare e puoi archiviare i manifest idratati nel controllo del codice sorgente.

1. Crea uno spazio dei nomi per il gateway se non ne hai già uno. Sostituisci GATEWAY_NAMESPACE con il nome del tuo spazio dei nomi.

   kubectl create namespace GATEWAY_NAMESPACE
   

2. Per abilitare l'inserimento automatico, etichetta gli spazi dei nomi con le etichette di inserimento predefinite se il tag predefinito è configurato o con l'etichetta di revisione allo spazio dei nomi. L'etichetta che aggiungi dipende anche dal fatto che tu abbia eseguito il deployment di Cloud Service Mesh gestito o installato il control plane in-cluster. L'etichetta viene utilizzata dal webhook di inserimento del sidecar per associare i sidecar inseriti a una particolare revisione del control plane.

   Seleziona la scheda di seguito in base al tipo di installazione (gestita o nel cluster).

   Gestito

   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 della revisione che corrisponde al canale di rilascio disponibile per la versione di Cloud Service Mesh.

   Interno al cluster

   Per i control plane in-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 il comando seguente per individuare l'etichetta di revisione su istiod per il control plane in-cluster:

   kubectl get deploy -n istio-system -l app=istiod \
     -o=jsonpath='{.items[*].metadata.labels.istio\.io\/rev}''{"\n"}'
   

3. Abilita lo spazio dei nomi per l'inserimento. Sostituisci e REVISION con il valore dell'etichetta della revisione.

   Nota:puoi sostituire istio.io/rev con l'etichetta istio-injection=enabled se il tag predefinito è configurato. 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
   

4. Se hai installato Cloud 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 verificare che siano presenti 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.

5. 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.

   In entrata

   kubectl apply -n GATEWAY_NAMESPACE -f samples/gateways/istio-ingressgateway
   

   In uscita

   kubectl apply -n GATEWAY_NAMESPACE -f samples/gateways/istio-egressgateway
   

6. 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

Importante: le risorse del gateway devono essere gestite come qualsiasi altra applicazione Kubernetes. Gli esempi nel repository anthos-service-mesh-packages sono pensati come guida e per iniziare rapidamente e devi personalizzarli in base alle tue esigenze.

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, consentendoti di specificare quale traffico vuoi che entri o esca 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 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 di Gateway e servizio virtuale, consulta frontend.yaml nell'applicazione di esempio Online Boutique.

Eseguire l'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 in loco. Poiché i gateway utilizzano l'inserimento di pod, i nuovi pod gateway creati verranno automaticamente inseriti con la configurazione più recente, che include la versione.

Se vuoi modificare la revisione del control plane in uso dal gateway, puoi impostare l'etichetta istio.io/rev nel deployment del gateway, che attiverà anche un riavvio graduale.

Control plane gestito

Poiché Google gestisce gli upgrade del control plane per il control plane gestito, puoi semplicemente riavviare il deployment del gateway e i nuovi pod verranno inseriti automaticamente con la configurazione e la versione più recenti.

kubectl rollout restart deployment istio-ingressgateway \
  -n GATEWAY_NAMESPACE

Control plane in-cluster

Per applicare lo stesso pattern ai gateway quando hai il control plane in-cluster, devi modificare la revisione del control plane in uso dal gateway. Imposta l'etichetta istio.io/rev sul deployment del gateway che attiverà un riavvio in sequenza. I passaggi necessari dipendono dal fatto che tu debba aggiornare l'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 sullo spazio dei nomi sul nuovo valore di revisione:

    kubectl label namespace GATEWAY_NAMESPACE \
      istio-injection- istio.io/rev=REVISION \
      --overwrite
  

• Se hai attivato l'inserimento solo per il pod gateway, imposta l'etichetta istio.io/rev nel deployment sul nuovo valore di revisione come nel seguente file YAML di 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
  

  Nota: se image non si aggiorna automaticamente con l'immagine proxy di Cloud Service Mesh effettiva, il container non verrà trovato e si verificherà un errore. Per i passaggi successivi, vedi Risolvere i problemi relativi ai gateway.

Upgrade canary (avanzato)

Se utilizzi il control plane in-cluster e vuoi controllare più lentamente l'implementazione di una nuova revisione del control plane, 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 traffico. Ad esempio, se vuoi eseguire il rollback di 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

Nota: se image non si aggiorna automaticamente con l'immagine proxy Cloud Service Mesh effettiva, il container non verrà trovato e si verificherà un errore. Per i passaggi successivi, consulta Risolvere i problemi relativi ai gateway.

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

Nota: a differenza dei servizi applicativi di cui è stato eseguito il deployment all'interno del mesh, non puoi utilizzare lo spostamento del traffico di Istio per distribuire il traffico tra le versioni del gateway perché il traffico proviene direttamente da client esterni che Istio non controlla. Puoi invece controllare la distribuzione del traffico in base al numero di repliche di ogni deployment. Se utilizzi un altro bilanciatore del carico davanti a Istio, puoi utilizzarlo anche per controllare la distribuzione del traffico.

Se ritieni che le tue applicazioni funzionino come previsto, esegui questo comando per eseguire la transizione alla nuova versione eliminando ladeploymente con il vecchio 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 versione 1.14 e successive, la versione TLS minima predefinita per i server gateway è 1.2. Puoi configurare la versione TLS minima utilizzando il campo minProtocolVersion. Per saperne di più, consulta ServerTLSSettings.

Risolvere 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 segnaposto nel campo image. Dopo la chiamata al webhook di mutazione, Cloud Service Mesh sostituisce automaticamente questo segnaposto con l'immagine proxy Cloud Service Mesh effettiva. Se la chiamata al webhook di mutazione non va a buon fine, il segnaposto auto rimane e il contenitore non verrà trovato. In genere, questo problema è causato da un'etichetta dello spazio dei nomi errata. Assicurati di aver configurato lo spazio dei nomi corretto, quindi esegui di nuovo il deployment o l'upgrade del gateway.