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 ou 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:
td-injection: "true" / "false"
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 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 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 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 para todas as
portas. Um valor vazio desativa todo o redirecionamento 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 por 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. A
anotação só é aplicada 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 gerenciada.
...
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 Certificate Authority Service
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 aceitar 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 e compartilham metadados com o Cloud Service Mesh quando o proxy secundário 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 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 |
|---|---|---|
| td-injection | 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 sidecar do Envoy. Use o caractere curinga "*" para configurar o redirecionamento para todas as portas. Um valor vazio desativa todos os redirecionamentos 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 vai ignorar o proxy Envoy e não será processado de acordo com a configuração do Cloud Service Mesh. 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 é direcionado ao proxy Envoy e é processado de acordo com a configuração da Cloud Service Mesh. 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 MutatingWebhookConfiguration td-mutating-webhook kubectl label namespace default td-injection-