Como configurar um gateway NAT de saída

Com o Google Distributed Cloud, é possível configurar a conversão de endereços de rede de origem (SNAT) para que determinado tráfego de saída do cluster de usuário receba um endereço IP de origem previsível.

Neste documento, mostramos como configurar um gateway NAT de saída para um cluster de usuário.

Cuidado: não é possível fazer upgrade de clusters da versão 1.8.x ou 1.9.x que tenham o Anthos Network Gateway ativado para qualquer versão posterior. Por exemplo, não é possível fazer upgrade de um cluster de versão 1.9.0 com o Anthos Network Gateway ativado para a versão 1.9.x. Também não é possível fazer upgrade para a versão 1.10. Só será possível fazer upgrade de clusters que tenham o Anthos Network Gateway ativado se tiverem sido criados na versão 1.10 ou mais recente. Exclua um cluster de versão 1.8.x ou 1.9.x e recrie-o seguindo as instruções deste documento.

Introdução

Às vezes, você tem pods em execução em um cluster de usuário que precisa enviar pacotes para componentes em execução na organização, mas fora do cluster. Projete esses componentes externos para que eles filtrem o tráfego de rede de entrada de acordo com um conjunto de endereços IP de origem conhecidos.

Veja alguns cenários:

• Você tem um firewall em frente a um banco de dados que permite acesso apenas por endereço IP. E a equipe que gerencia o firewall do banco de dados é diferente da equipe que gerencia o cluster de usuário.

• As cargas de trabalho no seu cluster de usuário precisam acessar uma API de terceiros pela Internet. Por motivos de segurança, o provedor da API autentica e autoriza o tráfego usando o endereço IP como a identidade.

Com um gateway NAT de saída, é possível ter um controle refinado sobre os endereços IP de origem usados para o tráfego de rede que sai de um cluster.

Preços

Não há cobrança pelo uso desse recurso durante a visualização.

Como funciona um gateway NAT de saída

Normalmente, quando um pod envia um pacote para fora do cluster, o pacote é convertido em SNAT com o endereço IP do nó em que o pod está sendo executado.

Quando um gateway NAT de saída está em vigor, é possível especificar que determinados pacotes de saída sejam enviados primeiro a um nó de gateway dedicado. A interface de rede no nó de gateway é configurada com dois endereços IP: o IP principal e um de origem de saída.

Quando um pacote selecionado para usar o gateway NAT de saída, ele sai do cluster do nó de gateway e é convertido SNAT com o endereço IP de origem de saída configurado na interface de rede.

O diagrama a seguir ilustra o fluxo de pacotes:

No diagrama anterior, é possível ver o fluxo de um pacote que é enviado do pod.

1. Em um nó com o endereço IP 192.168.1.1, um pod com endereço IP 10.10.10.1 gera um pacote de saída.

2. O pacote corresponde a uma regra de saída. Por isso, ele é encaminhado ao nó de gateway.

3. O nó de gateway altera o endereço IP de origem para 192.168.1.100 e envia o pacote do cluster.

4. O tráfego de retorno retorna ao nó de gateway com o destino 192.168.1.100.

5. O nó de gateway usa o conntrack para modificar o endereço IP de destino para 10.10.10.1.

6. O pacote é tratado como tráfego no cluster e encaminhado ao nó original e entregue de volta ao pod original.

Perfis

Este tópico se refere a dois perfis:

• Administrador do cluster. Essa pessoa cria um cluster de usuário e especifica endereços IP flutuantes a serem usados pelo gateway de rede do Anthos.

• Desenvolvedor. Essa pessoa executa cargas de trabalho no cluster de usuário e cria políticas de saída.

Ativar gateway NAT de saída

Esta seção é destinada aos administradores de cluster.

Para configurar um gateway NAT de saída, use os campos enableDataplaneV2 e advancedNetworking no arquivo de configuração do cluster de usuário e crie um ou mais objetos NetworkGatewayGroup.

No arquivo de configuração do cluster, defina estes campos como true:

enableDataplaneV2: true
...
advancedNetworking: true

Criar o cluster de usuário.

Especificar endereços IP flutuantes

Esta seção é destinada aos administradores de cluster.

Escolha um conjunto de endereços IP que você quer usar como endereços de origem de saída. Eles são chamados de endereços IP flutuantes, porque o Anthos Network Gateway os atribui, conforme necessário, às interfaces de rede dos nós escolhendo gateways de saída.

Os endereços IP flutuantes precisam estar na mesma sub-rede que os endereços IP do nó.

Seu conjunto de endereços IP flutuantes não pode se sobrepor ao conjunto de endereços IP especificados para seus nós.

Por exemplo, suponha que uma sub-rede tenha o intervalo de endereços 192.168.1.0/24. E suponha que você tenha escolhido usar 192.168.1.1 a 192.168.1.99 para nós. Em seguida, use 192.168.1.100 a 192.168.1.104 como endereços IP flutuantes.

Criar um objeto NetworkGatewayGroup

Esta seção é destinada aos administradores de cluster.

