Configurer une passerelle NAT de sortie

Version 1.28 (latest)

• Le plus récent
• Version 1.16
• Versions antérieures (non compatibles)

Ce document explique comment configurer une passerelle NAT de sortie pour GKE sur une solution Bare Metal. Cette passerelle fournit des adresses IP SNAT persistantes et déterministes pour le trafic de sortie de vos clusters. Lorsque vous exécutez des charges de travail contenant du trafic utilisateur sortant (en dehors de vos clusters), vos clients souhaitent identifier ce trafic à l'aide de quelques adresses IP déterministes. Cela permet à vos clients d'établir des mesures de sécurité basées sur l'adresse IP, telles que les règles d'ajout à la liste d'autorisation.

La passerelle NAT de sortie est activée à l'aide de deux ressources personnalisées. Pour un espace de noms donné, la ressource personnalisée NetworkGatewayGroup spécifie des adresses IP flottantes pouvant être configurées sur l'interface réseau d'un nœud choisi pour agir en tant que passerelle. La ressource personnalisée EgressNatPolicy vous permet de spécifier des règles de routage de sortie pour contrôler le trafic sur la passerelle de sortie.

Si vous ne configurez pas de passerelle NAT de sortie ou si le trafic sortant ne respecte pas les règles de sélection, le trafic sortant d'un pod donné vers une destination extérieure à votre cluster est masqué à l'adresse IP du nœud sur lequel le pod est en cours d'exécution. Dans ce scénario, rien ne garantit que tout le trafic de sortie d'un pod particulier aura la même adresse IP source ou sera masqué à la même adresse IP de nœud.

La passerelle NAT de sortie est une offre de mise en réseau avancée reposant sur Dataplane V2.

Remarque :Si les nœuds exécutent Ubuntu 18.04, le noyau Linux doit être de version 5.4 ou ultérieure. Pour en savoir plus, consultez la section Configurer Ubuntu.

Fonctionnement de la passerelle NAT de sortie

La logique de sélection du trafic sortant est basée sur un sélecteur d'espace de noms, un sélecteur de pod et un ensemble de plages d'adresses IP de destination dans la notation de bloc CIDR. Pour illustrer le fonctionnement de la passerelle NAT de sortie, considérons le flux d'un paquet à partir d'un pod vers un consommateur externe, et la réponse correspondante. Supposons que le sous-réseau de nœud comporte des adresses IP dans le bloc CIDR 192.168.1.0/24.

Le schéma suivant illustre l'architecture réseau pour le trafic sortant via un nœud de passerelle.

Le flux de paquets via la passerelle NAT de sortie peut ressembler à ceci :

1. Le trafic sortant est généré à partir d'un pod avec l'adresse IP 10.10.10.1 dans un nœud avec l'adresse IP 192.168.1.1.

   L'adresse de destination du trafic est un point de terminaison situé en dehors du cluster.

2. Si le trafic correspond à une règle de sortie, le programme eBPF achemine le trafic de sortie vers le nœud de passerelle, au lieu de le masquer directement avec l'adresse IP du nœud.

3. Le nœud de passerelle reçoit le trafic de sortie.

4. Le nœud de passerelle masque l'adresse IP source du trafic d'origine, 10.10.10.1, avec l'adresse IP de sortie source, 192.168.1.100, spécifiée dans la ressource personnalisée EgressNATPolicy.

5. Le trafic retour est renvoyé au nœud de passerelle avec la destination 192.168.1.100.

6. Le nœud de passerelle met en correspondance le conntrack du trafic de retour avec celui du trafic de sortie d'origine et réécrit l'adresse IP de destination en tant que 10.10.10.1.

7. 10.10.10.1 est traité comme du trafic en cluster, acheminé vers le nœud d'origine et renvoyé au pod d'origine.

Configurer des adresses IP flottantes pour le trafic de nœuds

La ressource personnalisée Network Gateway Group est un composant groupé de GKE sur Bare Metal. Le contrôleur gère une liste d'une ou de plusieurs adresses IP flottantes à utiliser pour le trafic de sortie des nœuds de votre cluster. Les nœuds participants sont déterminés par l'espace de noms spécifié. Le groupe de passerelles réseau rend une adresse IP flottante disponible à tout moment de la manière la plus optimale possible. Si un nœud utilisant une adresse IP flottante tombe en panne, la passerelle de réseau Anthos déplace l'adresse IP attribuée au prochain nœud disponible. Tout le trafic sortant utilisant cette adresse IP sera également déplacé.

Incluez les détails du groupe de passerelles réseau (annotation et spécification) dans le fichier de configuration du cluster lorsque vous créez un cluster 1.28.300-gke.131.

Créer la ressource personnalisée NetworkGatewayGroup

