Como configurar um gateway NAT de saída

10

Version 1.10 

• Versão mais recente
• Versão 1.16
• Versões anteriores (sem suporte)

Visualização

Este produto ou recurso está sujeito aos "Termos das ofertas pré-GA" na seção "Termos de Serviço gerais" dos Termos específicos do serviço. Os produtos e recursos pré-GA estão disponíveis "no estado em que se encontram" e podem ter suporte limitado. Para mais informações, consulte as descrições da fase de lançamento.

Com clusters do Anthos no VMware (GKE On-Prem), é 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.

Uma limitação dos clusters do Anthos no VMware para esta versão é que somente o NetworkGatewayGroup que tem o nome default no namespace kube-system é reconciliado para alocações de IP flutuantes. Além disso, somente o NetworkGatewayGroup padrão informa o status de alocação de todos os endereços IP flutuantes.

Portanto, ao criar vários objetos NetworkGatewayGroup, verifique se os endereços IP dos objetos não padrão também estão especificados no manifesto NetworkGatewayGroup padrão. Caso contrário, eles não serão alocados como IPs flutuantes e, portanto, não podem ser usados pelo objeto EgressNATPolicies.

Para configurar várias políticas de saída e vários objetos NetworkGatewayGroup, faça o seguinte:

1. Verifique o objeto NetworkGatewayGroup padrão (name: default) com kubectl para receber o status de alocação dos endereços IP flutuantes:

   kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get networkgatewaygroup --name default --output yaml
   

   A resposta de um cluster com dois nós, worker1 e worker2, pode ser semelhante a:

   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:
     ...
     floatingIPs:
       192.168.1.100: worker1
       192.168.1.101: worker2
       192.168.1.102: worker1
   

2. Depois de verificar o status do NetworkGatewayGroup padrão, crie outros objetos NetworkGatewayGroup no namespace kube-system para "rastrear" cada IP flutuante.

   Esses novos objetos não informam o status de alocação, que está no default NetworkGatewayGroup.

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

3. Crie várias políticas que façam referência aos objetos "secundários" do NetworkGatewayGroup, como o gateway1 criado 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