Stai visualizzando la documentazione di Service Mesh della versione 1.22.

Versioni disponibili

Cloud Service Mesh
Archivio 1.22
Archivio 1.21
Archivio 1.20
Archivio 1.19
Archivio 1.18

Questa pagina è stata tradotta dall'API Cloud Translation.

Esegui 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 di servizi Kubernetes nei cluster con Cloud Service Mesh, devi svolgere i seguenti passaggi:

Crea Servizi Kubernetes per tutti i container. A tutti i deployment deve essere associato un servizio Kubernetes.
Assegna un nome alle porte di servizio. Sebbene GKE ti consenta di definire porte di servizio, Cloud Service Mesh richiede che tu fornisca un nome per una porta che corrisponda protocollo.
Etichetta i tuoi deployment. In questo modo puoi utilizzare le funzionalità di gestione del traffico di Cloud Service Mesh, ad esempio la suddivisione del traffico tra le versioni dello stesso servizio.

Il deployment e il servizio di esempio che seguono illustrano questi requisiti:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: helloserver
spec:
  replicas: 1
  selector:
    matchLabels:
      app: helloserver
  template:
    metadata:
      labels:
        app: helloserver
    spec:
      containers:
      - image: gcr.io/google-samples/istio/helloserver:v0.0.1
        imagePullPolicy: Always
        name: main
      restartPolicy: Always
      terminationGracePeriodSeconds: 5

apiVersion: v1
kind: Service
metadata:
  name: hellosvc
spec:
  ports:
  - name: http
    port: 80
    targetPort: 8080
  selector:
    app: helloserver
  type: LoadBalancer

Dopo aver eseguito il deployment dei servizi su un cluster con Cloud Service Mesh, assicurati di iniettare i proxy sidecar.

Esempio: deployment dell'esempio di Boutique online

L'applicazione di esempio Online Boutique nel anthos-service-mesh-packages il repository viene modificato rispetto all'insieme originale di manifest microservices-demo repository Git. Seguendo le best practice, il deployment di ogni servizio viene eseguito 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

Risultato 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

Abilita gli spazi 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:
```
for ns in ad cart checkout currency email frontend loadgenerator payment product-catalog recommendation shipping; do
  kubectl label namespace $ns \
      istio.io/rev- istio-injection=enabled --overwrite
done;
```
Gestito (Istiod)
Consigliato: esegui questo comando per applicare l'etichetta di inserimento predefinita allo spazio dei nomi:
```
  for ns in ad cart checkout currency email frontend loadgenerator payment product-catalog recommendation shipping; do
    kubectl label namespace $ns \
        istio.io/rev- istio-injection=enabled --overwrite
  done;
```
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:
1. Esegui il comando seguente 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 control plane nel cluster non è supportata.
  
  Nell'output, il valore nella colonna NAME è l'etichetta di revisione corrispondente al canale di rilascio disponibile per la versione di Cloud Service Mesh.
2. Applica l'etichetta di revisione allo spazio dei nomi:
  for ns in ad cart checkout currency email frontend loadgenerator payment product-catalog recommendation shipping; do kubectl label namespace $ns \ istio-injection- istio.io/rev=REVISION_LABEL --overwrite done;
All'interno del cluster
Consigliato: esegui il seguente comando per applicare l'etichetta di inserimento predefinita allo spazio dei nomi:
```
  for ns in ad cart checkout currency email frontend loadgenerator payment product-catalog recommendation shipping; do
    kubectl label namespace $ns \
        istio.io/rev- istio-injection=enabled --overwrite
  done;
```
Ti consigliamo di utilizzare l'inserimento predefinito, ma è supportato anche l'inserimento basato sulle revisioni: segui le istruzioni riportate di seguito:
1. Utilizza il seguente 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"}'
2. Applica l'etichetta di revisione allo spazio dei nomi. Nel seguente comando, REVISION_LABEL è il valore dell'etichetta della revisione istiod che hai annotato nel passaggio precedente.
  for ns in ad cart checkout currency email frontend loadgenerator payment product-catalog recommendation shipping; do kubectl label namespace $ns \ istio-injection- istio.io/rev=REVISION_LABEL --overwrite done;

