Configure um gateway de NAT de saída

Este documento descreve como configurar um gateway NAT de saída para o Google Distributed Cloud. Este gateway fornece endereços IP SNAT determinísticos e persistentes para o tráfego de saída dos seus clusters. Quando executa cargas de trabalho que têm tráfego de utilizadores de saída (fora dos seus clusters), os seus clientes querem identificar este tráfego através de alguns endereços IP determinísticos. Isto permite que os seus clientes estabeleçam medidas de segurança baseadas em IP, como políticas de listas de autorizações.

Esta página destina-se a especialistas de redes que concebem e arquitetam a rede para a respetiva organização, e instalam, configuram e suportam o equipamento de rede. Para saber mais sobre as funções comuns e as tarefas de exemplo a que fazemos referência no Google Cloud conteúdo, consulte o artigo Funções e tarefas comuns de utilizadores do GKE.

O gateway NAT de saída é ativado através de dois recursos personalizados. Para um determinado espaço de nomes, o recurso personalizado NetworkGatewayGroup especifica endereços IP flutuantes que podem ser configurados na interface de rede de um nó escolhido para atuar como um gateway. O recurso personalizado EgressNatPolicy permite-lhe especificar políticas de encaminhamento de saída para controlar o tráfego no gateway de saída.

Se não configurar um gateway NAT de saída ou se o tráfego de saída não cumprir as regras de seleção de tráfego, o tráfego de saída de um determinado pod para um destino fora do cluster é mascarado para o endereço IP do nó onde o pod está a ser executado. Neste cenário, não existe garantia de que todo o tráfego de saída de um determinado Pod tenha o mesmo endereço IP de origem ou se faça passar pelo mesmo endereço IP do nó.

O gateway NAT de saída é uma oferta de rede avançada criada com base no Dataplane V2.

Como funciona o gateway NAT de saída

A lógica de seleção de tráfego de saída baseia-se num seletor de espaço de nomes, num seletor de pods e num conjunto de intervalos de endereços IP na notação de blocos CIDR. Para ilustrar como funciona o gateway NAT de saída, vamos considerar o fluxo de um pacote de um pod para um consumidor externo e a resposta correspondente. Suponha que a sub-rede do nó tem endereços IP no bloco CIDR 192.168.1.0/24.

O diagrama seguinte mostra a arquitetura de rede para o tráfego de saída através de um nó de gateway.

Diagrama da gateway NAT de saída para o Google Distributed Cloud

O fluxo de pacotes através do gateway NAT de saída pode ter o seguinte aspeto:

  1. O tráfego de saída é gerado a partir de um Pod com o endereço IP 10.10.10.1 num nó com o endereço IP 192.168.1.1.

    O endereço de destino do tráfego é um ponto final fora do cluster.

  2. Se o tráfego corresponder a uma regra de saída, o programa eBPF encaminha o tráfego de saída para o nó de gateway, em vez de o mascarar diretamente com o endereço IP do nó.

  3. O nó de gateway recebe o tráfego de saída.

  4. O nó de gateway oculta o endereço IP de origem do tráfego de origem, 10.10.10.1, com o endereço IP de saída de origem, 192.168.1.100 especificado no recurso personalizado EgressNATPolicy.

  5. O tráfego de retorno volta ao nó de gateway com o destino como 192.168.1.100.

  6. O nó de gateway corresponde ao conntrack do tráfego de retorno com o do tráfego de saída original e reescreve o endereço IP de destino como 10.10.10.1.

  7. 10.10.10.1 é tratado como tráfego no cluster, encaminhado para o nó original e entregue novamente no pod original.

Configure endereços IP flutuantes para o tráfego de nós

O recurso personalizado Network Gateway Group é um componente integrado do Google Distributed Cloud. O recurso gere uma lista de um ou mais endereços IP flutuantes a usar para o tráfego de saída dos nós no seu cluster. Os nós participantes são determinados pelo espaço de nomes especificado. O grupo de gateway de rede disponibiliza um endereço IP flutuante em todos os momentos com base no melhor esforço. Se um nó que usa um endereço IP flutuante ficar inativo, o operador de rede avançado move o endereço IP atribuído para o nó seguinte disponível. Todo o tráfego de saída da carga de trabalho que usa esse endereço IP também é movido.

Inclua os detalhes do grupo de gateways de rede (anotação e especificação) no ficheiro de configuração do cluster quando criar um novo cluster 1.33.100-gke.89.

Crie o recurso personalizado NetworkGatewayGroup

Ativa o grupo de gateways de rede definindo o campo spec.clusterNetwork.advancedNetworking como true no ficheiro de configuração do cluster quando cria um cluster, conforme mostrado no exemplo seguinte:

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  namespace: cluster-cluster1
spec:
  clusterNetwork:
    ...
    advancedNetworking: true
    ...

Quando criar o recurso personalizado NetworkGatewayGroup, defina o respetivo espaço de nomes como o espaço de nomes do cluster e especifique uma lista de endereços IP flutuantes, conforme mostrado no exemplo seguinte:

kind: NetworkGatewayGroup
apiVersion: networking.gke.io/v1
metadata:
  namespace: cluster-cluster1
  name: default
spec:
  floatingIPs:
  - 192.168.1.100
  - 192.168.1.101
  - 192.168.1.102

O operador de rede avançada atribui os IPs flutuantes aos nós com base nos seguintes critérios:

  • Sub-rede do nó: o endereço IP flutuante tem de corresponder à sub-rede do nó.
  • Função do nó (plano de controlo, trabalhador): os nós trabalhadores têm precedência sobre os nós do plano de controlo ao atribuir endereços IP flutuantes.
  • Se um nó tem um endereço IP flutuante: o operador dá prioridade às atribuições a nós que ainda não têm um IP flutuante atribuído.

O mapeamento de endereços/nós pode ser encontrado na secção status quando recebe o objeto NetworkGatewayGroup. Tenha em atenção que o objeto NetworkGatewayGroup está no espaço de nomes kube-system. Se um nó de gateway estiver inativo, o operador de rede avançada atribui os endereços IP flutuantes ao nó seguinte disponível.

Valide a configuração do gateway

Depois de aplicar as alterações de configuração da gateway, pode usar kubectl para verificar o estado da gateway e obter os endereços IP flutuantes especificados para a gateway.

  1. Use o seguinte comando para verificar o estado do NetworkGatewayGroup e ver como os endereços IP flutuantes são atribuídos:

    kubectl -n kube-system get networkgatewaygroups.networking.gke.io default -o yaml

    A resposta para um cluster com dois nós, worker1 e worker2, pode ter o seguinte aspeto:

    kind: NetworkGatewayGroup
apiVersion: networking.gke.io/v1
metadata:
  namespace: kube-system
  name: default
spec:
  floatingIPs:
  - 192.168.1.100
  - 192.168.1.101
  - 192.168.1.102
status:
  nodes:
    worker1: Up
    worker2: Up // Or Down
  floatingIPs:
    192.168.1.100: worker1
    192.168.1.101: worker2
    192.168.1.102: worker1

Defina regras de seleção de tráfego

O recurso personalizado EgressNATPolicy especifica regras de seleção de tráfego e atribui um endereço IP determinístico para o tráfego de saída que sai do cluster. Quando especificar o recurso personalizado, egress (com, pelo menos, uma regra), destinationCIDRs e egressSourceIP são todos obrigatórios.

Use kubectl apply para criar o EgressNATPolicy recurso personalizado. As secções seguintes fornecem detalhes e exemplos para definir a especificação.

Especifique regras de encaminhamento de saída

O recurso personalizado EgressNatPolicy permite especificar as seguintes regras para o tráfego de saída:

  • Tem de especificar uma ou mais regras de seleção de tráfego de saída na secção egress.

    • Cada regra consiste num podSelector e num namespaceSelector.
    • A seleção baseia-se numa etiqueta de espaço de nomes, namespaceSelector.matchLabels.user, e numa etiqueta de agrupamento, podSelector.matchLabels.role.
    • Se um Pod corresponder a qualquer uma das regras (a correspondência usa uma relação OR), é selecionado para tráfego de saída.

  • Especifique os endereços de destino permitidos na secção destinationCIDRs.

    • destinationCIDRs aceita uma lista de blocos CIDR.
    • Se o tráfego de saída de um Pod tiver um endereço IP de destino que se enquadre no intervalo de qualquer um dos blocos CIDR especificados, é selecionado para tráfego de saída.

No exemplo seguinte, o tráfego de saída de um pod é permitido quando os seguintes critérios são cumpridos:

  • O pod está etiquetado com role: frontend.
  • O pod está num espaço de nomes etiquetado como user: alice ou user: paul.
  • O pod está a comunicar com endereços IP no bloco CIDR 8.8.8.0/24.
kind: EgressNATPolicy
apiVersion: networking.gke.io/v1
metadata:
  name: egress
spec:
  sources:
  - namespaceSelector:
      matchLabels:
        user: alice
    podSelector:
      matchLabels:
        role: frontend
  - namespaceSelector:
      matchLabels:
        user: paul
    podSelector:
      matchLabels:
        role: frontend
  action: SNAT
  destinations:
    - cidr: 8.8.8.0/24
  gatewayRef:
    name: default
    namespace: kube-system

Para mais informações sobre a utilização de etiquetas, consulte o artigo Etiquetas e seletores na documentação do Kubernetes.

Obtenha um endereço IP de origem para o tráfego de saída

O recurso personalizado (política) EgressNATPolicyusa os valores gatewayRef.name e gatewayRef.namespace para encontrar um objeto NetworkGatewayGroup (gateway). A política usa um dos endereços IP flutuantes do gateway como o endereço IP de origem para o tráfego de saída. Se existirem vários endereços IP flutuantes no gateway correspondente, a política usa o primeiro endereço IP na lista floatingIPs e ignora todos os outros endereços IP. Para o gateway de exemplo, o primeiro endereço na lista floatingIPs é 192.168.1.100. A existência de campos ou valores inválidos na secção gatewayRef resulta na falha da aplicação do objeto de política.

