Configurazione di Anthos Service Mesh gestito

Panoramica

Anthos Service Mesh gestito è un piano di controllo gestito da Google e da un piano dati 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à Service Mesh abilitata. Puoi abilitarlo come parte dell'installazione passando --enable-gcp-components o eseguendo il comando seguente:

    gcloud container hub mesh enable --project=FLEET_PROJECT_ID
    

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

  • 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 da Google. In caso contrario, l'installazione non supererà i controlli di sicurezza. Il supporto per la funzionalità Controlli di servizio VPC è disponibile nei canali regolare 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.

  • Questa release di anteprima del piano dati gestito è disponibile solo per i nuovi deployment del piano di controllo gestito. 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 da Google.

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

  • 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 da Google, nel cluster specificato vengono installati i CRD di Istio che corrispondono al canale selezionato. Se nel cluster sono presenti CRD Istio esistenti, verranno sovrascritti.

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. Se installi Anthos Service Mesh su un cluster GKE, configura kubectl in modo che punti 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 da Google

Prima di applicare il piano di controllo gestito da Google, 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.

Se il tuo cluster è un cluster Autopilot GKE, controlla la sezione Autopilot GKE per ulteriori requisiti e flag da utilizzare con il comando 'asmcli'.

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.

GKE Autopilot

GKE Autopilot è supportato solo con Anthos Service Mesh nei canali regolari e rapidi. Il cluster deve avere GKE con versione 1.21.3 o successive. Per adattarsi al limite di risorse GKE Autopilot, le richieste e i limiti di risorse proxy predefiniti sono impostati su 500 m di CPU e 512 Mb di memoria. I cluster Autopilot richiedono l'interfaccia a riga di comando gestita, quindi devi includere il flag --use_managed_cni. Sostituisci RELEASE_CHANNEL con il canale appropriato: regular, stable o rapid.

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

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 da Google, Google ne 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 da Google, 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.

Questa versione di anteprima del piano dati gestito non gestisce quanto segue:

  • 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. Attiva la gestione del piano dati:

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

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

  2. Ripeti il passaggio precedente per ogni spazio dei nomi in cui vuoi un piano dati gestito.

    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 alpha container fleet mesh describe --project 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 namespace NAMESPACE \
  mesh.cloud.google.com/proxy='{"managed":"false"}'

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. Devi completare le sezioni Impostazione delle variabili del progetto e del cluster e Crea regola firewall prima di configurare il rilevamento degli endpoint.

Cluster pubblici

Configurare il rilevamento degli endpoint tra cluster pubblici

Se operi su cluster pubblici (non cluster privati), puoi configurare il rilevamento degli endpoint tra cluster pubblici o, semplicemente, attivare 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=asm-managed-rapid.

Se utilizzi un'etichetta di revisione diversa, fai clic su asm-managed-rapid e sostituiscila con l'etichetta applicabile: 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 hai applicato anche il piano dati gestito, riavvia i carichi di lavoro. In caso contrario, esegui un aggiornamento in sequenza. Ora è tutto pronto per il deployment delle applicazioni o 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. Inoltre, se il cluster esegue anche Anthos Service Mesh o il servizio di autorità di certificazione con CA CA in altri spazi dei nomi, verifica che l'applicazione sia in grado di comunicare con le altre applicazioni controllate dal piano di controllo nel 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. Nella console, visualizza 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

Per eseguire la migrazione ad Anthos Service Mesh gestito, esegui questi passaggi:

  1. Esegui lo strumento come indicato nella sezione Applicare 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 namespace NAMESPACE \
    mesh.cloud.google.com/proxy='{"managed":"true"}'
    
  3. (Facoltativo) Se vuoi utilizzare il piano dati gestito da Google, attiva Anthos Service Mesh nel parco risorse:

    gcloud alpha container hub mesh enable --project=PROJECT_ID
    
  4. Sostituisci l'etichetta dello spazio dei nomi corrente. I passaggi richiesti dipendono dal fatto che tu voglia utilizzare le etichette di iniezione predefinite (ad esempio, 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 MCP_RELEASE_CHANNEL
      
    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 \
      --overwrite
      

    Etichetta revisione

    Se hai utilizzato l'etichetta istio.io/rev=asm-managed-rapid, esegui il comando seguente:

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

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

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

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

  9. 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 in-cluster oppure conservarli come backup. istiod verrà utilizzato lo scale down per utilizzare automaticamente meno 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 da Google scala automaticamente a zero quando nessun spazio dei nomi lo utilizza. 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.

Codici bloccati di ControlPlaneRevision

Sono diversi i motivi per cui la condizione Stalled può diventare vera nello stato ControlPlaneRevisions.

Motivo Messaggio Descrizione
Precondizione non riuscita Sono supportati solo gli abbonamenti GKE, ma ${CLUSTER_NAME} non è un cluster GKE. Il cluster attuale non sembra essere un cluster GKE. Il piano di controllo gestito funziona solo sui cluster GKE.
Nome ControlPlaneRevision non supportato: ${NAME} Il nome di ControlPlaneRevision deve essere uno dei seguenti:
  • gestito da asm
  • rapido-gestito-am
  • stabile-gestita da asm
Spazio dei nomi ControlPlaneRevision non supportato: ${NAMESPACE} Lo spazio dei nomi di ControlPlaneRevision deve essere istio-system.
Canale non supportato ${CHANNEL} per ControlPlaneRevision con nome${NAME}. Valore previsto: ${OTHER_CHANNEL} Il nome di ControlPlaneRevision deve corrispondere al canale di ControlPlaneRevision con quanto segue:
  • gestito da asm -&GT; regolare
  • asm-managed-rapid -&GT; rapido
  • stabile-sm-gestito -> stabile
Il canale non deve essere omesso o vuoto Channel è un campo obbligatorio su ControlPlaneRevision. Risorsa mancante o vuota nella risorsa personalizzata.
Tipo di revisione del piano di controllo non supportato: ${TYPE} managed_service è l'unico campo di autorizzazione per il campo ControlPlaneRevisionType.
Versione di Kubernetes non supportata: ${VERSION} Sono supportate le versioni di Kubernetes 1.15 e successive.
Workload Identity non abilitato Abilita l'identità del carico di lavoro nel tuo cluster.
Pool di carichi di lavoro non supportato: ${POOL} Il pool di carichi di lavoro deve essere nel formato ${PROJECT_ID}.svc.id.goog.
Il progetto del cluster e il progetto nell'ambiente non corrispondono I cluster devono far parte dello stesso progetto in cui sono registrati nel parco risorse.
Provisioning non riuscito Si è verificato un errore durante l'aggiornamento delle risorse del cluster Google non è riuscita ad aggiornare le risorse nel cluster come CRD e webhook.
MutatingWebhookConfiguration "istiod-asm-managed" contiene un webhook con URL di ${EXISTING_URL} ma è previsto ${expected_URL} Google non sovrascriverà i webhook esistenti per evitare interruzioni dell'installazione. Aggiornala manualmente se vuoi.
ValidatingWebhookConfiguration ${NAME} contiene un webhook con URL di ${EXISTING_URL} ma ci sono i ${expected_URL} previsti Google non sovrascriverà i webhook esistenti per evitare interruzioni dell'installazione. Aggiornala manualmente se vuoi.

Passaggi successivi