Configurare Anthos Service Mesh gestito con "asmcli"

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Panoramica

Anthos Service Mesh gestito con asmcli è un piano di controllo gestito e un piano dati gestito facoltativo che configuri semplicemente. Google gestisce per te la propria affidabilità, upgrade, scalabilità e sicurezza in modo compatibile con le versioni precedenti. Questa guida spiega come configurare o eseguire la migrazione delle applicazioni ad Anthos Service Mesh gestito in una configurazione singola o multi-cluster con asmcli.

Per scoprire di più sulle funzionalità supportate e sulle limitazioni di Anthos Service Mesh gestito, consulta le funzionalità supportate di Anthos Service Mesh.

Prerequisiti

Come punto di partenza, questa guida presuppone che tu abbia:

Requisiti

  • Uno o più cluster con una versione supportata di GKE in una delle regioni supportate.
  • Assicurati che il computer client da cui installi Anthos Service Mesh gestito abbia una connettività di rete al server API.
  • I tuoi cluster devono essere registrati in un parco risorse. Questo passaggio può essere eseguito separatamente prima dell'installazione o come parte dell'installazione passando i flag --enable-registration e --fleet-id.
  • Il tuo progetto deve avere la funzionalità parco risorse Service Mesh abilitata. Puoi abilitarlo come parte dell'installazione passando --enable-gcp-components o eseguendo il comando seguente:

    gcloud container fleet mesh enable --project=FLEET_PROJECT_ID
    

    dove FLEET_PROJECT_ID è l'ID progetto del progetto host del parco risorse.

  • GKE Autopilot è supportato solo con GKE versione 1.21.3 e successive. La CNI verrà installata e gestita da Google.

  • Anthos Service Mesh gestito può utilizzare più cluster GKE in un ambiente a singola rete a progetto singolo o in un ambiente a rete singola multiprogetto.

    • Se unisci cluster che non si trovano nello stesso progetto, devono essere registrati nello stesso progetto host del parco risorse e i cluster devono essere in una configurazione VPC condivisa insieme sulla stessa rete.
    • Inoltre, ti consigliamo di avere un progetto per ospitare il VPC condiviso e progetti di servizio separati per la creazione dei cluster. Per ulteriori informazioni, consulta la pagina relativa alla configurazione dei cluster con VPC condiviso.
    • Se la tua organizzazione utilizza i Controlli di servizio VPC, devi utilizzare il flag --use-vpcsc aggiuntivo quando applichi il piano di controllo gestito. In caso contrario, l'installazione non supererà i controlli di sicurezza. Il supporto per la funzionalità Controlli di servizio VPC è disponibile nei canali standard e rapido.

Limitazioni

Ti consigliamo di esaminare l'elenco di funzionalità e limitazioni supportate da Anthos Service Mesh gestite. In particolare, tieni presente quanto segue:

  • L'API IstioOperator non è supportata poiché il suo scopo principale è controllare i componenti in-cluster.

  • Se in precedenza hai eseguito il deployment del piano di controllo gestito e vuoi eseguire il deployment del piano di dati gestito, devi eseguire di nuovo lo strumento di installazione come descritto in Applicare il piano di controllo gestito.

  • Per i cluster GKE Autopilot, la configurazione tra progetti è supportata solo con GKE 1.23 e versioni successive. Per adattarsi al limite di risorse GKE Autopilot, le richieste di risorse e i limiti predefiniti sono impostati su 500 m di CPU e 512 Mb di memoria.

  • Le funzionalità effettive disponibili per Anthos Service Mesh gestito dipendono dal canale di rilascio. Per ulteriori informazioni, consulta l'elenco completo delle funzionalità e delle limitazioni supportate da Anthos Service Mesh gestite.

  • Durante il processo di provisioning per un piano di controllo gestito, nel cluster specificato vengono installati i CRD Istio che corrispondono al canale selezionato. Se nel cluster sono presenti CRD Istio esistenti, verranno sovrascritti.

Prima di iniziare

Configura gcloud

