O Anthos Service Mesh e o Traffic Director agora são Cloud Service Mesh. Para mais informações, consulte a Visão geral do Cloud Service Mesh.

Esta página foi traduzida pela API Cloud Translation.

Como resolver problemas de serviço canônico no Cloud Service Mesh

Observação: os serviços canônicos são compatíveis com a versão 1.6.8 do Cloud Service Mesh e versões mais recentes.

Nesta seção, explicamos problemas comuns do Cloud Service Mesh e como resolvê-los. Se você precisar de mais ajuda, consulte Como receber suporte.

Os clusters na malha estão executando uma versão mais antiga do Cloud Service Mesh

Se algum dos clusters estiver executando uma versão anterior do Cloud Service Mesh (<1.6.8) ou uma cluster estiver executando o Cloud Service Mesh com o controlador de serviço canônico desativado, esses clusters (e os serviços em execução neles) não aparecerão na interface do Service Mesh. Para usar a função Canonical Serviços, é necessário fazer upgrade de cada cluster para o Cloud Service Mesh 1.6.8 ou superior usar a opção de instalação padrão, que inclui o controlador de serviço canônico. Para mais informações, consulte Como fazer upgrade do Cloud Service Mesh para a versão mais recente. se os clusters estiverem no GKE ou Como fazer upgrade do Cloud Service Mesh no local.

Como alternativa, se preferir não instalar o controlador nos clusters, ative o controlador de serviço canônico gerenciado (atualmente em prévia) para a malha.

Para mais informações sobre como ativar o controlador de serviços canônicos, consulte este link.

O Cloud Service Mesh não está instalado no cluster

Se o Cloud Service Mesh não estiver instalado em nenhum dos clusters, eles não vão aparecer na interface do Service Mesh. Para mais informações sobre como instalar Consulte a documentação do Cloud Service Mesh.

Você não fez login no cluster local

Se você tiver um cluster no local na malha e não tiver feito login nele, não será possível visualizar os serviços correspondentes a esse cluster. Para visualizar esses serviços no painel, faça login no cluster. Para mais informações sobre como fazer login em um cluster, consulte Como fazer login em um cluster no Console do Cloud.

Seu cluster local não está acessível

Se você tiver um cluster no local na malha e ele não estiver acessível por meio do agente de conexão, não será possível ver os serviços correspondentes a esse cluster. Para visualizar esses serviços no painel, verifique se o cluster está em execução e conectado ao Google Cloud. Para mais informações sobre como conectar o cluster ao Google Cloud, consulte Visão geral do Connect.

Um serviço com SLOs definidos não mapeia 1:1 com um serviço canônico

Antes da mudança para o serviço canônico, O Cloud Service Mesh mostrou painéis de serviços do Kubernetes. Os serviços do Kubernetes e os serviços canônicos padrão costumam estar alinhados, mas é possível que um serviço do Kubernetes não corresponda automaticamente ao Serviço canônico correspondente ou que o limite padrão do serviço canônico não seja desejado.

Se você tiver objetivos de nível de serviço (SLOs) configurados em serviços existentes que não podem corresponder automaticamente a um serviço canônico padrão, eles não poderão ser migrados. Para começar a usar os Serviços canônicos, você precisará excluir os SLOs do serviço problemático. Se preferir, crie novos SLOs para os serviços canônicos que mais se aproximam desse serviço antes de excluir o SLO antigo.

Meu painel de controle não tem o conteúdo que eu espero

Os painéis de serviço da malha de serviço têm escopo definido como um serviço canônico na malha de serviço, em que um serviço canônico é um conceito de serviço lógico de alto nível que abrange todas as cargas de trabalho, regiões relevantes etc.

Por padrão, os rótulos atuais em cada instância de carga de trabalho (Pod ou WorkloadEntry) definem os serviços canônicos e seguem estas regras em ordem de prioridade decrescente:

O rótulo service.istio.io/canonical-name já foi definido explicitamente. Nenhuma outra medida é tomada.
Caso contrário, o rótulo service.istio.io/canonical-name será adicionado e seu valor será definido como o do rótulo app.kubernetes.io/name.
Caso contrário, o rótulo service.istio.io/canonical-name será adicionado e seu valor será definido como o do rótulo app.
Caso contrário, o rótulo service.istio.io/canonical-name será adicionado e seu valor será definido como name da carga de trabalho proprietária. Nesse caso como o da "carga de trabalho proprietária" se o Pod for implantado sozinho, ou a implantação, StatefulSet etc. estiver usando orquestração de nível superior.

Para a maioria dos usuários idiomáticos do Kubernetes e do Kube Run/Knative, essas regras são mapeadas diretamente para como você já gerencia seus serviços e cargas de trabalho.

No entanto, em alguns casos de uso mais personalizados ou mais complexos, a heurística padrão não captura seu serviço adequadamente. Por sua vez, o painel do Cloud Service Mesh que você vê não inclui o conteúdo esperado.

Isso pode ser corrigido definindo manualmente o escopo do Serviço canônico.

Como definir manualmente o escopo de um serviço

Sempre que possível, recomendamos usar os mecanismos de agrupamento padrão automáticos. No entanto, se você quiser modificar esses agrupamentos padrão, aplique o rótulo service.istio.io/canonical-name do Kubernetes às configurações de Pod e WorkloadEntry do Kubernetes.

Para detalhes, consulte como definir manualmente um Serviço canônico.