O Anthos Service Mesh e o Traffic Director agora são Cloud Service Mesh. Para mais informações, consulte a Visão geral do Cloud Service Mesh.

Esta página foi traduzida pela API Cloud Translation.

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. Uma lista vazia desativa todo o tráfego de saída. A anotação assume o valor padrão *.

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

Você pode excluir o tráfego da interceptação e do redirecionamento pelo número da 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 pelo número da 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 as quais o tráfego será redirecionado para o sidecar do Envoy. 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 de pod cloud.google.com/excludeInboundPorts é uma lista separada por vírgulas de portas de entrada a serem excluídas do redirecionamento para o sidecar do Envoy. O só se aplica quando todo o tráfego de entrada (*) está sendo redirecionado. O 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, os certificados de carga de trabalho gerenciados pelo GKE assinados pelo serviço de autoridade de certificação são inseridos e montados no contêiner do sidecar. O valor da anotação é definido por padrão como 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.

Com o filtro de configuração, o Cloud Service Mesh pode compartilhar um subconjunto de configuração somente com os proxies específicos que correspondem a esse 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 Cloud Service Mesh é compatível com as seguintes anotações de pod para a injeção de sidecar. 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 vai ignorar o proxy Envoy e não será processado de acordo com a configuração do Cloud Service Mesh. O padrão é uma string vazia (por exemplo, "").
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 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. O valor padrão é uma string vazia ("").
cloud.google.com/excludeInboundPorts	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 não é 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 é 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.	O tráfego de saída que indica qualquer um desses IPs de destino é incluído na 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-