Revisões do plano de controlo do Cloud Service Mesh

Nota: este guia só suporta a Cloud Service Mesh com APIs Istio e não suporta Google Cloud APIs. Para mais informações, consulte o artigo Vista geral do Cloud Service Mesh.

Esta página aplica-se às implementações do ISTIOD plano de controlo no cluster e geridas. Esta página não se aplica à implementação do plano de controlo TRAFFIC_DIRECTOR, que é um plano de controlo global multi-inquilino, sem revisões individuais.

Esta página descreve como funcionam as revisões do plano de controlo e o valor da sua utilização para atualizações (e reversões) seguras da malha de serviços.

Princípios básicos da instalação da malha de serviço

A um nível elevado, a instalação do Cloud Service Mesh consiste em duas fases principais:

1. Primeiro, usa a ferramenta asmcli para instalar um plano de controlo no cluster ou configurar o plano de controlo gerido. O plano de controlo consiste num conjunto de serviços do sistema responsáveis pela gestão da configuração da malha.

2. Em seguida, implementa um proxy sidecar especial em todo o seu ambiente que interceta a comunicação de rede de e para cada carga de trabalho. Os proxies comunicam com o plano de controlo para obter a respetiva configuração, o que lhe permite direcionar e controlar o tráfego (tráfego do plano de dados) em torno da sua malha sem fazer alterações às suas cargas de trabalho.

   Para implementar os proxies, usa um processo denominado injeção automática de sidecar (injeção automática) para executar um proxy como um contentor sidecar adicional em cada um dos seus pods de carga de trabalho. Não tem de modificar os manifestos do Kubernetes que usa para implementar as suas cargas de trabalho, mas tem de adicionar uma etiqueta aos seus espaços de nomes e reiniciar os pods.

Use revisões para atualizar a sua malha em segurança

A capacidade de controlar o tráfego é uma das principais vantagens da utilização de uma malha de serviços. Por exemplo, pode mudar gradualmente o tráfego para uma nova versão de uma aplicação quando a implementa pela primeira vez na produção. Se detetar problemas durante a atualização, pode transferir o tráfego novamente para a versão original, o que lhe dá um meio simples e de baixo risco de reverter a atualização. Este procedimento é conhecido como lançamento canário e reduz significativamente o risco associado a novas implementações.

Nota: um tipo alternativo de atualização é uma atualização no local, na qual atualiza instalando uma nova versão do plano de controlo. A nova versão do plano de controlo substitui imediatamente a versão antiga. As atualizações no local são arriscadas porque, se ocorrerem falhas, pode ser difícil reverter a atualização. Para reinjetar os proxies e fazê-los comunicar com a nova versão do plano de controlo, tem de reiniciar todas as cargas de trabalho em todos os seus espaços de nomes. Consoante o número de cargas de trabalho e espaços de nomes na sua malha, todo o processo de atualização pode demorar uma hora ou mais. As atualizações no local podem provocar períodos de inatividade e devem ser agendadas em janelas de manutenção.

Ao usar revisões do plano de controlo numa atualização canary, instala um novo plano de controlo e uma configuração separados juntamente com o plano de controlo existente. O instalador atribui uma string denominada revisão para identificar o novo plano de controlo. Inicialmente, os proxies sidecar continuam a receber a configuração da versão anterior do plano de controlo. Associa gradualmente as cargas de trabalho ao novo plano de controlo etiquetando os respetivos espaços de nomes ou pods com a nova revisão do plano de controlo. Depois de etiquetar um espaço de nomes ou Pods com a nova revisão, reinicie os Pods de carga de trabalho para que os novos sidecars sejam injetados automaticamente e recebam a respetiva configuração do novo plano de controlo. Se houver problemas, pode reverter facilmente a situação associando as cargas de trabalho ao plano de controlo original.

Como funciona a injeção automática?

A injeção automática usa uma funcionalidade do Kubernetes denominada controlo de admissão. Um webhook de admissão de mutação está registado para monitorizar os pods recém-criados. O webhook está configurado com um seletor de espaço de nomes para que só corresponda a pods que estão a ser implementados em espaços de nomes com uma etiqueta específica. Quando um Pod corresponde, o webhook consulta um serviço de injeção fornecido pelo plano de controlo para obter uma nova configuração mutada para o Pod, que contém os contentores e os volumes necessários para executar o sidecar.

1. É criada uma configuração de webhook durante a instalação. O webhook está registado no servidor da API Kubernetes.
2. O servidor da API Kubernetes monitoriza as implementações de pods em espaços de nomes que correspondem ao webhook namespaceSelector.
3. Um espaço de nomes é etiquetado para que seja correspondido pelo namespaceSelector.
4. Os pods implementados no espaço de nomes acionam o webhook.
5. O serviço inject fornecido pelo plano de controlo altera as especificações do pod para injetar automaticamente o sidecar.

O que é uma revisão?

A etiqueta usada para a injeção automática é como qualquer outra etiqueta do Kubernetes definida pelo utilizador. Uma etiqueta é essencialmente um par de chave-valor que pode ser usado para suportar o conceito de etiquetagem. As etiquetas são amplamente usadas para etiquetagem e revisões. Por exemplo, etiquetas Git, etiquetas Docker e revisões do Knative.

