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.
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.
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 IP192.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 personalizadoEgressNATPolicy
.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.12.9.
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
eworker2
, 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 umnamespaceSelector
. - 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.
- Cada regra consiste em um
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
ouuser: 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
) comkubectl
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
eworker2
, 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ó.
Os upgrades não são compatíveis com clusters configurados para usar a visualização do gateway NAT de saída. Para clusters do Anthos na versão Bare Metal 1.21.0 e posterior, o gateway NAT de saída está apenas em Visualização no Ubuntu 18.04. Não há cobrança para usar esse recurso enquanto ele estiver em Visualização.