Controlar a comunicação entre pods e serviços usando políticas de rede

Autopilot Standard

---

Nesta página, explicamos como controlar a comunicação entre os pods e os serviços do cluster usando a aplicação da política de rede do GKE.

Também é possível controlar o tráfego de saída dos pods para qualquer endpoint ou serviço fora do cluster usando políticas de rede de nome de domínio totalmente qualificado (FQDN, na sigla em inglês). Para mais informações, consulte Controlar a comunicação entre pods e serviços usando FQDNs.

Sobre a aplicação da política de rede do GKE

A aplicação da política de rede permite criar políticas de rede do Kubernetes no cluster. Por padrão, todos os pods em um cluster podem se comunicar livremente. As políticas de rede criam regras de firewall no nível do pod que determinam quais pods e serviços podem acessar um ao outro dentro do cluster.

Ao definir a política de rede, você ativa itens como defesa em profundidade quando o cluster estiver veiculando um aplicativo de vários níveis. Por exemplo, você pode criar uma política de rede para garantir que um serviço comprometido de front-end no aplicativo não possa se comunicar diretamente com um serviço de faturamento ou contabilidade vários níveis abaixo.

A política de rede também pode facilitar a hospedagem de dados de vários usuários simultaneamente por parte do seu aplicativo. Por exemplo, você pode fornecer multilocação segura definindo um modelo de inquilino por namespace. Nesse modelo, as regras de política de rede podem garantir que pods e serviços em um determinado namespace não acessem outros pods ou serviços em um namespace diferente.

Observação: para que a aplicação da política de rede funcione corretamente, o GKE implementa pods nos nós que têm Permissões do RBAC elevadas, como a capacidade de corrigir todas as implementações e atualizar o status dos nós. Essas permissões são necessárias para que o GKE aplique as políticas de rede com base na configuração.

Antes de começar

Antes de começar, verifique se você realizou as tarefas a seguir:

• Ativar a API Google Kubernetes Engine.
Ativar a API Google Kubernetes Engine
• Se você quiser usar a Google Cloud CLI para essa tarefa, instale e, em seguida, inicialize a CLI gcloud. Se você instalou a CLI gcloud anteriormente, instale a versão mais recente executando gcloud components update.
  Observação: para instalações atuais da CLI gcloud, defina as propriedades compute/region e compute/zone. Ao definir locais padrão, é possível evitar erros na CLI gcloud, como: One of [--zone, --region] must be supplied: Please specify location.

Requisitos e limitações

Os requisitos e limitações a seguir se aplicam aos clusters do Autopilot e do Standard:

• É preciso permitir a saída para o servidor de metadados.
• Se você especificar um campo endPort em uma política de rede em um cluster com o GKE Dataplane V2 ativado, ele poderá não entrar em vigor a partir da versão 1.22 do GKE. Para mais informações, consulte Os intervalos de portas da política de rede não entram em vigor. Nos clusters do Autopilot, o GKE Dataplane V2 está sempre ativado.

Os requisitos e limitações a seguir se aplicam somente aos clusters padrão:

• É necessário permitir a saída para o servidor de metadados se você usar a política de rede com a federação de identidade da carga de trabalho para o GKE.
• Ativar a aplicação da política de rede aumenta o consumo de memória do processo kube-system em aproximadamente 128 MB e requer aproximadamente 300 milicores de CPU. Isso significa que, se você ativar políticas de rede para um cluster atual, talvez seja necessário aumentar o tamanho do cluster para continuar executando as cargas de trabalho programadas.
• A ativação da aplicação obrigatória da política de rede requer que os nós sejam recriados. Se o cluster tiver uma janela de manutenção ativa, os nós não serão recriados automaticamente até a próxima janela de manutenção. Se preferir, faça upgrade do cluster manualmente quando quiser.
• O tamanho mínimo recomendado do cluster para executar a aplicação da política de rede é de três instâncias e2-medium.
• A política de rede não é compatível com clusters com nós f1-micro ou g1-small porque os requisitos de recursos são muito altos.

