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. Então, o proxy Envoy processa de acordo com as instruções recebidas do Cloud Service Mesh. 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 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. Um valor vazio desativa todo o tráfego de saída. A anotação é padronizada como *.

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

Você pode excluir o tráfego da interceptação e do redirecionamento por porta de saída número

...
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 da porta de entrada

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

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

A anotação do pod cloud.google.com/includeInboundPorts é um valor separado por vírgulas lista de portas de entrada para as quais o tráfego será redirecionado para o Envoy arquivo secundário. O caractere curinga * pode ser usado para configurar o redirecionamento de todos 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

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

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

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

Ativar certificados gerenciados

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

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

Quando a anotação cloud.google.com/enableManagedCerts do pod é definida como true, 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 o padrão é false.

Como configurar metadados de proxy sidecar

Para oferecer suporte a outros recursos do Cloud Service Mesh, 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 os compartilham com o Cloud Service Mesh quando o proxy sidecar se conecta ao Cloud Service Mesh. 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.

Filtragem de configuração permite que o Cloud Service Mesh compartilhe um subconjunto de configurações somente com proxies específicos que correspondem ao marcador "version": "dev".

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

Anotações de pods compatíveis

O Cloud Service Mesh oferece suporte às seguintes anotações de pod para arquivo secundário por injeção. Embora outras anotações do injetor sidecar possam funcionar, a a lista a seguir representa anotações compatíveis com o Cloud Service Mesh. 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 sidecar 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 ignoram o proxy Envoy e não são processados de acordo com o Cloud Service Mesh configuração do Terraform. O padrão é uma string vazia (por exemplo, "").
cloud.google.com/includeInboundPorts Lista separada por vírgulas de portas de entrada Uma lista separada por vírgulas de portas de entrada para as quais o tráfego é redirecionado para o arquivo secundário do Envoy. Use o caractere curinga "*" para configurar o redirecionamento de todas as portas. Um valor vazio desativa todas o redirecionamento de entrada. Por padrão, o valor é uma string vazia ("").
cloud.google.com/excludeInboundPorts Lista separada por vírgulas de portas de entrada Uma lista separada por vírgulas de portas de entrada para as quais o tráfego é redirecionado para o arquivo secundário do Envoy. A anotação se aplica apenas quando todo o tráfego de entrada (*) está sendo redirecionado. O valor padrão como 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 ignoram o proxy Envoy e não são processados de acordo com o Cloud Service Mesh configuração do Terraform. 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 em interceptação/redirecionamento para o arquivo secundário do Envoy. Esse tráfego está é direcionado para o proxy Envoy e é processado de acordo com o Cloud Service Mesh configuração do Terraform. 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-