Risoluzione dei problemi generali del componente aggiuntivo Service Mesh Istio

Sommario

Questo articolo illustra le strategie generali (che usano kubectl, istioctl e altri strumenti) per risolvere i problemi correlati al componente aggiuntivo Istio service mesh per il servizio Azure Kubernetes di Microsoft. Questo articolo fornisce anche un elenco di possibili messaggi di errore, motivi per le occorrenze degli errori e suggerimenti per risolvere questi errori.

Prerequisiti

• Interfaccia della riga di comando di Azure

• Lo strumento kubectl kubernetes o uno strumento simile per connettersi al cluster

  Nota: per installare kubectl usando l'interfaccia della riga di comando di Azure, eseguire il comando az aks install-cli .

• Strumento da riga di comando Istio istioctl

• Strumento URL client (cURL)

Elenco di controllo per la risoluzione dei problemi: uso di kubectl

La procedura di risoluzione dei problemi seguente usa vari kubectl comandi per eseguire il debug di pod bloccati o errori nel daemon Istio (Istiod).

Passaggio 1: Ottenere i log dei pod Istiod

Ottenere i log dei pod Istiod eseguendo il comando kubectl logs seguente:

kubectl logs --selector app=istiod --namespace aks-istio-system

Passaggio 2: Rimbalzare (eliminare) un pod

Potresti avere un buon motivo per riavviare un pod. Poiché Istiod è una distribuzione, è possibile eliminare in modo sicuro il pod eseguendo il comando kubectl delete :

kubectl delete pods <istio-pod> --namespace aks-istio-system

Il pod Istio è gestito da un deployment. Viene ricreato e ridistribuito automaticamente dopo averlo eliminato direttamente. Pertanto, eliminare il pod rappresenta un metodo alternativo per riavviarlo.

kubectl rollout restart deployment <istiod-asm-revision> --namespace aks-istio-system

Passaggio 3: Controllare lo stato delle risorse

Se Istiod non è programmato o se il pod non risponde, potresti voler controllare lo stato del deployment e dei set di replica. Per eseguire questo passaggio, eseguire il comando kubectl get :

kubectl get <resource-type> [[--selector app=istiod] | [<resource-name>]]

Lo stato della risorsa corrente viene visualizzato vicino alla fine dell'output. L'output potrebbe anche visualizzare gli eventi associati al ciclo del controller.

Passaggio 4: Ottenere tipi di definizione di risorse personalizzati

Per visualizzare i tipi di definizioni di risorse personalizzate usate da Istio, eseguire il kubectl get comando :

kubectl get crd | grep istio

Per elencare tutti i nomi di risorse basati su un determinato CRD, eseguire il comando seguente kubectl get :

kubectl get <crd-type> --all-namespaces

Passaggio 5: Visualizzare l'elenco dei pod Istiod

Per visualizzare l'elenco dei pod Istiod, eseguire il comando seguente kubectl get :

kubectl get pod --namespace aks-istio-system --output yaml

Passaggio 6: Ottenere altre informazioni sulla configurazione di Envoy

Se si verificano problemi di connettività tra i pod, ottieni altre informazioni sulla configurazione di Envoy eseguendo il comando kubectl exec sulla porta di amministrazione di Envoy.

kubectl exec --namespace <pod-namespace> \
    "$(kubectl get pods \
        --namespace <pod-namespace> \
        --selector app=sleep \
        --output jsonpath='{.items[0].metadata.name}')" \
    --container sleep \
-- curl -s localhost:15000/clusters

Passaggio 7: Recuperare i log sidecar per le sidecar di origine e destinazione

Recuperare i log sidecar per i sidecar di origine e di destinazione eseguendo il comando seguente kubectl logs due volte (la prima volta per il pod di origine e la seconda volta per il pod di destinazione):

kubectl logs <pod-name> --namespace <pod-namespace> --container istio-proxy

Elenco di controllo per la risoluzione dei problemi: uso di istioctl

La procedura di risoluzione dei problemi seguente illustra come raccogliere informazioni ed eseguire il debug dell'ambiente mesh eseguendo vari istioctl comandi.

Tutti i comandi istioctl devono essere eseguiti insieme al flag --istioNamespace aks-istio-system per indirizzare l'installazione del componente aggiuntivo AKS di Istio.

Passaggio 1: Assicurarsi che Istio sia installato correttamente

Per verificare di disporre di un'installazione corretta del componente aggiuntivo Istio, eseguire il comando istioctl verify-install seguente:

