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

Esta página explica como controlar a comunicação entre os pods e os serviços do cluster através da aplicação de políticas de rede do GKE.

Também pode controlar o tráfego de saída dos pods para qualquer ponto final ou serviço fora do cluster através de políticas de rede de nome de domínio totalmente qualificado (FQDN). Para mais informações, consulte o artigo Controle a comunicação entre pods e serviços através de FQDNs.

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

A aplicação da política de rede permite-lhe criar políticas de rede do Kubernetes no seu cluster. Por predefinição, todos os pods num cluster podem comunicar livremente entre si. As políticas de rede criam regras de firewall ao nível do pod que determinam que pods e serviços podem aceder uns aos outros no seu cluster.

A definição da política de rede ajuda a ativar funcionalidades como a defesa em profundidade quando o cluster está a publicar uma aplicação de vários níveis. Por exemplo, pode criar uma política de rede para garantir que um serviço de front-end comprometido na sua aplicação não consegue comunicar diretamente com um serviço de faturação ou contabilidade vários níveis abaixo.

A política de rede também pode facilitar o alojamento de dados de vários utilizadores em simultâneo pela sua aplicação. Por exemplo, pode fornecer multi-tenancy segura definindo um modelo de inquilino por espaço de nomes. Num modelo deste tipo, as regras da política de rede podem garantir que os pods e os serviços num determinado espaço de nomes não podem aceder a outros pods nem serviços num espaço de nomes diferente.

Antes de começar

Antes de começar, certifique-se de que realizou as seguintes tarefas:

  • Ative a API Google Kubernetes Engine.
    • Ative a API Google Kubernetes Engine
  • Se quiser usar a CLI gcloud para esta tarefa, instale-a e, em seguida, inicialize-a. Se instalou anteriormente a CLI gcloud, execute gcloud components update para obter a versão mais recente.
* Certifique-se de que tem um cluster do Autopilot ou Standard existente. Se precisar de um, crie um cluster do Autopilot.

Requisitos e limitações

Os seguintes requisitos e limitações aplicam-se aos clusters do modo automático e padrão:

Os seguintes requisitos e limitações aplicam-se apenas aos clusters padrão:

  • Tem de permitir a saída para o servidor de metadados se usar a política de rede com a Workload Identity Federation para o GKE.
  • A ativação da aplicação da política de rede aumenta a pegada de memória do processo kube-system em aproximadamente 128 MB e requer aproximadamente 300 milicores da CPU. Isto significa que, se ativar as políticas de rede para um cluster existente, pode ter de aumentar o tamanho do cluster para continuar a executar as cargas de trabalho agendadas.
  • A ativação da aplicação da política de rede requer que os seus nós sejam recriados. Se o seu cluster tiver uma janela de manutenção ativa, os nós não são recriados automaticamente até à janela de manutenção seguinte. Se preferir, pode atualizar manualmente o cluster em qualquer altura.
  • O tamanho mínimo obrigatório do cluster para executar a aplicação da política de rede é de três instâncias e2-medium ou uma instância do tipo de máquina com mais de 1 vCPU atribuível. Consulte os problemas conhecidos do GKE para mais detalhes.
  • A política de rede não é suportada para clusters cujos nós são instâncias f1-micro ou g1-small, uma vez que os requisitos de recursos são demasiado elevados.
  • O Cilium ou o Calico não gerem pods que definam hostNetwork: true e as políticas de rede não podem reger estes pods.

Para mais informações sobre os tipos de máquinas de nós e os recursos atribuíveis, consulte o artigo Arquitetura de cluster padrão: nós.

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

A aplicação da política de rede está ativada por predefinição para clusters do Autopilot, pelo que pode avançar para a secção Criar uma política de rede.

Pode ativar a aplicação de políticas de rede no modo padrão através da CLI gcloud, da Google Cloud consola ou da API GKE.

A aplicação da política de rede está integrada no GKE Dataplane V2. Não precisa de ativar a aplicação de políticas de rede em clusters que usam o GKE Dataplane V2.

Esta alteração requer a recriação dos nós, o que pode causar interrupções nas cargas de trabalho em execução. Para ver detalhes acerca desta alteração específica, encontre a linha correspondente na tabela alterações manuais que recriam os nós através de uma estratégia de atualização de nós e respeitam as políticas de manutenção. Para saber mais sobre as atualizações de nós, consulte o artigo Planeamento de interrupções de atualizações 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 seu cluster, execute as seguintes tarefas:

    1. Execute o seguinte comando para ativar o suplemento:

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

      Substitua CLUSTER_NAME pelo nome do cluster.

    2. Execute o seguinte comando para ativar a aplicação da política de rede no seu cluster, o que, por sua vez, recria os conjuntos 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. Consola

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

    1. Aceda à página do Google Kubernetes Engine na Google Cloud consola.

      Aceda ao Google Kubernetes Engine

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

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

    4. Na caixa de diálogo Editar política de rede, selecione a caixa de verificação Ativar política de rede do Kubernetes do Calico para o plano de controlo e clique em Guardar alterações.

    5. Aguarde a aplicação das alterações. Para monitorizar o progresso, clique em Notificações no canto superior direito da consola.

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

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

    8. Clique em Guardar alterações.

    API

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

    1. Especifique o objeto networkPolicy no objeto cluster que fornece a projects.zones.clusters.create ou projects.zones.clusters.update.

    2. O objeto networkPolicy requer uma enumeração que especifique que fornecedor de políticas de rede usar e um valor booleano que especifique se deve ativar a política de rede. Se ativar a política de rede, mas não definir o fornecedor, os comandos create e update devolvem um erro.

Desative a aplicação da política de rede num cluster padrão

Pode desativar a aplicação da política de rede através da CLI gcloud, da Google Cloud consola ou da API GKE. Não pode desativar a aplicação da política de rede em clusters do Autopilot ou clusters que usam o GKE Dataplane V2.

Esta alteração requer a recriação dos nós, o que pode causar interrupções nas cargas de trabalho em execução. Para ver detalhes acerca desta alteração específica, encontre a linha correspondente na tabela alterações manuais que recriam os nós através de uma estratégia de atualização de nós e respeitam as políticas de manutenção. Para saber mais sobre as atualizações de nós, consulte o artigo Planeamento de interrupções de atualizações 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 da política de rede, realize as seguintes tarefas:

    1. Desative a aplicação 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 este comando, o GKE recria os pools de nós do cluster com a aplicação 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, o resultado é semelhante ao seguinte:

    No resources found

    Se o resultado for semelhante ao seguinte, tem de aguardar que o GKE termine a atualização dos grupos 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 desativa a aplicação da política de rede, o GKE pode não atualizar os nós imediatamente se o cluster tiver uma janela de manutenção ou uma exclusão configurada. Para mais informações, consulte o artigo O cluster demora a ser atualizado.

  4. Depois de todos os nós serem recriados, desative o suplemento:

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

    5. Consola

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

    1. Aceda à página do Google Kubernetes Engine na Google Cloud consola.

      Aceda ao Google Kubernetes Engine

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

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

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

    5. Aguarde que as alterações sejam aplicadas e, de seguida, clique novamente em Editar política de rede.

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

    7. Clique em Guardar alterações.

    API

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

    1. Atualize o cluster para usar o networkPolicy.enabled: false através da API setNetworkPolicy.

    2. Verifique se todos os nós foram recriados através da CLI gcloud:

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

      Se a operação for bem-sucedida, o resultado é semelhante ao seguinte:

      No resources found

      Se o resultado for semelhante ao seguinte, tem de aguardar que o GKE termine a atualização dos grupos 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 desativa a aplicação da política de rede, o GKE pode não atualizar os nós imediatamente se o cluster tiver uma janela de manutenção ou uma exclusão configurada. Para mais informações, consulte o artigo O cluster demora a ser atualizado.

    3. Atualize o cluster para usar o update.desiredAddonsConfig.NetworkPolicyConfig.disabled: true através da API updateCluster.

Crie uma política de rede

Pode criar uma política de rede através da API Network Policy do Kubernetes.

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

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

Se usar a política de rede com a Workload Identity Federation para o GKE, tem de permitir a saída para os seguintes endereços IP para que os seus pods possam comunicar com o servidor de metadados do GKE.

  • Para clusters com a versão 1.21.0-gke.1000 e posteriores do GKE, permita a saída para 169.254.169.252/32 na porta 988.
  • Para clusters que executam versões do GKE anteriores a 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 não permitir a saída para estes endereços IP e portas, pode ter interrupções durante as atualizações automáticas.

Migrar do Calico para o GKE Dataplane V2

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

  • Não pode usar um endereço IP de serviço ou de agrupamento no campo ipBlock.cidr de um manifesto NetworkPolicy. Tem de fazer referência às cargas de trabalho através de etiquetas. Por exemplo, a seguinte configuração é inválida:

    - ipBlock:
    cidr: 10.8.0.6/32

  • Não pode especificar um campo ports.port vazio num manifesto NetworkPolicy. Se especificar um protocolo, também tem de especificar uma porta. Por exemplo, a configuração seguinte é inválida:

    ingress:
- ports:
  - protocol: TCP

Trabalhar com balanceadores de carga de aplicações

Quando um Ingress é aplicado a um serviço para criar um balanceador de carga de HTTP(S), tem de garantir que a sua política de rede permite o tráfego dos intervalos de endereços IP de verificação de funcionamento do balanceador de carga de aplicações de HTTP(S).

Se não estiver a usar o balanceamento de carga nativo do contentor com grupos de pontos finais da rede, as portas dos nós de um serviço podem encaminhar ligações para pods noutros nós, a menos que isso seja impedido definindo externalTrafficPolicy como Local na definição do serviço. Se externalTrafficPolicy não estiver definido como Local, a política de rede também tem de permitir ligações de outros endereços IP de nós no cluster.

Inclusão de intervalos de IP de pods em regras ipBlock

Para controlar o tráfego de determinados pods, selecione sempre os pods pelo respetivo espaço de nomes ou etiquetas de pods através dos campos namespaceSelector e podSelector nas regras de entrada ou saída da NetworkPolicy. Não use o campo ipBlock.cidr para selecionar intencionalmente intervalos de endereços IP de pods, que são efémeros por natureza. O projeto Kubernetes não define explicitamente o comportamento do campo ipBlock.cidr quando inclui intervalos de endereços IP de pods. A especificação de intervalos CIDR amplos neste campo, como 0.0.0.0/0 (que incluem os intervalos de endereços IP do pod), pode ter resultados inesperados em diferentes implementações de NetworkPolicy.

As secções seguintes descrevem como as diferentes implementações de NetworkPolicy no GKE avaliam os intervalos de endereços IP que especifica no campo ipBlock.cidr e como isso pode afetar os intervalos de endereços IP de pods que estão inerentemente incluídos em intervalos CIDR amplos. Compreender o comportamento diferente entre as implementações ajuda a preparar-se para os resultados quando migrate para outra implementação.

Comportamento de 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. Por conseguinte, mesmo que defina uma regra abrangente, como cidr: '0.0.0.0/0', esta não inclui o tráfego de pods. Isto é útil, pois permite-lhe, por exemplo, permitir que os pods num espaço de nomes recebam tráfego da Internet sem também permitir tráfego de pods. Para também incluir o tráfego de agrupamentos, selecione agrupamentos explicitamente através de um agrupamento ou um seletor de espaço de nomes adicional nas definições de regras de entrada ou saída da NetworkPolicy.

Comportamento do ipBlock no Calico

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

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 tiver vários intervalos de IPs, estes podem ser incluídos individualmente na matriz, por exemplo ['10.95.0.0/17', '10.108.128.0/17'].

Controle o comportamento da política de rede com externalTrafficPolicy

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

externalTrafficPolicytem dois valores possíveis:

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

  • Local: quando externalTrafficPolicy está definido como Local, o pod vê o endereço IP de origem como o endereço IP do cliente original. Isto permite um controlo mais detalhado com as políticas de rede, uma vez que pode definir regras com base nos endereços IP reais do cliente.

Resolução de problemas

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

Os pods em clusters do GKE que usam o Private Service Connect podem ter um problema de comunicação com o plano de controlo se a saída do pod para o endereço IP interno do plano de controlo estiver restrita nas políticas de rede de saída.

Para mitigar este problema:

  1. Confirme se o seu cluster usa o Private Service Connect. Em clusters que usam o Private Service Connect, se usar a flag master-ipv4-cidr ao criar a sub-rede, o GKE atribui a cada plano de controlo um endereço IP interno a partir dos valores que definiu em master-ipv4-cidr. Caso contrário, o GKE usa a sub-rede do nó do cluster para atribuir a cada plano de controlo 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 controlo.

    Para encontrar o endereço IP interno do plano de controlo:

    gcloud

    Para procurar privateEndpoint, execute o seguinte comando:

    gcloud container clusters describe CLUSTER_NAME

    Substitua CLUSTER_NAME pelo nome do cluster.

    Este comando obtém o privateEndpoint do cluster especificado.

    Consola

    1. Aceda à página do Google Kubernetes Engine na Google Cloud consola.

      Aceda ao Google Kubernetes Engine

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

    3. Em Noções básicas do cluster, navegue até Internal endpoint, onde o endereço IP interno é apresentado.

    Assim que conseguir localizar o privateEndpoint ou o Internal endpoint, configure a política de saída do cluster para permitir o tráfego para o endereço IP interno do plano de controlo. Para mais informações, consulte Crie uma política de rede.

Atualização lenta do cluster

Quando ativa ou desativa a aplicação da política de rede num cluster existente, o GKE pode não atualizar os nós imediatamente se o cluster tiver uma janela de manutenção ou uma exclusão configurada.

Pode atualizar manualmente um conjunto de nós definindo a flag --cluster-version para a mesma versão do GKE que o plano de controlo está a executar. Tem de usar a Google Cloud CLI para realizar esta operação. Para mais informações, consulte ressalvas para janelas de manutenção.

Pods implementados manualmente não agendados

Quando ativa a aplicação de políticas de rede no plano de controlo do cluster existente, o GKE anula a programação de todos os pods ip-masquerade-agent ou calico node que implementou manualmente.

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

Se tiver configurado uma janela de manutenção ou uma exclusão, isto pode causar uma interrupção prolongada.

Para minimizar a duração desta interrupção, pode atribuir manualmente as seguintes etiquetas 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á a ter efeito

Se uma NetworkPolicy não estiver a ser aplicada, pode resolver o problema através dos seguintes passos:

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

    Se o seu cluster tiver 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 está ativada.

    Se o cluster não tiver o GKE Dataplane V2 ativado, 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 está ativada.

  2. Verifique as etiquetas do pod:

    kubectl describe pod POD_NAME

    Substitua POD_NAME pelo nome do pod.

    O resultado é semelhante ao seguinte:

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

  3. Confirme que as etiquetas na política correspondem às etiquetas no Pod:

    kubectl describe networkpolicy

    O resultado é semelhante ao seguinte:

    PodSelector: app=store

    Neste resultado, as etiquetas app=store correspondem às etiquetas app=store do passo anterior.

  4. Verifique se existem políticas de rede a selecionar as suas cargas de trabalho:

    kubectl get networkpolicy

    Se o resultado estiver vazio, não foi criada nenhuma NetworkPolicy no espaço de nomes e nada está a selecionar as suas cargas de trabalho. Se o resultado não estiver vazio, verifique se a política seleciona as suas cargas de trabalho:

    kubectl describe networkpolicy

    O resultado é semelhante ao seguinte:

    ...
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

Terminação de pods StatefulSet com Calico

Os clusters do GKE com a política de rede Calico ativada podem ter um problema em que um pod StatefulSet elimina as ligações existentes quando o pod é eliminado. Depois de um pod entrar no estado Terminating, a configuração terminationGracePeriodSeconds na especificação do pod não é respeitada e causa interrupções para outras aplicações que tenham uma ligação existente com o pod StatefulSet. Para mais informações sobre este problema, consulte o problema n.º 4710 do Calico.

Este 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 mitigar este problema, atualize o plano de controlo do GKE para uma das seguintes versões:

  • 1.19.16-gke.100 ou posterior
  • 1.20.11-gke.1300 ou posterior
  • 1.21.4-gke.1500 ou posterior

Agrupamento bloqueado no estado containerCreating

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

No separador Eventos do podcast, é apresentada uma mensagem semelhante à seguinte:

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

Para mitigar este problema, use o IPAM local do anfitrião para o Calico em vez do calico-ipam nos clusters do GKE.

O que se segue?