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

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.

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 CLI do Google Cloud para essa tarefa, instale e inicialize a gcloud CLI. Se você instalou a CLI gcloud anteriormente, instale a versão mais recente executando o comando gcloud components update. Talvez as versões anteriores da CLI gcloud não sejam compatíveis com a execução dos comandos neste documento.
* Verifique se você tem um cluster do Autopilot ou Standard. Se precisar de um, crie um cluster do Autopilot.

Requisitos e limitações

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

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 necessário do cluster para executar a aplicação da política de rede é de três instâncias e2-medium ou uma instância de tipo de máquina com mais de uma vCPU alocável. Consulte Problemas conhecidos do GKE para mais detalhes.
  • 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.
  • O Cilium ou o Calico não gerenciam pods que definem hostNetwork: true, e as políticas de rede não podem governar esses pods.

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

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 Standard pode ser ativada usando a CLI gcloud, o console 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.

Essa mudança exige a recriação dos nós, o que pode causar interrupções nas cargas de trabalho em execução. Para mais detalhes sobre essa mudança específica, encontre a linha correspondente na tabela Alterações manuais que recriam os nós usando uma estratégia de upgrade de nós e respeitando as políticas de manutenção. Para saber mais sobre atualizações de nós, consulte Planejar interrupções de atualização de nós.

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 no cluster, execute as seguintes tarefas:

    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

    3. Console

    Para ativar a aplicação da política de rede no cluster:

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

      Acessar o Google Kubernetes Engine

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

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

    4. Na caixa de diálogo Editar política de rede, marque a caixa de seleção Ativar a política de rede do Kubernetes no Calico para o plano de controle e clique em Salvar alterações.

    5. Aguarde as mudanças serem aplicadas. Para acompanhar o progresso, clique em Notificações no canto superior direito do console.

    6. No campo Política de rede do Kubernetes no Calico, clique em Editar política de rede novamente.

    7. Na caixa de diálogo Editar política de rede, marque a caixa de seleção Ativar a política de rede do Kubernetes no Calico para nós.

    8. 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 CLI gcloud, o console 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.

Essa mudança exige a recriação dos nós, o que pode causar interrupções nas cargas de trabalho em execução. Para mais detalhes sobre essa mudança específica, encontre a linha correspondente na tabela Alterações manuais que recriam os nós usando uma estratégia de upgrade de nós e respeitando as políticas de manutenção. Para saber mais sobre atualizações de nós, consulte Planejar interrupções de atualização de nós.

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

    5. Console

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

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

      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:

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 HTTP(S), você precisa garantir que sua política de rede permita o tráfego dos intervalos de endereços IP de verificação de integridade do balanceador de carga de aplicativo HTTP(S).

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 endereços IP 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'].

Controlar o comportamento da política de rede com externalTrafficPolicy

A configuração externalTrafficPolicy do seu serviço influencia a forma como o Kubernetes aplica as políticas de rede. Essa configuração determina o endereço IP de origem que seus pods veem para o tráfego de entrada, o que pode afetar a forma como o Kubernetes avalia regras de NetworkPolicy.

externalTrafficPolicytem dois valores possíveis:

  • Cluster:quando externalTrafficPolicy é definido como Cluster, o pod de destino vê o endereço IP de origem como o endereço IP do nó em que o tráfego é recebido inicialmente. Se você tiver uma NetworkPolicy que nega o tráfego com base em endereços IP de clientes, mas não inclui os endereços IP de nós remotos, ela poderá bloquear involuntariamente o tráfego externo dos clientes externos especificados nas regras da política. Para evitar isso, crie uma política que permita o tráfego de todos os nós no cluster. No entanto, essa política permite o tráfego de qualquer cliente externo.

  • Local:quando externalTrafficPolicy é definido como Local, o pod vê o endereço IP de origem como o endereço IP do cliente original. Isso permite um controle mais granular com políticas de rede, já que é possível definir regras com base nos endereços IP reais dos clientes.

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:

  1. Confirme se o cluster usa o Private Service Connect. Em clusters que usam o Private Service Connect, se você usar a flag master-ipv4-cidr ao criar a sub-rede, o GKE vai atribuir a cada plano de controle um endereço IP interno dos valores definidos em master-ipv4-cidr. Caso contrário, o GKE usa a sub-rede do nó do cluster para atribuir a cada plano de controle um endereço IP interno.

  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 do Google Kubernetes Engine no Google Cloud console.

      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