Eseguire l'onboarding dei carichi di lavoro Kubernetes
Questa pagina mostra come eseguire l'onboarding dei carichi di lavoro Kubernetes con Cloud Service Mesh.
Esegui il deployment dei servizi Kubernetes
Per eseguire il deployment dei servizi Kubernetes in cluster con Cloud Service Mesh, devi seguire questi passaggi:
Creare servizi Kubernetes per tutti i container. Tutti i deployment devono avere un servizio Kubernetes collegato.
Assegna un nome alle porte di servizio. Sebbene GKE consenta di definire porte di servizio senza nome, Cloud Service Mesh richiede di fornire un nome per una porta che corrisponda al protocollo della porta.
Etichetta i tuoi deployment. In questo modo puoi utilizzare le funzionalità di gestione del traffico di Cloud Service Mesh, come la suddivisione del traffico tra le versioni dello stesso servizio.
Il deployment e il servizio di esempio che seguono illustrano questi requisiti:
Dopo aver eseguito il deployment dei servizi in un cluster con Cloud Service Mesh, assicurati di inserire proxy sidecar.
Esempio: deployment dell'esempio di Boutique online
L'applicazione di esempio Online Boutique nel repository
anthos-service-mesh-packages
viene modificata rispetto all'insieme originale di manifest nel repository
microservices-demo
. Seguendo le best practice, il deployment di ogni servizio viene eseguito in uno spazio dei nomi separato con un account di servizio univoco.
Crea gli spazi dei nomi per l'applicazione:
kubectl apply -f \ DIR_PATH/samples/online-boutique/kubernetes-manifests/namespaces
Output previsto:
namespace/ad created namespace/cart created namespace/checkout created namespace/currency created namespace/email created namespace/frontend created namespace/loadgenerator created namespace/payment created namespace/product-catalog created namespace/recommendation created namespace/shipping created
Attiva l'inserimento automatico del file collaterale (inserimento automatico). Questo comando è diverso a seconda che utilizzi Cloud Service Mesh gestito o Cloud Service Mesh nel cluster. Se utilizzi Cloud Service Mesh gestito, usa le etichette di inserimento predefinite (ad esempio,
istio-injection=enabled
). Se utilizzi Cloud Service Mesh nel cluster, utilizza la stessa etichetta di revisione che hai utilizzato per annotare lo spazio dei nomi del gateway in entrata. Tieni presente che i clienti esistenti del piano di controllo gestito migrati possono utilizzare le etichette di revisione esistenti oltre a quella predefinita di inserimento.Etichette di inserimento predefinite
Applica le etichette di inserimento predefinite allo spazio dei nomi. Nel comando seguente, GATEWAY_NAMESPACE è lo stesso valore che hai utilizzato per annotare lo spazio dei nomi del gateway in entrata.
for ns in ad cart checkout currency email frontend loadgenerator payment product-catalog recommendation shipping; do kubectl label namespace $ns istio-injection=enabled istio.io/rev- done;
Output previsto:
namespace/ad labeled namespace/cart labeled namespace/checkout labeled namespace/currency labeled namespace/email labeled namespace/frontend labeled namespace/loadgenerator labeled namespace/payment labeled namespace/product-catalog labeled namespace/recommendation labeled namespace/shipping labeled
Etichetta di revisione
Applica l'etichetta di revisione agli spazi dei nomi dell'applicazione. Nel comando seguente, REVISION è lo stesso valore che hai utilizzato per annotare lo spazio dei nomi del gateway in entrata.
for ns in ad cart checkout currency email frontend loadgenerator payment product-catalog recommendation shipping; do kubectl label namespace $ns istio.io/rev=REVISION --overwrite done;
Output previsto:
namespace/ad labeled namespace/cart labeled namespace/checkout labeled namespace/currency labeled namespace/email labeled namespace/frontend labeled namespace/loadgenerator labeled namespace/payment labeled namespace/product-catalog labeled namespace/recommendation labeled namespace/shipping labeled
Esegui il deployment dell'applicazione di esempio nel cluster.
Crea gli account di servizio e i deployment:
kubectl apply -f \ DIR_PATH/samples/online-boutique/kubernetes-manifests/deployments
Output previsto:
serviceaccount/ad created deployment.apps/adservice created serviceaccount/cart created deployment.apps/cartservice created serviceaccount/checkout created deployment.apps/checkoutservice created serviceaccount/currency created deployment.apps/currencyservice created serviceaccount/email created deployment.apps/emailservice created serviceaccount/frontend created deployment.apps/frontend created serviceaccount/loadgenerator created deployment.apps/loadgenerator created serviceaccount/payment created deployment.apps/paymentservice created serviceaccount/product-catalog created deployment.apps/productcatalogservice created serviceaccount/recommendation created deployment.apps/recommendationservice created serviceaccount/shipping created deployment.apps/shippingservice created
Crea i servizi:
kubectl apply -f \ DIR_PATH/samples/online-boutique/kubernetes-manifests/services
Output previsto:
service/adservice created service/cartservice created service/checkoutservice created service/currencyservice created service/emailservice created service/frontend created service/frontend-external created service/paymentservice created service/productcatalogservice created service/recommendationservice created service/shippingservice created
Crea le voci di servizio:
kubectl apply -f \ DIR_PATH/samples/online-boutique/istio-manifests/allow-egress-googleapis.yaml
Output previsto:
serviceentry.networking.istio.io/allow-egress-googleapis created serviceentry.networking.istio.io/allow-egress-google-metadata created
Assegnazione di nomi alle porte dei servizi
Per essere incluse in Cloud Service Mesh, le porte di servizio devono essere denominate e il nome deve includere il protocollo della porta, ad esempio:
apiVersion: v1 kind: Service metadata: name: ratings labels: app: ratings service: ratings spec: ports: - port: 9080 name: http
Il nome della porta del servizio può includere un suffisso nella seguente sintassi:
name: protocol[-suffix]
in cui le parentesi quadre indicano un suffisso facoltativo che deve iniziare con un
trattino, ad esempio:
kind: Service metadata: name: myservice spec: ports: - number: 3306 name: mysql - number: 80 name: http-web
Affinché le metriche vengano visualizzate nella console Google Cloud, le porte dei servizi devono essere denominate con uno dei seguenti protocolli: http
, http2
o grpc
.
Le porte dei servizi denominate con il protocollo https
vengono trattate come tcp
e le metriche
per questi servizi non vengono visualizzate.
Inserimento di proxy sidecar
Questa sezione illustra come configurare l'inserimento di proxy sidecar con Cloud Service Mesh per migliorare la sicurezza, l'affidabilità e l'osservabilità della rete. Queste funzioni sono astratte dal container principale dell'applicazione e implementate in un proxy out-of-process comune (il sidecar), fornito come container separato nello stesso pod. Puoi utilizzare le funzionalità di Cloud Service Mesh senza riprogettare le tue applicazioni di produzione per partecipare a un mesh di servizi.
L'inserimento automatico del proxy sidecar (iniezione automatica) si verifica quando Cloud Service Mesh rileva un'etichetta dello spazio dei nomi che configuri per il pod del carico di lavoro. Il proxy intercetta tutto il traffico in entrata e in uscita verso i carichi di lavoro e comunica con Cloud Service Mesh.
Attivazione dell'inserimento automatico di file collaterali
Abilita lo spazio dei nomi per l'inserimento. I passaggi dipendono dall'implementazione del piano di controllo.
Gestito (TD)
- Applica l'etichetta di inserimento predefinita allo spazio dei nomi:
kubectl label namespace 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 NAMESPACE \ istio.io/rev- istio-injection=enabled --overwrite
Se sei un utente esistente con il piano di controllo Managed Istiod: ti consigliamo di utilizzare l'inserimento predefinito, ma l'inserimento basato sulle revisioni è supportato. 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 precedente sono presenti due revisioni del piano di controllo, rimuovine una. La presenza di più canali del piano di controllo 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 NAMESPACE \ istio-injection- istio.io/rev=REVISION_LABEL --overwrite
Nel cluster
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 dell'etichetta di revisioneistiod
che hai annotato nel passaggio precedente.kubectl label namespace NAMESPACE \ istio-injection- istio.io/rev=REVISION_LABEL --overwrite
Riavvia i pod interessati, seguendo i passaggi nella sezione successiva.
Annota lo spazio dei nomi
demo
come segue:kubectl annotate --overwrite namespace NAMESPACE \ mesh.cloud.google.com/proxy='{"managed":"true"}'
Riavvia i pod per aggiornare i proxy sidecar
Con l'inserimento automatico di file collaterali, puoi aggiornare i file collaterali per i pod esistenti con il riavvio dei pod:
Il modo in cui riavvii i pod dipende dal fatto che siano stati creati o meno durante un deployment.
Se hai utilizzato un deployment, riavvialo. In questo modo vengono riavviati tutti i pod con file collaterali:
kubectl rollout restart deployment -n NAMESPACE
Se non hai utilizzato un deployment, elimina i pod, in modo che vengano ricreati automaticamente con i file collaterali:
kubectl delete pod -n NAMESPACE --all
Controlla che in tutti i pod nello spazio dei nomi siano stati inseriti file collaterali:
kubectl get pod -n NAMESPACE
Nel seguente output di esempio del comando precedente, nota che la colonna
READY
indica che sono presenti due container per ciascuno dei tuoi carichi di lavoro: il container principale e il container per il proxy sidecar.NAME READY STATUS RESTARTS AGE WORKLOAD 2/2 Running 0 20s ...