Para mais informações sobre tipos de máquinas de nó e recursos alocáveis, consulte Arquitetura do cluster padrão - nós.

Cuidado: por padrão, ativar a aplicação de política de rede para o cluster também ativa a aplicação nos nós do cluster e pode causar uma interrupção nos pods implantados manualmente. Para mais informações, consulte Pods implantados manualmente não programados.

Ativar a aplicação da política de rede

A aplicação da política de rede é ativada por padrão para os clusters do Autopilot. Portanto, pule para Criar uma política de rede.

A aplicação da política de rede no GKE pode ser ativada usando a ferramenta gcloud, o Console do Google Cloud ou a API GKE.

A aplicação da política de rede é integrada ao GKE Dataplane V2. Não é necessário ativar a aplicação da política de rede nos clusters que usam o GKE Dataplane V2.

Observação: se você ativar ou desativar a aplicação obrigatória da política de rede em um cluster atual, o GKE recriará automaticamente todas as configurações do pool de nós antes que o cluster possa executar o processo de política de rede. Para mais informações, consulte avisos e limitações.

gcloud

1. In the Google Cloud console, activate Cloud Shell.

   Activate Cloud Shell

   At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

2. Para ativar a aplicação da política de rede ao criar um novo cluster, execute o comando a seguir:

   gcloud container clusters create CLUSTER_NAME --enable-network-policy
   

   Substitua CLUSTER_NAME pelo nome do novo cluster.

   Para ativar a aplicação da política de rede para um cluster existente, execute as tarefas a seguir:

   1. Execute o comando a seguir para ativar o complemento:

      gcloud container clusters update CLUSTER_NAME --update-addons=NetworkPolicy=ENABLED
      

      Substitua CLUSTER_NAME pelo nome do cluster.

   2. Execute o comando a seguir para ativar a aplicação obrigatória da política de rede no cluster, que, por sua vez, recria os pools de nós do cluster com a aplicação da política de rede ativada:

      gcloud container clusters update CLUSTER_NAME --enable-network-policy
      

Console

Para ativar a aplicação da política de rede ao criar um novo cluster:

1. Acesse a página Google Kubernetes Engine no Console do Google Cloud.

   Acessar o Google Kubernetes Engine

2. Clique em Criar.

3. Na caixa de diálogo Criar cluster do GKE Standard, clique em Configurar.

4. Configure o cluster como preferir.

5. No painel de navegação, em Cluster, clique em Rede.

6. Marque a caixa de seleção Ativar política de rede.

7. Clique em Criar.

Para ativar a aplicação da política de rede para um cluster atual:

1. Acesse a página do Google Kubernetes Engine no Console do Google Cloud.

   Acessar o Google Kubernetes Engine

2. Na lista de clusters, clique no nome do cluster que você quer modificar.

3. Em Rede, no campo Política de rede, clique em Editar política de rede.

4. Marque a caixa de seleção Ativar a política de rede para mestre e clique em Salvar alterações.

5. Aguarde a aplicação das suas alterações e clique em Editar política de rede novamente.

6. Marque a caixa de seleção Ativar política de rede para nós.

7. Clique em Salvar alterações.

API

Para ativar a aplicação da política de rede, faça o seguinte:

1. Especifique o objeto networkPolicy dentro do objeto cluster fornecido para projects.zones.clusters.create ou projects.zones.clusters.update.

2. O objeto networkPolicy requer um enum que especifique qual provedor de política de rede usar e um valor booleano que especifique se a política de rede será ativada. Se você ativar a política de rede, mas não definir o provedor, os comandos create e update retornarão um erro.

Desativar a aplicação da política de rede em um cluster padrão

Desative a aplicação da política de rede usando a gcloud CLI, o Console do Google Cloud ou a API GKE. Não é possível desativar a aplicação da política de rede em clusters do Autopilot ou clusters que usam o GKE Dataplane V2.

Aviso: desativar a aplicação obrigatória da política de rede é uma operação disruptiva. Todos os nós de cluster são recriados de acordo com o processo de upgrade de nós do GKE.

gcloud

1. In the Google Cloud console, activate Cloud Shell.

   Activate Cloud Shell

   At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

2. Para desativar a aplicação obrigatória da política de rede, execute as seguintes tarefas:

   1. Desative a aplicação obrigatória da política de rede no cluster:

   gcloud container clusters update CLUSTER_NAME --no-enable-network-policy
   

   Substitua CLUSTER_NAME pelo nome do cluster.

   Depois de executar o comando, o GKE recria os pools de nós do cluster com a aplicação obrigatória da política de rede desativada.

3. Verifique se todos os nós foram recriados:

   kubectl get nodes -l projectcalico.org/ds-ready=true
   

   Se a operação for bem-sucedida, a saída será semelhante a esta:

   No resources found
   

   Se a saída for semelhante a essa, será necessário aguardar o GKE terminar de atualizar os pools de nós:

   NAME                                             STATUS                     ROLES    AGE     VERSION
   gke-calico-cluster2-default-pool-bd997d68-pgqn   Ready,SchedulingDisabled   <none>   15m     v1.22.10-gke.600
   gke-calico-cluster2-np2-c4331149-2mmz            Ready                      <none>   6m58s   v1.22.10-gke.600
   

   Quando você desativa a aplicação obrigatória da política de rede, o GKE talvez deixe de atualizar os nós imediatamente se o cluster tiver uma janela de manutenção ou exclusão configurada. Para ver mais informações, consulte Atualização lenta do cluster.

4. Após a recriação de todos os nós, desative o complemento:

   gcloud container clusters update CLUSTER_NAME --update-addons=NetworkPolicy=DISABLED
   

Console

Para desativar a aplicação da política de rede em um cluster atual, faça o seguinte:

1. Acesse a página do Google Kubernetes Engine no Console do Google Cloud.

   Acessar o Google Kubernetes Engine

2. Na lista de clusters, clique no nome do cluster que você quer modificar.

3. Em Rede, no campo Política de rede, clique em Editar política de rede.

4. Desmarque a caixa de seleção Ativar política de rede para nós e clique em Salvar alterações.

5. Aguarde a aplicação das suas alterações e clique em Editar política de rede novamente.

6. Desmarque a caixa de seleção Ativar política de rede para mestre.

7. Clique em Salvar alterações.

API

Para desativar a aplicação da política de rede em um cluster atual, faça o seguinte:

1. Atualize o cluster para usar networkPolicy.enabled: false com a API setNetworkPolicy.

2. Verifique se todos os nós foram recriados usando a gcloud CLI:

   kubectl get nodes -l projectcalico.org/ds-ready=true
   

   Se a operação for bem-sucedida, a saída será semelhante a esta:

   No resources found
   

   Se a saída for semelhante a essa, será necessário aguardar o GKE terminar de atualizar os pools de nós:

   NAME                                             STATUS                     ROLES    AGE     VERSION
   gke-calico-cluster2-default-pool-bd997d68-pgqn   Ready,SchedulingDisabled   <none>   15m     v1.22.10-gke.600
   gke-calico-cluster2-np2-c4331149-2mmz            Ready                      <none>   6m58s   v1.22.10-gke.600
   

   Quando você desativa a aplicação obrigatória da política de rede, o GKE talvez deixe de atualizar os nós imediatamente se o cluster tiver uma janela de manutenção ou exclusão configurada. Para ver mais informações, consulte Atualização lenta do cluster.

3. Atualize o cluster para usar update.desiredAddonsConfig.NetworkPolicyConfig.disabled: true com a API updateCluster.

Criar uma política de rede

É possível criar uma política de rede usando a API Kubernetes Network Policy.

Para mais detalhes sobre como criar uma política de rede, consulte os tópicos a seguir na documentação do Kubernetes:

• Visão geral da política de rede
• Declarar política de rede

Política de rede e federação de identidade da carga de trabalho para o GKE

Se você usar a política de rede com a federação de identidade da carga de trabalho, precisará permitir a saída para os seguintes endereços IP para que seus pods possam se comunicar com o servidor de metadados do GKE.

• Para clusters que executam o GKE versão 1.21.0-gke.1000 e posterior, permita a saída para 169.254.169.252/32 na porta 988.
• Para clusters que executam versões anteriores ao GKE 1.21.0-gke.1000, permita a saída para 127.0.0.1/32 na porta 988.
• Para clusters que executam o GKE Dataplane V2, permita a saída para 169.254.169.254/32 na porta 80.

Se você não permitir a saída para esses endereços IP e portas, poderá enfrentar interrupções durante os upgrades automáticos.

Como migrar do Calico para o GKE Dataplane V2

Se você migrar as políticas de rede do Calico para o GKE Dataplane V2, considere as seguintes limitações:

• Não é possível usar um endereço IP de pod ou de serviço no campo ipBlock.cidr de um manifesto NetworkPolicy. Você precisa referenciar cargas de trabalho usando rótulos. Por exemplo, a seguinte configuração é inválida:

  - ipBlock:
      cidr: 10.8.0.6/32
  

• Não é possível especificar um campo ports.port vazio em um manifesto NetworkPolicy. Se você especificar um protocolo, também precisará especificar uma porta. Por exemplo, a seguinte configuração é inválida:

  ingress:
  - ports:
    - protocol: TCP
  

Como trabalhar com balanceadores de carga de aplicativo

Quando uma entrada é aplicada a um serviço para criar um balanceador de carga de aplicativo, você precisa configurar a política de rede aplicada aos pods atrás desse serviço para permitir os intervalos de IP apropriados da verificação de integridade do balanceador de carga de aplicativo. Se você estiver usando um balanceador de carga de aplicativo interno, também precisará configurar a política de rede para permitir a sub-rede somente proxy.

Se você não estiver usando o balanceamento de carga nativo de contêiner com grupos de endpoints da rede, as portas de um serviço podem encaminhar conexões para pods em outros nós, a menos que sejam impedidas de fazê-lo, definindo a configuração externalTrafficPolicy como Local na definição do Serviço. Se externalTrafficPolicy não estiver definido como Local, a política de rede também deverá permitir conexões de outros IPs de nó no cluster.

Inclusão de intervalos de IP do pod nas regras ipBlock

Para controlar o tráfego de pods específicos, sempre selecione pods por namespace ou identificadores usando os campos namespaceSelector e podSelector nas regras de entrada ou saída do NetworkPolicy. Não use o campo ipBlock.cidr para selecionar intencionalmente intervalos de endereços IP do pod, que são temporários por natureza. O projeto do Kubernetes não define explicitamente o comportamento do campo ipBlock.cidr quando ele inclui intervalos de endereços IP do pod. Especificar intervalos amplos de CIDR nesse campo, como 0.0.0.0/0 (que inclui os intervalos de endereços IP do pod), pode ter resultados inesperados em diferentes implementações da NetworkPolicy.

As seções a seguir descrevem como aa diferentes implementações de NetworkPolicy no GKE avaliam os intervalos de endereços IP que você especifica no campo ipBlock.cidr e como isso pode afetar os intervalos de endereços IP de pods que são inerentemente incluídos em intervalos CIDR amplos. Entender o comportamento diferente entre as implementações vai ajudar você a se preparar para os resultados ao migrar para outra implementação.

Comportamento do ipBlock no GKE Dataplane V2

Com a implementação do NetworkPolicy do GKE Dataplane V2, o tráfego de pods nunca é coberto por uma regra ipBlock. Portanto, mesmo que você defina uma regra ampla, como cidr: '0.0.0.0/0', ela não incluirá o tráfego de pods. Isso é útil porque permite, por exemplo, permitir que pods em um namespace recebam tráfego da Internet, sem também permitir o tráfego dos pods. Para incluir também o tráfego de pods, selecione os pods explicitamente usando um seletor extra de pod ou namespace nas definições de regra de entrada ou saída da NetworkPolicy.

Comportamento do ipBlock no Calico

Para a implementação da NetworkPolicy no Calico, as regras ipBlock cobrem o tráfego de pods. Com essa implementação, para configurar um intervalo CIDR amplo sem permitir o tráfego do pod, exclua explicitamente o intervalo CIDR do pod do cluster, como no exemplo a seguir:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-non-pod-traffic
spec:
  ingress:
  - from:
    - ipBlock:
      cidr: '0.0.0.0/0'
      except: ['POD_IP_RANGE']

Neste exemplo, POD_IP_RANGE é o intervalo de endereços IPv4 do pod do cluster, por exemplo, 10.95.0.0/17. Se você tiver vários intervalos de IP, eles poderão ser incluídos individualmente na matriz, por exemplo, ['10.95.0.0/17', '10.108.128.0/17'].

Solução de problemas

Os pods não conseguem se comunicar com o plano de controle em clusters que usam o Private Service Connect

Os pods em clusters do GKE que usam o Private Service Connect podem ter problemas de comunicação com o plano de controle caso a saída do pod para o endereço IP interno do plano de controle esteja restrita nas políticas de rede de saída.

Para minimizar esse problema, confira essas informações:

1. Descubra se o cluster usa o Private Service Connect. Para mais informações, consulte Clusters públicos com o Private Service Connect. Nos clusters que usam o Private Service Connect, cada plano de controle é atribuído a um endereço IP interno da sub-rede do nó do cluster.

2. Configure a política de saída do cluster para permitir o tráfego para o endereço IP interno do plano de controle.

   Para encontrar o endereço IP interno do plano de controle, faça o seguinte:

   gcloud

   Para procurar por privateEndpoint, execute o seguinte comando:

   gcloud container clusters describe CLUSTER_NAME
   

   Substitua CLUSTER_NAME pelo nome do cluster.

   Esse comando recupera o privateEndpoint do cluster especificado.

   Console

   1. Acesse a página Google Kubernetes Engine no console do Google Cloud.

      Acessar o Google Kubernetes Engine

   2. No painel de navegação, em Clusters, clique no cluster que tem o endereço IP interno que você quer encontrar.

   3. Em Noções básicas sobre o cluster, acesse Internal endpoint para conferir uma lista com o endereço IP interno.

   Depois de localizar privateEndpoint ou Internal endpoint, configure a política de saída do cluster a fim de permitir o tráfego para o endereço IP interno do plano de controle. Para saber mais, consulte Criar uma política de rede.

Atualização lenta do cluster

Quando você ativa ou desativa a aplicação obrigatória da política de rede em um cluster atual, o GKE talvez deixe de atualizar os nós imediatamente se o cluster tiver uma janela de manutenção ou exclusão configurada.

É possível fazer upgrade manual de um pool de nós definindo a sinalização --cluster-version para a mesma versão do GKE em que o plano de controle está em execução. Use a Google Cloud CLI para realizar essa operação. Para mais informações, consulte avisos sobre janelas de manutenção.

Pods implantados manualmente não programados

Quando você ativa a aplicação da política de rede no plano de controle do cluster existente, o GKE cancela a programação de qualquer pod de nó ip-masquerade-agent ou de calico que você implantou manualmente.

O GKE não reprograma esses pods até que a aplicação da política de rede esteja ativada nos nós do cluster e os nós sejam recriados.

Se você configurou uma janela ou exclusão de manutenção, isso pode causar uma interrupção estendida.

