Canonical Service

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

O que é um serviço canônico?

O Cloud Service Mesh 1.6.8 introduz o suporte aos serviços canônicos, um modelo conceitual modelo de arquitetura para representar suas cargas de trabalho de produção como um ú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 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, o que, no Cloud 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 Serviços.

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

Os serviços canônicos estão disponíveis apenas no Cloud 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 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 definir esse rótulo, consulte 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