Opções de configuração de pods do Google Kubernetes Engine através da injeção automática do Envoy

Este guia fornece informações sobre opções e tarefas adicionais para o injetor sidecar do Envoy automático.

Nota: este guia só suporta a Cloud Service Mesh com Google Cloud APIs e não suporta as APIs Istio. Para mais informações, consulte o artigo Vista geral do Cloud Service Mesh.

Adicionar proxies sidecar a cargas de trabalho existentes

Depois de instalar o injetor de sidecar nos seus clusters, os proxies sidecar são injetados automaticamente nos pods recém-criados nos espaços de nomes ativados. Se já tiver cargas de trabalho em execução antes de ativar o injetor de sidecar, tem de as reiniciar para que a injeção ocorra.

Para pods geridos por controladores de implementação, DaemonSet ou StatefulSet, pode executar o seguinte:

# Deployment
kubectl rollout restart deployment/DEPLOYMENT_NAME --namespace NAMESPACE

# DaemonSet
kubectl rollout restart daemonset/DAEMONSET_NAME --namespace NAMESPACE

# StatefulSet
kubectl rollout restart statefulset/STATEFULSET_NAME --namespace NAMESPACE

Se não usou nenhum dos controladores acima para implementar os seus pods, tem de eliminar os pods individualmente. Posteriormente, são recriados automaticamente com novos proxies sidecar.

kubectl delete pod POD_NAME -n NAMESPACE

Verifique se foi injetado um contentor de proxy sidecar em cada um dos seus pods:

kubectl get pods -n NAMESPACE

Por exemplo, com o cliente busybox criado acima, deve ver 2/2 pods em execução, um para a própria aplicação busybox e outro para o proxy sidecar Envoy injetado:

NAME                      READY   STATUS    RESTARTS   AGE
busybox-c54f578c9-c9fk4   2/2     Running   183        7d15h

Substituições de injeção

Por predefinição, a ativação de um espaço de nomes ativa a injeção de proxy sidecar para todos os pods residentes. A injeção também pode ser configurada seletivamente para diferentes âmbitos de acordo com necessidades específicas. Por exemplo, as substituições devem ser usadas para impedir a injeção de proxy sidecar para serviços gRPC sem proxy.

Tenha em atenção que as substituições de injeção só se aplicam quando o espaço de nomes está ativado e entram em vigor com a seguinte prioridade: Anotações de pods > NeverInjectSelector > AlwaysInjectSelector > Política predefinida

Ativar ou desativar a injeção para pods individuais específicos

Use a seguinte anotação de pod para ativar ou desativar a injeção para um pod específico num espaço de nomes ativado:

...
metadata:
  annotations:
    td-injection: "true" / "false"

Personalizar o comportamento de interceção de tráfego

Por predefinição, todo o tráfego de saída da sua aplicação é intercetado e redirecionado para o proxy sidecar do Envoy. Em seguida, o proxy Envoy pode processar o tráfego de acordo com as instruções recebidas do Cloud Service Mesh. Em alguns casos, pode querer modificar este comportamento para ignorar o proxy sidecar.

Use as seguintes anotações de Pod para excluir tráfego da interceção e do redirecionamento.

Exclua da interceção por intervalo de endereços IP de saída

Pode excluir o tráfego da interceção por intervalo de endereços IP.

...
metadata:
  annotations:
    cloud.google.com/excludeOutboundCIDRs: "10.0.0.1/32,169.254.169.254/32"

A anotação cloud.google.com/excludeOutboundCIDRs Pod é uma lista separada por vírgulas de intervalos de endereços IP de saída no formato CIDR. O tráfego de saída destinado a estes intervalos de endereços IP não é redirecionado para o sidecar do Envoy.

Tenha em atenção que tem de listar 169.254.169.254/32 na anotação Pod para garantir que as aplicações podem comunicar com o servidor de metadados. Se não especificar a anotação cloud.google.com/excludeOutboundCIDRs Pod, a interceção de tráfego é configurada para excluir o intervalo CIDR de saída "169.254.169.254/32".

Inclua na interceção por intervalo de endereços IP de saída

Pode incluir tráfego na interceção por intervalo de endereços IP.

...
metadata:
  annotations:
    cloud.google.com/includeOutboundCIDRs: "10.0.0.1/32,169.254.169.254/32"

