Versione 1.13

Installazione e upgrade dei gateway

Anthos Service Mesh ti offre la possibilità di eseguire il deployment e gestire i gateway come parte del tuo mesh di servizi. Un gateway descrive un bilanciatore del carico che funziona a livello del mesh che riceve connessioni HTTP/TCP in entrata o in uscita. I gateway sono proxy di 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 in uscita: un gateway in uscita ti consente di configurare un nodo di uscita dedicato per il traffico in uscita dal mesh, di limitare i servizi che possono o devono accedere a reti esterne o di abilitare il controllo sicuro del traffico in uscita per aggiungere sicurezza al mesh.

  • Gateway est-ovest: un proxy per il traffico east-west per consentire la comunicazione tra i carichi di lavoro dei servizi attraverso i confini dei cluster in una rete multi-principale su reti diverse. Per impostazione predefinita, questo gateway sarà pubblico su Internet.

In questa pagina sono descritte le best practice per il deployment e l'upgrade dei proxy del gateway, nonché esempi di configurazione dei proxy del gateway istio-ingressgateway e istio-egressgateway. È possibile, ad esempio, la suddivisione del traffico, i reindirizzamenti e la logica di nuovo tentativo applicando una configurazione Gateway ai proxy gateway. Invece di aggiungere il routing del traffico a livello di applicazione (L7) alla stessa risorsa API, puoi associare un servizio virtuale al gateway. In questo modo puoi 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 saperne di più su queste topologie, consulta le topologie di deployment del gateway nella documentazione di Istio.

Best practice per il deployment dei gateway

  1. Esegui il deployment del piano di controllo e dei gateway separatamente.
  2. Come best practice per la sicurezza, ti consigliamo di eseguire il deployment dei gateway in uno spazio dei nomi diverso dal piano di controllo.
  3. Utilizza l'inserimento automatico del sidecar (inserimento automatico) per inserire la configurazione del proxy per i gateway, come fai per i proxy dei tuoi servizi.

Queste best practice:

  • Consenti agli amministratori dello spazio dei nomi di gestire i gateway senza bisogno di disporre di privilegi più elevati per l'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.
  • Offre agli amministratori il controllo completo sul deployment del gateway, oltre a semplificare le operazioni. Quando è disponibile un nuovo upgrade o è cambiata una configurazione, gli amministratori aggiornano i pod del gateway semplicemente riavviandoli. In questo modo sarà possibile utilizzare il deployment di un gateway allo stesso modo in cui utilizzi i proxy sidecar per i tuoi servizi.

Eseguire il deployment dei gateway

Per supportare gli utenti con gli strumenti di deployment esistenti, Anthos Service Mesh supporta gli stessi modi per eseguire il deployment di un gateway di Istio: IstioOperator, Helm e YAML 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 memorizzare i manifest idrati nel controllo del codice sorgente.

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

    kubectl create namespace GATEWAY_NAMESPACE

  2. Per abilitare l'inserimento automatico, etichetta i tuoi 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 da se hai eseguito il deployment di Kubernetes Service Mesh gestito o hai installato il piano di controllo in-cluster. L'etichetta viene utilizzata dal webhook dell'iniettore sidecar per associare le sidecar iniettate a una revisione specifica del piano di controllo.

    Seleziona la scheda riportata di seguito a seconda del tipo di installazione (gestita da Google o nel cluster).

    Gestita da Google

    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 presente nella colonna NAME è l'etichetta di revisione che corrisponde al canale di rilascio disponibile per la versione Anthos Service Mesh.

    Nel cluster

    Per i piani di controllo in-cluster, il servizio e il deployment istiod di solito hanno un'etichetta di revisione simile a istio.io/rev=asm-1134-4, dove asm-1134-4 identifica la versione di Anthos Service Mesh. La revisione diventa parte del nome del servizio istiod, ad esempio: istiod-asm-1134-4.istio-system

    Utilizza il seguente comando per individuare l'etichetta di revisione su istiod per il piano di controllo 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 di revisione.

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

  4. Se hai installato Anthos Service Mesh utilizzando asmcli, passa alla directory specificata in --output_dir, quindi cd alla directory samples.

    Se non hai installato l'app utilizzando asmcli, copia i file di configurazione per i gateway dal repository anthos-service-mesh.

  5. Puoi eseguire il deployment della configurazione di gateway di esempio che si trova nella directory samples/gateways/ così com'è o modificarla, se necessario.

    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

Selettori gateway

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

Ad esempio, nei deployment in alto, l'etichetta istio=ingressgateway è impostata sui pod 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 del gateway e servizio virtuale, consulta frontend.yaml nell'applicazione di esempio Online Boutique.

Upgrade dei gateway

Upgrade in loco

Nella maggior parte dei casi d'uso, è necessario eseguire l'upgrade dei gateway seguendo il pattern di upgrade esistente. Poiché i gateway utilizzano l'inserimento di pod, i nuovi pod 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 un riavvio in sequenza.

Piano di controllo gestito da Google
Dato che Google gestisce gli upgrade del piano di controllo per il piano di controllo gestito da Google, 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 nel 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 in sequenza.

  1. Aggiorna l'etichetta di revisione sullo spazio dei nomi o sul 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

OPPURE

  • Se hai abilitato l'inserimento solo per il pod gateway:
    • Imposta l'etichetta istio.io/rev sul deployment sul nuovo valore di revisione
      • 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 interno al 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 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 hai la certezza che le tue applicazioni funzionino come previsto, esegui questo comando per passare alla nuova versione eliminando il Deployment 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 della tua 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:

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