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

Requisitos e limitações

Os requisitos e limitações a seguir se aplicam aos clusters do Autopilot e do Standard: 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.

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.

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.

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:

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