O processo de instalação atual do Cloud Service Mesh permite etiquetar o plano de controlo instalado com uma string de revisão. O instalador etiqueta todos os objetos do plano de controlo com a revisão. A chave no par de chave-valor é istio.io/rev, mas o valor da etiqueta de revisão difere para o plano de controlo gerido e os planos de controlo no cluster.

• Para os painéis de controlo no cluster, o serviço e a implementação têm normalmente uma etiqueta de revisão semelhante a istio.io/rev=asm-1246-12, em que asm-1246-12 identifica a versão do Cloud Service Mesh.istiod A revisão passa a fazer parte do nome do serviço, por exemplo: istiod-asm-1246-12.istio-system

• Para o plano de controlo gerido, a etiqueta de revisão corresponde a um canal de lançamento:

  Etiqueta de revisão	Canal
  istio.io/rev=asm-managed	Normal
  istio.io/rev=asm-managed-rapid	Inovação
  istio.io/rev=asm-managed-stable	Estável

Além disso, tem a opção de usar etiquetas de injeção predefinidas (por exemplo, istio-injection=enabled).

Para ativar a injeção automática, adicione uma etiqueta de revisão aos seus espaços de nomes que corresponda à etiqueta de revisão no plano de controlo. Por exemplo, um plano de controlo com a revisão istio.io/rev=asm-1246-12 seleciona pods em espaços de nomes com a etiqueta istio.io/rev=asm-1246-12 e injeta sidecars.

O processo de atualização de testes

As etiquetas de revisão permitem fazer atualizações canary e reversões fáceis do painel de controlo no cluster. O controlo gerido usa um processo semelhante, mas o cluster é atualizado automaticamente para a versão mais recente nesse canal.

Os passos seguintes descrevem como funciona o processo:

1. Comece com uma instalação existente do Cloud Service Mesh ou do Istio de código aberto. Não importa se os espaços de nomes estão a usar uma etiqueta de revisão ou a etiqueta istio-injection=enabled.
2. Use uma string de revisão quando instalar a nova versão do plano de controlo. Devido à string de revisão, o novo plano de controlo é instalado juntamente com a versão existente. A nova instalação inclui uma nova configuração de webhook com um namespaceSelector configurado para monitorizar espaços de nomes com essa etiqueta de revisão específica.
3. Migre os proxies sidecar para o novo plano de controlo removendo a etiqueta antiga do espaço de nomes, adicionando a nova etiqueta de revisão e, em seguida, reiniciando os pods. Se usar revisões com a Cloud Service Mesh, tem de parar de usar a etiqueta istio-injection=enabled. Um plano de controlo com uma revisão não seleciona pods em espaços de nomes com uma etiqueta istio-injection, mesmo que exista uma etiqueta de revisão. O webhook para o novo plano de controlo injeta sidecars nos pods.
4. Teste cuidadosamente as cargas de trabalho associadas ao painel de controlo atualizado e continue a implementar a atualização ou reverta para o painel de controlo original.

Depois de associar os Pods ao novo plano de controlo, o plano de controlo existente e o webhook continuam instalados. O webhook antigo não tem efeito nos pods em espaços de nomes que foram migrados para o novo plano de controlo. Pode reverter os pods num espaço de nomes para o plano de controlo original removendo a nova etiqueta de revisão, adicionando novamente a etiqueta original e reiniciando os pods. Quando tiver a certeza de que a atualização está concluída, pode remover o plano de controlo antigo.

Para ver passos detalhados sobre a atualização através de revisões, consulte o guia de atualização.

Uma análise mais detalhada de uma configuração de webhook de mutação

Para compreender melhor o webhook de mutação para a injeção automática de sidecar, inspecione a configuração. Use o seguinte comando:

kubectl -n istio-system get mutatingwebhookconfiguration -l app=sidecar-injector -o yaml

Deve ver uma configuração separada para cada plano de controlo que tiver instalado. Um seletor de espaço de nomes para um plano de controlo baseado em revisões tem o seguinte aspeto:

 namespaceSelector:
    matchExpressions:
    - key: istio-injection
      operator: DoesNotExist
    - key: istio.io/rev
      operator: In
      values:
      - asm-1246-12

O seletor pode variar consoante a versão do Cloud Service Mesh ou do Istio que está a executar. Este seletor corresponde a espaços de nomes com uma etiqueta de revisão específica, desde que também não tenham uma etiqueta istio-injection.

Quando um Pod é implementado num espaço de nomes correspondente ao seletor, a respetiva especificação do Pod é enviada para o serviço de injetor para mutação. O serviço de injetor a ser chamado é especificado da seguinte forma:

     service:
        name: istiod-asm-1246-12
        namespace: istio-system
        path: /inject
        port: 443

Nota: para a malha de serviços na nuvem gerida, o serviço gerido pela Google é especificado por url: em vez de service:.

O serviço é exposto pelo plano de controlo na porta 443 no caminho do URL inject.

A secção rules especifica que o webhook deve aplicar-se à criação de pods:

   rules:
    - apiGroups:
      - ""
      apiVersions:
      - v1
      operations:
      - CREATE
      resources:
      - pods
      scope: '*'

O que se segue?

• Atualize o Cloud Service Mesh
• Injetar proxies complementares