Installazione e upgrade dei gateway con le API Istio

Per ulteriori informazioni, consulta la panoramica di Cloud Service Mesh.

Cloud Service Mesh ti offre la possibilità di eseguire il deployment e gestire i gateway all'interno del tuo mesh di servizi. Un gateway descrive un bilanciatore del carico che opera all'edge del mesh e riceve connessioni HTTP/TCP in entrata o in uscita. I gateway vengono utilizzati principalmente per gestire il traffico in entrata, ma puoi anche configurarli per gestire altri tipi di traffico.

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

• Gateway in entrata: un gateway in entrata ti consente di configurare un nodo di ingresso dedicato per ricevere connessioni HTTP/TCP in entrata.

• Gateway est-ovest: un proxy per il traffico est-ovest per consentire ai carichi di lavoro dei servizi di comunicare oltre i confini del cluster in un mesh multi-principale 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 proxy gateway istio-ingressgateway e istio-egressgateway.

Puoi eseguire il deployment dei gateway in diversi modi e puoi utilizzare più di una topologia nello stesso cluster. Per saperne di più su queste topologie, consulta la sezione Topologie di deployment dei gateway nella documentazione di Istio.

Best practice per l'implementazione di gateway

Le best practice per il deployment dei gateway dipendono dall'utilizzo del piano dati gestito o del piano dati non gestito.

Best practice per il piano dati gestito

1. Attiva il piano di dati gestito.
2. Aggiungi un'etichetta di revisione gestita a un ambito.
3. Esegui il deployment e gestisci il piano di controllo e i gateway separatamente.
4. Come best practice per la sicurezza, ti consigliamo di implementare i gateway in un distinto spazio dei nomi rispetto al piano di controllo.
5. Utilizza l'inserimento automatico di sidecar (inserimento automatico) 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 tuoi gateway gestiti vengano aggiornati automaticamente con i miglioramenti e gli aggiornamenti della sicurezza più recenti.
• Offload la gestione e la manutenzione delle istanze gateway nel data plane gestito di Cloud Service Mesh.

Best practice per il piano dati non gestito

1. Esegui il deployment e gestisci il piano di controllo e i gateway separatamente.
2. Come best practice per la sicurezza, ti consigliamo di implementare i gateway in un distinto spazio dei nomi rispetto al piano di controllo.
3. Utilizza l'inserimento automatico di sidecar (inserimento automatico) 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 dover disporre di privilegi elevati per l'intero cluster.
• Consenti agli amministratori di utilizzare gli stessi strumenti o meccanismi di deployment impiegati per gestire le applicazioni Kubernetes per eseguire il deployment e la gestione dei gateway.
• Offrire agli amministratori il controllo completo sul deployment del gateway e anche simplificare le operazioni. Quando è disponibile un nuovo upgrade o una configurazione è stata modificata, gli amministratori aggiornano i pod del gateway riavviandoli. In questo modo, l'esperienza di gestione di un deployment del gateway è la stessa dell'utilizzo di proxy sidecar per i tuoi servizi.

Esegui il deployment di un gateway di esempio

Per supportare gli utenti con gli 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. Sebbene tu possa scegliere il metodo che conosci meglio, ti consigliamo di utilizzare il metodo YAML di Kubernetes perché è più facile da modificare e puoi archiviare i manifest idratati nel controllo del codice sorgente.

I passaggi riportati di seguito mostrano come eseguire il deployment di un gateway di esempio.

1. Crea un nome di spazio 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. Attiva lo spazio dei nomi per l'iniezione. I passaggi dipendono dall'implementazione del piano di controllo.

   Gestito (TD)

   1. Applica l'etichetta di inserimento predefinita allo spazio dei nomi:

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

   Gestito (Istiod)

   Consigliato:esegui il seguente comando per applicare l'etichetta di inserimento predefinita allo spazio dei nomi:

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

   Se sei già un utente con il piano di controllo Istiod gestito: consigliamo di utilizzare l'iniezione predefinita, ma è supportata anche l'iniezione basata su revisione. Segui le istruzioni riportate di seguito:

   1. Esegui il comando seguente per individuare i canali di rilascio disponibili:

      kubectl -n istio-system get controlplanerevision
      

      L'output è simile al seguente:

      NAME                AGE
      asm-managed-rapid   6d7h
      

      NOTA: se nell'elenco riportato sopra sono presenti due revisioni del piano di controllo, rimuovine una. La presenza di più canali del control plane nel cluster non è supportata.

      Nell'output, il valore nella colonna NAME è l'etichetta di revisione corrispondente al canale di rilascio disponibile per la versione di Cloud Service Mesh.

   2. Applica l'etichetta di revisione allo spazio dei nomi:

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

   All'interno del cluster

   Consigliato:esegui il seguente comando per applicare l'etichetta di inserimento predefinita allo spazio dei nomi:

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

   Ti consigliamo di utilizzare l'inserimento predefinito, ma è supportato anche l'inserimento basato sulle revisioni: segui le istruzioni riportate di seguito:

   1. Utilizza il seguente comando per individuare l'etichetta di revisione su istiod:

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

   2. Applica l'etichetta di revisione allo spazio dei nomi. Nel seguente comando, REVISION_LABEL è il valore dell'etichetta della revisione istiod che hai annotato nel passaggio precedente.

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

