Version 1.15. Cette version n'est plus compatible. Pour en savoir plus sur la mise à niveau vers la version 1.16, consultez la section Mettre à niveau des clusters dans la dernière documentation. Pour en savoir plus sur les versions compatibles et non compatibles, consultez la page Historique des versions dans la dernière documentation.

Configurer une passerelle NAT de sortie

Ce document explique comment configurer une passerelle NAT de sortie pour GDCV pour 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.

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.

Schéma de la passerelle NAT de sortie pour GKE sur une solution Bare Metal

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

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.
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.
Le nœud de passerelle reçoit le trafic de sortie.
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.
Le trafic retour est renvoyé au nœud de passerelle avec la destination 192.168.1.100.
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.
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.15.11.

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 :

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

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.

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

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

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

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

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