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).
Princípios básicos da instalação da malha de serviço
Em geral, a instalação do Anthos Service Mesh consiste em duas fases principais:
Primeiro, use a ferramenta
asmcli
para instalar um plano de controle no cluster ou configurar o plano de controle gerenciado. O plano de controle 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.
Use revisões para fazer o upgrade da malha de maneira segura
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.
Usando revisões do plano de controle em um upgrade canário, você instala um plano de controle novo e separado e a configuração junto com o plano de controle atual. O instalador atribui uma string chamada de revisão para identificar o novo plano de controle. Inicialmente, os proxies sidecar continuam a receber a configuração da versão anterior do plano de controle. Associe gradualmente as cargas de trabalho ao novo plano de controle ao rotular os namespaces com a nova revisão do plano de controle. Depois de rotular um namespace com a nova revisão, você reinicia os pods de carga de trabalho para que novos arquivos secundários sejam injetados automaticamente e eles recebam a configuração do novo plano de controle. Se houver problemas, é fácil fazer a reversão ao associar as cargas de trabalho ao plano de controle original.
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 plano de controle 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.
- A configuração de um webhook é criada durante a instalação. O webhook é registrado no servidor da API Kubernetes.
- O servidor da API Kubernetes observa implantações de pod em namespaces
que correspondem ao webhook
namespaceSelector
. - Um namespace é rotulado para que seja correspondido por
namespaceSelector
. - Os pods implantados no namespace acionam o webhook.
- O serviço
inject
fornecido pelo plano de controle modifica as especificações do pod para injetar automaticamente 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 atual de instalação do Anthos Service Mesh permite marcar o plano de controle
instalado com uma string de revisão. O instalador rotula todos os objetos do plano de
controle com a revisão. A chave no par de chave-valor é istio.io/rev
, mas o valor do rótulo de
revisão é diferente para o plano de controle gerenciado e
nos planos de controle no cluster.
Para planos de controle no cluster, o Serviço e a Implantação
istiod
costumam ter um rótulo de revisão semelhante aistio.io/rev=asm-1139-10
, em queasm-1139-10
identifica a versão do Anthos Service Mesh. A revisão se torna parte do nome do serviço, por exemplo,istiod-asm-1139-10.istio-system
.Para o plano de controle gerenciado, o rótulo de revisão corresponde a um canal de lançamento:
Rótulo de revisão Channel istio.io/rev=asm-managed
Normal istio.io/rev=asm-managed-rapid
Rápido istio.io/rev=asm-managed-stable
Estável
Para ativar a injeção automática, adicione um rótulo de revisão aos namespaces que
corresponda ao rótulo de revisão no plano de controle. Por exemplo, um plano de controle
com revisão istio.io/rev=asm-1139-10
seleciona pods em namespaces com o rótulo
istio.io/rev=asm-1139-10
e injeta arquivos secundários.
Além disso, você tem a opção de usar
rótulos de injeção padrão
(por exemplo, istio-injection=enabled
).
O processo de upgrade canário
Os rótulos de revisão permitem executar upgrades canário e reversões fáceis do plano de controle no cluster. O controle gerenciado usa um processo parecido, mas o seu cluster é atualizado automaticamente para a versão mais recente nesse canal.
As etapas a seguir descrevem como o processo funciona:
- 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
. - 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. - 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ótuloistio-injection
, mesmo que haja um rótulo de revisão. O webhook do novo plano de controle injeta arquivos secundários nos pods. - 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
Para entender melhor o webhook de mutação para injeção automática de sidecar, inspecione a configuração por conta própria. Use o comando a seguir:
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 poderá 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 pelo plano de controle 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: '*'