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

Esta página foi traduzida pela API Cloud Translation.

Resolver problemas de serviços canónicos na malha de serviço na nuvem

Nota: os serviços canónicos são suportados automaticamente na versão 1.6.8 e superiores do Cloud Service Mesh.

Esta secção explica os problemas comuns do Cloud Service Mesh e como os resolver. Se precisar de assistência adicional, consulte o artigo Receber apoio técnico.

Os clusters na sua malha estão a executar uma versão mais antiga do Cloud Service Mesh

Se algum dos seus clusters estiver a executar uma versão anterior do Cloud Service Mesh (<1.6.8) ou um cluster estiver a executar o Cloud Service Mesh com o controlador de serviços canónico desativado, esses clusters (e os serviços executados neles) não aparecem na IU do Service Mesh. Para usar os serviços da Canonical, tem de atualizar cada cluster para o Cloud Service Mesh 1.6.8 ou superior e usar a opção de instalação predefinida que inclui o controlador de serviços da Canonical. Para mais informações, consulte o artigo Atualizar o Cloud Service Mesh para a versão mais recente se os seus clusters estiverem no GKE ou Atualizar o Cloud Service Mesh no local.

Em alternativa, se preferir não instalar o controlador nos seus clusters, pode ativar o Managed Canonical Service Controller (atualmente em pré-visualização) para a sua malha.

Para mais informações sobre como ativar o controlador de serviços canónicos, consulte o artigo Ativar o controlador de serviços canónicos.

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

Se o Cloud Service Mesh não estiver instalado em nenhum dos seus clusters, esses clusters não aparecem na IU do Service Mesh. Para mais informações sobre como instalar o Cloud Service Mesh, consulte a documentação do Cloud Service Mesh.

Não tem sessão iniciada no cluster no local

Se tiver um cluster no local na malha e não tiver sessão iniciada no cluster, não pode ver os serviços correspondentes a esse cluster. Para ver esses serviços no painel de controlo, tem de iniciar sessão no cluster. Para mais informações sobre como iniciar sessão num cluster, consulte o artigo Iniciar sessão num cluster a partir da Cloud Console.

O seu cluster no local não está acessível

Se tiver um cluster no local na malha e este não estiver acessível através do agente connect, não poderá ver os serviços correspondentes a esse cluster. Para ver esses serviços no painel de controlo, certifique-se de que o cluster está em execução e ligado a Google Cloud. Para mais informações sobre como associar o seu cluster ao Google Cloud, consulte a vista geral da associação.

Um serviço com SLOs definidos não é mapeado 1:1 com um serviço canónico

Antes da mudança para o serviço canónico, o Cloud Service Mesh mostrava painéis de controlo para os serviços Kubernetes. Embora os serviços do Kubernetes e os serviços canónicos predefinidos se alinhem frequentemente, é possível que um serviço do Kubernetes não possa ser automaticamente associado ao respetivo serviço canónico ou que o limite do serviço canónico predefinido não seja desejado.

Se tiver Objetivos ao nível do serviço (SLOs) configurados em serviços existentes que não podem ser automaticamente associados a um serviço canónico predefinido, não podem ser migrados. Para começar a usar os serviços canónicos, tem de eliminar os SLOs do serviço problemático. Se quiser, pode criar novos SLOs para os serviços canónicos que correspondam mais de perto a esse serviço antes de eliminar o SLO antigo.

O meu painel de controlo não tem o conteúdo que esperava

Os painéis de controlo do serviço Service Mesh têm cada um âmbito definido para um serviço canónico na sua malha de serviços, onde 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, etc. relevantes.

Por predefinição, as etiquetas existentes em cada instância de carga de trabalho (Pod ou WorkloadEntry) definem os serviços canónicos e seguem estas regras por ordem decrescente de prioridade:

A etiqueta service.istio.io/canonical-name já foi definida explicitamente. Não é tomada nenhuma ação adicional.
Caso contrário, a etiqueta service.istio.io/canonical-name é adicionada e o respetivo valor é definido como o da etiqueta app.kubernetes.io/name.
Caso contrário, a etiqueta service.istio.io/canonical-name é adicionada e o respetivo valor é definido como o da etiqueta app.
Caso contrário, a etiqueta service.istio.io/canonical-name é adicionada e o respetivo valor é definido como o name da carga de trabalho proprietária. A "carga de trabalho proprietária" neste caso é o Pod se for implementado sozinho ou a implementação, o StatefulSet, etc., se usar uma orquestração de nível superior.

Para a maioria dos utilizadores idiomáticos do Kubernetes e do Kube Run / Knative, estas regras são mapeadas diretamente para a forma como já gere os seus serviços e cargas de trabalho.

No entanto, em alguns exemplos de utilização mais personalizados ou mais complexos, as heurísticas predefinidas não captam o seu serviço adequadamente e, por sua vez, o painel de controlo do Cloud Service Mesh que vê não inclui o conteúdo que espera.

Pode corrigir este problema definindo manualmente o âmbito do serviço canónico.

Definir manualmente o âmbito de um serviço

Sempre que possível, recomendamos que use os mecanismos de agrupamento predefinidos automáticos. No entanto, se quiser substituir estas agrupações predefinidas, pode fazê-lo aplicando a etiqueta service.istio.io/canonical-name do Kubernetes às configurações do pod e do WorkloadEntry do Kubernetes.

Para ver detalhes, consulte o artigo sobre como definir manualmente um serviço canónico.

Resolva problemas do controlador canónico gerido

1. Verifique o estado da funcionalidade: execute o seguinte comando, em que FLEET_PROJECT_ID é o ID do seu projeto anfitrião da frota. Geralmente, o FLEET_PROJECT_ID é criado por predefinição e tem o mesmo nome que o projeto.

  gcloud container fleet mesh describe --project FLEET_PROJECT_ID

Exemplo de saída:

      membershipStates:
        projects/<project-number>/locations/<location>/memberships/<membership-name>:
          state:
            code: OK
            description: 
              Revision(s) ready for use: istiod-asm-183-2.
              All Canonical Services have been reconciled successfully.

2. Tome medidas com base em state.code:

Na saída do estado da funcionalidade, verifique o estado do cluster. Examine o valor de state.code. Isto ajuda a compreender o estado atual do CSC gerido. Com base no valor de state.code, implemente as ações correspondentes:

MISSING:
1. Aguarde uma hora para permitir potenciais atrasos na inicialização.
2. Execute novamente o comando gcloud container fleet mesh describe --project <FLEET_PROJECT_ID>. Se state.code ainda estiver em falta, contacte o apoio técnico do Google Cloud para receber assistência.
WARNING/ERROR:
1. Verifique o servicemesh.conditions para ver informações detalhadas sobre o erro.
2. Se for encontrada a condição CANONICAL_SERVICE_ERROR, o controlador de serviço canónico gerido está a ter um problema. Caso contrário, o problema é provavelmente externo ao controlador de serviços canónico.
3. Em ambos os cenários, contacte o apoio técnico do Google Cloud para uma resolução de problemas mais detalhada
OK: consulte a tabela seguinte para ver as ações com base no texto state.description:

State.Description	Ação necessária
Todos os serviços canónicos foram reconciliados com êxito	O CSC está a funcionar conforme esperado. Não é necessária nenhuma intervenção adicional.
O controlador de serviço canónico gerido está a ceder ao controlador no cluster	Siga o guia para migrar do controlador no cluster
Não são mencionadas informações específicas sobre os serviços canónicos em `state.description`	Esta situação pode ocorrer se o seu cluster não tiver pods injetados com sidecar ou entradas de serviço. Para confirmar o estado operacional do controlador canónico gerido, siga os passos descritos na secção O controlador gerido está operacional. Se os serviços canónicos necessários continuarem em falta, certifique-se de que os serviços canónicos estão definidos corretamente. Consulte: Defina o serviço canónico .