Installazione ed 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 opera sul perimetro del mesh che riceve connessioni HTTP/TCP in entrata o in uscita. I gateway sono proxy Envoy che ti forniscono 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 consente di configurare un nodo di uscita dedicato per il traffico che esce dal mesh, consentendoti di limitare i servizi che possono o dover accedere alle reti esterne o di abilitare il controllo sicuro del traffico in uscita per aggiungere, ad esempio, sicurezza al tuo mesh.
Gateway est-ovest: un proxy per il traffico est-ovest per consentire ai carichi di lavoro dei servizi di comunicare oltre i confini dei cluster in un mesh multi-primario su reti diverse. Per impostazione predefinita, questo gateway sarà pubblico su internet.
In questa pagina vengono descritte le best practice per il deployment e l'upgrade dei proxy del gateway, nonché gli esempi di configurazione dei proxy dei gateway istio-ingressgateway
e istio-egressgateway
.
Funzionalità come la suddivisione del traffico, i reindirizzamenti e la logica dei nuovi tentativi sono possibili applicando una configurazione di gateway ai proxy del gateway. Quindi, invece di aggiungere il routing del traffico a livello di applicazione (L7) alla stessa risorsa API, associa un servizio virtuale al gateway. Ciò consente di gestire il traffico del gateway come qualsiasi altro traffico del piano dati
nel mesh di servizi.
Puoi eseguire il deployment dei gateway in diversi modi e scegliere di utilizzare più una topologia all'interno dello stesso cluster. Per saperne di più su queste topologie, consulta Topologie di deployment dei 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
- Abilitare il piano dati gestito.
- Aggiungi un'etichetta di revisione gestita a uno spazio dei nomi.
- Esegui il deployment e la gestione del piano di controllo e dei gateway separatamente.
- Come best practice per la sicurezza, consigliamo di eseguire il deployment dei gateway in uno spazio dei nomi diverso da quello del piano di controllo.
- Utilizza l'inserimento automatico dei componenti collaterali (inserimento automatico) per inserire la configurazione proxy per i gateway in modo simile a come inseriresti i proxy collaterali per i servizi.
Queste best practice:
- Assicurati che i tuoi gateway gestiti siano aggiornati automaticamente con i miglioramenti e gli aggiornamenti della sicurezza più recenti.
- Trasferisce la gestione e la manutenzione delle istanze del gateway al piano dati gestito da Anthos Service Mesh.
Best practice per un piano dati non gestito
- Esegui il deployment e la gestione del piano di controllo e dei gateway separatamente.
- Come best practice per la sicurezza, consigliamo di eseguire il deployment dei gateway in uno spazio dei nomi diverso da quello del piano di controllo.
- Utilizza l'inserimento automatico dei componenti collaterali (inserimento automatico) per inserire la configurazione proxy per i gateway in modo simile a come inseriresti i proxy collaterali per i 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 che utilizzano per gestire le applicazioni Kubernetes per il deployment e la gestione dei gateway.
- Offri agli amministratori il controllo completo sul deployment del gateway e semplifica le operazioni. Se è disponibile un nuovo upgrade o se la configurazione viene modificata, gli amministratori aggiornano i pod del gateway semplicemente riavviandoli. In questo modo, l'utilizzo di un deployment gateway equivale a gestire i proxy collaterali per i servizi.
Esegui il deployment dei gateway
Per supportare gli utenti con strumenti di deployment esistenti, Anthos Service Mesh supporta gli stessi modi per eseguire il deployment di un gateway come Istio: IstioOperator
, Helm e YAML di Kubernetes. Ogni metodo produce lo stesso
risultato. Anche se puoi scegliere il metodo che conosci meglio, ti consigliamo di usare il metodo YAML di Kubernetes, perché è più facile da modificare e puoi archiviare manifest idrati 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 spazio dei nomi.kubectl create namespace GATEWAY_NAMESPACE
Per abilitare l'inserimento automatico, etichetta gli spazi dei nomi con le etichette di iniezione predefinite, se è configurato il tag predefinito, o con l'etichetta di revisione nello spazio dei nomi. L'etichetta che aggiungi dipende anche dal fatto che tu abbia eseguito il deployment di Anthos Service Mesh gestito o installato il piano di controllo nel cluster. L'etichetta viene utilizzata dal webhook iniettore collaterale per associare i file collaterali inseriti a una determinata revisione del piano di controllo.
Seleziona la scheda riportata di seguito in base al tipo di installazione (gestita o in 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 di revisione che corrisponde al canale di rilascio disponibile per la versione di Anthos 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 aistio.io/rev=asm-1204-0
, in cuiasm-1204-0
identifica la versione di Anthos Service Mesh. La revisione diventa parte del nome del servizioistiod
, ad esempio:istiod-asm-1204-0.istio-system
Usa il comando seguente per individuare l'etichetta della revisione su
istiod
per il 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.kubectl label namespace GATEWAY_NAMESPACE istio-injection- istio.io/rev=REVISION --overwrite
Se hai installato Anthos Service Mesh utilizzando
asmcli
, passa alla directory specificata in--output_dir
, quindicd
alla directorysamples
.Se non hai eseguito l'installazione utilizzando
asmcli
, copia i file di configurazione per i gateway dal repositoryanthos-service-mesh
.Puoi eseguire il deployment della configurazione del gateway di esempio situata nella directory
samples/gateways/
così com'è o modificarla 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 gateway
Applica una configurazione del gateway ai proxy istio-ingressgateway
e istio-egressgateway
per gestire il traffico in entrata e in uscita per la tua rete mesh, in modo da specificare il traffico in entrata o in uscita dal mesh. Le etichette sui pod del deployment di un gateway vengono utilizzate dalle risorse di configurazione del gateway, perciò è 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 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 gateway e servizio virtuale, consulta frontend.yaml nell'applicazione di esempio Boutique Online.
Esegui 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 vigore. Poiché i gateway utilizzano l'inserimento dei pod, i nuovi pod dei gateway creati verranno inseriti 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, il che attiverà anche un riavvio in sequenza.
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 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 piano di controllo nel cluster, devi cambiare la revisione del piano di controllo utilizzata dal gateway.
Imposta l'etichetta istio.io/rev
sul deployment del gateway che attiverà un riavvio in sequenza. I passaggi richiesti variano a seconda che sia necessario 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 il 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 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 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" \
-n GATEWAY_NAMESPACE
L'output è simile al seguente:
NAME PODS
istio-ingressgateway istio-ingressgateway-788854c955-8gv96,istio-ingressgateway-canary-b78944cbd-mq2qf
Se sei sicuro che le applicazioni funzionino come previsto, esegui questo comando 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 si è verificato 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 Anthos Service Mesh 1.14 e versioni successive, 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.
Risolvere i problemi relativi ai gateway
Impossibile aggiornare l'immagine del gateway da auto
Quando esegui il deployment o l'upgrade di un gateway, Anthos Service Mesh inserisce auto
come segnaposto nel campo image
. Dopo la chiamata al webhook mutante, Anthos Service Mesh sostituisce automaticamente questo segnaposto con l'immagine proxy effettiva del proxy Anthos Service Mesh. Se la chiamata al webhook mutante non va a buon fine, il segnaposto auto
rimane e il contenitore non verrà trovato. In genere questo è causato da un'etichetta dello spazio dei nomi non corretta. Assicurati di aver configurato lo spazio dei nomi corretto, quindi esegui di nuovo il deployment o l'upgrade del gateway.