istioctl verify-install --istioNamespace aks-istio-system --revision <tag>

Passaggio 2: Analizzare i namespace

Per analizzare tutti gli spazi dei nomi o per analizzare uno spazio dei nomi specifico, eseguire il comando istioctl analyze seguente:

istioctl analyze --istioNamespace aks-istio-system \
    --revision <tag> \
    [--all-namespaces | --namespace <namespace-name>] \
    [--failure-threshold {Info | Warning | Error}]

Passaggio 3: Ottenere lo stato del proxy

Per recuperare lo stato del proxy, eseguire il comando istioctl proxy-status seguente:

istioctl proxy-status pod/<pod-name> \
    --istioNamespace aks-istio-system \
    --revision <tag> \
    --namespace <pod-namespace>

Passaggio 4: Scaricare la configurazione del proxy

Per scaricare la configurazione del proxy, eseguire il comando istioctl proxy-config all seguente:

istioctl proxy-config all <pod-name> \
    --istioNamespace aks-istio-system \
    --namespace <pod-namespace> \
    --output json

Passaggio 5: Controllare lo stato di iniezione

Per controllare lo stato di inserimento della risorsa, eseguire il comando seguente istioctl experimental check-inject :

istioctl experimental check-inject --istioNamespace aks-istio-system \
    --namespace <pod-namespace> \
    --labels <label-selector> | <pod-name> | deployment/<deployment-name>

Passaggio 6: Ottenere un report completo dei bug

Un report completo sui bug contiene le informazioni più dettagliate. Tuttavia, l'esecuzione di questo report può richiedere molto tempo in un cluster di grandi dimensioni perché include tutti i pod. È possibile limitare il report di bug a determinati spazi dei nomi. È anche possibile limitare il report a determinate distribuzioni, pod o selettori di etichetta.

Per recuperare un report di bug, eseguire il comando istioctl bug-report seguente:

istioctl bug-report --istioNamespace aks-istio-system \
    [--include <namespace-1>[, <namespace-2>[, ...]]]

Elenco di controllo per la risoluzione dei problemi: problemi vari

Passaggio 1: Risolvere i problemi di utilizzo delle risorse

Se si verifica un utilizzo elevato della memoria in Envoy, controllare le impostazioni di Envoy per la raccolta dei dati delle statistiche. Se si personalizzano le metriche Istio tramite MeshConfig, tenere presente che alcune metriche possono avere cardinalità elevata e, di conseguenza, creare un footprint di memoria superiore. Altri campi in MeshConfig, ad esempio la concorrenza, influiscono sull'utilizzo della CPU e devono essere configurati con attenzione.

Per impostazione predefinita, Istio aggiunge informazioni su tutti i servizi presenti nel cluster a ogni configurazione di Envoy. Il sidecar può limitare l'ambito di questa aggiunta ai carichi di lavoro esclusivamente all'interno di namespace specifici. Per ulteriori informazioni, consultare Attenzione a questo insidia della memoria nel sidecar del proxy Istio.

Ad esempio, la seguente definizione Sidecar nel namespace aks-istio-system limita la configurazione di Envoy per tutti i proxy dell'intera mesh a aks-istio-system e ad altri carichi di lavoro all'interno dello stesso namespace di quella specifica applicazione:

apiVersion: networking.istio.io/v1alpha3
kind: Sidecar
metadata:
  name: sidecar-restrict-egress
  namespace: aks-istio-system  # Needs to be deployed in the root namespace.
spec:
  egress:
  - hosts:
    - "./*"
    - "aks-istio-system/*"

È anche possibile provare a usare l'opzione Istio discoverySelectors in MeshConfig. L'opzione discoverySelectors contiene un array di selettori Kubernetes e può limitare la visibilità di Istiod a uno spazio dei nomi specifico (anziché a tutti gli spazi dei nomi nel cluster). Per ulteriori informazioni, vedere Usare i selettori di individuazione per configurare i namespace per la mesh di servizio Istio.

Passaggio 2: Risolvere i problemi di configurazione errata del traffico e della sicurezza

Per risolvere i problemi di configurazione comuni relativi alla gestione del traffico e alla sicurezza riscontrati spesso dagli utenti di Istio, vedere Problemi di gestione del traffico e Problemi di sicurezza nel sito Web Istio.

Per collegamenti a discussioni relative ad altri problemi, come l'inserimento di sidecar, l'osservabilità e gli aggiornamenti, consultare Problemi comuni nel sito della documentazione di Istio.