A anotação cloud.google.com/includeOutboundCIDRs Pod é uma lista separada por vírgulas de intervalos de endereços IP de saída no formato CIDR. O tráfego de saída destinado a estes intervalos de endereços IP é redirecionado para o sidecar do Envoy.

O caráter universal * pode ser usado para redirecionar todo o tráfego de saída. Uma lista vazia desativa todo o tráfego de saída. A anotação tem como predefinição *.

Exclua da interceção pelo número da porta de saída

Pode excluir tráfego de interceção e redirecionamento por número de porta de saída.

...
metadata:
  annotations:
    cloud.google.com/excludeOutboundPorts: "10001, 10002"

A anotação cloud.google.com/excludeOutboundPorts Pod é uma lista separada por vírgulas de portas de saída. O tráfego de saída destinado a estas portas é excluído da interceção e do redirecionamento para o sidecar do Envoy.

Se não especificar a anotação cloud.google.com/excludeOutboundPorts, o tráfego de saída destinado a qualquer porta é intercetado e redirecionado para o sidecar do Envoy. Isto é equivalente a transmitir a anotação cloud.google.com/excludeOutboundPorts com uma lista vazia ("").

Incluir na interceção pelo número da porta de entrada

Pode incluir tráfego na interceção por número de porta de entrada.

...
metadata:
  annotations:
    cloud.google.com/includeInboundPorts: "10001, 10002"

A anotação cloud.google.com/includeInboundPorts Pod é uma lista separada por vírgulas de portas de entrada para as quais o tráfego vai ser redirecionado para o sidecar do Envoy. Pode usar o caráter universal * para configurar o redirecionamento para todas as portas. Um valor vazio desativa todo o redirecionamento de entrada. O valor é predefinido como uma string vazia ("").

Exclua da interceção pelo número da porta de entrada

Pode excluir tráfego da interceção por número de porta de entrada.

...
metadata:
  annotations:
    cloud.google.com/excludeInboundPorts: "10001, 10002"

A anotação cloud.google.com/excludeInboundPorts Pod é uma lista separada por vírgulas de portas de entrada a excluir do redirecionamento para o sidecar do Envoy. A anotação só se aplica quando todo o tráfego de entrada (*) está a ser redirecionado. O valor é predefinido como uma string vazia ("").

Ative os certificados geridos

Pode ativar certificados de carga de trabalho geridos.

...
metadata:
  annotations:
    cloud.google.com/enableManagedCerts: "true"

Quando a anotação do pod cloud.google.com/enableManagedCerts está definida como true, os certificados de carga de trabalho geridos pelo GKE assinados pelo serviço de autoridade de certificação são inseridos e montados no contentor sidecar. O valor da anotação é predefinido como false.

Configurar metadados do proxy sidecar

Para suportar funcionalidades adicionais da Cloud Service Mesh, os proxies sidecar podem herdar metadados específicos dos respetivos pods de encapsulamento. Existem duas formas de o fazer. Ambas as opções anexam metadados e partilham os metadados com o Cloud Service Mesh quando o proxy sidecar se liga ao Cloud Service Mesh. As opções são mutuamente exclusivas.

A primeira opção permite-lhe especificar pares de chave/valor de metadados individuais. Por exemplo, inclua a seguinte anotação na especificação do modelo de pod para aplicar a etiqueta "version": "dev" aos respetivos proxies sidecar injetados.

...
metadata:
  annotations:
    cloud.google.com/proxyMetadata: '{"version": "dev"}'

A segunda opção anexa todas as etiquetas do pod ao proxy sidecar injetado do pod.

...
metadata:
  annotations:
    cloud.google.com/forwardPodLabels: "true"

Se não especificar a anotação cloud.google.com/forwardPodLabels, as etiquetas Pod não são anexadas ao proxy sidecar. Tenha em atenção que as anotações cloud.google.com/proxyMetadata e cloud.google.com/forwardPodLabels são mutuamente exclusivas. Se definir ambos, cloud.google.com/forwardPodLabels tem prioridade e cloud.google.com/proxyMetadata é ignorado.

A filtragem de configurações permite que a malha de serviços na nuvem partilhe apenas um subconjunto de configurações com os proxies específicos que correspondem a esta etiqueta "version": "dev".

As implementações existentes têm de ser reiniciadas para que esta configuração entre em vigor.

Anotações de agrupamentos suportadas

