Questo documento descrive i problemi comuni di Anthos Service Mesh e come risolverli, ad esempio quando un pod viene inserito con istio.istio-system, lo strumento di installazione genera errori come i codici di stato HTTP 400 e gli errori di appartenenza al cluster.
Se hai bisogno di ulteriore assistenza per la risoluzione dei problemi di Anthos Service Mesh, consulta la pagina Assistenza.
Report delle revisioni come errore non integro
Potresti visualizzare un errore Revision(s) reporting unhealthy generico se Anthos Service Mesh non ha l'account di servizio gestito da Google richiesto con le associazioni del ruolo Identity and Access Management (IAM) dell'agente di servizio Anthos Service Mesh. In genere, ciò si verifica quando l'autorizzazione per il ruolo di agente di servizio Anthos Service Mesh viene revocata tramite la riconfigurazione di Terraform, Puppet o CI/CD.
I passaggi necessari per risolvere questo errore dipendono dall'utilizzo o meno della console Google Cloud o di Google Cloud CLI.
Console Google Cloud
Nella console Google Cloud, vai a IAM e amministrazione > IAM.
Seleziona Includi concessioni di ruoli fornite da Google.
Esamina l'elenco Entità.
Se nell'elenco è presente l'account di servizio gestito con il ruolo IAM richiesto, significa che è configurato correttamente.
Se nell'elenco non è presente l'account di servizio gestito richiesto con il ruolo IAM richiesto, l'associazione del ruolo IAM agente di servizio Anthos Service Mesh richiesta non esiste nell'account di servizio gestito.
Concedi le associazioni di ruoli IAM dell'agente di servizio Anthos Service Mesh (
roles/anthosservicemesh.serviceAgent) all'account di servizio gestito di Anthos Service Mesh nella console Google Cloud.
Google Cloud CLI
In Google Cloud CLI, esegui questo comando per verificare se è configurato il ruolo IAM richiesto:
gcloud projects get-iam-policy PROJECT_ID \ --flatten="bindings[].members" \ --filter="bindings.members:serviceAccount:service-PROJECT_NUMBER@gcp-sa-servicemesh.iam.gserviceaccount.com AND bindings.role:roles/anthosservicemesh.serviceAgent" \ --format='table(bindings.role)'Consulta l'elenco
ROLE.Se nell'elenco sono presenti ruoli, significa che è configurato correttamente.
Se non visualizzi alcun ruolo nell'elenco, tutti i ruoli degli account di servizio gestiti sono stati revocati.
Esegui questo comando per assegnare le associazioni di ruoli IAM appropriate all'account di servizio gestito di Anthos Service Mesh:
gcloud projects add-iam-policy-binding PROJECT_ID \ --member="serviceAccount:service-PROJECT_NUMBER@gcp-sa-servicemesh.iam.gserviceaccount.com" \ --role="roles/anthosservicemesh.serviceAgent"
Il pod viene inserito con istiod.istio-system
Questo può accadere se non hai sostituito l'etichetta istio-injection: enabled.
Inoltre, verifica la configurazione dei webhook mutanti utilizzando il seguente comando:
kubectl get mutatingwebhookconfiguration
...
istiod-asm-managed
…
# may include istio-sidecar-injector
kubectl get mutatingwebhookconfiguration istio-sidecar-injector -o yaml
# Run debug commands
export T=$(echo '{"kind":"TokenRequest","apiVersion":"authentication.k8s.io/v1","spec":{"audiences":["istio-ca"], "expirationSeconds":2592000}}' | kubectl create --raw /api/v1/namespaces/default/serviceaccounts/default/token -f - | jq -j '.status.token')
export INJECT_URL=$(kubectl get mutatingwebhookconfiguration istiod-asmca -o json | jq -r .webhooks[0].clientConfig.url)
export ISTIOD_ADDR=$(echo $INJECT_URL | 'sed s/\/inject.*//')
curl -v -H"Authorization: Bearer $T" $ISTIOD_ADDR/debug/configz
Lo strumento di installazione genera errori HTTP 400
Lo strumento di installazione potrebbe generare errori HTTP 400 come il seguente:
HealthCheckContainerError, message: Cloud Run error: Container failed to start.
Failed to start and then listen on the port defined by the PORT environment
variable. Logs for this revision might contain more information.
L'errore può verificarsi se non hai abilitato Workload Identity sul cluster Kubernetes. Puoi farlo utilizzando il seguente comando:
export CLUSTER_NAME=...
export PROJECT_ID=...
export LOCATION=...
gcloud container clusters update $CLUSTER_NAME --zone $LOCATION \
--workload-pool=$PROJECT_ID.svc.id.goog
Stato del piano dati gestito
Il seguente comando mostra lo stato del piano dati gestito:
gcloud container fleet mesh describe --project PROJECT_ID
La tabella seguente elenca tutti i possibili stati del piano dati gestito:
| Stato | Codice | Descrizione |
|---|---|---|
ACTIVE |
OK |
Il piano dati gestito funziona normalmente. |
DISABLED |
DISABLED |
Il piano dati gestito sarà in questo stato se non sono stati configurati uno spazio dei nomi o una revisione per utilizzarlo. Segui le istruzioni per
abilitare Anthos Service Mesh gestito tramite l'API del parco risorse o
abilitare il piano dati gestito dopo il provisioning di Anthos Service Mesh gestito con asmcli.
Tieni presente che i report sullo stato del piano dati gestito sono disponibili solo se hai abilitato il piano dati gestito annotando uno spazio dei nomi o una revisione.
L'annotazione dei singoli pod fa sì che questi pod vengano gestiti, ma con uno stato delle funzionalità DISABLED se non sono annotati spazi dei nomi o revisioni. |
FAILED_PRECONDITION |
MANAGED_CONTROL_PLANE_REQUIRED |
Il piano dati gestito richiede un piano di controllo Anthos Service Mesh gestito attivo. |
PROVISIONING |
PROVISIONING |
È in corso il provisioning del piano dati gestito. Se questo stato persiste per più di 10 minuti, è probabile che si sia verificato un errore e dovresti contattare l'assistenza. |
STALLED |
INTERNAL_ERROR |
Il piano dati gestito è bloccato a causa di una condizione di errore interno. Se il problema persiste, contatta l'assistenza. |
NEEDS_ATTENTION |
UPGRADE_FAILURES |
Il piano dati gestito richiede un intervento manuale per riportare il servizio allo stato normale. Per ulteriori informazioni e per sapere come risolvere il problema, consulta lo stato NEEDS_ATTENTION. |
NEEDS_ATTENTION stato
Se il comando gcloud container fleet mesh describe mostra che lo stato del piano dati gestito è in stato NEEDS_ATTENTION e il codice è UPGRADE_FAILURES, significa che non è stato possibile eseguire l'upgrade di determinati carichi di lavoro per il piano dati gestito. Questi carichi di lavoro verranno etichettati con dataplane-upgrade: failed dal
servizio del piano dati gestito per ulteriori analisi. È necessario riavviare i proxy manualmente per poter eseguire l'upgrade. Per ottenere l'elenco dei pod che richiedono
attenzione, esegui questo comando:
kubectl get pods --all-namespaces -l dataplane-upgrade=failed
Errore di appartenenza al cluster (nessun provider di identità specificato)
Lo strumento di installazione potrebbe non riuscire con errori di appartenenza al cluster come il seguente:
asmcli: [ERROR]: Cluster has memberships.hub.gke.io CRD but no identity
provider specified. Please ensure that an identity provider is available for the
registered cluster.
L'errore può verificarsi se GKE Workload Identity è abilitato prima di registrare il cluster. Puoi registrare di nuovo il cluster nella riga di comando utilizzando il comando gcloud container fleet memberships register --enable-workload-identity.
Controllare lo stato del piano di controllo gestito
Per controllare lo stato del piano di controllo gestito, esegui gcloud container fleet mesh describe --project FLEET_PROJECT_ID.
Nella risposta, il campo membershipStates[].servicemesh.controlPlaneManagement.details potrebbe spiegare l'errore specifico.
Se hai bisogno di ulteriori dettagli, controlla la risorsa personalizzata ControlPlaneRevision nel cluster, che viene aggiornata quando viene eseguito il provisioning del piano di controllo gestito o il provisioning non va a buon fine.
Per ispezionare 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 a questo:
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 Reconciled determina se il piano di controllo gestito viene eseguito correttamente. Se true, il piano di controllo è in esecuzione correttamente.
Stalled determina se si è verificato un errore nel processo di provisioning del piano di controllo gestito. Se Stalled, il campo Message contiene ulteriori informazioni sull'errore specifico. Consulta
Codici bloccati per ulteriori informazioni sui possibili errori.
Codici di blocco della revisione del piano di controllo
Esistono diversi motivi per cui la condizione Stalled potrebbe diventare vera nello stato ControlPlaneRevisions.
| Motivo | Messaggio | Descrizione |
|---|---|---|
| PreconditionFailed | Sono supportate solo le iscrizioni a 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:
|
|
| Spazio dei nomi ControlPlaneRevision non supportato: ${NAMESPACE} | Lo spazio dei nomi di ControlPlaneRevision deve essere istio-system. |
|
| Canale ${CHANNEL} non supportato per ControlPlaneRevision con nome${NAME}. Previsto ${OTHER_CHANNEL} | Il nome del controllo ControlPlaneRevision deve corrispondere al canale del controllo ControlPlaneRevision con quanto segue:
|
|
| Il canale non deve essere omesso o vuoto | Channel è un campo obbligatorio in ControlPlaneRevision. Non è presente o è vuoto 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 Workload Identity sul 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 cluster e il progetto environ non corrispondono | I cluster devono far parte dello stesso progetto in cui sono registrati nel parco risorse. | |
| ProvisioningFailed | Si è verificato un errore durante l'aggiornamento delle risorse del cluster | Google non è riuscita ad aggiornare le risorse nel cluster, ad esempio CRD e webhook. |
| MutatingWebhookConfiguration "istiod-asm-managed" contiene un webhook con l'URL ${EXISTING_URL} ma l'URL previsto è ${atte_URL} | Google non sovrascriverà i webhook esistenti per evitare di interrompere l'installazione. Aggiornalo manualmente se è il comportamento desiderato. | |
| ValidatingWebhookConfiguration ${NAME} contiene un webhook con l'URL ${EXISTING_URL} ma previsto ${expected_URL} | Google non sovrascriverà i webhook esistenti per evitare di interrompere l'installazione. Aggiornalo manualmente se è il comportamento desiderato. |
Anthos Service Mesh gestito non è in grado di connettersi al cluster GKE
Tra giugno e settembre 2022, Google ha completato il lavoro di sicurezza relativo a reti autorizzate, Cloud Run e Cloud Functions su Google Kubernetes Engine (GKE). I progetti che in precedenza utilizzavano Anthos Service Mesh gestito, ma che non lo utilizzavano prima della migrazione, non dispongono dell'API richiesta per la comunicazione tra Cloud Run e GKE.
In questo scenario, il provisioning gestito di Anthos Service Mesh non andrà a buon fine e Cloud Logging mostrerà il seguente messaggio di errore:
Connect Gateway API has not been used in project [*PROJECT_NUMBER*] before or it is disabled.
Enable it by visiting https://console.developers.google.com/apis/api/connectgateway.googleapis.com/overview?project=[*PROJECT_NUMBER*] then retry.
If you enabled this API recently, wait a few minutes for the action to propagate to our systems and retry.
Filtra questo messaggio utilizzando la seguente query:
resource.type="istio_control_plane"
resource.labels.project_id=[*PROJECT_ID*]
resource.labels.location=[*REGION*]
severity=ERROR
jsonPayload.message=~"Connect Gateway API has not been used in project"
Nel frattempo, anche l'inserimento e il deployment di qualsiasi risorsa personalizzata Kubernetes correlata a Anthos Service Mesh avranno esito negativo e Cloud Logging mostrerà il seguente messaggio di avviso:
Error creating: Internal error occurred: failed calling webhook
"rev.namespace.sidecar-injector.istio.io": failed to call webhook: an error on
the server ("unknown") has prevented the request from succeeding.
Filtra questo messaggio utilizzando la seguente query:
resource.type="k8s_cluster"
resource.labels.project_id=[*PROJECT_ID*]
resource.labels.location=[*REGION*]
resource.labels.cluster_name=[*CLUSTER_NAME*]
severity=WARNING
jsonPayload.message=~"Internal error occurred: failed calling webhook"
Per risolvere il problema:
Abilita l'API
connectgatewayrichiesta:gcloud services enable connectgateway.googleapis.com --project=[*PROJECT_ID*]Eseguire un riavvio in sequenza dei carichi di lavoro.