Configurar um gateway de NAT de saída

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

Este documento mostra como configurar um gateway NAT de saída para um cluster de utilizadores.

Aviso: não pode atualizar nenhum cluster da versão 1.8.x ou 1.9.x que tenha o Anthos Network Gateway ativado para uma versão posterior. Por exemplo, não pode atualizar um cluster da versão 1.9.0 com o Anthos Network Gateway ativado para a versão 1.9.x, nem para a versão 1.10. Só pode atualizar clusters com o Anthos Network Gateway ativado se tiverem sido criados na versão 1.10 ou posterior. Pode eliminar um cluster da versão 1.8.x ou 1.9.x e, em seguida, recriá-lo seguindo as instruções neste documento.

Introdução

Por vezes, tem Pods em execução num cluster de utilizadores que precisam de enviar pacotes para componentes em execução na sua organização, mas fora do cluster. Pode querer conceber esses componentes externos para que filtrem o tráfego de rede recebido de acordo com um conjunto de endereços IP de origem bem conhecidos.

Seguem-se alguns cenários:

• Tem uma firewall à frente de uma base de dados que permite o acesso apenas por endereço IP. Além disso, a equipa que gere a firewall da base de dados é diferente da equipa que gere o cluster de utilizadores.

• As cargas de trabalho no cluster de utilizadores têm de aceder a uma API de terceiros através da Internet. Por motivos de segurança, o fornecedor da API autentica e autoriza o tráfego através do endereço IP como identidade.

Com um gateway NAT de saída, pode ter um controlo detalhado sobre os endereços IP de origem usados para o tráfego de rede que sai de um cluster.

Preços

Não existe qualquer custo financeiro pela utilização desta funcionalidade durante a pré-visualização.

Como funciona um gateway NAT de saída

Normalmente, quando um Pod envia um pacote para fora do cluster, o pacote é traduzido com o endereço IP do nó onde o Pod está a ser executado.

Quando existe um gateway NAT de saída, pode especificar que determinados pacotes de saída devem ser enviados primeiro para um nó de gateway dedicado. A interface de rede no nó do gateway está configurada com dois endereços IP: o endereço IP principal e um endereço IP de origem de saída.

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

O diagrama seguinte ilustra o fluxo de pacotes:

No diagrama anterior, pode ver o fluxo de um pacote enviado a partir do Pod.

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

2. O pacote corresponde a uma regra de saída, pelo que é encaminhado para o nó do gateway.

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

4. O tráfego de retorno volta 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 para o nó original, e entregue novamente ao pod original.

Personagens fictícias

Este tópico refere-se a duas personagens fictícias:

• Administrador do cluster. Esta pessoa cria um cluster de utilizadores e especifica endereços IP flutuantes a serem usados pelo Anthos Network Gateway.

• Programador. Esta pessoa executa cargas de trabalho no cluster de utilizadores e cria políticas de saída.

Ative o gateway de NAT de saída

Esta secção destina-se a administradores de clusters.

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

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

enableDataplaneV2: true
...
advancedNetworking: true

Crie o cluster de utilizadores.

Especifique endereços IP flutuantes

Esta secção destina-se a administradores de clusters.

Escolha um conjunto de endereços IP que quer usar como endereços de origem de saída. Estes são denominados endereços IP flutuantes, porque o grupo de gateways de rede os atribui, conforme necessário, às interfaces de rede dos nós que escolhe para serem gateways de saída.

Os seus endereços IP flutuantes têm de estar na mesma sub-rede que os endereços IP dos nós.

O seu conjunto de endereços IP flutuantes não pode sobrepor-se ao conjunto de endereços IP que especificou para os seus nós.

Por exemplo, suponha que uma sub-rede tem o intervalo de endereços 192.168.1.0/24. Suponhamos que optou por usar 192.168.1.1 a 192.168.1.99 para nós. Em seguida, pode usar 192.168.1.100 a 192.168.1.104 como endereços IP flutuantes.

Crie um objeto NetworkGatewayGroup

Esta secção destina-se a administradores de clusters.

Segue-se um exemplo de um 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 seus endereços IP flutuantes e guarde o manifesto num ficheiro denominado my-ngg.yaml.

Crie o objeto NetworkGatewayGroup:

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

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

Esta secção destina-se a programadores.

Segue-se 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 é candidato a NAT de saída se satisfizer uma das seguintes condições:

  • O pod tem a etiqueta role: frontend e está num espaço de nomes que tem a etiqueta user: alice.

  • O pod tem a etiqueta role: frontend e está num espaço de nomes que tem a etiqueta 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 secção gatewayRef determina o endereço IP de origem de 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 existirem vários endereços IP flutuantes no NetworkGatewayGroup correspondente, a política usa o primeiro endereço IP na lista floatingIPs e ignora todos os outros endereços IP. Se existirem campos inválidos na secção gatewayRef, isto resulta numa falha na aplicação do objeto EgressNATPolicy.

Crie um objeto EgressNATPolicy

Crie o seu próprio manifesto EgressNATPolicy. Defina metadata.name como "my-policy". Guarde o manifesto num ficheiro com o nome my-policy.yaml.

Crie o objeto EgressNatPolicy:

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

Veja informações acerca da sua política de NAT de saída

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 das operações

A política de NAT de saída é compatível com as APIs de políticas de rede. A política de rede é avaliada antes da política de NAT de saída. Se uma política de rede indicar para rejeitar um pacote, o pacote é rejeitado independentemente da política de NAT de saída.

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 criar várias políticas e pretender usar diferentes endereços IP, tem de criar vários objetos NetworkGatewayGroup e referi-los respetivamente. Se criar várias políticas, o objeto gatewayRef tem de ser único para cada política.

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.

Nota: o Anthos Network Gateway não permite criar novos objetos de gateway que contenham endereços IP em spec.floatingIPs que já sejam usados em objetos de gateway existentes. 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 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: 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) 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.