Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Solução de problemas do Cloud Service Mesh passo a passo
Esta seção explica como solucionar e resolver problemas ao usar o
Cloud Service Mesh. Se você precisar de mais ajuda, consulte
Como receber suporte.
Etapas da solução de problemas
Siga estas etapas gerais para resolver problemas do Cloud Service Mesh:
Use as ferramentas de validação de configurações automatizadas.
Verifique se você tem um problema comum com uma solução conhecida.
Restrinja o escopo do problema.
Analise registros e informações relevantes.
Colete registros de diagnóstico e procure ajuda.
A ferramenta de diagnóstico do Cloud Service Mesh pode detectar problemas comuns de configuração. Instale a ferramenta de solução de problemas usando estas
instruções.
Antes de começar
Verifique se o contexto kubeconfig do cluster está disponível no
arquivo kubeconfig. Caso contrário, execute o seguinte comando:
MEMBERSHIP_LOCATION: a região da sua
filiação. Você pode verificar a localização da assinatura com
gcloud container fleet memberships list --project FLEET_PROJECT_ID
substituindo FLEET_PROJECT_ID pelo ID do projeto da
frota.
PROJECT_NAME: o nome do projeto
A tabela a seguir descreve as possíveis respostas.
DESCONHECIDO
(Padrão) As informações de status não estão disponíveis ou são desconhecidas.
SINCRONIZADO
O plano de controle enviou a configuração para o cliente e recebeu um ACK dele.
ERRO
O plano de controle enviou a configuração para o cliente e recebeu um NACK dele.
VENCIDO
O plano de controle enviou a configuração ao cliente, mas não recebeu um ACK ou um NACK do cliente.
NOT SENT
A configuração não foi enviada.
N/A
Não relevante.
Sem suporte
O status de sincronização não é compatível com nossa API de solução de problemas.
No cluster
kubectl get pods -n istio-system
kubectl describe -n istio-system
Para todos os pods no istio-system: kubectl logs -n istio-system -l istio --all-containers
istioctl version
istioctl proxy-status
kubectl get configmap istio -o yaml && kubectl get configmap istio-sidecar-injector -o yaml
kubectl top pods -n istio-system
Use os seguintes comandos para entender a escala da implantação:
kubectl get nodes
kubectl get services --all-namespaces
kubectl get pods --all-namespaces
Conferir as configurações de proxy
O comando a seguir pode ajudar a entender as configurações do proxy do Cloud Service Mesh:
TYPE: um dos seguintes: cluster, listeners,
rotas, endpoints, bootstrap, log, secret, all.
MEMBERSHIP_NAME: o nome da sua assinatura.
MEMBERSHIP_LOCATION: a região da sua
filiação. Você pode verificar a localização da assinatura com
gcloud container fleet memberships list --project FLEET_PROJECT_ID
substituindo FLEET_PROJECT_ID pelo ID do projeto da
frota.
PROJECT_NAME: o nome do projeto
No cluster
Use o istioctl proxy-config para conferir as configurações de proxy dos planos de controle no cluster. Para mais informações, consulte
Como depurar o Envoy e o istiod.
Se o problema persistir, consulte a próxima seção para verificar se ele
já é conhecido.
Verificar problemas e soluções comuns
É possível economizar tempo verificando se os sintomas correspondem a um problema nessas seções comuns
de problemas e resoluções, agrupado pela área funcional do
Cloud Service Mesh:
Se isso não resolver o problema, veja a próxima seção.
Restringir o escopo do problema
O Cloud Service Mesh consiste em várias tecnologias que trabalham juntas. Isso significa
que determinados tipos de problemas estão associados a determinadas funções ou
componentes funcionais. Cada um desses componentes gera registros úteis. Antes
de tentar analisar manualmente o volume de informações que eles fornecem, restrinja
o escopo da solução de problemas respondendo às seguintes perguntas:
O problema ocorre dentro do plano de controle ou do plano de dados, por exemplo, proxies do istiod ou Envoy?
Em qual área funcional você está enfrentando o problema, por exemplo: rede, telemetria, segurança etc.?
Há perda de tráfego de malha de serviço ampla ou em uma implantação específica?
O problema surge ou piora devido à falta de capacidade de escalonamento de tráfego na malha de serviço?
O problema causa latência ou outros problemas de desempenho?
É possível reproduzir o problema sob demanda?
O problema começou após uma alteração de configuração recente no Istio, no GKE etc.?
Há um aumento ou pico no tráfego na malha de serviço?
Esse cluster tem algum recurso perceptível ativado ou implantações não típicas?
Você observa alta utilização da CPU ou da memória? Em caso afirmativo, qual é o uso esperado em grande escala?
Há restrições de cota a serem consideradas?
Analisar registros e informações relevantes
Depois de restringir o escopo do problema, concentre-se em determinados registros e
informações com mais eficiência. Para saber mais sobre os registros que o Cloud Service Mesh
gera e como interpretar as informações que eles contêm, consulte
Como interpretar os registros do Cloud Service Mesh.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-08-19 UTC."],[],[],null,["# Troubleshoot Cloud Service Mesh step-by-step\n============================================\n\nThis section explains how to troubleshoot and resolve problems when using\nCloud Service Mesh. If you need additional assistance, see\n[Getting support](/service-mesh/v1.25/docs/getting-support).\n\nTroubleshooting steps\n---------------------\n\nFollow these general steps to troubleshoot Cloud Service Mesh:\n\n1. Use the automated configuration validation tools.\n2. Check if you have a common problem with a known solution.\n3. Narrow the scope of the problem.\n4. Review relevant logs and information.\n5. Gather diagnostic logs and seek help.\n\n| **Note:** If you are unable to troubleshoot manually, see [Gather diagnostic logs and seek help](/service-mesh/v1.25/docs/troubleshooting/troubleshoot-collect-logs) for next steps.\n\nThe Cloud Service Mesh diagnostic tool can detect common configuration\nproblems. Install the troubleshooting tool using these\n[instructions](/service-mesh/v1.25/docs/downloading-istioctl).\n\nBefore you begin\n----------------\n\n1. Make sure the kubeconfig context for your cluster is available in your\n kubeconfig file. If not, then run the following command:\n\n gcloud container clusters get-credentials \u003cvar translate=\"no\"\u003eCLUSTER_NAME\u003c/var\u003e \\\n --location=\u003cvar translate=\"no\"\u003eCLUSTER_LOCATION\u003c/var\u003e --project=\u003cvar translate=\"no\"\u003ePROJECT_NAME\u003c/var\u003e\n\n Replace the following:\n - \u003cvar translate=\"no\"\u003eCLUSTER_NAME\u003c/var\u003e: the name of your cluster.\n - \u003cvar translate=\"no\"\u003eCLUSTER_LOCATION\u003c/var\u003e: the zone or region for your cluster.\n - \u003cvar translate=\"no\"\u003ePROJECT_NAME\u003c/var\u003e: the project name.\n2. Verify that the [Application Default Credentials](/authentication/provide-credentials-adc)\n are created. If they are not, run one of the following commands:\n\n gcloud auth application-default login --billing-project=\u003cvar translate=\"no\"\u003ePROJECT_NAME\u003c/var\u003e\n\n gcloud auth application-default set-quota-project \u003cvar translate=\"no\"\u003ePROJECT_NAME\u003c/var\u003e\n\n Replacing \u003cvar translate=\"no\"\u003ePROJECT_NAME\u003c/var\u003e with the your project name.\n\nView control plane status\n-------------------------\n\nThe following commands can help you understand the status of the\nCloud Service Mesh control plane: \n\n### Managed\n\n- Get the list of clients connection status to the Cloud Service Mesh control plane:\n\n gcloud beta container fleet mesh debug proxy-status \\\n --membership=\u003cvar translate=\"no\"\u003eMEMBERSHIP_NAME\u003c/var\u003e \\\n --location=\u003cvar translate=\"no\"\u003eMEMBERSHIP_LOCATION\u003c/var\u003e \\\n --project=\u003cvar translate=\"no\"\u003ePROJECT_NAME\u003c/var\u003e\n\n Replace the following:\n - \u003cvar translate=\"no\"\u003eMEMBERSHIP_NAME\u003c/var\u003e: the name of your membership.\n - \u003cvar translate=\"no\"\u003eMEMBERSHIP_LOCATION\u003c/var\u003e: the region for your membership. You can check your membership's location with `gcloud container fleet memberships list --project `\u003cvar translate=\"no\"\u003eFLEET_PROJECT_ID\u003c/var\u003e replacing \u003cvar translate=\"no\"\u003eFLEET_PROJECT_ID\u003c/var\u003e with the fleet project ID.\n - \u003cvar translate=\"no\"\u003ePROJECT_NAME\u003c/var\u003e: the project name.\n\n The following table describes the possible responses.\n\n### In-cluster\n\n- `kubectl get pods -n istio-system`\n- `kubectl describe -n istio-system`\n- For all pods in istio-system: `kubectl logs -n istio-system -l istio --all-containers`\n- `istioctl version`\n- `istioctl proxy-status`\n- `kubectl get configmap istio -o yaml && kubectl get configmap istio-sidecar-injector -o yaml`\n- `kubectl top pods -n istio-system`\n\nUse the following commands to understand the scale of the deployment:\n\n- `kubectl get nodes`\n- `kubectl get services --all-namespaces`\n- `kubectl get pods --all-namespaces`\n\nView proxy configurations\n-------------------------\n\nThe following command can help you understand the Cloud Service Mesh proxy\nconfigurations: \n\n### Managed\n\n gcloud beta container fleet mesh debug proxy-config \u003cvar translate=\"no\"\u003ePOD_NAME\u003c/var\u003e.\u003cvar translate=\"no\"\u003eNAMESPACE\u003c/var\u003e \\ \n --type=\u003cvar translate=\"no\"\u003eTYPE\u003c/var\u003e \\\n --membership=\u003cvar translate=\"no\"\u003eMEMBERSHIP_NAME\u003c/var\u003e \\\n --location=\u003cvar translate=\"no\"\u003eMEMBERSHIP_LOCATION\u003c/var\u003e \\\n --project=\u003cvar translate=\"no\"\u003ePROJECT_NAME\u003c/var\u003e\n\n- \u003cvar translate=\"no\"\u003ePOD_NAME\u003c/var\u003e: the name of your Pod.\n- \u003cvar translate=\"no\"\u003eNAMESPACE\u003c/var\u003e: the namespace of your Pod.\n- \u003cvar translate=\"no\"\u003eTYPE\u003c/var\u003e: One of for following: cluster, listeners, routes, endpoints, bootstrap, log, secret, all.\n- \u003cvar translate=\"no\"\u003eMEMBERSHIP_NAME\u003c/var\u003e: the name of your membership.\n- \u003cvar translate=\"no\"\u003eMEMBERSHIP_LOCATION\u003c/var\u003e: the region for your membership. You can check your membership's location with `gcloud container fleet memberships list --project `\u003cvar translate=\"no\"\u003eFLEET_PROJECT_ID\u003c/var\u003e replacing \u003cvar translate=\"no\"\u003eFLEET_PROJECT_ID\u003c/var\u003e with the fleet project ID.\n- \u003cvar translate=\"no\"\u003ePROJECT_NAME\u003c/var\u003e: the project name.\n\n### In-cluster\n\nUse the `istioctl proxy-config` to see proxy configurations for in-cluster\ncontrol planes. For more information, see\n[Debugging Envoy and istiod](https://istio.io/latest/docs/ops/diagnostic-tools/proxy-cmd/).\n\nIf the problem persists, see the next section to check if your problem is\nalready known.\n\nCheck for common problems and solutions\n---------------------------------------\n\nYou can save time by checking if your symptoms match an issue in these common\nproblems and resolutions sections, grouped by Cloud Service Mesh functional\narea:\n\n- [Installation issues](/service-mesh/v1.25/docs/troubleshooting/troubleshoot-installation)\n- [Managed control plane issues](/service-mesh/v1.25/docs/managed/troubleshoot-managed-anthos-service-mesh)\n- [Observability issues](/service-mesh/v1.25/docs/troubleshooting/troubleshoot-observability)\n- [Off-Google Cloud deployment issues](/service-mesh/v1.25/docs/troubleshooting/troubleshoot-off-gcp)\n- [Proxy issues](/service-mesh/v1.25/docs/troubleshooting/troubleshoot-proxy)\n- [Resource issues](/service-mesh/v1.25/docs/troubleshooting/troubleshoot-resources)\n- [Scaling issues](/service-mesh/v1.25/docs/troubleshooting/troubleshoot-scaling)\n- [Security issues](/service-mesh/v1.25/docs/troubleshooting/troubleshoot-security)\n- [Traffic management issues](/service-mesh/v1.25/docs/troubleshooting/troubleshoot-traffic)\n- [Webhook issues](/service-mesh/v1.25/docs/troubleshooting/troubleshoot-webhook)\n- [Sidecar proxies issues](/service-mesh/v1.25/docs/troubleshooting/troubleshoot-sidecar-proxies)\n\nIf this does not resolve your issue, see the next section.\n\nNarrow the scope of the problem\n-------------------------------\n\nCloud Service Mesh consists of several technologies working together, which means\nthat certain types of problems are associated with particular functional areas\nor components. Each of these components generate helpful logs of their own. Before\nyou attempt to manually analyze the volume of information they provide, narrow\nthe scope of your troubleshooting by answering the following questions:\n\n- Does the issue occur within the control plane or the data plane, for example `istiod` or Envoy proxies?\n- In which functional area are you experiencing the issue, for example Networking, Telemetry, Security, etc.?\n- Is there service-mesh wide traffic loss or in a specific deployment?\n- Does the problem appear or worsen due to lack of ability to scale traffic in service mesh?\n- Does the issue cause latency or other performance issues?\n- Can you reproduce the issue on demand?\n- Did the problem begin after a recent configuration change in Istio, GKE, etc.?\n- Is there an increase or spike in traffic within the service mesh?\n- Does this cluster have any noticeable features enabled or non-typical deployments?\n- Do you observe high CPU or memory utilization? If so, what is the expected usaged at scale?\n- Are there quota restrictions to consider?\n\nReview relevant logs and information\n------------------------------------\n\nAfter you narrow the scope of the problem, you can focus on certain logs and\ninformation more effectively. To learn about the logs that Cloud Service Mesh\ngenerates and how to interpret the information they contain, see\n[Interpreting Cloud Service Mesh logs](/service-mesh/v1.25/docs/observability/accessing-logs#interpret_anthos_service_mesh_logs)."]]