Segui questi passaggi anche se utilizzi Cloud Shell.

  1. Esegui l'autenticazione con Google Cloud CLI:

    gcloud auth login --project PROJECT_ID
    
  2. Aggiorna i componenti:

    gcloud components update
    
  3. Configura kubectl per puntare al cluster.

    gcloud container clusters get-credentials CLUSTER_NAME \
         --zone CLUSTER_LOCATION \
         --project PROJECT_ID
    

Scarica lo strumento di installazione

  1. Scarica la versione più recente dello strumento nella directory di lavoro corrente:

    curl https://storage.googleapis.com/csm-artifacts/asm/asmcli > asmcli
    
  2. Rendi lo strumento eseguibile:

    chmod +x asmcli
    

Configura ogni cluster

Segui i passaggi seguenti per configurare Anthos Service Mesh gestito per ogni cluster nel mesh.

Applica il piano di controllo gestito

Prima di applicare il piano di controllo gestito, devi selezionare un canale di rilascio.

Esegui lo strumento di installazione per ogni cluster che utilizzerà Anthos Service Mesh gestito. Ti consigliamo di includere entrambe le opzioni:

  • --enable-registration --fleet_id FLEET_PROJECT_ID Questi due flag registrano il cluster in un parco risorse, dove FLEET_ID è l'ID progetto del progetto host del parco risorse. Se utilizzi un singolo progetto, FLEET_PROJECT_ID è uguale a PROJECT_ID, il progetto host del parco risorse e il progetto cluster sono uguali. Per le configurazioni più complesse, ad esempio in più progetti, consigliamo di utilizzare un progetto host del parco risorse separato.

  • --enable-all. Questo flag consente sia i componenti richiesti sia la registrazione.

Se la tua organizzazione applica controlli di servizio VPC per il progetto, devi configurare un flag aggiuntivo: --use-vpcsc. In caso contrario, l'installazione non supererà i controlli di sicurezza. Il supporto per la funzionalità Controlli di servizio VPC è disponibile nei canali standard e rapido.

Lo strumento asmcli configura direttamente il piano di controllo gestito utilizzando strumenti e logica all'interno dello strumento dell'interfaccia a riga di comando. Utilizza le istruzioni riportate di seguito a seconda dell'autorità di certificazione preferita.

Autorità di certificazione

Seleziona un'autorità di certificazione da utilizzare per il tuo mesh.

CA mesh

Esegui il comando seguente per installare il piano di controllo con funzionalità predefinite e mesh CA. Inserisci i valori nei segnaposto forniti. Sostituisci RELEASE_CHANNEL con il canale appropriato: regular, stable o rapid.

  ./asmcli install \
      -p PROJECT_ID \
      -l LOCATION \
      -n CLUSTER_NAME \
      --fleet_id FLEET_PROJECT_ID \
      --managed \
      --verbose \
      --output_dir CLUSTER_NAME \
      --enable-all \
      --channel RELEASE_CHANNEL

Servizio CA

  1. Segui i passaggi descritti in Configurare il servizio autorità di certificazione.
  2. Esegui il comando seguente per installare il piano di controllo con le funzionalità predefinite e il servizio per le autorità di certificazione. Inserisci i valori nei segnaposto forniti. Sostituisci RELEASE_CHANNEL con il canale appropriato: regular, stable o rapid.
  ./asmcli install \
      -p PROJECT_ID \
      -l LOCATION \
      -n CLUSTER_NAME \
      --fleet_id FLEET_PROJECT_ID \
      --managed \
      --verbose \
      --output_dir CLUSTER_NAME \
      --enable-all \
      --channel RELEASE_CHANNEL \
      --ca gcp_cas \
      --ca_pool pool_name

Lo strumento scarica tutti i file per la configurazione del piano di controllo gestito nell'oggetto --output_dir specificato, installando lo strumento istioctl e le applicazioni di esempio. I passaggi in questa guida presuppongono che esegui istioctl dalla località --output_dir specificata durante l'esecuzione di asmcli install, con istioctl presente nella relativa sottodirectory <Istio release dir>/bin.

