Opções para configuração do pod do Google Kubernetes Engine com injeção automática de Envoy

Neste guia, você verá informações sobre opções e tarefas adicionais para o injetor sidecar automático do Envoy.

Como adicionar proxies sidecar a cargas de trabalho atuais

Depois de instalar o injetor sidecar nos clusters, os proxies sidecar serão injetados automaticamente nos pods recém-criados em namespaces ativados. Se você já tiver cargas de trabalho em execução antes de ativar o injetor sidecar, será necessário reiniciá-las para que a injeção ocorra.

Para pods gerenciados por controladores de implantação, DaemonSet ou StatefulSet, é possível 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 você não usou nenhum dos controladores acima para implantar os pods, é necessário excluí-los individualmente. Depois, eles são recriados automaticamente com novos proxies sidecar.

kubectl delete pod POD_NAME -n NAMESPACE

Verifique se um contêiner de proxy sidecar foi injetado em cada um dos pods:

kubectl get pods -n NAMESPACE

Por exemplo, com o cliente busybox criado acima, você verá dois pods em execução, um para o próprio aplicativo busybox e um para o proxy sidecar do Envoy injetado:

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

Modificações de injeção

Por padrão, ativar um namespace ativa a injeção de proxy sidecar para todos os pods residentes. A injeção também pode ser configurada de maneira seletiva para que escopos diferentes atendam a necessidades específicas. Por exemplo, as modificações precisam ser usadas para evitar a injeção de proxy sidecar para serviços gRPC sem proxy.

Observe que as substituições de injeção só se aplicam quando o namespace está ativado e entram em vigor com a seguinte prioridade: Anotações de pod > NeverInjectSelector > AlwaysInjectSelector > Política padrão

Como ativar/desativar a injeção de pods específicos

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

...
metadata:
  annotations:
    sidecar.istio.io/inject: "true" / "false"

Ativar/desativar a injeção para grupos específicos de pods

O injetor sidecar pode ser configurado para sempre ou nunca injetar pods em namespaces ativados com base em uma matriz de seletores de rótulos do Kubernetes. Por exemplo, use os seguintes comandos para configurar o injetor sidecar para não injetar um proxy sidecar se o pod tiver o rótulo "run=client":

kubectl edit configmap -n istio-control istio-sidecar-injector

...
config: |-
  policy: enabled
  alwaysInjectSelector:
    []

  neverInjectSelector:
    - matchLabels:
        run: client
...

As implantações de injetor sidecar atuais precisam ser reiniciadas para que essa configuração entre em vigor.

Como personalizar o comportamento de interceptação de tráfego

Por padrão, todo o tráfego de saída do aplicativo é interceptado e redirecionado para o proxy sidecar do Envoy. O proxy do Envoy pode processar o tráfego de acordo com as instruções recebidas do Traffic Director. Em alguns casos, convém modificar esse comportamento para ignorar o proxy sidecar.

Use as seguintes anotações de pod para excluir o tráfego da interceptação e redirecionamento.

Excluir da interceptação por intervalo de endereços IP de saída

Você pode excluir o tráfego da interceptação por intervalo de endereços IP.

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

Essa anotação de pod cloud.google.com/excludeOutboundCIDRs é 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 esses intervalos de endereços IP não é redirecionado para o arquivo secundário do Envoy.

Observe que é necessário listar 169.254.169.254/32 na anotação de pod para garantir que os aplicativos possam se comunicar com o servidor de metadados. Se você não especificar a anotação de pod cloud.google.com/excludeOutboundCIDRs, a interceptação do tráfego será configurada para excluir o intervalo CIDR de saída "169.254.169.254/32".

Incluir na interceptação pelo intervalo de endereços IP de saída

É possível incluir o tráfego na interceptação por intervalo de endereços IP.

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

Essa anotação de pod cloud.google.com/includeOutboundCIDRs é 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 esses intervalos de endereços IP é redirecionado para o arquivo secundário do Envoy.

O caractere curinga * 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 padrão é *.

Excluir da interceptação pelo número da porta de saída

É possível excluir o tráfego de interceptação e redirecionamento por número de porta de saída.

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

Essa anotação de pod cloud.google.com/excludeOutboundPorts é uma lista separada por vírgulas de portas de saída. O tráfego de saída destinado a essas portas é excluído da interceptação e do redirecionamento para o arquivo secundário do Envoy.

Se você não especificar a anotação cloud.google.com/excludeOutboundPorts, o tráfego de saída destinado a qualquer porta será interceptado e redirecionado ao arquivo secundário do Envoy. Isso é equivalente transmitir a anotação cloud.google.com/excludeOutboundPorts com uma lista vazia ("").

Incluir na interceptação por número de porta de entrada

É possível incluir o tráfego na interceptação pelo número da porta de entrada.

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

A anotação de pod cloud.google.com/includeInboundPorts é uma lista separada por vírgulas de portas de entrada para que o tráfego será redirecionado para o arquivo secundário do Envoy. O caractere curinga * pode ser usado para configurar o redirecionamento para todas as portas. Um valor vazio desativa todos os redirecionamentos de entrada. O valor padrão é uma string vazia ("").

Excluir da interceptação pelo número da porta de saída

Você pode excluir o tráfego da interceptação por número de porta de entrada.

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