Veja um exemplo de manifesto para um objeto NetworkGatewayGroup:

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
  - 192.168.1.103
  - 192.168.1.104

Substitua a matriz floatingIPs pelos endereços IP flutuantes e salve o manifesto em um arquivo chamado my-ngg.yaml.

Crie o objeto NetworkGatewayGroup:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG apply -f my-ngg.yaml

Exemplo de uma política de saída de NAT

Esta seção é destinada a desenvolvedores.

Aqui está um exemplo de um recurso personalizado EgressNatPolicy:

kind: EgressNATPolicy
apiVersion: networking.gke.io/v1
metadata:
  name: alice-paul
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

No manifesto anterior, vemos:

• Um pod é um candidato para a saída NAT se atender a um dos seguintes itens:

  • O pod tem o rótulo role: frontend e o pod está em um namespace que tem o rótulo user: alice.

  • O pod tem o rótulo role: frontend e está em um namespace que tem o rótulo user: paul.

• O tráfego de um pod candidato para um endereço no intervalo 8.8.8.0/24 é enviado para o gateway NAT de saída.

• A seção gatewayRef determina o endereço IP de origem da saída. O recurso personalizado EgressNATPolicy usa os valores gatewayRef.name e gatewayRef.namespace para encontrar um objeto NetworkGatewayGroup. A política usa um dos endereços IP flutuantes do NetworkGatewayGroup como o endereço IP de origem para o tráfego de saída. Se houver vários endereços IP flutuantes no NetworkGatewayGroup correspondente, a política usará o primeiro endereço IP na lista do floatingIPs e ignorará os outros endereços IP. Se houver campos inválidos na seção gatewayRef, ocorrerá uma falha ao aplicar o objeto EgressNATPolicy.

Criar um objeto EgressNATPolicy

Crie seu próprio manifesto EgressNATPolicy. Defina metadata.name como "my-policy". Salve o manifesto em um arquivo chamado my-policy.yaml.

Crie o objeto EgressNatPolicy:

kubectl apply --kubeconfig USER_CLUSTER_KUBECONFIG -f my-policy.yaml

Ver informações sobre sua política de saída de NAT

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get egressnatpolicy my-policy --output yaml

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get networkgatewaygroup --namespace kube-system --output yaml

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe egressnatpolicy my-policy

Ordem de operações

A política de saída NAT é compatível com as APIs da política de rede. A política de rede é avaliada antes da política NAT de saída. Se uma política de rede diz para descartar um pacote, o pacote é descartado, independentemente da política de saída NAT.

Várias políticas de saída

Conforme descrito anteriormente, cada EgressNATPolicy usa o primeiro endereço IP na lista floatingIPs do NetworkGatewayGroup que corresponde a gatewayRef.name e gatewayRef.namespace. Se você criar várias políticas e quiser usar endereços IP diferentes, precisará criar vários objetos NetworkGatewayGroup e refere-los respectivamente. Se você criar várias políticas, o objeto gatewayRef precisará ser exclusivo para cada política.

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

Observação: o gateway de rede do Anthos não permite criar novos objetos de gateway que contenham endereços IP em spec.floatingIPs que já são usados em objetos de gateway. Esta regra é aplicada por um webhook no Google Distributed Cloud versão 1.15.0 e superior.

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 gerenciar cada endereço IP flutuante. Normalmente, cada política de saída precisa ter um objeto de gateway correspondente para garantir que o endereço IP correto seja alocado.

   Em seguida, verifique cada objeto de gateway com kubectl para ver o status de alocaçã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 se refiram aos objetos de gateway, como a gateway1 criada na etapa anterior:

   kind: EgressNATPolicy
   apiVersion: networking.gke.io/v1
   metadata:
     name: egresspolicy1
   spec:
     ...
     gatewayRef:
       name: gateway1
       namespace: kube-system
   ---
   kind: EgressNATPolicy
   apiVersion: networking.gke.io/v1
   metadata:
     name: egresspolicy2
   spec:
     ...
     gatewayRef:
       name: gateway2
       namespace: kube-system
   ---
   kind: EgressNATPolicy
   apiVersion: networking.gke.io/v1
   metadata:
     name: egresspolicy3
   spec:
     ...
     gatewayRef:
       name: gateway3
       namespace: kube-system
   

(Opcional) Especificar os nós em que colocar endereços IP flutuantes

Os recursos NetworkGatewayGroup oferecem suporte a seletores de nós. Especificar um subconjunto de nós considerados para hospedar um endereço IP flutuante, é possível adicionar ao seletor de nós ao objeto NetworkGatewayGroup, conforme mostrado no 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 o rótulo especificado e apenas esses nós são considerados para hospedar um endereço IP flutuante. Se você especificar vários seletores, a lógica deles é cumulativa, portanto, um nó precisa corresponder a cada rótulo para ser considerado para hospedar um endereço IP flutuante. Se não houver muitos nós com rótulos correspondentes, um seletor de nós pode reduzir as qualidades de alta disponibilidade de posicionamento de endereços IP flutuantes.