Como resolver problemas do serviço canônico no Anthos Service Mesh

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

Nesta seção, explicamos problemas comuns do Anthos 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 Anthos Service Mesh

Se algum dos clusters estiver executando uma versão anterior do Anthos Service Mesh (<1.6.8) ou um cluster estiver executando o Anthos Service Mesh com o controlador de serviço canônico desativado, esses clusters (e serviços em execução neles) não aparecerão na IU da malha de serviço. Para usar os serviços canônicos, faça upgrade de todos os clusters para o Anthos Service Mesh 1.6.8 ou posterior e use 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 Anthos Service Mesh para a versão mais recente se os clusters estiverem no GKE ou Como fazer upgrade do Anthos 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 Anthos Service Mesh não está instalado no cluster

Se o Anthos Service Mesh não estiver instalado em nenhum dos clusters, esses clusters não aparecerão na IU do Service Mesh. Para mais informações sobre como instalar o Anthos Service Mesh, consulte a documentação do Anthos 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 Anthos Service Mesh mostrou painéis para os 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 Anthos 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.