Canonical Service

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 página, você verá o que é um serviço canônico no Anthos Service Mesh.

O que é um serviço canônico?

O Anthos Service Mesh 1.6.8 introduz suporte para Serviços canônicos, um modelo conceitual e de arquitetura para representar suas cargas de trabalho de produção como um serviço único, mais fácil de observar e gerenciar. Essas cargas de trabalho podem abranger vários clusters, diferentes plataformas de back-end e esquemas e configurações diferentes.

Para usuários do Compute Engine: o serviço canônico é parecido com os Grupos gerenciados de instâncias, mas um Serviço canônico pode ser multirregional.

Para usuários do Kubernetes: o serviço canônico é quase análogo ao conceito de "app" do Kubernetes e ao CRD do aplicativo.

Para usuários sem servidor: o serviço canônico é muito semelhante aos conceitos do serviço do App Engine e do serviço do Cloud Run. A diferença é que os serviços sem servidor do Google são, inerentemente, regionais, enquanto os Serviços canônicos são uma abstração global/multirregional.

Por exemplo, todas as situações a seguir descrevem maneiras de se referir a um serviço canônico:

  • Um serviço tem uma interrupção.
  • Um serviço é executado no local e em uma nuvem pública.
  • Implantação de uma nova revisão de um serviço.
  • O serviço Foo está enviando muito tráfego e pode exceder nossa capacidade.

Os serviços canônicos existem em uma única malha, que, no Anthos Service Mesh, significa que eles também são únicos dentro de uma frota e de um projeto do Google Cloud. Todos eles são um para um com a malha.

Uma determinada carga de trabalho só pode fazer parte de um serviço canônico.

É possível determinar o escopo completo de um Serviço canônico no grupo de cargas de trabalho que o definem, incluindo:

  • Nomes de host e endereços IP
  • Redes
  • Políticas de rede e segurança
  • Roteamento e balanceamento de carga
  • Imagens de VM e contêiner
  • Infraestrutura física ou virtual
  • Regiões geográficas
  • Sistema de CI/CD
  • Código-fonte
  • Telemetria
  • Objetivos e alertas de nível de serviço

É possível acessar painéis que exibem esses detalhes operacionais de cada serviço na página de Serviços do GKE Enterprise.

Requisitos e limitações do Serviço canônico

Os serviços canônicos estão disponíveis apenas no Anthos Service Mesh versão 1.6.8 e superior.

Cada Serviço canônico existe dentro de um único namespace do Kubernetes/Istio e não pode ultrapassar os limites do namespace.

Você precisa dar um serviço canônico a um nome exclusivo no namespace pai. Para mais informações, consulte Como definir um serviço canônico.

Os serviços canônicos podem existir em vários clusters e regiões. Embora seja possível dividir recursos e telemetria por cluster e região, eles não são fatores para determinar o escopo ou a exclusividade de um serviço.

Portanto, a identidade exclusiva de um Serviço canônico é determinada por:

mesh id + namespace + canonical name.

Revisões

As revisões referem-se a alterações incrementais em um serviço que é possível usar para distinguir e identificar diferentes "versões" ou "versões" dos serviços.

Diferencie as revisões de um serviço canônico rotulando uma carga de trabalho individual com a "revisão canônica". Esse rótulo é uma string arbitrária que é possível definir. O rótulo pode ser definido automaticamente em alguns casos, mas você ou o sistema de CI/CD que implanta o serviço precisa aplicá-lo. Para mais orientações sobre como configurar esse rótulo, consulte Como definir um serviço canônico.

Várias revisões podem estar em produção ao mesmo tempo. A execução de várias revisões ao mesmo tempo é usada com mais frequência:

  • O lançamento progressivo de um novo binário, uma nova configuração ou ambas em todas as instâncias do serviço de um. Nesse caso, a revisão antiga e a nova serão publicadas durante a transição.
  • Um "Teste A/B" ou "experimento ao vivo", em que duas versões diferentes do serviço são expostas aos subconjuntos de autores de chamada downstream para testar o efeito de uma alteração.

A seguir