Pour activer le groupe de passerelles réseau, définissez le champ spec.clusterNetwork.advancedNetworking sur true dans le fichier de configuration du cluster lorsque vous créez un cluster, comme illustré dans l'exemple suivant :

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

Lorsque vous créez la ressource personnalisée NetworkGatewayGroup, définissez son espace de noms sur l'espace de noms du cluster et spécifiez une liste d'adresses IP flottantes, comme indiqué dans l'exemple suivant :

Remarque : L'opérateur de cluster crée une copie de la ressource personnalisée NetworkGatewayGroup dans l'espace de noms kube-system. Cette copie de la ressource personnalisée NetworkGatewayGroup dans l'espace de noms kube-system est chargée de définir les adresses IP flottantes utilisées par l'opérateur de mise en réseau avancée.

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

Remarque : La passerelle NAT de sortie n'est pas compatible avec une configuration en haute disponibilité. Si le nœud de passerelle réseau gérant l'adresse IP flottante tombe en panne ou présente des problèmes de connectivité, le trafic de sortie peut être interrompu pendant de courtes périodes. L'opérateur de mise en réseau avancée réattribue automatiquement l'adresse IP flottante à un nouveau nœud pour restaurer le trafic de sortie.

L'opérateur de mise en réseau avancé attribue les adresses IP flottantes aux nœuds en fonction des critères suivants :

• Sous-réseau de nœud : l'adresse IP flottante doit correspondre au sous-réseau du nœud.
• Rôle du nœud (plan de contrôle, nœud de calcul) : les nœuds de calcul sont prioritaires sur les nœuds du plan de contrôle lors de l'attribution d'adresses IP flottantes.
• Si un nœud possède une adresse IP flottante, l'opérateur donne la priorité pour les attributions aux nœuds qui n'ont pas encore d'adresse IP flottante.

Le mappage d'adresse/nœud est disponible dans la section status lorsque vous obtenez l'objet NetworkGatewayGroup. Notez que l'objet NetworkGatewayGroup se trouve dans l'espace de noms kube-system. Si un nœud de passerelle est indisponible, l'opérateur de mise en réseau avancée attribue les adresses IP flottantes au prochain nœud disponible.

Vérifier la configuration de passerelle

Après avoir appliqué vos modifications de configuration de passerelle, vous pouvez utiliser kubectl pour vérifier l'état de la passerelle et récupérer les adresses IP flottantes spécifiées pour la passerelle.

1. Utilisez la commande suivante pour vérifier l'état de NetworkGatewayGroup et voir comment les adresses IP flottantes sont allouées :

   kubectl -n kube-system get networkgatewaygroups.networking.gke.io default -o yaml

   La réponse pour un cluster avec deux nœuds, worker1 et worker2, peut se présenter comme suit :

   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
   

Définir des règles de sélection du trafic

La ressource personnalisée EgressNATPolicy spécifie des règles de sélection de trafic et attribue une adresse IP déterministe au trafic de sortie quittant le cluster. Lorsque vous spécifiez la ressource personnalisée, egress (avec au moins une règle), destinationCIDRs et egressSourceIP sont tous obligatoires.

Remarque :Il est possible de définir des règles de sélection du trafic qui spécifient une adresse egressSourceIP déjà utilisée pour un autre objet EgressNATPolicy. Cela peut provoquer des conflits de routage du trafic de sortie. Collaborez avec votre équipe de développement pour déterminer les adresses IP flottantes disponibles avant de spécifier l'adresse egressSourceIP dans votre ressource personnalisée EgressNATPolicy.

Utilisez kubectl apply pour créer la ressource personnalisée EgressNATPolicy. Les sections suivantes fournissent des détails et des exemples de définition de spécification.

Spécifier des règles de routage de sortie

La ressource personnalisée EgressNatPolicy vous permet de spécifier les règles suivantes pour le trafic de sortie :

• Vous devez spécifier une ou plusieurs règles de sélection du trafic de sortie dans la section egress.

  • Chaque règle se compose d'un podSelector et d'un namespaceSelector.
  • La sélection est basée sur une étiquette d'espace de noms, namespaceSelector.matchLabels.user, et une étiquette de pod, podSelector.matchLabels.role.
  • Si un pod correspond à l'une des règles (la correspondance utilise une relation OR), il est sélectionné pour le trafic de sortie.

• Spécifiez les adresses de destination autorisées dans la section destinationCIDRs.

  • destinationCIDRs prend une liste de blocs CIDR.
  • Si le trafic sortant d'un pod possède une adresse IP de destination comprise dans la plage de l'un des blocs CIDR spécifiés, il est sélectionné pour le trafic de sortie.

Dans l'exemple suivant, le trafic sortant d'un pod est autorisé lorsque les critères suivants sont remplis :

• L'étiquette role: frontend est attribuée au pod.
• Le pod se trouve dans un espace de noms libellé user: alice ou user: paul.
• Le pod communique avec les adresses IP dans le bloc 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

