Installazione e upgrade dei gateway con le API Istio

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 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 lascia il mesh, consentendoti di limitare i servizi che possono o devono accedere alle reti esterne o di abilitare il controllo sicuro del traffico in uscita per aggiungere sicurezza al 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 tra i limiti dei cluster in un mesh multi-primary 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 personalizzati.

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

Best practice per il deployment dei gateway

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

Best practice per il piano dati gestito

  1. Abilita 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 per la 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 (auto-injection) 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 del 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 per la 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 (auto-injection) 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:

  • Consentono agli amministratori dello spazio dei nomi di gestire i gateway senza la necessità di privilegi elevati per l'intero cluster.
  • Consentono agli amministratori di utilizzare gli stessi strumenti o meccanismi di deployment che utilizzano per gestire le applicazioni Kubernetes per eseguire il deployment e gestire i gateway.
  • Offrono agli amministratori il controllo completo del deployment del gateway e semplificano 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 di quella dei proxy sidecar per i tuoi servizi.

Esegui il deployment del gateway di esempio

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. Sebbene tu possa 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.

I passaggi che seguono mostrano come eseguire il deployment di un gateway di esempio.

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

  2. Abilita lo spazio dei nomi per l'inserimento. I passaggi dipendono dall'implementazione del control plane.

    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 questo 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 un utente esistente con il control plane Istiod gestito: ti consigliamo di utilizzare l'inserimento predefinito, ma è supportato anche l'inserimento basato sulla revisione. Segui queste istruzioni:

    1. Esegui questo comando 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 precedente sono presenti due revisioni del control plane, rimuovine una. L'utilizzo di più canali del control plane nel cluster non è supportato.

      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.

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

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

    Interno al cluster

    Consigliato: esegui questo 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 sulla revisione: Segui queste istruzioni:

    1. Utilizza il comando seguente per individuare l'etichetta della 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 comando seguente, REVISION_LABEL è il valore dell'etichetta di 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 anthos-service-mesh repository.

  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 siano presenti 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. Questi si trovano nella directory samples/gateways/ così com'è oppure modificali 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. Gli esempi nel repository anthos-service-mesh-packages sono pensati per fornire indicazioni e un avvio rapido. Personalizzali in base alle tue esigenze.

Selettori di gateway

Applica una configurazione del gateway ai proxy istio-ingressgateway e istio-egressgateway per gestire il traffico in entrata e in uscita per il mesh, consentendoti di specificare il traffico che 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 del gateway e del servizio virtuale, consulta frontend.yaml nell'applicazione di esempio Online Boutique.

Esegui l'upgrade dei gateway

Upgrade in loco

Nella 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 dei pod, i nuovi pod del gateway creati verranno inseriti automaticamente con la configurazione più recente, inclusa la versione.

Se vuoi modificare la revisione del control plane in uso dal gateway, puoi impostare l'etichetta istio.io/rev sul 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

Piano di controllo 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 graduale. I passaggi necessari variano a seconda 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 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 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 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

Upgrade canary (avanzato)

Se utilizzi il control plane in-cluster e vuoi controllare più lentamente il rollout 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 rollout 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

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

Se sei soddisfatto del funzionamento previsto delle tue applicazioni, esegui questo comando per passare alla nuova versione eliminando il deployment con l'etichetta istio.io/rev precedente impostata:

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 la nuova etichetta istio.io/rev impostata:

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 saperne di più, consulta ServerTLSSettings.

Funzionalità non supportate

Se hai l'implementazione del TRAFFIC_DIRECTOR control plane, allora 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 al webhook di mutazione, Cloud Service Mesh sostituisce automaticamente questo segnaposto con l'immagine del proxy Cloud Service Mesh effettiva. Se la chiamata al webhook di mutazione non riesce, il segnaposto auto rimane e il container non viene trovato. In genere, questo è dovuto a 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.