Configurer une passerelle NAT de sortie

Version 1.10 (unsupported)

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

Preview

Ce produit ou cette fonctionnalité est soumis aux "Conditions des offres de pré-DG" dans la section "Conditions d'utilisation générales" des Conditions spécifiques au service. Les produits et fonctionnalités pré-DG sont disponibles "en l'état" et peuvent bénéficier d'une assistance limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

Ce document explique comment configurer une passerelle NAT de sortie pour des clusters Anthos sur 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. L'utilisation de cette fonctionnalité est gratuite pendant la version bêta.

Remarque : La fonctionnalité de passerelle NAT de sortie n'est qu'une fonctionnalité bêta. Vous pouvez activer le groupe de passerelles réseau pour un cluster, mais les mises à niveau des clusters sur lesquels il est activé ne sont pas prises en charge. Pour cette raison, nous vous déconseillons de mettre à niveau les clusters de production existants afin d'activer cette fonctionnalité, car cela peut vous empêcher d'effectuer des mises à niveau ultérieures.

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.

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 du groupe de passerelles réseau est un composant groupé d'Anthos clusters on 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.10.8.

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 obligatoires.

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 un libellé d'espace de noms, namespaceSelector.matchLabels.**user**, et un libellé 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.

Une limite de NetworkGatewayGroup existe dans cette version d'Anthos clusters on bare metal, à savoir que seul l'objet "par défaut" est rapproché pour les allocations d'adresses IP flottantes. De plus, seul les rapports de la passerelle par défaut indiquent l'état d'allocation pour toutes les adresses IP flottantes.

La passerelle par défaut est définie par la ressource NetworkGatewayGroup avec le nom default dans l'espace de noms kube-system. Par conséquent, lorsque vous créez plusieurs objets de passerelle, vous devez vous assurer que les adresses IP des passerelles autres que celles par défaut sont également spécifiées dans le fichier manifeste de la passerelle par défaut. Sinon, elles ne seront pas allouées en tant qu'adresses IP flottantes et ne peuvent donc pas être utilisées par l'objet EgressNATPolicies.

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

1. Vérifiez l'objet de passerelle par défaut (name: default) avec kubectl pour obtenir l'état d'allocation des adresses IP flottantes :

   kubectl -n kube-system get NetworkGatewayGroup.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:
     ...
     floatingIPs:
       192.168.1.100: worker1
       192.168.1.101: worker2
       192.168.1.102: worker1
   

2. Après avoir vérifié l'état de la passerelle par défaut, créez des objets de passerelle supplémentaires dans l'espace de noms kube-system pour "suivre" chaque adresse IP flottante.

   Notez que ces nouveaux objets de passerelle ne signalent pas l'état d'allocation, qui se trouve dans la passerelle 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
   

3. Créez plusieurs règles faisant référence aux objets de passerelle "secondaires", tels que 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
   

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 avec des adresses IP de nœud pour cette version bêta.

• Les mises à niveau ne sont pas acceptées pour les clusters qui sont configurés pour utiliser l'aperçu de la passerelle NAT de sortie.