A anotação de pod cloud.google.com/excludeInboundPorts é uma lista separada por vírgulas de portas de entrada a serem excluídas do redirecionamento para o arquivo secundário do Envoy. A anotação só se aplica quando todo o tráfego de entrada (*) estiver sendo redirecionado. O valor padrão é uma string vazia ("").

Ativar certificados gerenciados

É possível ativar certificados de carga de trabalho gerenciada.

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

Quando a anotação do pod cloud.google.com/enableManagedCerts é definida como true, os certificados de carga de trabalho gerenciados pelo GKE assinados pelo Certificate Authority Service são inseridos e montados no contêiner do arquivo secundário. O valor da anotação é definido como false por padrão.

Como configurar metadados de proxy sidecar

Para aceitar outros recursos do Traffic Director, os proxies sidecar podem herdar metadados específicos dos pods de encapsulamento. Há duas maneiras de fazer isso. Ambas as opções anexam metadados e compartilham os metadados com o Traffic Director quando o proxy secundário se conecta ao Traffic Director. As opções são mutuamente exclusivas.

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

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

A segunda opção anexa todos os rótulos do pod ao proxy sidecar injetado do pod.

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

Se você não especificar a anotação cloud.google.com/forwardPodLabels, os rótulos do pod não serão anexados ao proxy sidecar. Observe que as anotações cloud.google.com/proxyMetadata e cloud.google.com/forwardPodLabels são mutuamente exclusivas. Se as duas forem definidas, cloud.google.com/forwardPodLabels terá prioridade e cloud.google.com/proxyMetadata será ignorada.

Com o filtro de configuração, o Traffic Director consegue compartilhar um subconjunto de configuração somente com os proxies específicos que correspondam ao rótulo "version": "dev".

As implantações atuais precisam ser reiniciadas para que a configuração entre em vigor.

Anotações de pods compatíveis

O Traffic Director é compatível com as anotações de pod a seguir para a injeção de sidecar. Mesmo que outras anotações do injetor sidecar possam funcionar, a lista a seguir representa anotações compatíveis com o Traffic Director. Para evitar interrupções ou instabilidade, não crie uma dependência em outras anotações na implantação de produção.

Nome da anotação	Valor	Descrição
sidecar.istio.io/inject	Booleano, representado como uma string. Por exemplo: "`true`"	Especifica se um arquivo secundário do Envoy precisa 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 em um mapa JSON que precisam ser anexados aos metadados do Envoy.
cloud.google.com/forwardPodLabels	"verdadeiro" ou "falso"	Quando definido como "true", todos os rótulos de pod são anexados aos metadados do Envoy e a anotação "cloud.google.com/proxyMetadata" é ignorada. O padrão é "false".
cloud.google.com/excludeOutboundPorts	Lista separada por vírgulas de portas de saída	O tráfego de saída que indica qualquer uma dessas portas de destino é excluído da interceptação/redirecionamento para o arquivo secundário do Envoy. Esse tráfego vai ignorar o proxy Envoy e não será processado de acordo com a configuração do Traffic Director. O padrão é uma string vazia (por exemplo, "").
cloud.google.com/includeInboundPorts	Lista de portas de entrada separada por vírgulas	Uma lista de portas de entrada separada por vírgulas para a qual o tráfego é redirecionado para o arquivo secundário do Envoy. Use o caractere curinga "*" para configurar o redirecionamento para todas as portas. Um valor vazio desativa todo o redirecionamento de entrada. O valor padrão é uma string vazia ("").
cloud.google.com/excludeInboundPorts	Lista de portas de entrada separada por vírgulas	Uma lista de portas de entrada separada por vírgulas para a qual o tráfego não é redirecionado para o arquivo secundário do Envoy. A anotação se aplica somente quando todo o tráfego de entrada (*) estiver sendo redirecionado. O valor padrão é 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 desses IPs de destino é excluído da interceptação/redirecionamento para o arquivo secundário do Envoy. Esse tráfego vai ignorar o proxy Envoy e não será processado de acordo com a configuração do Traffic Director. Assume como padrão "169.254.169.254/32", que é o intervalo necessário para se comunicar com o servidor de metadados. Esse intervalo é obrigatório. Portanto, se você especificar a anotação "excludeOutboundCIDRs", inclua também "169.254.169.254/32", além de qualquer outro CIDR. Verifique se não há 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.	Tráfego de saída que indica que qualquer um desses IPs de destino está incluído na interceptação/redirecionamento para o arquivo secundário do Envoy. Esse tráfego é direcionado para o proxy Envoy e é processado de acordo com a configuração do Traffic Director. Assume como padrão "169.254.169.254/32", que é o intervalo necessário para se comunicar com o servidor de metadados. Esse intervalo é obrigatório. Portanto, se você especificar a anotação "includeOutboundCIDRs", inclua também "169.254.169.254/32", além de qualquer outro CIDR. Verifique se não há espaços na lista separada por vírgulas.
cloud.google.com/enableManagedCerts	Booleano, representado como uma string. Por exemplo: "`true`"	Quando definidos como "`true`", os certificados de carga de trabalho gerenciados pelo GKE assinados pelo Certificate Authority Service são inseridos e montados no contêiner do arquivo secundário. O valor padrão é "`false`".

Como desinstalar o injetor sidecar

Desinstale o injetor sidecar com os seguintes comandos:

kubectl delete -f specs/
kubectl label namespace default istio-injection-