Installazione e upgrade dei gateway con le API Istio
Cloud Service Mesh ti offre la possibilità di eseguire il deployment e gestire i gateway nell'ambito di dalla tua rete 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 consente di configurare un nodo di uscita dedicato per il traffico che esce dal mesh, consentendoti di limitare i servizi che possono o devono accedere a reti esterne o consentire il controllo sicuro del traffico in uscita per aggiungere ad esempio per la tua rete mesh.
Gateway in entrata: un gateway in entrata consente di configurare un'entrata dedicata per ricevere le connessioni HTTP/TCP in entrata.
Gateway est-ovest: un proxy per est-ovest per consentire ai carichi di lavoro dei servizi di comunicare attraverso i confini del cluster un mesh multi-principale 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 del gateway
proxy, nonché esempi di configurazione di istio-ingressgateway
e
istio-egressgateway
proxy gateway.
Puoi eseguire il deployment dei gateway in diversi modi e puoi utilizzare più di una topologia nello stesso cluster. Consulta Topologie di deployment del gateway nella documentazione di Istio, per saperne di più su queste topologie.
Best practice per l'implementazione dei 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
- Attiva il piano di dati gestito.
- Aggiungi un'etichetta di revisione gestita a una nello spazio dei nomi.
- Esegui il deployment e gestisci il piano di controllo e i gateway separatamente.
- Come best practice per la sicurezza, ti consigliamo di implementare i gateway in un distinto spazio dei nomi rispetto al piano di controllo.
- Utilizza le funzionalità di iniezione automatica del file collaterale (inserimento automatico) per inserire la configurazione proxy per gateway simili a come inseriresti i proxy collaterali per i tuoi servizi.
Queste best practice:
- Assicurati che i gateway gestiti siano automaticamente aggiornati con le ultime miglioramenti e aggiornamenti della sicurezza.
- 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
- Esegui il deployment e gestisci il piano di controllo e i gateway separatamente.
- Come best practice per la sicurezza, ti consigliamo di implementare i gateway in un distinto spazio dei nomi rispetto al piano di controllo.
- Utilizza le funzionalità di iniezione automatica del file collaterale (inserimento automatico) per inserire la configurazione proxy per gateway simili a come inseriresti i proxy collaterali per i tuoi servizi.
Queste best practice:
- Consenti agli amministratori dello spazio dei nomi di gestire i gateway senza dover privilegi elevati per l'intero cluster.
- Consenti agli amministratori di utilizzare gli stessi strumenti o meccanismi di deployment che usano per gestire le applicazioni Kubernetes, gateway VPN ad alta disponibilità.
- Concedi agli amministratori il controllo completo sul deployment del gateway per semplificare le operazioni. Quando è disponibile un nuovo upgrade o viene è cambiata, 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 del 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 YAML di Kubernetes. Ogni metodo produce lo stesso
o il risultato finale. 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.
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
Attiva lo spazio dei nomi per l'iniezione. I passaggi dipendono dall'implementazione del piano di controllo.
Gestito (TD)
- 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 piano di controllo Managed Istiod: Ti consigliamo di usare l'inserimento predefinito, ma l'inserimento basato sulle revisioni supportati. Segui queste istruzioni:
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 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 sotto la colonna
NAME
è l'etichetta di revisione che corrisponde al canale di rilascio disponibile per la versione di Cloud Service Mesh.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 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 sulle revisioni: segui le istruzioni riportate di seguito:
Usa questo 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"}'
Applica l'etichetta di revisione allo spazio dei nomi. Nel comando seguente,
REVISION_LABEL
è il valore della revisioneistiod
che hai annotato nel passaggio precedente.kubectl label namespace GATEWAY_NAMESPACE \ istio-injection- istio.io/rev=REVISION_LABEL --overwrite
Copia i file di configurazione per i gateway di esempio dal Repository
anthos-service-mesh
.Cambia la directory nella directory
samples
. Per assicurarti di trovarti nella directory corretta, esegui il comandols
per elencare i contenuti della directory e poi verifica che esistano una directorygateways
(a cui accederai nel passaggio successivo) e una directoryonline-boutique
.Eseguire il deployment di un gateway in entrata o in uscita. Questi si trovano nella
samples/gateways/
così com'è o modificala 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
Gestisci le risorse del gateway come qualsiasi altra applicazione Kubernetes. Gli esempi in
il repository anthos-service-mesh-packages
è destinato a fornire indicazioni e un
Guida rapida. 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 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 di un servizio virtuale, vedi 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 le istruzioni in loco pattern di upgrade. 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 per il piano di controllo gestito, basta riavviare il deployment del gateway e i nuovi pod automaticamente l'ultima configurazione e la versione più recente.
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'inserimento, imposta l'etichetta
istio.io/rev
su lo spazio dei nomi al 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 gateway, imposta
istio.io/rev
etichetta sul deployment al nuovo valore di revisione come la 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
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 gateway
Deployment con l'etichetta istio.io/rev=REVISION
impostata su
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 il deployment, avrai due versioni Gateway, entrambi selezionati 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 ritieni che le tue applicazioni funzionino come previsto, esegui questo 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 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
Risolvi i problemi relativi ai gateway
Impossibile aggiornare l'immagine della porta di accesso 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 mutante,
Cloud Service Mesh sostituisce automaticamente questo segnaposto con il valore
Immagine proxy Cloud Service Mesh. Se la chiamata al webhook mutante non va a buon fine, auto
rimane invariato e il container non è stato 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.