Risoluzione dei problemi di App Mesh Kubernetes

Questo argomento descrive i problemi più comuni che potresti riscontrare quando utilizzi App Mesh con Kubernetes.

Le risorse App Mesh create in Kubernetes non possono essere trovate in App Mesh

Sintomi

Hai creato le risorse App Mesh utilizzando la definizione di risorsa personalizzata (CRD) di Kubernetes, ma le risorse che hai creato non sono visibili in App Mesh quando utilizzi le API or. AWS Management Console

Risoluzione

La causa probabile è un errore nel controller Kubernetes per App Mesh. Per ulteriori informazioni, consulta Risoluzione dei problemi su. GitHub Controlla i log del controller per eventuali errori o avvisi che indicano che il controller non è riuscito a creare alcuna risorsa.

kubectl logs -n appmesh-system -f \
    $(kubectl get pods -n appmesh-system -o name | grep controller)

Se il problema persiste, valuta la possibilità di aprirne uno GitHub o di contattare l'AWSassistenza.

Dopo l'iniezione del sidecar Envoy, i pod non sono stati sottoposti ai controlli di prontezza e vivacità

Sintomi

I pod della tua applicazione funzionavano correttamente in precedenza, ma dopo l'iniezione del sidecar Envoy in un pod, i controlli di prontezza e vivacità iniziano a fallire.

Risoluzione

Assicurati che il contenitore Envoy che è stato iniettato nel pod sia stato avviato con il servizio di gestione Envoy di App Mesh. Puoi verificare eventuali errori facendo riferimento ai codici di errore in. Envoy disconnesso dal servizio di gestione App Mesh Envoy con testo di errore È possibile utilizzare il seguente comando per ispezionare i log di Envoy per il relativo pod.

kubectl logs -n appmesh-system -f \
    $(kubectl get pods -n appmesh-system -o name | grep controller) \
    | grep "gRPC config stream closed"

Se il problema persiste, valuta la possibilità di aprirne uno GitHub o di contattare l'AWSassistenza.

I pod non vengono registrati o annullati come istanze AWS Cloud Map

Sintomi

I tuoi pod Kubernetes non vengono registrati o cancellati durante il loro ciclo di vita. AWS Cloud Map Un pod può avviarsi correttamente ed essere pronto a servire il traffico, ma non a riceverne. Quando un pod viene terminato, i client possono comunque conservare il relativo indirizzo IP e tentare di inviargli traffico, senza successo.

Risoluzione

Si tratta di un problema noto. Per ulteriori informazioni, consulta i Pod non si registrano automaticamente o annullano la registrazione in Kubernetes con problemi. AWS Cloud Map GitHub A causa della relazione tra pod, nodi virtuali App Mesh e AWS Cloud Map risorse, il controller App Mesh per Kubernetes potrebbe desincronizzarsi e perdere risorse. Ad esempio, ciò può accadere se una risorsa di nodo virtuale viene eliminata da Kubernetes prima di terminare i pod associati.

Per mitigare questo problema:

• Assicurati di utilizzare la versione più recente del controller App Mesh per Kubernetes.

• Assicurati che i AWS Cloud Map namespaceName e serviceName siano corretti nella definizione del nodo virtuale.

• Assicurati di eliminare tutti i pod associati prima di eliminare la definizione del nodo virtuale. Se hai bisogno di aiuto per identificare quali pod sono associati a un nodo virtuale, consulta. Impossibile determinare dove è in esecuzione un pod per una risorsa App Mesh

• Se il problema persiste, esegui il comando seguente per ispezionare i log del controller alla ricerca di errori che potrebbero aiutare a rivelare il problema sottostante.

  kubectl logs -n appmesh-system \
      $(kubectl get pods -n appmesh-system -o name | grep appmesh-controller)

• Valuta la possibilità di utilizzare il seguente comando per riavviare i pod del controller. Questo può risolvere i problemi di sincronizzazione.

  kubectl delete -n appmesh-system \
      $(kubectl get pods -n appmesh-system -o name | grep appmesh-controller)

Se il problema persiste, valuta la possibilità di aprirne uno GitHub o di contattare l'AWSassistenza.

