Instalar um sidecar proxy - Alibaba Cloud Service Mesh: Central de Documentação do Alibaba Cloud

Quando vários serviços se comunicam em um cluster Kubernetes, é necessário controle centralizado sobre recursos de rede como balanceamento de carga, descoberta de serviço, controle de tráfego, novas tentativas e timeouts, sem modificar o código da aplicação. O Alibaba Cloud Service Mesh (ASM) resolve isso ao injetar um sidecar proxy (uma instância do Envoy) ao lado de cada contêiner da aplicação. O sidecar proxy intercepta todo o tráfego de entrada e saída e aplica regras de roteamento e políticas de governança de serviço que o plano de controle do Istio envia em tempo real. Cada serviço da sua aplicação requer um sidecar proxy em execução no respectivo pod.

Para adicionar sidecar proxies às suas cargas de trabalho, rotule um namespace para ativar a injeção automática e reinicie os pods desse namespace.

Como funciona a injeção

Ao ativar a injeção de sidecar proxy para um namespace, o ASM registra um webhook de admissão com mutação do Kubernetes. Sempre que um pod é criado nesse namespace, o webhook adiciona um contêiner istio-proxy ao pod. Após a injeção, o pod executa dois contêineres:

Contêiner da aplicação: o seu serviço.
Contêiner do sidecar proxy (istio-proxy): uma instância do Envoy que intercepta todo o tráfego HTTP de entrada e saída e se comunica com o componente Pilot no plano de controle do Istio.

Como a injeção ocorre na criação do pod, os pods existentes não recebem um sidecar proxy até que sejam reiniciados.

Pré-requisitos

Antes de começar, verifique se você tem:

Uma instância do ASM com um cluster Kubernetes adicionado à malha.
O kubectl configurado para conexão com o cluster.
Permissões para rotular namespaces e reiniciar cargas de trabalho.

Etapa 1: Ativar a injeção automática de sidecar proxy

Por padrão, a injeção automática de sidecar proxy está desativada para todos os namespaces. É possível injetar manualmente um sidecar proxy ao atualizar a configuração do Kubernetes do pod correspondente ou usar o recurso de injeção automática. Para ativar a injeção automática, rotule o namespace de destino:

kubectl label namespace <namespace> istio-injection=enabled --overwrite

Substitua <namespace> pelo namespace da sua aplicação. Se esse parâmetro não for especificado, o namespace default será usado.

Verifique o rótulo:

kubectl get namespace <namespace> --show-labels

A saída deve incluir istio-injection=enabled.

Nota

Também é possível ativar a injeção de sidecar proxy pelo console do ASM. Para mais informações, consulte Gerenciar namespaces globais.

Etapa 2: Reiniciar pods para acionar a injeção

Os sidecar proxies são injetados apenas na criação dos pods. Para injetar sidecar proxies em cargas de trabalho existentes, reinicie-as.

Reiniciar um deployment (recomendado)

Use kubectl rollout restart para executar uma reinicialização gradual. Esse comando substitui progressivamente os pods antigos por novos que incluem o sidecar proxy:

kubectl rollout restart deployment <deployment-name> -n <namespace>

Reiniciar um pod específico

Para reiniciar um pod individual, execute o seguinte comando:

kubectl get pod <pod-name> -n <namespace> -o yaml | kubectl replace --force -f -

Importante

Este comando força a exclusão e recria o pod, causando uma breve interrupção de tráfego. Teste essa abordagem primeiro em um ambiente fora de produção para confirmar que seu serviço tolera a interrupção. Execute várias reinicializações para verificar a estabilidade antes de aplicar este método em produção.

Etapa 3: Verificar a injeção do sidecar proxy

Após a reinicialização, confirme a injeção do sidecar proxy.

Verificar a coluna READY

Execute o seguinte comando:

kubectl get pods -n <namespace>

Antes da injeção, os pods mostram 1/1 na coluna READY (apenas o contêiner da aplicação). Após a injeção, os pods mostram 2/2 (contêiner da aplicação + contêiner do sidecar proxy):

NAME                          READY   STATUS    RESTARTS   AGE
my-app-6b7d8f9c4d-abc12      2/2     Running   0          30s
my-app-6b7d8f9c4d-def34      2/2     Running   0          28s

Se um pod ainda mostrar 1/1, verifique se o rótulo do namespace está definido corretamente e se o pod foi criado após a rotulagem.

Confirmar o contêiner istio-proxy

Para uma verificação detalhada, descreva um pod específico:

kubectl describe pod <pod-name> -n <namespace>

Procure istio-proxy na seção Containers da saída. O contêiner istio-proxy é o sidecar proxy do Envoy. Sua presença confirma que o pod faz parte do plano de dados do ASM.

Próximos passos

Políticas de injeção: controle quais pods recebem sidecar proxies usando rótulos e seletores. Ajuste também a configuração de recursos do injetor de sidecar com base no tamanho e na carga do seu cluster. Consulte Configurar políticas de injeção de sidecar proxy.
Configurações do sidecar proxy: ajuste limites de recursos, hooks de ciclo de vida, modo de interceptação de tráfego e configurações de observabilidade pelo console do ASM. Consulte Configurar sidecar proxies.
Configuração baseada em anotações: modifique recursos e comportamento do sidecar proxy (como duração de drenagem de encerramento e sequência de inicialização do istio-proxy) usando anotações de pod. Consulte Configurar um sidecar proxy adicionando anotações de recursos.
Ignorar sidecar proxies: configure regras de bypass para o tráfego que não deve passar pelos sidecar proxies. Consulte Configurar definições para permitir que o tráfego ignore sidecar proxies.