Injete proxies secundários com Cloud Service Mesh

Este documento aborda como configurar a injeção de proxy sidecar com Cloud Service Mesh para aprimorar 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 redesenhar seus aplicativos de produção para participar de uma malha de serviço.

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

Habilitando a injeção automática de sidecar

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

Para ativar a injeção automática, você rotula seus 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 do seu namespace. O rótulo adicionado também depende se você implementou 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 sidecar para associar sidecars injetados a uma revisão específica do plano de controle.

Para ativar a injeção automática:

No cluster

  1. 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 saída é semelhante a esta:

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

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

  2. Aplique o rótulo de revisão aos namespaces e remova o rótulo de injeção istio (se existir). No comando a seguir, NAMESPACE é o nome do namespace onde você deseja habilitar 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 anteriormente o rótulo istio-injection , o que você deve esperar em novas instalações do Cloud Service Mesh ou em novas implantações. Como o comportamento de injeção automática é indefinido quando um namespace tem a 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.

  3. Reinicie os pods afetados seguindo as etapas da próxima seção.

Malha de serviço gerenciada

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

    kubectl -n istio-system get controlplanerevision

    A saída é semelhante à seguinte:

    NAME                AGE
asm-managed         6d7h

    Na saída, selecione o valor na coluna NAME que é o rótulo REVISION que corresponde ao canal de lançamento disponível para a versão do Cloud Service Mesh. Aplique este rótulo aos seus namespaces e remova o rótulo istio-injection (se existir). No comando a seguir, substitua REVISION pelo rótulo de revisão anotado acima e substitua NAMESPACE pelo nome do namespace onde você deseja habilitar 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 anteriormente o rótulo istio-injection , o que você deve esperar em novas instalações do Cloud Service Mesh ou em novas implantações. Como o comportamento de injeção automática é indefinido quando um namespace tem a 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.

  2. Reinicie os pods afetados seguindo as etapas da próxima seção.

  3. Se você também implantou o plano de dados opcional gerenciado pelo Google , anote o namespace demo da seguinte forma:

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

Reinicie os pods para atualizar proxies secundários

Com a injeção automática de sidecar, você pode atualizar os sidecars de pods existentes com uma reinicialização do pod:

A forma como você reinicia os pods depende se eles foram criados como parte de um Deployment .

  1. Se você usou uma implantação, reinicie a implantação, que reinicia todos os pods com arquivos secundários:

    kubectl rollout restart deployment -n YOUR_NAMESPACE

    Se você não usou uma implantação, exclua os pods e eles serão recriados automaticamente com arquivos secundários:

    kubectl delete pod -n YOUR_NAMESPACE --all

  2. Verifique se todos os pods no namespace têm sidecars injetados: 

    kubectl get pod -n YOUR_NAMESPACE

    No exemplo de saída do comando anterior a seguir, observe que a coluna READY indica que há dois contêineres para cada uma de suas cargas de trabalho: o contêiner primário e o contêiner do proxy secundário. 

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

O que vem a seguir

Saiba mais sobre: