Configurer une passerelle NAT de sortie pour la communication externe

Version 1.9 (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 un routage déterministe persistant 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.

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

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

Le contrôleur Anthos Network Gateway est un composant groupé des clusters Anthos 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é. La passerelle de réseau Anthos 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 de Anthos Network Gateway (annotation et spécification) dans le fichier de configuration du cluster lorsque vous créez un cluster 1.8.0.

Remarque : La fonctionnalité de passerelle NAT de sortie n'est qu'une fonctionnalité bêta. Vous pouvez activer Anthos Network Gateway sur un cluster, mais nous n'acceptons pas les mises à niveau pour les clusters sur lesquels cette fonctionnalité est activée. 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.

Créer la ressource personnalisée AnthosNetworkGateway

Vous activez Anthos Network Gateway en utilisant l'annotation baremetal.cluster.gke.io/enable-anthos-network-gateway dans le fichier de configuration de cluster lorsque vous créez un cluster. Définissez l'annotation sur true, comme indiqué dans l'exemple suivant :

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

Lorsque vous créez la ressource personnalisée AnthosNetworkGateway, 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 du contrôleur AnthosNetworkGateway dans l'espace de noms kube-system. Cette copie du contrôleur AnthosNetworkGateway dans l'espace de noms kube-system est chargée d'attribuer des adresses IP flottantes aux nœuds de passerelle.

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

Le nombre d'adresses IP flottantes que vous spécifiez a une incidence sur la fiabilité de votre cluster. Par exemple, une passerelle NAT de sortie fonctionne en spécifiant une seule adresse IP flottante, mais une défaillance du nœud peut entraîner des interruptions du trafic. Si vous ajoutez d'autres adresses IP flottantes, AnthosNetworkGateway les attribue et les déplace si nécessaire. Nous vous recommandons de fournir au moins deux adresses IP flottantes pour le domaine L2 utilisé dans le cluster.

Le contrôleur 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 (maître, nœud de calcul) : les nœuds de calcul prévalent sur les nœuds maîtres lors de l'attribution d'adresses IP flottantes.
• Si un nœud possède une adresse IP flottante, le contrôleur 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 AnthosNetworkGateway. Notez que l'objet AnthosNetworkGateway se trouve dans l'espace de noms kube-system. Si un nœud de passerelle est indisponible, le contrôleur de AnthosNetworkGateway 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 AnthosNetworkGateway et voir comment les adresses IP flottantes sont allouées :

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

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

   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
   

2. Utilisez la commande suivante pour récupérer l'état de AnthosNetworkGateway et l'allocation d'adresses pour un nœud spécifique.

   kubectl -n kube-system get anthosnetworkgatewaynode.networking.gke.io NODE_NAME -oyaml
   

   Remplacez NODE_NAME par le nom du nœud ou de la machine spécifique que vous souhaitez inspecter.

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 de la plage 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

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

Spécifier une adresse IP source pour le trafic de sortie

Indiquez l'adresse IP source que vous souhaitez utiliser dans le champ egressSourceIP. L'adresse IP source doit correspondre à l'une des adresses IP flottantes spécifiées dans la ressource personnalisée AnthosNetworkGateway.

À l'aide de l'exemple EgressNATPolicy de la section précédente, si les critères de sélection et d'adresse IP de destination du pod sont remplis, le trafic sortant du pod est traduit par 192.168.1.100 en utilisant SNAT.

Pour que la route soit acceptée, l'adresse egressSourceIP doit se trouver dans le même sous-réseau que l'adresse IP du nœud de passerelle. Si l'adresse egressSourceIP est inconnue (non attribuée) au nœud de passerelle, la requête de routage ne peut pas être traitée. Dans ce cas, vous obtiendrez une erreur UnknownEgressIP dans les événements Kubernetes.

Utilisez la commande kubectl suivante pour imprimer les événements de l'objet EgressNATPolicy :

kubectl describe EgressNATPolicy egress

S'il existe plusieurs RS EgressNATPolicy, chacune doit avoir une adresse egressSourceIP différente. Pour éviter les conflits, travaillez en coordination avec l'équipe de développement.

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