Neste documento, descrevemos como configurar um gateway NAT de saída para o Google Distributed Cloud. 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 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 do grupo de gateway de rede é um componente empacotado do Google Distributed Cloud. O recurso gerencia um ou mais endereços IP flutuantes usados para o tráfego de saída dos nós do 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.29.400-gke.86.
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 o recurso personalizado, 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.
Cada recurso NetworkGatewayGroup
precisa conter endereços IP flutuantes exclusivos.
Para configurar vários objetos EgressNATPolicy
para usar o mesmo endereço IP, use
os mesmos gatewayRef.name
e gatewayRef.namespace
para ambos.
Para configurar várias políticas de saída e vários objetos de gateway:
Crie objetos de gateway no namespace
kube-system
para gerenciar cada endereço IP flutuante. Normalmente, cada política de saída precisa ter um objeto de gateway correspondente para garantir que o endereço IP correto seja alocado.Em seguida, verifique cada objeto de gateway com
kubectl
para ver o status de alocaçã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
Crie várias políticas que se refiram aos objetos de gateway, como a
gateway1
criada 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
(Opcional) Especificar os nós em que colocar endereços IP flutuantes
Os recursos NetworkGatewayGroup
oferecem suporte a seletores de nós. Especificar um subconjunto
de nós considerados para hospedar um endereço IP flutuante, é possível adicionar ao
seletor de nós ao objeto NetworkGatewayGroup
, conforme mostrado no
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 o rótulo especificado e apenas esses nós são considerados para hospedar um endereço IP flutuante. Se você especificar vários seletores, a lógica deles é cumulativa, portanto, um nó precisa corresponder a cada rótulo para ser considerado para hospedar um endereço IP flutuante. Se não houver muitos nós com rótulos correspondentes, um seletor de nós pode reduzir as qualidades de alta disponibilidade de posicionamento de endereços IP flutuantes.
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 a versão 1.29.0 e mais recentes do Google Distributed Cloud, a saída do gateway NAT está em pré-lançamento apenas no Ubuntu 18.04. Não há cobrança para usar esse recurso enquanto ele estiver em Visualização.