Várias políticas de saída e vários objetos de gateway

Conforme descrito na secção anterior, cada objeto egressNATPolicy (política) usa o primeiro endereço IP na lista floatingIPs do objeto de gateway que corresponde a gatewayRef.name e gatewayRef.namespace. Pode criar várias políticas e, se pretender usar endereços IP diferentes, tem de criar vários objetos NetworkGatewayGroup e referi-los respetivamente.

Cada recurso NetworkGatewayGroup tem de conter endereços IP flutuantes exclusivos. Para configurar vários objetos EgressNATPolicy para usar o mesmo endereço IP, use o mesmo gatewayRef.name e gatewayRef.namespace para ambos.

Para configurar várias políticas de saída e vários objetos de gateway:

  1. Crie objetos de gateway no namespace kube-system para gerir cada endereço IP flutuante. Normalmente, cada política de saída deve ter um objeto de gateway correspondente para garantir que o endereço IP correto é atribuído.

    Em seguida, valide cada objeto de gateway com kubectl para obter o estado de atribuição dos endereços IP flutuantes:

    kind: NetworkGatewayGroup
apiVersion: networking.gke.io/v1
metadata:
  namespace: kube-system
  name: gateway1
spec:
  floatingIPs:
  - 192.168.1.100
status:
  ...
  floatingIPs:
    192.168.1.100: worker1
---
kind: NetworkGatewayGroup
apiVersion: networking.gke.io/v1
metadata:
  namespace: kube-system
  name: gateway2
spec:
  floatingIPs:
  - 192.168.1.101
status:
  ...
  floatingIPs:
    192.168.1.101: worker2
---
kind: NetworkGatewayGroup
apiVersion: networking.gke.io/v1
metadata:
  namespace: kube-system
  name: gateway3
spec:
  floatingIPs:
  - 192.168.1.102
status:
  ...
  floatingIPs:
    192.168.1.102: worker1

  2. Crie várias políticas que façam referência aos objetos de gateway, como gateway1 criados no passo anterior:

    kind: EgressNATPolicy
apiVersion: networking.gke.io/v1
metadata:
  name: egress1
spec:
  ...
  gatewayRef:
    name: gateway1
    namespace: kube-system
---
kind: EgressNATPolicy
apiVersion: networking.gke.io/v1
metadata:
  name: egress2
spec:
  ...
  gatewayRef:
    name: gateway2
    namespace: kube-system
---
kind: EgressNATPolicy
apiVersion: networking.gke.io/v1
metadata:
  name: egress3
spec:
  ...
  gatewayRef:
    name: gateway3
    namespace: kube-system

(Opcional) Especifique os nós nos quais colocar endereços IP flutuantes

Os recursos NetworkGatewayGroup suportam seletores de nós. Para especificar um subconjunto de nós que são considerados para alojar um endereço IP flutuante, pode adicionar o seletor de nós ao objeto NetworkGatewayGroup, conforme mostrado no seguinte exemplo:

kind: NetworkGatewayGroup
apiVersion: networking.gke.io/v1
metadata:
  namespace: cluster-cluster1
  name: default
spec:
  floatingIPs:
  - 192.168.1.100
  - 192.168.1.101
  - 192.168.1.102
  nodeSelector:
    node-type: "egressNat"

O seletor de nós corresponde aos nós que têm a etiqueta especificada e apenas estes nós são considerados para alojar um endereço IP flutuante. Se especificar vários seletores, a respetiva lógica é aditiva, pelo que um nó tem de corresponder a todas as etiquetas para ser considerado para alojar um endereço IP flutuante. Se não existirem muitos nós com etiquetas correspondentes, um seletor de nós pode reduzir as qualidades de alta disponibilidade (HA) do posicionamento do endereço IP flutuante.

Regras de seleção de tráfego de saída e políticas de rede

O gateway NAT de saída é compatível com APIs de políticas de rede. As políticas de rede são avaliadas primeiro e têm precedência sobre as regras de seleção de tráfego do gateway NAT de saída. Por exemplo, se o tráfego de saída acionar uma política de rede que resulte na eliminação do pacote, as regras do gateway de saída não verificam o pacote. Só quando a política de rede permite que o pacote saia, as regras de seleção de tráfego de saída são avaliadas para decidir como o tráfego é processado, quer através do gateway NAT de saída ou mascarando diretamente com o endereço IP do nó onde o pod está a ser executado.

Limitações

As limitações atuais do gateway de NAT de saída incluem:

  • O gateway NAT de saída só está ativado para o modo IPv4.

  • Os endereços IP de saída têm de estar no mesmo domínio da camada 2 com os endereços IP dos nós.