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 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 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
- Defina um serviço canônico.
- Práticas recomendadas de serviços canônicos.
- Como solucionar problemas de serviços canônicos.