Verificare le regole di valutazione di AuthorizationPolicy

Quando si applicano più criteri di autorizzazione a un determinato carico di lavoro, prendere in considerazione l'ordine in cui Istio elabora i diversi tipi di controllo di accesso. Per altre informazioni, vedere la documentazione relativa ai criteri di autorizzazione Istio

Passaggio 3: Verificare la selezione del protocollo

Sebbene Istio possa rilevare automaticamente qualsiasi protocollo basato su TCP, in alcuni casi, il protocollo nella Service specifica potrebbe dover essere dichiarato in modo esplicito per sbloccare i problemi di comunicazione. Per eseguire questa dichiarazione, impostare il protocollo nella porta name o in appProtocol. In questo caso, appProtocol ha la precedenza. Ad esempio, alcuni scenari potrebbero richiedere l'impostazione del protocollo su tcp per il proxy del traffico come TCP non elaborato, anziché HTTP o HTTPS.

Passaggio 4: Evitare l'overload CoreDNS

I problemi relativi all'overload CoreDNS potrebbero richiedere la modifica di determinate impostazioni DNS Istio, ad esempio il dnsRefreshRate campo nella definizione Istio MeshConfig.

Passaggio 5: Correggere le condizioni di corsa di pod e sidecar

Se il pod dell'applicazione viene avviato prima dell'avvio del sidecar Envoy, l'applicazione potrebbe non rispondere o potrebbe essere riavviata. Per istruzioni su come evitare questo problema, vedere Pod o contenitori che iniziano con problemi di rete se istio-proxy non è pronto. In particolare, l'impostazione del campo MeshConfig sotto holdApplicationUntilProxyStarts a defaultConfig può aiutare a prevenire queste condizioni di race.

Passaggio 6: Verificare la modalità OutboundTrafficPolicy e la configurazione del Service Entry per l'accesso in uscita

I problemi relativi all'accesso in uscita o ai gateway in uscita possono verificarsi a causa di determinate configurazioni Istio relative alla configurazione del servizio esterno. Verificare se outboundTrafficPolicy.mode è impostato su REGISTRY_ONLY in Shared MeshConfig o Sidecar nelle risorse personalizzate. In caso affermativo, è necessario dichiarare in modo esplicito un oggetto ServiceEntry per consentire l'accesso in uscita al servizio esterno. Quando si usano gateway in uscita, la risoluzione per ServiceEntry deve essere impostata su DNS.

Inoltre, ricorda che ServiceEntries viene esportato in tutti gli spazi dei nomi per impostazione predefinita. Per limitare l'ambito di un ServiceEntry a uno spazio dei nomi specifico, utilizzare il campo exportTo in spec.

Passaggio 7: Configurare un entry di servizio quando si usa un proxy HTTP per il traffico in uscita

Se il cluster usa un proxy HTTP per l'accesso a Internet in uscita, è necessario configurare un Service Entry. Per maggiori informazioni, consultare la sezione Supporto proxy HTTP nel servizio Azure Kubernetes.

Passaggio 8: Abilitare la registrazione dell'accesso a Envoy

È possibile abilitare la registrazione dell'accesso per Envoy per identificare e individuare i problemi nei gateway e nei proxy sidecar. Per altre informazioni sulla registrazione e la raccolta di dati di telemetria per il componente aggiuntivo Istio, vedere la documentazione sulla configurazione mesh, sull'API telemetria e sulla raccolta di metriche Istio.

Messaggi di errore

La tabella seguente contiene un elenco di possibili messaggi di errore (per la distribuzione del componente aggiuntivo, l'abilitazione dei gateway in ingresso e l'esecuzione di aggiornamenti), il motivo per cui si verifica un errore e raccomandazioni per risolvere l'errore.

Riferimenti

• Per suggerimenti generali sul debug istio, vedere Strumenti di diagnostica Istio

• Risoluzione dei problemi del componente aggiuntivo MeshConfig del service mesh Istio

• Risoluzione dei problemi del gateway di ingresso dell'add-on Istio service mesh

• Risoluzione dei problemi nell'aggiornamento minore delle revisioni del componente aggiuntivo Istio Service Mesh

• Risoluzione dei problemi del certificato CA del plug-in complementare Istio service mesh

Dichiarazione di non responsabilità sulle informazioni di terze parti

I prodotti di terzi citati in questo articolo sono prodotti da società indipendenti da Microsoft. Microsoft non rilascia alcuna garanzia implicita o esplicita relativa alle prestazioni o all'affidabilità di tali prodotti