3. Copia i file di configurazione per i gateway di esempio dal repository anthos-service-mesh.

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

5. Esegui il deployment di un gateway in entrata o in uscita. che si trovano nella directory samples/gateways/ così come sono o modificarli 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

Gestisci le risorse del gateway come qualsiasi altra applicazione Kubernetes. I sample nel repository anthos-service-mesh-packages sono pensati per fornire indicazioni e un quickstart. Personalizzarle in base alle tue esigenze.

Selettori di gateway

Applicchi una configurazione di gateway ai proxy istio-ingressgateway e istio-egressgateway per gestire il traffico in entrata e in uscita per il tuo mesh, in modo da specificare il traffico che vuoi far entrare o uscire dal mesh. Le etichette dei pod di un deployment di gateway vengono utilizzate dalle risorse di configurazione del gateway, pertanto è importante che il selettore del gateway corrisponda a queste etichette.

Ad esempio, nei deployment precedenti, l'etichetta istio=ingressgateway è impostata sui pod gateway. Per applicare una configurazione del gateway a questi implementazioni, 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 un gateway e di un 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 situ. Poiché i gateway utilizzano l'iniezione di pod, i nuovi pod gateway creati verranno iniettati automaticamente con la configurazione più recente, che include la versione.

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

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 i nuovi pod verranno iniettati automaticamente con 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 in cluster, devi modificare la revisione del piano di controllo in uso dal gateway. Imposta l'etichetta istio.io/rev sul deployment del gateway, che attiverà un riavvio graduale. I passaggi richiesti dipendono dal fatto che tu debba aggiornare l'etichetta di revisione nello spazio dei nomi e/o nel pod gateway.

• Se hai etichettato lo spazio dei nomi per l'iniezione, 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'iniezione solo per il pod gateway, imposta l'etichetta istio.io/rev sul deployment sul nuovo valore di revisione, come nel 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 Cloud 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 Cloud Service Mesh effettiva, il contenitore non verrà trovato e si verificherà un errore. Per i passaggi successivi, consulta Risolvere i problemi relativi ai gateway.

Upgrade canary (avanzato)

Se utilizzi il piano di controllo in-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 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

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

Quando viene 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 di applicazioni di cui è stato eseguito il deployment all'interno del mesh, non puoi utilizzare il trasferimento del traffico Istio per distribuire il traffico tra le versioni del gateway perché il loro traffico proviene direttamente da client esterni che Istio non controlla. In alternativa, puoi 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 passare alla nuova versione eliminando il deployment con l'etichetta istio.io/rev precedente:

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, la versione TLS minima predefinita per i server gateway è 1.2. Puoi configurare la versione TLS minima utilizzando il campo minProtocolVersion. Per ulteriori informazioni, consulta ServerTLSSettings.

Funzionalità non supportate

Se hai eseguito l'TRAFFIC_DIRECTOR implementazione del control plane, then i seguenti campi o valori in Gateway non sono supportati:

• ServerTLSSettings.TLSmode con valore AUTO_PASSTHROUGH
• ServerTLSSettings.verifyCertificateSpki
• ServerTLSSettings.verifyCertificateHash

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 all'webhook con mutazioni, Cloud Service Mesh sostituisce automaticamente questo segnaposto con l'immagine proxy di Cloud Service Mesh effettiva. Se la chiamata all'webhook con modifica non va a buon fine, il segnaposto auto rimane e il contenitore non viene trovato. Questo problema è solitamente 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.