Impossibile determinare dove è in esecuzione un pod per una risorsa App Mesh

Sintomi

Quando esegui App Mesh su un cluster Kubernetes, un operatore non può determinare dove è in esecuzione un carico di lavoro, o pod, per una determinata risorsa App Mesh.

Risoluzione

Le risorse del pod Kubernetes sono annotate con la mesh e il nodo virtuale a cui sono associate. Puoi interrogare quali pod sono in esecuzione per un determinato nome di nodo virtuale con il seguente comando.

kubectl get pods --all-namespaces -o json | \
    jq '.items[] | { metadata } | select(.metadata.annotations."appmesh.k8s.aws/virtualNode" == "virtual-node-name")'

Se il problema persiste, valuta la possibilità di aprirne uno GitHub o di contattare l'AWSassistenza.

Impossibile determinare su quale risorsa App Mesh sia in esecuzione un pod

Sintomi

Quando si esegue App Mesh su un cluster Kubernetes, un operatore non può determinare su quale risorsa App Mesh è in esecuzione un determinato pod.

Risoluzione

Le risorse del pod Kubernetes sono annotate con la mesh e il nodo virtuale a cui sono associate. Puoi generare i nomi della mesh e dei nodi virtuali interrogando direttamente il pod utilizzando il seguente comando.

kubectl get pod pod-name -n namespace -o json | \
    jq '{ "mesh": .metadata.annotations."appmesh.k8s.aws/mesh", "virtualNode": .metadata.annotations."appmesh.k8s.aws/virtualNode" }'

Se il problema persiste, valuta la possibilità di aprirne uno GitHub o di contattare l'AWSassistenza.

I Client Envoy non sono in grado di comunicare con App Mesh Envoy Management Service con IMDSv1 disabilitato

Sintomi

Quando IMDSv1 è disabilitato, gli Envoy client non sono in grado di comunicare con il piano di controllo App Mesh (Envoy Management Service). IMDSv2il supporto non era disponibile nella versione precedente di App Mesh Envoy. v1.24.0.0-prod

Risoluzione

Per risolvere questo problema, puoi fare una di queste tre cose.

• Esegui l'aggiornamento alla versione App Mesh Envoy v1.24.0.0-prod o successiva, che IMDSv2 supporta.

• Riabilitalo IMDSv1 sull'istanza in cui è in esecuzione Envoy. Per istruzioni sul ripristinoIMDSv1, consulta Configurare le opzioni dei metadati dell'istanza.

• Se i tuoi servizi sono in esecuzione su Amazon EKS, ti consigliamo di utilizzare i ruoli IAM per gli account di servizio (IRSA) per recuperare le credenziali. Per istruzioni su come abilitare IRSA, consulta i ruoli IAM per gli account di servizio.

Se il problema persiste, valuta la possibilità di aprirne uno GitHub o di contattare l'AWSassistenza.

IRSA non funziona sul contenitore dell'applicazione quando App Mesh è abilitato e Envoy viene iniettato

Sintomi

Quando App Mesh è abilitato su un cluster Amazon EKS con l'aiuto del controller App Mesh per Amazon EKS, Envoy e proxyinit i contenitori vengono iniettati nel pod dell'applicazione. L'applicazione non è in grado di assumere IRSA e invece presuppone il. node role Quando descriviamo i dettagli del pod, vediamo che la variabile di AWS_ROLE_ARN ambiente AWS_WEB_IDENTITY_TOKEN_FILE o la variabile di ambiente non sono incluse nel contenitore dell'applicazione.

Risoluzione

Se una delle due AWS_WEB_IDENTITY_TOKEN_FILE variabili di AWS_ROLE_ARN ambiente è definita, il webhook salterà il pod. Non fornite nessuna di queste variabili e il webhook si occuperà di iniettarle per voi.

reservedKeys := map[string]string{
        "AWS_ROLE_ARN":                "",
        "AWS_WEB_IDENTITY_TOKEN_FILE": "",
    }
    ...
    for _, env := range container.Env {
        if _, ok := reservedKeys[env.Name]; ok {
            reservedKeysDefined = true
        }

Se il problema persiste, valuta la possibilità di aprirne uno GitHub o di contattare l'AWSassistenza.