Revisões do plano de controle do Anthos Service Mesh

Esta página descreve como as revisões do plano de controle funcionam e o valor para usá-las para upgrades seguros de malha de serviço (e reversões). Até a versão 1.6.8, o processo de instalação padrão do Anthos Service Mesh não usava revisões de plano de controle. A introdução de revisões pode exigir esforço e modificações nos procedimentos de instalação, mas é altamente recomendável usá-las porque trazem benefícios significativos.

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

A instalação do Anthos Service Mesh consiste em duas partes principais: primeiro, use a ferramenta de linha de comando istioctl e os arquivos YAML IstioOperator para instalar o plano de controle e sua configuração. O plano de controle, também conhecido como istiod, consiste em um conjunto de serviços do sistema responsáveis por gerenciar a configuração da malha. Em seguida, você implanta um proxy sidecar especial em todo o ambiente que intercepta a comunicação de rede de e para cada carga de trabalho. Os proxies se comunicam com o plano de controle para conseguir a configuração deles. Isso permite que você direcione e controle o tráfego (tráfego do plano de dados) na sua malha sem fazer nenhuma alteração nas cargas de trabalho.

Para implantar os proxies, use um processo chamado injeção automática de arquivo secundário (injeção automática) para executar um proxy como um contêiner de arquivo secundário em cada um dos pods de carga de trabalho. Você não precisa modificar os manifestos do Kubernetes usados para implantar suas cargas de trabalho, mas é necessário adicionar um rótulo aos namespaces e reiniciar os pods.

Antes do Anthos Service Me 1.6, você fez upgrade de uma nova versão do plano de controle que substituiu imediatamente a versão antiga. Esse procedimento é conhecido como upgrade no local e é arriscado porque, se houver falhas, a reversão pode ser difícil. Para injetar novamente os proxies e fazer com que eles se comuniquem com a nova versão do plano de controle, era necessário reiniciar todas as cargas de trabalho em todos os namespaces. Dependendo do número de cargas de trabalho e namespaces na sua malha, todo o processo de upgrade pode levar uma hora ou mais. Upgrades no local podem causar inatividade e ser programados em janelas de manutenção.

Como funciona a injeção automática?

A injeção automática usa um recurso do Kubernetes chamado controle de admissão. Um webhook de admissão mutável é registrado para observar os pods recém-criados. O webhook é configurado com um seletor de namespace para que ele corresponda apenas aos pods que estão sendo implantados em namespaces com um rótulo específico. Quando um pod corresponde, o webhook consulta um serviço de injeção fornecido pelo istiod para conseguir uma nova configuração modificada para o pod, que contém os contêineres e volumes necessários para executar o arquivo secundário.

injetor de arquivo secundário

  1. A configuração do webhook é criada durante a instalação. Registra o webhook com o servidor da API Kubernetes.
  2. O servidor da API Kubernetes observa implantações de pod em namespaces que correspondem ao webhook namespaceSelector.
  3. Um namespace é rotulado para que seja correspondido por namespaceSelector.
  4. Os pods implantados no namespace acionam o webhook.
  5. O serviço inject fornecido pela istiod modifica as especificações do pod para injetar o arquivo secundário.

O que é uma revisão?

O rótulo usado para injeção automática é como qualquer outro rótulo do Kubernetes definido pelo usuário. Um rótulo é essencialmente um par de chave-valor que pode ser usado para dar suporte ao conceito de inclusão de tag. Os rótulos são amplamente usados em marcações e revisões. Por exemplo, tags do Git, tags do Docker e revisões do Knative.

Até o Anthos Service Mesh versão 1.6.8, os procedimentos de instalação padrão estabelecem uma convenção para configurar o seletor de namespace no webhook para usar o rótulo: istio-injection=enabled

O processo de instalação atual do Anthos Service Mesh permite marcar o plano de controle instalado com uma string de revisão, como um argumento revision para os comandos istioctl e como um campo no recurso personalizado IstioOperator. A chave de rótulo correspondente para namespaces é istio.io/rev e o valor normalmente é definido para indicar a versão da malha. Por exemplo, um plano de controle com revisão asm-173-6 seleciona pods em namespaces com o rótulo istio.io/rev=asm-173-6 e injeta arquivos secundários.

Por que as revisões são importantes?