Se esegui nuovamente asmcli sullo stesso cluster, viene sovrascritta la configurazione del piano di controllo esistente. Assicurati di specificare le stesse opzioni e gli stessi flag se vuoi la stessa configurazione.

Verifica che sia stato eseguito il provisioning del piano di controllo

Lo strumento asmcli crea una risorsa personalizzata ControlPlaneRevision nel cluster. Lo stato di questa risorsa viene aggiornato quando viene eseguito il provisioning del piano di controllo gestito o se il provisioning non riesce.

Controlla lo stato della risorsa. Sostituisci NAME con il valore corrispondente a ciascun canale: asm-managed, asm-managed-stable o asm-managed-rapid.

kubectl describe controlplanerevision NAME -n istio-system

L'output è simile al seguente:

    Name:         asm-managed

    …

    Status:
      Conditions:
        Last Transition Time:  2021-08-05T18:56:32Z
        Message:               The provisioning process has completed successfully
        Reason:                Provisioned
        Status:                True
        Type:                  Reconciled
        Last Transition Time:  2021-08-05T18:56:32Z
        Message:               Provisioning has finished
        Reason:                ProvisioningFinished
        Status:                True
        Type:                  ProvisioningFinished
        Last Transition Time:  2021-08-05T18:56:32Z
        Message:               Provisioning has not stalled
        Reason:                NotStalled
        Status:                False
        Type:                  Stalled

La condizione riconciliata determina se il piano di controllo gestito è in esecuzione correttamente. Se true, il piano di controllo è in esecuzione. Stalled determina se il processo di provisioning del piano di controllo gestito ha rilevato un errore. Se Stalled, il campo Message contiene ulteriori informazioni sull'errore specifico. Per ulteriori informazioni sui possibili errori, consulta Codici bloccati.

Upgrade zero-touch

Una volta installato il piano di controllo gestito, Google eseguirà automaticamente l'upgrade quando saranno disponibili nuove release o patch.

Non è obbligatorio eseguire l'upgrade del piano dati ogni volta che viene eseguito un piano di controllo. Il piano di controllo continua a funzionare con tutti i proxy nella finestra di assistenza, ma è consigliabile accedere alle funzionalità, alle correzioni e ai miglioramenti delle prestazioni del piano dati più recenti. Per eseguire l'upgrade all'ultima immagine proxy pubblicata nel tuo canale, puoi eseguire un riavvio in sequenza, se necessario, o applicare il piano dati gestito che effettuerà l'operazione automaticamente.

Applica il piano dati gestito (facoltativo)

Se vuoi che Google gestisca completamente gli upgrade dei proxy, attiva il piano dati gestito.

Se questa opzione è abilitata, i proxy sidecar e i gateway inseriti vengono aggiornati automaticamente insieme al piano di controllo gestito riavviando i carichi di lavoro per reinserire nuove versioni del proxy. Se disabilitato, la gestione del proxy è guidata dal ciclo di vita naturale dei pod nel cluster e deve essere attivata manualmente dall'utente per controllare la frequenza di aggiornamento.

Il piano dati gestito esegue l'upgrade dei proxy eliminando i pod che eseguono versioni precedenti del proxy. Gli sgomberi vengono effettuati gradualmente, rispettando il budget di interruzione dei pod e controllando la frequenza di modifica.

Tieni presente che il piano dati gestito richiede il plug-in Istio di rete dell'interfaccia (CNI), che è abilitato per impostazione predefinita quando esegui il deployment del piano di controllo gestito.

Il piano dati gestito non gestisce:

  • Pod non inseriti
  • Pod inseriti manualmente
  • Job
  • StatefulSet
  • DaemonSet

Il piano dati gestito è disponibile sui canali di rilascio rapidi e regolari.

