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.

As cargas de trabalho do Kubernetes sem um serviço do Kubernetes não são exibidas

Se aparecer "Cargas de trabalho do Kubernetes sem um serviço do Kubernetes não são exibidas. Crie um serviço do Kubernetes para cada carga de trabalho para visualizá-las abaixo", é necessário migrar manualmente para os serviços canônicos.

Há duas causas principais para esse problema:

  1. Os clusters na malha estão executando uma versão mais antiga do Anthos Service Mesh (< 1.6.8)
  2. Um serviço com SLOs definidos não mapeia 1:1 com um serviço canônico

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 mais antiga do ASM (<1.6.8), você não poderá usar os painéis baseados em serviço canônico. Para usar serviços canônicos, faça upgrade de todos os clusters para o Anthos Service Mesh 1.6.8 ou superior. Para mais informações, consulteComo 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 se os clusters estiverem no local.

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:

  1. O rótulo service.istio.io/canonical-name já foi definido explicitamente. Nenhuma outra medida é tomada.
  2. 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.
  3. Caso contrário, o rótulo service.istio.io/canonical-name será adicionado e seu valor será definido como o do rótulo app.
  4. 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.