A capacidade de controlar o tráfego é um dos principais benefícios do uso de uma malha de serviço. Por exemplo, é possível alterar gradualmente o tráfego para uma nova versão de um aplicativo quando implantá-lo pela primeira vez na produção. Se você detectar problemas durante o upgrade, será possível reverter o tráfego para a versão original, oferecendo um meio de reversão simples e de baixo de risco. Esse procedimento é conhecido como uma versão canário e reduz drasticamente o risco associado a novas implantações.

Da mesma forma, é possível minimizar o risco associado ao upgrade da malha de serviço. O Anthos Service Mesh 1.6 e posterior é compatível com upgrades canário usando revisões de plano de controle. Ao instalar uma nova versão do plano de controle, você fornece uma string de revisão. O instalador rotula todos os objetos do plano de controle com a revisão, incluindo o serviço istiod e a implantação. A revisão se torna parte do nome do serviço, por exemplo, istiod-asm-173-6.istio-system.

Com um upgrade canário, você implanta uma nova revisão do plano de controle junto com a versão atual. Em seguida, associe gradualmente os proxies ao novo plano de controle rotulando os namespaces com uma revisão correspondente à nova revisão do plano de controle. Se houver problemas, é fácil fazer a reversão associando os proxies de serviço à revisão anterior.

O processo de upgrade canário

Com os rótulos de revisão, é possível executar upgrades canário e reversões de maneira simples do plano de controle.

upgrade canário

As etapas a seguir descrevem como o processo funciona:

  1. Comece com um Anthos Service Mesh existente ou uma instalação de Istio de código aberto. Não importa se os namespaces estão usando um rótulo de revisão ou o rótulo istio-injection=enabled.
  2. Use uma string de revisão ao instalar a nova versão do plano de controle. Devido à string de revisão, o novo plano de controle é instalado com a versão atual. A nova instalação inclui uma nova configuração de webhook com um namespaceSelector configurado para observar namespaces com esse rótulo de revisão específico.
  3. Você migra proxies sidecar para o novo plano de controle removendo o rótulo antigo do namespace, adicionando o novo rótulo de revisão e reiniciando os pods. Se você usar revisões com o Anthos Service Mesh, interrompa o uso do rótulo istio-injection=enabled. Um plano de controle com uma revisão não seleciona pods em namespaces com um rótulo istio-injection, mesmo que haja um rótulo de revisão. O webhook do novo plano de controle injeta arquivos secundários nos pods.
  4. Teste cuidadosamente as cargas de trabalho associadas ao plano de controle atualizado e continue implantando ou revertendo para o plano de controle original.

Depois de associar os pods ao novo plano de controle, o plano de controle e o webhook atuais continuarão instalados. O webhook antigo não afeta os pods nos namespaces que foram migrados para o novo plano de controle. É possível reverter os pods em um namespace para o plano de controle original removendo o novo rótulo de revisão, adicionando novamente o rótulo original e reiniciando os pods. Quando tiver certeza de que o upgrade foi concluído, remova o plano de controle antigo.

Para ver etapas detalhadas sobre o upgrade usando revisões, consulte os Guias de upgrade.

Uma análise mais detalhada da configuração do webhook

A melhor maneira de entender o webhook modificado para a injeção de arquivo secundário automática é inspecionar a configuração por conta própria. Use o seguinte comando:

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

Você verá uma configuração separada para cada plano de controle instalado. Um seletor de namespace para um plano de controle baseado em revisão tem esta aparência:

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

O seletor pode variar de acordo com a versão do Anthos Service Mesh ou do Istio em execução. Esse seletor corresponde a namespaces com um rótulo de revisão específico, desde que não tenham um rótulo istio-injection.

Quando um pod é implantado em um namespace correspondente ao seletor, a especificação do pod é enviada ao serviço injetor para mutação. O serviço injetor a ser chamado é especificado da seguinte maneira:

     service:
        name: istiod-asm-173-6
        namespace: istio-system
        path: /inject
        port: 443

O serviço é exposto por istiod na porta 443 no caminho do URL inject.

A seção rules especifica que o webhook precisa ser aplicado à criação do pod:

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

Resumo

Embora a mudança no uso de rótulos de revisão nos namespaces para ativar a injeção automática leve algum tempo, os benefícios que os rótulos de revisão fornecem para upgrades seguros, canários, valem o esforço.

A seguir