Per attivare il piano dati gestito:

  1. Abilita la gestione del piano dati per l'intero cluster:

    kubectl annotate --overwrite controlplanerevision -n istio-system \
    REVISION_LABEL \
    mesh.cloud.google.com/proxy='{"managed":"true"}'
    

    In alternativa, puoi abilitare il piano dati gestito in modo selettivo per una revisione, uno spazio dei nomi o un pod specifico del piano di controllo, annotandolo con la stessa annotazione. Se controlli selettivamente i singoli componenti, l'ordine di precedenza è la revisione del piano di controllo, quindi lo spazio dei nomi e infine il pod.

    Potrebbero essere necessari fino a dieci minuti affinché il servizio sia pronto per gestire i proxy nel cluster. Esegui il comando seguente per controllare lo stato:

    gcloud container fleet mesh describe --project FLEET_PROJECT_ID
    

    Output previsto

     membershipStates:
       projects/PROJECT_NUMBER/locations/global/memberships/CLUSTER_NAME:
         servicemesh:
           dataPlaneManagement:
             details:
             - code: OK
               details: Service is running.
             state: ACTIVE
         state:
           code: OK
           description: 'Revision(s) ready for use: asm-managed-rapid.'
     ```
    

Se il servizio non diventa pronto entro dieci minuti, consulta lo stato del piano dati gestito per i passaggi successivi.

Se vuoi disattivare il piano dati gestito e tornare a gestire autonomamente i proxy sidecar, modifica l'annotazione:

kubectl annotate --overwrite controlplanerevision -n istio-system \
REVISION_LABEL \
  mesh.cloud.google.com/proxy='{"managed":"false"}'

Per disabilitare il piano dati gestito per uno spazio dei nomi:

kubectl annotate --overwrite namespace NAMESPACE \
  mesh.cloud.google.com/proxy='{"managed":"false"}'

In alternativa, puoi disabilitare il piano dati gestito per un pod specifico annotandolo con la stessa annotazione.

Abilita notifiche di manutenzione

Puoi richiedere di ricevere notifiche sulla manutenzione imminente fino a una settimana prima della manutenzione programmata. Le notifiche di manutenzione non vengono inviate per impostazione predefinita. Devi anche configurare un periodo di manutenzione di GKE per poter ricevere le notifiche.

Per attivare le notifiche di manutenzione:

  1. Vai alla pagina Comunicazione.

    Vai alla pagina Comunicazione

  2. Nella riga Anthos Service Mesh Upgrade, nella colonna Email, seleziona il pulsante di opzione per attivare le notifiche di manutenzione.

L'attivazione delle notifiche deve essere effettuata separatamente da ciascun utente che vuole ricevere le notifiche. Se vuoi impostare un filtro email per queste notifiche, l'oggetto è:

Upcoming upgrade for your ASM cluster "CLUSTER_LOCATION/CLUSTER_NAME".

Configura individuazione endpoint (solo per installazioni multi-cluster)

Prima di continuare, devi aver già configurato Anthos Service Mesh gestito in ogni cluster come descritto nei passaggi precedenti. Non è necessario indicare che un cluster è un cluster primario, che è il comportamento predefinito.

Inoltre, assicurati di aver scaricato asmcli (solo se vuoi verificare la tua configurazione con l'applicazione di esempio) e imposta le variabili del progetto e del cluster.

Cluster pubblici

Configurare il rilevamento degli endpoint tra cluster pubblici

Se utilizzi cluster pubblici (non cluster privati), puoi configurare il rilevamento degli endpoint tra cluster pubblici o più semplicemente abilitare il rilevamento degli endpoint tra i cluster pubblici.

Cluster privati

Configura il rilevamento degli endpoint tra cluster privati

Quando utilizzi i cluster privati GKE, devi configurare l'endpoint del piano di controllo del cluster in modo che sia l'endpoint pubblico anziché l'endpoint privato. Fai riferimento a Configurare il rilevamento degli endpoint tra cluster privati.

Per un'applicazione di esempio con due cluster, vedi Esempio di servizio HelloWorld.

Esegue il deployment delle applicazioni

Per eseguire il deployment delle applicazioni, utilizza l'etichetta corrispondente al canale configurato durante l'installazione o istio-injection=enabled se utilizzi etichette di iniezione predefinite.

Etichetta iniezione predefinita

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

Etichetta revisione

Prima di eseguire il deployment delle applicazioni, rimuovi eventuali etichette istio-injection precedenti dai rispettivi spazi dei nomi e imposta invece l'etichetta istio.io/rev=REVISION_LABEL.

Per modificare un'etichetta di revisione specifica, fai clic su REVISION_LABEL e sostituiscila con l'etichetta applicabile: asm-managed-rapid per Rapido, asm-managed per Regolare o asm-managed-stable per Stabile.

L'etichetta di revisione corrisponde a un canale di rilascio:

Etichetta revisione Canale
asm-managed Normale
asm-managed-rapid Elasticità
asm-managed-stable Stabile
kubectl label namespace NAMESPACE istio-injection- istio.io/rev=REVISION_LABEL --overwrite

A questo punto, hai configurato correttamente il piano di controllo gestito di Anthos Service Mesh. Se sono presenti carichi di lavoro esistenti negli spazi dei nomi etichettati, riavviali in modo che vengano inseriti i proxy.

Ora è tutto pronto per il deployment delle applicazioni oppure puoi eseguire il deployment dell'applicazione di esempio Bookinfo.

Se esegui il deployment di un'applicazione in una configurazione multi-cluster, replica la configurazione di Kubernetes e del piano di controllo in tutti i cluster, a meno che tu non abbia intenzione di limitare la configurazione specifica a un sottoinsieme di cluster. La configurazione applicata a un determinato cluster è la fonte di riferimento per il cluster.

Verificare le metriche del piano di controllo

Puoi visualizzare la versione del piano di controllo e del piano dati in Metrics Explorer.

Per verificare che la configurazione funzioni correttamente:

  1. In Google Cloud Console, puoi visualizzare le metriche del piano di controllo:

    Vai a Metrics Explorer

  2. Scegli la tua area di lavoro e aggiungi una query personalizzata utilizzando i seguenti parametri:

    • Tipo di risorsa: Container Kubernetes
    • Metrica: Client proxy
    • Filtro: container_name="cr-REVISION_LABEL"
    • Group By (Raggruppa per): etichetta di revisione ed etichetta proxy_version
    • Somma aggregatore
    • Periodo: 1 minuto

    Quando esegui Anthos Service Mesh con un piano di controllo gestito da Google e in un cluster, puoi distinguere le metriche in base al nome del container. Ad esempio, le metriche gestite hanno container_name="cr-asm-managed", mentre le metriche non gestite hanno container_name="discovery". Per visualizzare le metriche di entrambi, rimuovi il filtro su container_name="cr-asm-managed".

  3. Verifica la versione del piano di controllo e la versione proxy esaminando i seguenti campi in Metrics Explorer:

    • Il campo revisione indica la versione del piano di controllo.
    • Il campo proxy_version indica il proxy_version.
    • Il campo value indica il numero di proxy connessi.

    Per la mappatura delle versioni del canale attuale ad Anthos Service Mesh, consulta Versioni di Anthos Service Mesh per canale.

Esegui la migrazione delle applicazioni ad Anthos Service Mesh gestito

Prepararsi per la migrazione

Per prepararti alla migrazione delle applicazioni da Anthos Service Mesh nel cluster ad Anthos Service Mesh gestito, segui questi passaggi:

  1. Esegui lo strumento come indicato nella sezione Applica il piano di controllo gestito da Google.

  2. (Facoltativo) Se vuoi utilizzare il piano dati gestito da Google, attiva la gestione del piano dati:

      kubectl annotate --overwrite controlplanerevision REVISION_TAG \
      mesh.cloud.google.com/proxy='{"managed":"true"}'
    

Eseguire la migrazione delle applicazioni

Per eseguire la migrazione delle applicazioni da Anthos Service Mesh nel cluster ad Anthos Service Mesh gestito, esegui i passaggi seguenti:

  1. Sostituisci l'etichetta dello spazio dei nomi corrente. I passaggi richiesti variano a seconda che tu voglia utilizzare le etichette di iniezione predefinite (ad es. istio-injection enabled) o l'etichetta di revisione.

    Etichetta iniezione predefinita

    1. Esegui questo comando per spostare il tag predefinito nella revisione gestita:

      istioctl tag set default --revision REVISION_LABEL
      
    2. Esegui il comando seguente per etichettare lo spazio dei nomi utilizzando istio-injection=enabled, se non lo era già:

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

    Etichetta revisione

    Se hai utilizzato l'etichetta istio.io/rev=REVISION_LABEL, esegui il comando seguente:

    kubectl label namespace NAMESPACE istio-injection- istio.io/rev=REVISION_LABEL \
        --overwrite
    
  2. Esegui un upgrade in sequenza dei deployment nello spazio dei nomi:

    kubectl rollout restart deployment -n NAMESPACE
    
  3. Testa la tua applicazione per verificare che i carichi di lavoro funzionino correttamente.

  4. Se hai carichi di lavoro in altri spazi dei nomi, ripeti i passaggi precedenti per ogni spazio dei nomi.

  5. Se hai eseguito il deployment dell'applicazione in una configurazione multi-cluster, replica la configurazione Kubernetes e Istio in tutti i cluster, a meno che tu non voglia limitare la configurazione a un sottoinsieme di cluster. La configurazione applicata a un determinato cluster è la fonte di riferimento per il cluster.

  6. Per verificare che le metriche vengano visualizzate come previsto, segui la procedura descritta in Verificare le metriche del piano di controllo.

Se ritieni che l'applicazione funzioni come previsto, puoi rimuovere istiod nel cluster dopo aver trasferito tutti gli spazi dei nomi al piano di controllo gestito o conservarli come backup. istiod verrà ridimensionato automaticamente per utilizzare altre risorse. Per rimuovere, vai a Elimina il piano di controllo precedente.

Se riscontri problemi, puoi identificarli e risolverli utilizzando le informazioni riportate in Risolvere i problemi relativi al piano di controllo gestito e, se necessario, eseguire il rollback alla versione precedente.

Elimina piano di controllo precedente

Dopo aver installato e confermato che tutti gli spazi dei nomi utilizzano il piano di controllo gestito da Google, puoi eliminare il piano di controllo precedente.

kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod -n istio-system --ignore-not-found=true

Se hai utilizzato istioctl kube-inject anziché l'inserimento automatico o se hai installato gateway aggiuntivi, controlla le metriche per il piano di controllo e verifica che il numero di endpoint connessi sia pari a zero.

Rollback

Se devi eseguire il rollback alla versione precedente del piano di controllo, esegui i passaggi seguenti:

  1. Aggiorna i carichi di lavoro da inserire con la versione precedente del piano di controllo. Nel comando seguente, il valore di revisione asm-191-1 viene utilizzato solo come esempio. Sostituisci il valore di esempio con l'etichetta di revisione del piano di controllo precedente.

    kubectl label namespace NAMESPACE istio-injection- istio.io/rev=asm-191-1 --overwrite
    
  2. Riavvia i pod per attivare la nuova iniezione in modo che i proxy dispongano della versione precedente:

    kubectl rollout restart deployment -n NAMESPACE
    

Il piano di controllo gestito scala automaticamente a zero e non utilizza alcuna risorsa quando non è in uso. I webhook e il provisioning mutanti rimarranno e non influiranno sul comportamento del cluster.

Il gateway è ora impostato per la revisione asm-managed. Per eseguire il rollback, esegui nuovamente il comando di installazione di Anthos Service Mesh, che esegue nuovamente il deployment del gateway che punta al piano di controllo nel cluster:

kubectl -n istio-system rollout undo deploy istio-ingressgateway

Questo output dovrebbe funzionare correttamente:

deployment.apps/istio-ingressgateway rolled back

Disinstalla

Il piano di controllo gestito scala automaticamente a zero quando non viene utilizzato da alcun spazio dei nomi. Per la procedura dettagliata, vedi Disinstallare Anthos Service Mesh.

Risolvere i problemi

Per identificare e risolvere i problemi quando utilizzi il piano di controllo gestito, vedi Risolvere i problemi relativi al piano di controllo gestito.

Passaggi successivi