Pour plus d'informations sur l'utilisation des étiquettes, consultez la section Étiquettes et sélecteurs dans la documentation de Kubernetes.

Obtenir une adresse IP source pour le trafic de sortie

La ressource personnalisée (règle) EgressNATPolicy utilise les valeurs gatewayRef.name et gatewayRef.namespace pour rechercher un objet NetworkGatewayGroup (passerelle). La règle utilise l'une des adresses IP flottantes de la passerelle comme adresse IP source pour le trafic de sortie. Si la passerelle correspondante contient plusieurs adresses IP flottantes, la règle utilise la première adresse IP de la liste floatingIPs et ignore toutes les autres adresses IP. Pour l'exemple de passerelle, la première adresse de la liste floatingIPs est 192.168.1.100. La présence de champs ou de valeurs non valides dans la section gatewayRef entraîne l'échec de l'application de l'objet de la règle.

Plusieurs règles de sortie et plusieurs objets de passerelle

Comme décrit dans la section précédente, chaque objet egressNATPolicy (règle) utilise la première adresse IP de la liste floatingIPs de l'objet de passerelle qui correspond à gatewayRef.name et gatewayRef.namespace. Vous pouvez créer plusieurs règles. Si vous souhaitez utiliser des adresses IP différentes, vous devez créer plusieurs objets NetworkGatewayGroup et y faire référence.

Chaque ressource NetworkGatewayGroup doit contenir des adresses IP flottantes uniques. Pour configurer plusieurs objets EgressNATPolicy afin qu'ils utilisent la même adresse IP, utilisez les mêmes gatewayRef.name et gatewayRef.namespace pour les deux.

Remarque :La passerelle réseau Anthos ne vous permet pas de créer des objets passerelle contenant des adresses IP dans spec.floatingIPs qui sont déjà utilisées dans des objets passerelle existants. Cette règle est appliquée par un webhook dans GKE sur une solution Bare Metal version 1.15.0 ou ultérieure.

Pour configurer plusieurs règles de sortie et plusieurs objets de passerelle :

1. Créez des objets passerelle dans l'espace de noms kube-system pour gérer chaque adresse IP flottante. En règle générale, chaque règle de sortie doit comporter un objet passerelle correspondant pour garantir l'allocation de l'adresse IP appropriée.

   Vérifiez ensuite chaque objet passerelle avec kubectl pour obtenir l'état d'allocation des adresses IP flottantes:

   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. Créez plusieurs règles faisant référence aux objets passerelle, comme gateway1 créés à l'étape précédente:

   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
   

(Facultatif) Spécifier les nœuds sur lesquels placer des adresses IP flottantes

Les ressources NetworkGatewayGroup sont compatibles avec les sélecteurs de nœuds. Pour spécifier un sous-ensemble de nœuds pouvant héberger une adresse IP flottante, vous pouvez ajouter le sélecteur de nœuds à l'objet NetworkGatewayGroup, comme indiqué dans l'exemple suivant:

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"

Le sélecteur de nœuds établit une correspondance avec les nœuds portant le libellé spécifié, et seuls ces nœuds sont pris en compte pour l'hébergement d'une adresse IP flottante. Si vous spécifiez plusieurs sélecteurs, leur logique est additive. Un nœud doit donc correspondre à chaque étiquette pour pouvoir héberger une adresse IP flottante. S'il n'y a pas beaucoup de nœuds avec des libellés correspondants, un sélecteur de nœuds peut réduire la haute disponibilité de l'emplacement des adresses IP flottantes.

Règles de sélection du trafic de sortie et règles de réseau

La passerelle NAT de sortie est compatible avec les API de règles de réseau. Les règles de réseau sont évaluées en premier et sont prioritaires sur les règles de sélection du trafic de la passerelle NAT de sortie. Par exemple, si le trafic de sortie déclenche une règle de réseau entraînant la suppression du paquet, les règles de passerelle de sortie ne vérifient pas le paquet. Les règles de sélection du trafic de sortie sont évaluées pour déterminer la manière dont le trafic est traité, soit en utilisant la passerelle NAT de sortie, soit en masquant directement l'adresse IP du nœud sur lequel le pod est en cours d'exécution.

Limites

Les limitations actuelles de la passerelle NAT de sortie sont les suivantes :

• La passerelle NAT de sortie n'est activée que pour le mode IPv4.

• Les adresses IP de sortie doivent appartenir au même domaine de couche 2 que les adresses IP des nœuds.

• Les mises à niveau ne sont pas acceptées pour les clusters configurés pour utiliser la version bêta de la passerelle NAT de sortie. Pour GKE sur Bare Metal 1.28.0 et versions ultérieures, la passerelle NAT de sortie est en version preview sur Ubuntu 18.04 uniquement. L'utilisation de cette fonctionnalité est gratuite en version bêta.