Eseguire 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

Risultato 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 del 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 dei servizi 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] dove le parentesi quadre indicano un suffisso facoltativo che deve iniziare con un tratto, 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 di servizio devono essere denominate con uno dei seguenti protocolli: http, http2 o grpc. Le porte di servizio denominate con il protocollo https vengono trattate come tcp e le metriche non vengono visualizzati per questi servizi.

Inserimento di proxy sidecar

Questa sezione spiega come configurare l'iniezione di proxy sidecar con Cloud Service Mesh per migliorare la sicurezza, l'affidabilità e l'osservabilità della rete. Queste funzioni vengono rimosse dal contenitore principale dell'applicazione e implementate in un proxy out-of-process comune (il sidecar), fornito come contenitore separato nello stesso pod. Puoi utilizzare le funzionalità di Cloud Service Mesh senza riprogettare le tue applicazioni di produzione per partecipare a un service mesh.

L'inserimento automatico proxy sidecar (auto-injection) avviene quando Cloud Service Mesh rileva un'etichetta dello spazio dei nomi che configuri per all'interno del pod. Il proxy intercetta tutto il traffico in entrata e in uscita verso i carichi di lavoro e comunica con Cloud Service Mesh.

Autorizzazioni richieste per queste attività

Per eseguire le attività in questa pagina, devi disporre del ruolo roles/container.clusterAdmin o di un ruolo superiore. Consulta: Ruoli di Google Kubernetes Engine sulle autorizzazioni incluse in questo ruolo.

Attivazione dell'iniezione automatica di sidecar

Attiva lo spazio dei nomi per l'iniezione. I passaggi dipendono dall'implementazione del piano di controllo.
Gestito (TD)
1. 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 usare l'inserimento predefinito, ma l'inserimento basato sulle revisioni supportati. Segui queste istruzioni:
1. Esegui il comando seguente 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.
2. Applica l'etichetta di revisione allo spazio dei nomi:
  kubectl label namespace NAMESPACE \ istio-injection- istio.io/rev=REVISION_LABEL --overwrite
All'interno del cluster
Consigliato: esegui il seguente comando per applicare l'etichetta di inserimento predefinita allo spazio dei nomi:
```
  kubectl label namespace 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:
1. Utilizza il seguente 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"}'
2. Applica l'etichetta di revisione allo spazio dei nomi. Nel comando seguente, REVISION_LABEL è il valore della revisione istiod che hai annotato nel passaggio precedente.
  kubectl label namespace NAMESPACE \ istio-injection- istio.io/rev=REVISION_LABEL --overwrite
Riavviare i pod interessati seguendo i passaggi descritti 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 dei sidecar, puoi aggiornare i sidecar per i pod esistenti con un riavvio del pod:

Il modo in cui riavvii i pod dipende dal fatto che siano stati creati o meno come parte Deployment.

Se hai utilizzato un deployment, riavvialo, il che riavvia tutti i pod con i sidecar:
```
kubectl rollout restart deployment -n NAMESPACE
```
Se non hai utilizzato un deployment, elimina i pod, che verranno rielaborati automaticamente con i sidecar:
```
kubectl delete pod -n NAMESPACE --all
```
Verifica che in tutti i pod nello spazio dei nomi siano stati iniettati i sidecar:
```
kubectl get pod -n NAMESPACE
```
Nell'esempio di output del comando precedente riportato di seguito, tieni presente che la colonna READY indica che sono presenti due contenitori per ogni carico di lavoro: il contenitore principale e il contenitore per il proxy sidecar.
```
NAME                    READY   STATUS    RESTARTS   AGE
WORKLOAD           2/2     Running   0          20s
...
```