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 :
Le trafic sortant est généré à partir d'un pod avec l'adresse IP
10.10.10.1dans un nœud avec l'adresse IP192.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éeEgressNATPolicy.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.1est 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.
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 :
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 la 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
AnthosNetworkGatewayet voir comment les adresses IP flottantes sont allouées :kubectl -n kube-system get anthosnetworkgateway.networking.gke.io default -oyamlLa réponse pour un cluster avec deux nœuds,
worker1etworker2, 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: worker1Utilisez la commande suivante pour récupérer l'état de
AnthosNetworkGatewayet l'allocation d'adresses pour un nœud spécifique.kubectl -n kube-system get anthosnetworkgatewaynode.networking.gke.io NODE_NAME -oyamlRemplacez 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
podSelectoret d'unnamespaceSelector. - 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.
- Chaque règle se compose d'un
Spécifiez les adresses de destination autorisées dans la section
destinationCIDRs.destinationCIDRsprend 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: frontendest attribuée au pod. - Le pod se trouve dans un espace de noms libellé
user: aliceouuser: 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.