Version 1.10. Esta versão não é mais compatível. Para mais informações, consulte a política de suporte de versões. Para informações sobre como fazer upgrade para a versão 1.11, consulte Como fazer upgrade do Anthos em Bare Metal na documentação do 1.11.

Versões com suporte disponíveis: 1.14 | 1.13 | 1.12

Configurar um gateway NAT de saída

Neste documento, descrevemos como configurar um gateway NAT de saída para clusters do Anthos em Bare Metal. Esse gateway fornece endereços IP SNAT permanentes e determinísticos para o tráfego de saída dos clusters. Quando você executa cargas de trabalho que têm tráfego de saída do usuário (fora dos clusters), seus clientes querem identificar esse tráfego usando alguns endereços IP determinísticos. Isso permite que os clientes estabeleçam medidas de segurança baseadas em IP, como políticas de listas de permissão. Não há cobrança para usar esse recurso enquanto ele estiver em visualização.

O gateway NAT de saída é ativado usando dois recursos personalizados. Para um determinado namespace, 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 especificar políticas de roteamento de saída para controlar o tráfego no gateway de saída.

Se você não configurar um gateway NAT de saída ou se o tráfego de saída não atender às regras de seleção de tráfego, o tráfego de saída de um determinado pod para um destino fora do seu cluster será mascarado para o endereço IP do nó em que o pod está em execução. Nesse cenário, não há garantia de que todo o tráfego de saída de um determinado pod terá o mesmo endereço IP de origem ou se mascarará para o 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 tem como base um seletor de namespace, um seletor de pod e um conjunto de intervalos de endereços IP de destino na notação de bloco CIDR. Para ilustrar como o gateway NAT de saída funciona, vamos pensar no fluxo de um pacote de um pod para um consumidor externo e a resposta correspondente. Suponha que a sub-rede do nó tenha endereços IP no bloco CIDR 192.168.1.0/24.

O diagrama a seguir mostra a arquitetura de rede para o tráfego de saída por meio de um nó de gateway.

Diagrama do gateway NAT de saída para clusters Anthos em bare metal

O fluxo de pacotes pelo gateway NAT de saída pode ser assim:

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

O endereço de destino do tráfego é um endpoint fora do cluster.
Se o tráfego corresponder a uma regra de saída, o programa eBPF o roteará para o nó do gateway, em vez de mascarar-se diretamente com o endereço IP do nó.
O nó de gateway recebe o tráfego de saída.
O nó de gateway mascara o endereço IP de origem do tráfego de origem, 10.10.10.1, com o endereço IP de saída da origem, 192.168.1.100 especificado no recurso personalizado EgressNATPolicy.
O tráfego de retorno volta para o nó de gateway com o destino como 192.168.1.100.
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.
10.10.10.1 é tratado como tráfego no cluster, roteado para o nó original e entregue de volta ao pod original.

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

O recurso personalizado Grupo de gateways de rede é um componente incluído dos clusters do Anthos em bare metal. O recurso gerencia uma lista de um ou mais endereços IP flutuantes a serem usados para o tráfego de saída a partir dos nós no cluster. Os nós participantes são determinados pelo namespace especificado. O grupo de gateways de rede disponibiliza sempre um endereço IP flutuante, da melhor maneira possível. Se um nó que usa um endereço IP flutuante ficar inativo, o gateway de rede avançado moverá o endereço IP atribuído para o próximo nó disponível. Todo o tráfego de saída da carga de trabalho que usar esse endereço IP também será movido.

Inclua os detalhes do Grupo do gateway de rede (anotação e especificação) no arquivo de configuração do cluster ao criar um novo cluster 1.10.8.

Criar o recurso personalizado `NetworkGatewayGroup`

Para ativar o grupo de gateways de rede, defina o campo spec.clusterNetwork.advancedNetworking como true no arquivo de configuração do cluster ao criar um cluster, conforme mostrado no exemplo a seguir:

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

Ao criar o recurso personalizado NetworkGatewayGroup, defina o namespace dele como o namespace de cluster e especifique uma lista de endereços IP flutuantes, como mostrado no exemplo a seguir:

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çado atribui os IPs flutuantes aos nós com base nos seguintes critérios:

Sub-rede de nós: o endereço IP flutuante precisa corresponder à sub-rede do nó.
Papel de nó (plano de controle, worker): os nós de trabalho têm preferência sobre os nós do plano de controle ao atribuir endereços IP flutuantes.
Se um nó tiver um endereço IP flutuante, o operador irá priorizar atribuições para nós que ainda não têm um IP flutuante atribuído.

O mapeamento de endereço/nó pode ser encontrado na seção status quando você recebe o objeto NetworkGatewayGroup. O objeto NetworkGatewayGroup está no namespace kube-system. Se um nó de gateway estiver inativo, o operador de rede avançado atribuirá os endereços IP flutuantes ao próximo nó disponível.

Verificar a configuração do gateway

Depois de aplicar as alterações de configuração do gateway, use kubectl para verificar o status do gateway e recuperar os endereços IP flutuantes especificados para o gateway.

Use o comando a seguir para verificar o status de NetworkGatewayGroup e ver como os endereços IP flutuantes são alocados:

kubectl -n kube-system get networkgatewaygroups.networking.gke.io default -o 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:
  nodes:
    worker1: Up
    worker2: Up // Or Down
  floatingIPs:
    192.168.1.100: worker1
    192.168.1.101: worker2
    192.168.1.102: worker1

Definir 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. Ao especificar a resposta automática, egress (com pelo menos uma regra), destinationCIDRs e egressSourceIP são obrigatórios.

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

Especificar regras de roteamento de saída

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

Você precisa especificar uma ou mais regras de seleção de tráfego de saída na seção egress.
- Cada regra consiste em um podSelector e um namespaceSelector.
- A seleção é baseada em um rótulo de namespace, namespaceSelector.matchLabels.**user**, e um rótulo de pod, podSelector.matchLabels.**role**.
- Se um pod corresponder a qualquer uma das regras (a correspondência usa uma relação OR), ele será selecionado para o tráfego de saída.
Especifique os endereços de destino permitidos na seção destinationCIDRs.
- destinationCIDRs usa uma lista de blocos CIDR.
- Se o tráfego de saída de um pod tiver um endereço IP de destino que esteja dentro do intervalo de qualquer um dos blocos CIDR especificados, ele será selecionado para o tráfego de saída.

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

O pod é rotulado com role: frontend.
O pod está em um namespace rotulado como user: alice ou user: paul.
O pod está se comunicando 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 o uso de rótulos, consulte Rótulos e seletores na documentação do Kubernetes.

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

O recurso personalizado EgressNATPolicy (política) usa 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 houver vários endereços IP flutuantes no gateway correspondente, a política usará o primeiro endereço IP na lista floatingIPs e ignorará os outros endereços IP. Para o gateway de exemplo, o primeiro endereço na lista floatingIPs é 192.168.1.100. O uso de campos ou valores inválidos na seção gatewayRef resultará na falha de aplicar o objeto de política.

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

Conforme descrito na seçã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. É possível criar várias políticas e, se você pretende usar endereços IP diferentes, precisará criar vários objetos NetworkGatewayGroup e referenciá-los, respectivamente.

Uma limitação de NetworkGatewayGroup em clusters do Anthos em Bare Metal para esta versão é que somente o objeto "padrão" é reconciliado para alocações de IP flutuantes. Além disso, somente o gateway padrão informa o status de alocação de todos os endereços IP flutuantes.

O gateway padrão é definido pelo NetworkGatewayGroup com o nome default no namespace kube-system. Portanto, ao criar vários objetos de gateway, você precisa garantir que os endereços IP nos gateways não padrão também sejam especificados no manifesto do gateway padrão. Caso contrário, eles não serão alocados como IPs flutuantes e, portanto, não poderão ser usados pelo objeto EgressNATPolicies.

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

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

kubectl -n kube-system get NetworkGatewayGroup.networking.gke.io default -o 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

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

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

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

Crie várias políticas que façam referência aos objetos de gateway "secundário", como gateway1 criado na etapa 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

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ítica 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 queda do pacote, as regras do gateway de saída não verificarão o pacote. Somente quando a política de rede permitir a saída do pacote, as regras de seleção do tráfego de saída serão avaliadas para decidir como o tráfego será processado, usando o gateway NAT de saída ou mascarando diretamente o endereço IP do Nó em que o pod está em execução.

Limitações

As limitações atuais do gateway 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 precisam estar no mesmo domínio da camada 2 com endereços IP do nó para essa visualização.
Os upgrades não são compatíveis com clusters configurados para usar a visualização do gateway NAT de saída.