Como definir um serviço canônico

Observação: os serviços canônicos têm suporte automático no Cloud Service Mesh versão 1.6.8 e superior.

Os serviços canônicos são um grupo de cargas de trabalho que implementam os mesmos serviços e APIs. Para tipos de carga de trabalho com suporte, O Cloud Service Mesh cria automaticamente recursos de serviço canônicos com base informações do servidor da API Kubernetes. Veja nesta página quais rótulos definem serviços canônicos automaticamente e saiba como é possível ajustar os limites dos serviços manualmente.

Os tipos de instância de carga de trabalho atualmente compatíveis são:

  • Pods do Kubernetes (inclusive via implantações do Kubernetes, serviços de execução do Kube etc.)
  • Instâncias de máquina virtual
  • Serviços externos de malha (especificamente recursos de ServiceEntry com um local de MESH_EXTERNAL)

O que define serviços canônicos

O Cloud Service Mesh determina a assinatura do serviço canônico lendo o service.istio.io/canonical-name rótulo no recurso de configuração do Kubernetes associado a cada instância de carga de trabalho:

  • Para pods, o rótulo está no recurso de pod do Kubernetes
  • Para VMs, o rótulo no recurso WorkloadEntry do Istio (link em inglês).
  • Para serviços externos, o identificador está no recurso ServiceEntry do Istio

Os serviços canônicos têm o mesmo Namespace do Kubernetes como as instâncias de carga de trabalho associadas e não podem abranger namespaces.

Regras de rotulagem automática

O Cloud Service Mesh agrupa automaticamente suas cargas de trabalho baseadas em pod e VM em Serviços canônicos sem ação da sua parte.

Você só precisa:

  • ajustar a clareza do rótulo para o usuário/leitor;
  • substituir o comportamento padrão.

Rotulagem automática nos pods do Kubernetes

Os serviços canônicos se concentram nos rótulos app.kubernetes.io/name e app do Kubernetes. Observe que o rótulo antigo tem precedência.

Nenhuma outra ação será necessária se você usar um desses dois rótulos nas cargas de trabalho.

Rotulagem automática em máquinas virtuais

Para criar serviços canônicos nas suas VMs, você precisa adicioná-las a um da malha de serviço configurando Recurso WorkloadEntry no servidor da API Kubernetes.

Rotulagem manual

Para aplicar ou substituir manualmente um identificador de serviço canônico, aplique o rótulo service.istio.io/canonical-name às configurações de recursos de carga de trabalho compatíveis.

Para que um serviço externo seja reconhecido como um serviço canônico, você precisa rotular manualmente a ServiceEntry aplicável.

Rotulagem manual nos pods do Kubernetes

Para implantar muitos pods de uma só vez usando uma implantação, defina o rótulo service.istio.io/canonical-name no PodTemplateSpec:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
  namespace: my-namespace
spec:
  replicas: 3
  template:
    metadata:
      labels:
        service.istio.io/canonical-name: my-service
    spec:
      containers:
        ...

Para rotular o serviço canônico de um único pod, adicione o rótulo service.istio.io/canonical-name à seção labels da configuração do pod:

apiVersion: v1
kind: Pod
metadata:
  name: my-test-pod
  namespace: my-namespace
  labels:
    service.istio.io/canonical-name: my-service
spec:
  ...

Rotular máquinas virtuais manualmente

Para rotular o serviço canônico em uma única VM/WorkloadEntry, adicione o rótulo service.istio.io/canonical-name à seção "labels" da sua configuração de WorkloadEntry:

apiVersion: networking.istio.io/v1alpha3
kind: WorkloadEntry
metadata:
  name: my-vm-123
  namespace: my-namespace
  labels:
    service.istio.io/canonical-name: my-service
spec:
  ...

Identificar serviços externos manualmente

Para identificar o serviço canônico de um único serviço externo/ServiceEntry, adicione o identificador service.istio.io/canonical-name à seção "identificadores" da configuração do ServiceEntry:

apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: example-com
  namespace: my-namespace
  labels:
    service.istio.io/canonical-name: an-external-service
spec:
   location: MESH_EXTERNAL
  ...

A seguir