Injetar proxies sidecar com o Cloud Service Mesh

Este documento mostra como configurar a injeção do proxy sidecar com o Cloud Service Mesh para melhorar a segurança, a confiabilidade e a observabilidade da rede. Essas funções são abstraídas do contêiner principal do aplicativo e implementadas em um proxy comum fora do processo (o sidecar), entregue como um contêiner separado no mesmo pod. Isso fornece os recursos do Cloud Service Mesh sem reformular seus aplicativos de produção para participar de uma malha de serviço.

A injeção automática de proxy sidecar ocorre quando o Cloud Service Mesh detecta um rótulo de namespace que você configura para o pod da carga de trabalho. O proxy intercepta todo o tráfego de entrada e saída das cargas de trabalho e se comunica com o Cloud Service Mesh.

Permissões necessárias para as tarefas

Para executar as tarefas descritas nesta página, você precisa ter o papel roles/container.clusterAdmin ou um superior a esse. Consulte Papéis do Google Kubernetes Engine para ver detalhes sobre as permissões incluídas nesse papel.

Como ativar a injeção automática de sidecar

A maneira recomendada de injetar proxies sidecar ários é usar o injetor automático de sidecar baseado em webhooks, embora você possa atualizar manualmente a configuração do Kubernetes dos pods.

Para ativar a injeção automática, rotule os namespaces com os rótulos de injeção padrão se a tag padrão estiver configurada ou com o rótulo de revisão ao namespace. O rótulo adicionado também depende da implantação o Cloud Service Mesh gerenciado (com a API Fleet ou com asmcli) ou instalou o plano de controle no cluster. O rótulo é usado pelo webhook do injetor do arquivo secundário para associar os arquivos secundários injetados a uma revisão específica do plano de controle.

Para ativar a injeção automática:

No cluster

Use o seguinte comando para localizar o rótulo de revisão em istiod:

kubectl -n istio-system get pods -l app=istiod --show-labels

A resposta será semelhante a:

NAME                                READY   STATUS    RESTARTS   AGE   LABELS
istiod-asm-1233-2-5788d57586-bljj4   1/1     Running   0          23h   app=istiod,istio.io/rev=asm-1233-2,istio=istiod,pod-template-hash=5788d57586
istiod-asm-1233-2-5788d57586-vsklm   1/1     Running   1          23h   app=istiod,istio.io/rev=asm-1233-2,istio=istiod,pod-template-hash=5788d57586

Na saída, na coluna LABELS, anote o valor do rótulo de revisão istiod, que segue o prefixo istio.io/rev=. Neste exemplo, o valor é asm-1233-2.

Observação: é possível substituir istio.io/rev pelo rótulo istio-injection=enabled se a tag padrão for configurada. Verifique se a tag padrão existe executando istioctl tag list com o istioctl em OUTPUT_DIR.

Aplique o rótulo de revisão aos namespaces e remova o rótulo istio-injection (se houver). No comando a seguir, NAMESPACE é o nome do namespace no qual quer ativar a injeção automática, e REVISION, o rótulo de revisão que você anotou na etapa anterior.
```
kubectl label namespace NAMESPACE  istio-injection- istio.io/rev=REVISION --overwrite
```
Você pode ignorar a mensagem "istio-injection not found" na saída. Isso significa que o namespace não tinha antes o istio-injection, que é o novo padrão instalações do Cloud Service Mesh ou novas implantações. Como o comportamento da injeção automática é indefinido quando um namespace tem o istio-injection e o rótulo de revisão, todos os comandos kubectl label na documentação do Cloud Service Mesh garantem explicitamente que apenas um seja definido.
Reinicie os pods afetados usando as etapas da próxima seção.

Malha de serviço gerenciada

Use o seguinte comando para localizar os canais de lançamento disponíveis:
```
kubectl -n istio-system get controlplanerevision
```
O resultado será assim:
```
NAME                AGE
asm-managed         6d7h
```
Na saída, o valor na coluna NAME é o rótulo REVISION que corresponde ao canal de lançamento disponível para a versão do Cloud Service Mesh. Aplique esse rótulo aos seus namespaces e remova o rótulo istio-injection (se houver). No comando a seguir, substitua REVISION pelo rótulo de revisão que você anotou acima e substitua NAMESPACE pelo nome do namespace em que você quer ativar a injeção automática:
```
kubectl label namespace NAMESPACE  istio-injection- istio.io/rev=REVISION --overwrite
```
Você pode ignorar a mensagem "istio-injection not found" na saída. Isso significa que o namespace não tinha antes o istio-injection, que é o novo padrão instalações do Cloud Service Mesh ou novas implantações. Porque a injeção automática o comportamento é indefinido quando um namespace tem o istio-injection e o rótulo de revisão, todos os comandos kubectl label na A documentação do Cloud Service Mesh garante explicitamente que apenas um deles seja definido.
Reinicie os pods afetados usando as etapas da próxima seção.
Se você também implantou o plano de dados gerenciado pelo Google opcional, anote o namespace demo da seguinte maneira:
```
kubectl annotate --overwrite namespace YOUR_NAMESPACE \
mesh.cloud.google.com/proxy='{"managed":"true"}'
```

Reinicie os pods para atualizar proxies sidecar

Com a injeção automática de sidecar, é possível reiniciar os pods para atualizar os sidecars deles:

A maneira como você reinicia os pods depende se foram criados como parte de uma implantação.

Se você usou uma implantação, reinicie-a. Isso reinicia todos os pods com sidecars:
```
kubectl rollout restart deployment -n YOUR_NAMESPACE
```
Se você não usou uma implantação, exclua os pods. Eles serão recriados automaticamente com os sidecars:
```
kubectl delete pod -n YOUR_NAMESPACE --all
```
Confira se todos os pods no namespace têm sidecars injetados:
```
kubectl get pod -n YOUR_NAMESPACE
```
Neste exemplo de saída do comando anterior, observe que a coluna READY indica que há dois contêineres para cada uma das cargas de trabalho: o principal e o contêiner do proxy sidecar.
```
NAME                    READY   STATUS    RESTARTS   AGE
YOUR_WORKLOAD           2/2     Running   0          20s
...
```

A seguir

Saiba mais sobre: