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.

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 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 seguintes requisitos e limitações se aplicam:

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

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.

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

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.

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:

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

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:

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.

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

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