O Cloud Service Mesh suporta as seguintes anotações de pods para injeção de sidecar. Embora possam funcionar anotações do injetor de sidecar adicionais, a lista seguinte representa as anotações suportadas pelo Cloud Service Mesh. Para evitar falhas ou instabilidade, não crie uma dependência noutras anotações na sua implementação de produção.

Nome da anotação	Valor	Descrição
td-injection	Booleano, representado como uma string. Por exemplo: "true"	Especifica se um sidecar do Envoy deve ou não ser injetado automaticamente na carga de trabalho.
cloud.google.com/proxyMetadata	Mapa JSON de pares de chave-valor. Por exemplo: "'{"version": "dev"}'"	Especifica os pares de chave/valor num mapa JSON que devem ser anexados aos metadados do Envoy.
cloud.google.com/forwardPodLabels	"true" ou "false"	Quando definido como "true", todas as etiquetas de Pod são anexadas aos metadados do Envoy, e a anotação "cloud.google.com/proxyMetadata" é ignorada. A predefinição é "false".
cloud.google.com/excludeOutboundPorts	Lista de portas de saída separadas por vírgulas	O tráfego de saída que indica que qualquer uma destas portas de destino está excluída da interceção/redirecionamento para o sidecar do Envoy. Este tráfego vai ignorar o proxy Envoy e não vai ser processado de acordo com a configuração do Cloud Service Mesh. A predefinição é uma string vazia (ou seja, "").
cloud.google.com/includeInboundPorts	Lista de portas de entrada separadas por vírgulas	Uma lista separada por vírgulas de portas de entrada para as quais o tráfego é redirecionado para o sidecar do Envoy. Use o caráter universal `*` para configurar o redirecionamento para todas as portas. Um valor vazio desativa todo o redirecionamento de entrada. O valor é predefinido como uma string vazia ("").
cloud.google.com/excludeInboundPorts	Lista de portas de entrada separadas por vírgulas	Uma lista de portas de entrada separada por vírgulas para as quais o tráfego não é redirecionado para o sidecar do Envoy. A anotação aplica-se apenas quando todo o tráfego de entrada (*) está a ser redirecionado. O valor é predefinido para uma string vazia ("").
cloud.google.com/excludeOutboundCIDRs	Lista separada por vírgulas de intervalos de IP de saída no formato CIDR.	O tráfego de saída que indica que qualquer um destes IPs de destino está excluído da interceção/redirecionamento para o sidecar do Envoy. Este tráfego vai ignorar o proxy Envoy e não vai ser processado de acordo com a configuração do Cloud Service Mesh. O valor predefinido é "169.254.169.254/32", que é o intervalo necessário para comunicar com o servidor de metadados. Tenha em atenção que este intervalo é obrigatório. Por isso, se especificar a anotação `excludeOutboundCIDRs`, certifique-se de que também inclui "169.254.169.254/32" além de quaisquer outros CIDRs. Certifique-se de que não existem espaços na lista separada por vírgulas.
cloud.google.com/includeOutboundCIDRs	Lista separada por vírgulas de intervalos de IP de saída no formato CIDR.	O tráfego de saída que indica que qualquer um destes IPs de destino está incluído na interceção/redirecionamento para o sidecar do Envoy. Este tráfego é direcionado para o proxy Envoy e é processado de acordo com a configuração do Cloud Service Mesh. O valor predefinido é "169.254.169.254/32", que é o intervalo necessário para comunicar com o servidor de metadados. Tenha em atenção que este intervalo é obrigatório. Por isso, se especificar a anotação `includeOutboundCIDRs`, certifique-se de que também inclui "169.254.169.254/32" além de outros CIDRs. Certifique-se de que não existem espaços na lista separada por vírgulas.
cloud.google.com/enableManagedCerts	Booleano, representado como uma string. Por exemplo: "true"	Quando definido como "true", os certificados de carga de trabalho geridos pelo GKE assinados pelo serviço de autoridade de certificação são inseridos e montados no contentor auxiliar. O valor predefinido é "false".

Desinstalar o injetor de sidecar

Desinstale o injetor sidecar com os seguintes comandos:

kubectl delete MutatingWebhookConfiguration td-mutating-webhook
kubectl label namespace default td-injection-

Nota: os comandos acima desinstalam o injetor de sidecar, mas os proxies de sidecar injetados persistem até ao próximo reinício contínuo ou eliminação manual do pod.