Versão 1.9. 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.10, consulte Como fazer upgrade do Anthos em Bare Metal na documentação do 1.10.

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

Configurar um gateway NAT de saída para comunicação externa

Neste documento, descrevemos como configurar um gateway NAT de saída para clusters do Anthos em Bare Metal. Esse gateway fornece roteamento determinístico permanente para o tráfego de saída dos clusters. Quando você executa cargas de trabalho com 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 seus 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 está na visualização.

O gateway NAT de saída é ativado usando dois recursos personalizados. Para um determinado namespace, o recurso personalizado AnthosNetworkGateway 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ó.

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 controlador do gateway de rede do Anthos é um componente empacotado de clusters do Anthos em Bare Metal. O controlador gerencia uma lista de um ou mais endereços IP flutuantes a serem usados para o tráfego de saída dos nós no cluster. Os nós participantes são determinados pelo namespace especificado. O Anthos Network Gateway disponibiliza um endereço IP flutuante sempre, da melhor maneira possível. Se um nó que usa um endereço IP flutuante ficar inativo, o gateway de rede do Anthos 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 gateway de rede do Anthos (anotação e especificação) no arquivo de configuração do cluster ao criar um novo cluster 1.8.0.

Criar o recurso personalizado `AnthosNetworkGateway`

Ative o gateway de rede do Anthos usando a anotação baremetal.cluster.gke.io/enable-anthos-network-gateway no arquivo de configuração do cluster ao criar um cluster. Defina a anotação como true, como mostrado no exemplo a seguir:

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  annotations:
    baremetal.cluster.gke.io/enable-anthos-network-gateway: "true"
  name: cluster1
  namespace: cluster-cluster1

Ao criar o recurso personalizado AnthosNetworkGateway, 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: AnthosNetworkGateway
apiVersion: networking.gke.io/v1alpha1
metadata:
  namespace: cluster-cluster1
  name: default
spec:
  floatingIPs:
  - 192.168.1.100
  - 192.168.1.101
  - 192.168.1.102

O número de endereços IP flutuantes que você especifica afeta a confiabilidade do seu cluster. Por exemplo, um gateway NAT de saída funcionará com apenas um endereço IP flutuante especificado, mas uma falha no nó poderá levar a interrupções de tráfego. Se você adicionar mais endereços IP flutuantes, o AnthosNetworkGateway atribuirá e moverá os endereços conforme necessário. Recomendamos pelo menos dois endereços IP flutuantes por domínio L2 usado no cluster.

O controlador 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ó (mestre, worker) - os nós de trabalho têm precedência sobre os nós mestres ao atribuir endereços IP flutuantes.
Se um nó tem um endereço IP flutuante, o controlador prioriza 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 AnthosNetworkGateway. O objeto AnthosNetworkGateway está no namespace kube-system. Se um nó de gateway estiver inativo, o controlador de AnthosNetworkGateway 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 AnthosNetworkGateway e ver como os endereços IP flutuantes são alocados:

kubectl -n kube-system get anthosnetworkgateway.networking.gke.io default -oyaml

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

kind: AnthosNetworkGateway
apiVersion: networking.gke.io/v1alpha1
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

Use o seguinte comando para recuperar o status AnthosNetworkGateway e a alocação de endereços de um nó específico.
```
kubectl -n kube-system get anthosnetworkgatewaynode.networking.gke.io NODE_NAME -oyaml
```
Substitua NODE_NAME pelo nome do nó/máquina específico que você quer inspecionar.

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 intervalo 8.8.8.0/24.

kind: EgressNATPolicy
apiVersion: networking.gke.io/v1alpha1
metadata:
  name: egress
spec:
  egress:
  - namespaceSelector:
      matchLabels:
        user: alice
    podSelector:
      matchLabels:
        role: frontend
  - namespaceSelector:
      matchLabels:
        user: paul
    podSelector:
      matchLabels:
        role: frontend
  destinationCIDRs:
  - 8.8.8.0/24
  egressSourceIP: 192.168.1.100

Para mais informações sobre o uso de rótulos, consulte Rótulos e seletores na documentação do Kubernetes.

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

Especifique o endereço IP de origem que você quer usar no campo egressSourceIP. O endereço IP de origem precisa corresponder a um dos endereços IP flutuantes especificados no recurso personalizado AnthosNetworkGateway.

Usando o exemplo EgressNATPolicy da seção anterior, se os critérios de seleção de pod e de endereço IP de destino forem atendidos, o tráfego de saída do pod será convertido para 192.168.1.100 usando SNAT.

Para que a rota seja aceita, o endereço egressSourceIP precisa estar na mesma sub-rede que o IP do nó do gateway. Se o endereço egressSourceIP for desconhecido (não atribuído) ao nó de gateway, a solicitação de rota não poderá ser atendida. Nesse caso, você receberá um erro UnknownEgressIP nos eventos do Kubernetes.

Use o seguinte comando kubectl para imprimir os eventos do objeto EgressNATPolicy:

kubectl describe EgressNATPolicy egress

Se houver várias respostas automáticas EgressNATPolicy, cada uma precisará ter um endereço egressSourceIP diferente. Para evitar conflitos, coordene com a equipe de desenvolvimento.

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 L2 com endereços IP do nó para esta visualização.
Os upgrades não são compatíveis com clusters configurados para usar a visualização do gateway NAT de saída.