Esegui l'onboarding dei carichi di lavoro Kubernetes

Nota: questa guida supporta solo Cloud Service Mesh con le API Istio e non supporta le API Google Cloud. Per ulteriori informazioni, consulta la panoramica di Cloud Service Mesh.

Questa pagina mostra come eseguire l'onboarding dei carichi di lavoro Kubernetes con Cloud Service Mesh.

Esegui il deployment di 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 dei servizi. Sebbene GKE ti consenta di definire porte di servizio senza nome, Cloud Service Mesh richiede che tu fornisca un nome per una porta che corrisponda al protocollo della porta.

• Etichetta i 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 seguente esempio di deployment e servizio illustra 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: esegui il deployment dell'esempio Online Boutique

L'applicazione di esempio Online Boutique nel repository anthos-service-mesh-packages viene modificata dall'insieme originale di manifest nel microservices-demo repository. Seguendo le best practice, ogni servizio viene disegnato in un distinto nome spazio con un account di servizio univoco.

1. 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
   

2. Attiva gli spazi 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:

   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 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;
   

   Se sei già un utente con il piano di controllo Istiod gestito: consigliamo di utilizzare l'iniezione predefinita, ma è supportata anche l'iniezione basata su revisione. Segui le istruzioni riportate di seguito:

   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;
      

3. Esegui il deployment dell'applicazione di esempio nel cluster.

   1. 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
      

   2. Crea i servizi:

      kubectl apply -f \
       DIR_PATH/samples/online-boutique/kubernetes-manifests/services
      

      Risultato 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
      

   3. Crea le voci del servizio:

      kubectl apply -f \
       DIR_PATH/samples/online-boutique/istio-manifests/allow-egress-googleapis.yaml
      

      Risultato 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 visualizzate 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 mesh di servizi.

L'iniezione automatica del proxy sidecar (iniezione automatica) si verifica quando Cloud Service Mesh rileva un'etichetta dello spazio dei nomi configurata per il pod del carico di lavoro. Il proxy intercetta tutto il traffico in entrata e in uscita verso i carichi di lavoro e comunicata 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. Per informazioni dettagliate sulle autorizzazioni incluse in questo ruolo, consulta la sezione Ruoli di Google Kubernetes Engine.

Attivazione dell'iniezione automatica di sidecar

1. 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 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
   

   Se sei già un utente con il piano di controllo Istiod gestito: consigliamo di utilizzare l'iniezione predefinita, ma è supportata anche l'iniezione basata su revisione. Segui le istruzioni riportate di seguito:

   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 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:

      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 seguente comando, REVISION_LABEL è il valore dell'etichetta della revisione istiod che hai annotato nel passaggio precedente.

      kubectl label namespace NAMESPACE \
          istio-injection- istio.io/rev=REVISION_LABEL --overwrite
      

2. Riavviare i pod interessati seguendo i passaggi descritti nella sezione successiva.

3. Aggiungi un'annotazione allo 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

Avviso: a meno che tu non abbia configurato un bilanciatore del carico o un router per i deployment blue-green, assicurati di testare il riavvio dei pod in un ambiente di staging per verificare che i tuoi servizi possano gestire eventuali interruzioni del traffico.

Con l'inserimento automatico dei sidecar, puoi aggiornare i sidecar per i pod esistenti con un riavvio del pod:

La modalità di riavvio dei pod dipende dal fatto che siano stati creati nell'ambito di un deployment.

1. 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

2. 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 esistono 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
   ...