Para minimizar a duração dessa interrupção, é possível atribuir manualmente os seguintes rótulos aos nós do cluster:

• node.kubernetes.io/masq-agent-ds-ready=true
• projectcalico.org/ds-ready=true

A política de rede não está em vigor

Se uma NetworkPolicy não entrar em vigor, você poderá resolver os problemas seguindo estas etapas:

1. Confirme se a aplicação da política de rede está ativada. O comando a ser usado depende se o cluster tiver o GKE Dataplane V2 ativado.

   Se o cluster estiver com o GKE Dataplane V2 ativado, execute o seguinte comando:

   kubectl -n kube-system get pods -l k8s-app=cilium
   

   Se a saída estiver vazia, a aplicação da política de rede não estará ativada.

   Se o cluster do GKE Dataplane V2 não estiver ativado no cluster, execute o seguinte comando:

   kubectl get nodes -l projectcalico.org/ds-ready=true
   

   Se a saída estiver vazia, a aplicação da política de rede não estará ativada.

2. Verifique os rótulos do pod:

   kubectl describe pod POD_NAME
   

   Substitua POD_NAME pelo nome do pod.

   O resultado será assim:

   Labels:        app=store
                  pod-template-hash=64d9d4f554
                  version=v1
   

3. Confirme se os identificadores da política correspondem aos identificadores do pod:

   kubectl describe networkpolicy
   

   O resultado será assim:

   PodSelector: app=store
   

   Nesta saída, os rótulos app=store correspondem aos rótulos app=store da etapa anterior.

4. Verifique se há políticas de rede que selecionem suas cargas de trabalho:

   kubectl get networkpolicy
   

   Se a saída estiver vazia, nenhuma NetworkPolicy foi criada no namespace e nenhuma está selecionando suas cargas de trabalho. Se a saída não estiver vazia, verifique se a política seleciona as cargas de trabalho:

   kubectl describe networkpolicy
   

   O resultado será assim:

   ...
   PodSelector:     app=nginx
   Allowing ingress traffic:
      To Port: <any> (traffic allowed to all ports)
      From:
         PodSelector: app=store
   Not affecting egress traffic
   Policy Types: Ingress
   

Problemas conhecidos

Encerramento de pod do StatefulSet com o Calico

Os clusters do GKE com a política de rede da Calico ativada podem ter um problema em que um pod do StatefulSet descarta conexões atuais quando o pod é excluído. Depois que um pod entra no estado Terminating, a configuração terminationGracePeriodSeconds na especificação do pod não é respeitada e causa interrupções em outros aplicativos que têm uma conexão atual com o pod do StatefulSet. Saiba mais sobre esse problema no problema nº 4710 do Calico.

Esse problema afeta as seguintes versões do GKE:

• 1.18
• 1.19 a 1.19.16-gke.99
• 1.20 a 1.20.11-gke.1299
• 1.21 a 1.21.4-gke.1499

Para atenuar esse problema, faça upgrade do plano de controle do GKE para uma das seguintes versões:

• 1.19.16-gke.100 ou mais recente
• 1.20.11-gke.1300 ou mais recente
• 1.21.4-gke.1500 ou mais recente

Pod travado no estado containerCreating

Pode haver um cenário em que os clusters do GKE com a política de rede Calico ativada possam enfrentar um problema em que os pods ficam presos no estado containerCreating.

Na guia Eventos do pod, você encontrará uma mensagem semelhante à seguinte:

plugin type="calico" failed (add): ipAddrs is not compatible with
configured IPAM: host-local

Para atenuar esse problema, use o ipam host local para Calico em vez de calico-ipam em clusters do GKE.

A seguir

• Siga o tutorial Políticas de rede.

• Leia a documentação do Kubernetes sobre políticas de rede.

• Implementar abordagens comuns para restringir o tráfego usando políticas de rede.

• Como usar a geração de registros de política de rede.

• Use insights de segurança para conhecer outras formas de aumentar a infraestrutura.