Serviço canónico

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

Esta página explica o que é um serviço canónico na Cloud Service Mesh.

O que é um serviço canónico?

O Cloud Service Mesh 1.6.8 introduz o suporte para serviços canónicos, um modelo conceptual e arquitetónico para representar as suas cargas de trabalho de produção como um serviço singular mais fácil de observar e gerir. Estas cargas de trabalho podem abranger vários clusters, plataformas de back-end distintas e esquemas e configurações diferentes.

Para utilizadores do Kubernetes: o serviço canónico é aproximadamente análogo ao conceito de "app" do Kubernetes e ao CRD da aplicação.

Para utilizadores sem servidor: o serviço canónico é muito semelhante aos conceitos de serviço do App Engine e serviço do Cloud Run. A única diferença é que os serviços sem servidor da Google são inerentemente regionais, enquanto os serviços canónicos são uma abstração global / multirregional.

Por exemplo, os seguintes cenários descrevem formas de se referir a um serviço canónico:

  • Um serviço tem uma indisponibilidade.
  • Um serviço é executado nas instalações e numa nuvem pública.
  • Implementar uma nova revisão de um serviço.
  • O serviço Foo está a enviar demasiado tráfego e pode exceder a nossa capacidade.

Os serviços canónicos existem numa única malha, o que, na malha de serviços na nuvem, significa que também são únicos numa frota e num projeto Google Cloud(todos estes elementos têm uma relação individual com a malha).

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

Pode determinar o âmbito completo de um serviço canónico a partir do grupo de cargas de trabalho que o definem, incluindo:

  • Nomes de anfitriões e endereços IP
  • Rede(s)
  • Políticas de rede e segurança
  • Encaminhamento e balanceamento de carga
  • Imagens de VMs e contentores
  • Infraestrutura física ou virtual
  • Regiões geográficas
  • Sistema de CI/CD
  • Código-fonte
  • Telemetria
  • Objetivos ao nível do serviço e alertas

Pode ver painéis de controlo que apresentam estes detalhes operacionais para cada serviço na página de serviços empresariais do GKE.

Requisitos e limitações do serviço canónico

Os serviços canónicos só estão disponíveis na versão 1.6.8 e superior do Cloud Service Mesh.

Cada serviço canónico existe num único namespace do Kubernetes/Istio e não pode ultrapassar os limites do namespace.

Tem de atribuir um nome exclusivo a um serviço canónico no respetivo espaço de nomes principal. Para mais informações, consulte o artigo sobre 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 discriminar os recursos e a telemetria por cluster e região, estes não são fatores na determinação do âmbito ou da exclusividade de um serviço.

Por conseguinte, a identidade única de um serviço canónico é determinada por:

mesh id + namespace + canonical name.

Revisões

As revisões referem-se a alterações incrementais a um serviço que pode usar para distinguir e identificar diferentes "versões" ou "lançamentos" dos seus serviços.

Diferencie as revisões de um serviço canónico etiquetando uma carga de trabalho individual com a respetiva "revisão canónica". Esta etiqueta é uma string arbitrária que pode definir. Embora a etiqueta possa ser definida automaticamente em alguns casos, tem de ser aplicada por si ou pelo sistema de CI/CD que implementa o serviço. Para orientações sobre como definir esta etiqueta, consulte o artigo Definir um serviço canónico.

Tenha em atenção que podem estar em produção várias revisões em simultâneo. A execução de várias revisões em simultâneo é usada com maior frequência para realizar o seguinte:

  • A implementação progressiva de um novo ficheiro binário, uma nova configuração ou ambos em todas as instâncias do serviço. Neste caso, as revisões antigas e novas estão ativas durante a transição.
  • Um "teste A/B" ou uma "experiência em direto", em que duas versões diferentes do serviço são expostas a subconjuntos de autores de chamadas a jusante para testar o efeito de uma alteração.

O que se segue?