Injete proxies sidecar com o Cloud Service Mesh

Este documento aborda a configuração da injeção de proxy sidecar com a Cloud Service Mesh para melhorar a segurança, a fiabilidade e a observabilidade da rede. Estas funções são abstraídas do contentor principal da aplicação e implementadas num proxy comum fora do processo (o sidecar), fornecido como um contentor separado no mesmo Pod. Isto fornece as funcionalidades da Cloud Service Mesh sem redesenhar as suas aplicações de produção para participar numa service mesh.

A injeção automática de proxy sidecar ocorre quando o Cloud Service Mesh deteta uma etiqueta de espaço de nomes que configura para o pod da carga de trabalho. O proxy interceta todo o tráfego de entrada e saída para as cargas de trabalho e comunica com o Cloud Service Mesh.

Ativar a injeção automática de sidecar

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

Para ativar a injeção automática, etiquete os seus espaços de nomes com as etiquetas de injeção predefinidas se a etiqueta predefinida estiver configurada ou com a etiqueta de revisão no seu espaço de nomes. A etiqueta que adiciona também depende de ter implementado o Cloud Service Mesh gerido (com a API Fleet ou com o asmcli) ou instalado o plano de controlo no cluster. A etiqueta é usada pelo webhook do injetor de sidecar para associar sidecars injetados a uma revisão do plano de controlo específica.

Para ativar a injeção automática:

No cluster

  1. Use o seguinte comando para localizar a etiqueta de revisão em istiod:

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

    O resultado tem um aspeto semelhante ao seguinte:

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

    Na saída, na coluna LABELS, repare no valor da etiqueta de revisão istiod, que segue o prefixo istio.io/rev=. Neste exemplo, o valor é asm-1264-1.

  2. Aplique a etiqueta de revisão aos espaços de nomes e remova a etiqueta istio-injection (se existir). No comando seguinte, NAMESPACE é o nome do espaço de nomes onde quer ativar a injeção automática e REVISION é a etiqueta de revisão que anotou no passo anterior.

    kubectl label namespace NAMESPACE  istio-injection- istio.io/rev=REVISION --overwrite

    Pode ignorar a mensagem "istio-injection not found" no resultado. Isto significa que o espaço de nomes não tinha anteriormente a etiqueta istio-injection, o que deve esperar em novas instalações do Cloud Service Mesh ou novas implementações. Uma vez que o comportamento de injeção automática não está definido quando um espaço de nomes tem a etiqueta istio-injection e a etiqueta de revisão, todos os comandos kubectl label na documentação do Cloud Service Mesh garantem explicitamente que apenas uma está definida.

  3. Reinicie os pods afetados através dos passos na secção seguinte.

Malha de serviço gerida

  1. Use o seguinte comando para localizar os canais de lançamento disponíveis:

    kubectl -n istio-system get controlplanerevision

    O resultado é semelhante ao seguinte:

    NAME                AGE
asm-managed         6d7h

    Na saída, selecione o valor na coluna NAME, que é a etiqueta REVISION correspondente ao canal de lançamento disponível para a versão do Cloud Service Mesh. Aplique esta etiqueta aos seus espaços de nomes e remova a etiqueta istio-injection (se existir). No comando seguinte, substitua REVISION pela etiqueta de revisão que anotou acima e substitua NAMESPACE pelo nome do espaço de nomes onde quer ativar a injeção automática:

    kubectl label namespace NAMESPACE  istio-injection- istio.io/rev=REVISION --overwrite

    Pode ignorar a mensagem "istio-injection not found" no resultado. Isto significa que o espaço de nomes não tinha anteriormente a etiqueta istio-injection, o que deve esperar em novas instalações do Cloud Service Mesh ou novas implementações. Uma vez que o comportamento de injeção automática não está definido quando um espaço de nomes tem a etiqueta istio-injection e a etiqueta de revisão, todos os comandos kubectl label na documentação do Cloud Service Mesh garantem explicitamente que apenas uma está definida.

  2. Reinicie os pods afetados através dos passos na secção seguinte.

  3. Se também implementou o plano de dados gerido pela Google opcional, anote o espaço de nomes demo da seguinte forma:

    kubectl annotate --overwrite namespace YOUR_NAMESPACE \
mesh.cloud.google.com/proxy='{"managed":"true"}'

Reinicie os pods para atualizar os proxies sidecar

Com a injeção automática de sidecars, pode atualizar os sidecars para os pods existentes com um reinício do pod:

A forma como reinicia os pods depende de terem sido criados como parte de uma implementação.

  1. Se usou uma implementação, reinicie-a, o que reinicia todos os pods com sidecars:

    kubectl rollout restart deployment -n YOUR_NAMESPACE

    Se não usou uma implementação, elimine os pods. Estes são recriados automaticamente com os sidecars:

    kubectl delete pod -n YOUR_NAMESPACE --all

  2. Verifique se todos os pods no espaço de nomes têm sidecars injetados:

    kubectl get pod -n YOUR_NAMESPACE

    No exemplo de saída seguinte do comando anterior, repare que a coluna READY indica que existem dois contentores para cada uma das suas cargas de trabalho: o contentor principal e o contentor para o proxy sidecar.

    NAME                    READY   STATUS    RESTARTS   AGE
YOUR_WORKLOAD           2/2     Running   0          20s
...

O que se segue?

Saiba mais sobre: