11 min de lecture

Objectifs d'apprentissage

À la fin de ce module, vous serez en mesure de:

  • Expliquer avec précision ce qu'un Cluster privé isole (le plan de données Node) et ce qu'il n'isole pas (le point de terminaison Kubernetes API), et de protéger correctement le API.
  • Établir la séquence des deux dépendances réseau (une passerelle NAT et, pour le trafic Node entre centres de données virtuels, un Cross Connect privé) qui doivent exister avant la création du Cluster.
  • Placer le plan de contrôle dans la région pour la souveraineté numérique et réfléchir aux champs qui deviennent permanents lors de la création.
  • Provisionner un Cluster privé et un pool Node privé dans le Data Center Designer, en réutilisant le modèle de Cluster public de l'unité 6.2.

Unité 6.3 : Provisionnement d'un Cluster privé

Introduction

Un Cluster privé est le paramètre par défaut de production pour un domaine réglementé : les Worker Nodes ne comportent pas de NIC publics, donc le plan de données n'est accessible qu'à travers votre réseau privé. Cette isolation est réelle, mais plus étroite que ce que le nom suggère, et la différence est là où les équipes sont touchées. Cette unité rend la limite honnête, corrige les prérequis réseau qui doivent exister en premier, puis construit la variante privée dans le Data Center Designer au-dessus du modèle public-Cluster de l'unité 6.2.

1. Ce que "Privé" isole, et ce qu'il ne fait pas

La décision privée s'applique au pool Node, et non à l'ensemble du service. Un pool Node privé est déployé dans un centre de données privé LAN derrière une passerelle NAT : le trafic sortant vers Internet est autorisé via la passerelle, mais le trafic entrant ne l'est pas. Les nœuds n'ont pas d'adresses publiques, et le trafic Node-vers-Kubernetes-service reste sur votre réseau privé. C'est l'isolation du plan de données que FinCorp souhaite pour les charges de travail qui touchent les données de compte sous GDPR et les contrôles BSI.

Ce que "privé" ne fait pas est cacher le serveur Kubernetes API. Le plan de contrôle est géré par IONOS et le point de terminaison API reste orienté vers Internet, quelle que soit le type de pool Node. Traiter "le Cluster privé" comme s'il protégeait également le pare-feu API est la principale méconception de cette unité. La plateforme vous donne un contrôle séparé pour cela : le Cluster comporte une liste d'autorisation API IP (le paramètre "Restreindre l'accès par IP"), vous pouvez donc protéger le API en répertoriant les plages de sources autorisées à y accéder, par exemple les adresses IP de sortie CI/CD de FinCorp et la sortie VPN de l'équipe d'exploitation. Isoler les nœuds et créer une liste d'autorisation pour le API sont des décisions indépendantes ; un Cluster privé conforme nécessite les deux.

Deux limites de l'unité 6.1 sont plus importantes ici. Le type de service LoadBalancer n'est pas disponible sur les Node Pools privés, donc le modèle d'entrée unique-Node a disparu ; l'entrée est un Load Balancer provisionné séparément plus un contrôleur d'entrée dans le Cluster (le modèle de l'unité 6.2). Et les Network Security Groups sont liés aux cartes réseau des workers, et non à l'abstraction Cluster, donc les stratégies de réseau dans le Cluster restent votre contrôle au niveau du pod.

2. Les deux dépendances réseau (Construire ceux-ci en premier)

Un Cluster privé est d'abord et avant tout un réseau : la boîte de dialogue de création de Cluster demande une passerelle IP qui doit déjà exister, donc le réseau doit être construit avant le Cluster.

Passerelle NAT pour la sortie. Les nœuds privés ont toujours besoin d'Internet sortant pour les téléchargements d'images, les mises à jour de packages et de sécurité, NTP, et le trafic Backup Service. Ce chemin est la Managed NAT Gateway, qui est uniquement SNAT : elle ne fournit pas d'entrée (pas de DNAT), ce qui est exactement la propriété qui maintient le plan de données privé. La passerelle nécessite une adresse IPv4 publique réservée, et cette adresse IP réservée devient la passerelle IP du Cluster. Un détail crucial : la route par défaut vers la passerelle n'est pas injectée automatiquement. Pour les machines virtuelles privées, la table de routage doit être modifiée de sorte que la route par défaut (ou une route dédiée par cible) pointe vers la passerelle NAT ; l'intégration du Node Pool privé gère la sortie Node via la passerelle, mais vous êtes propriétaire de l'adresse IP réservée et de l'intention de routage. Une seule passerelle NAT peut servir jusqu'à six réseaux LAN privés.

Réseau Cross Connect privé pour le trafic Node entre centres de données virtuels. Lorsque les nœuds doivent accéder à des ressources dans un autre centre de données virtuel (pour FinCorp, le niveau de données privé du module 5 dans un centre de données virtuel séparé), ce chemin est-ouest est un réseau Cross Connect privé. Ses contraintes sont des règles d'éligibilité, et non des options : il s'agit de la même région et du même contrat uniquement (pas de région croisée, pas de contrat croisé), chaque carte réseau sur chaque centre de données virtuel connecté doit partager la même plage d'adresses IP, et chaque LAN ne peut appartenir qu'à une seule connexion Cross Connect. Sa bande passante est comparable à celle d'une carte réseau privée normale, et elle n'est pas gratuite. Établissez-la avant que les Node Pools qui dépendent de la portée entre centres de données virtuels ne soient lancés, ou ces nœuds seront configurés dans un réseau qui ne peut pas voir leurs dépendances.

DCD Implementation Walkthrough

Objectif de construction : Construire la variante privée en réutilisant les modèles de Cluster publics, en commençant par le réseau.

Vous créerez un Cluster privé et un pool de Node privé dans le Data Center Designer pour la plateforme de conteneurs FinCorp. Cela réutilise le flux de Cluster public de l'unité 6.2 ; les différences résident dans les prérequis de réseau et trois champs qui deviennent permanents. La présentation du pool de Node lui-même (paramètres de pool, modèle de Node, type de serveur, stockage, LAN attaché et adresses IP réservées) est identique à 6.2 et n'est pas répétée ici.

Prérequis : une adresse IPv4 réservée pour la passerelle NAT (DCD > Menu > Services de réseau > Gestion de IP) ; une passerelle NAT attachée au LAN privé avec la route par défaut de LAN pointant vers elle ; et, lorsque les nœuds nécessitent un autre centre de données virtuel, un Cross Connect privé en place. Le centre de données virtuel et sa région sont réutilisés à partir de modules précédents.

Étapes (dans le Data Center Designer) :

  1. Réservez une adresse IPv4 sous Menu > Services de réseau > Gestion de IP. Cela devient l'adresse IP de la passerelle, donc réservez-la avant d'ouvrir la boîte de dialogue de Cluster.
  2. Construisez la passerelle NAT : sélectionnez le centre de données, assurez-vous qu'un réseau privé avec le LAN de travailleur existe, ajoutez la passerelle NAT, connectez son interface source à ce LAN privé, et attribuez l'adresse IP publique réservée dans l'Inspecteur > Onglet Paramètres. Définissez la route par défaut de LAN privé pour pointer vers la passerelle.
  3. Allez à Menu > Conteneurs > Managed Kubernetes et sélectionnez + Créer Cluster. Entrez un nom suivant la convention d'affectation de noms Kubernetes (maximum 63 caractères, début et fin alphanumériques).
  4. Sélectionnez la version Kubernetes dans le menu déroulant.
  5. Dans le champ de type de pool de Node, choisissez Privé.
  6. Sélectionnez une Région dans le menu déroulant. Vous ne pouvez créer les centres de données virtuels de Cluster privé que dans la même région que Cluster, donc cela fixe la position de souveraineté maintenant.
  7. Dans Adresse IP de la passerelle, sélectionnez l'adresse IP réservée attribuée à votre passerelle NAT.
  8. (Facultatif) Définissez un Sous-réseau pour le LAN privé : un CIDR /16 qui ne doit pas chevaucher les réseaux de pod et de service de Cluster (pour Kubernetes 1.30 et supérieur, 100.96.0.0/12 et 100.64.0.0/18 ; pour les versions antérieures, 10.208.0.0/12 et 10.233.0.0/18).
  9. Sélectionnez + Créer Cluster. Une fois que Cluster est actif, ajoutez le pool de Node privé exactement comme dans l'unité 6.2 : un pool de Node nécessite un centre de données dans le même emplacement que Cluster, plus un LAN privé attaché et des adresses IP réservées.
  10. Définissez la liste d'autorisation d'adresse IP de API (Restreindre l'accès par IP) aux plages de sources autorisées à atteindre le API de Kubernetes, puis récupérez le kubeconfig pour vous connecter avec kubectl.

Erreurs courantes :

  • Traiter « privé » comme protégeant le API. Il protège les nœuds ; le API reste géré et accessible à Internet. Définissez la liste d'autorisation d'adresse IP séparément, ou le plan de contrôle est ouvert au monde.
  • Créer le Cluster avant la passerelle NAT. Le champ d'adresse IP de la passerelle nécessite une adresse IP réservée qui existe déjà sur une passerelle déployée.
  • Supposer que la sortie fonctionne. La route par défaut de NAT n'est pas injectée automatiquement ; définissez la route par défaut de LAN privé pour pointer vers la passerelle ou les images de traction et les mises à jour échouent silencieusement.
  • Choisir une région américaine pour le plan de contrôle sur une charge de travail liée à la souveraineté. Pour un Cluster privé, le plan de contrôle est créé dans le centre de données choisi, donc la sélection de la région est la décision de souveraineté.
  • Compter sur un service LoadBalancer. Il est indisponible sur les Node Pools privés ; utilisez un Load Balancer provisionné séparément plus un contrôleur d'entrée dans Cluster.
  • Oublier que les champs sont permanents. La région, l'adresse IP de la passerelle et le sous-réseau ne peuvent pas être modifiés après la mise en service, et le type de pool de Node ne peut pas être commuté entre privé et public.

3. Placement du plan de contrôle et immutabilité

Pour un Cluster privé, le plan de contrôle est créé dans le centre de données que vous choisissez, donc les métadonnées du plan de contrôle restent dans la région choisie. Le choix de l'emplacement allemand (Francfort) permet de conserver les données du plan de contrôle de FinCorp en Allemagne et de préserver la souveraineté de l'UE/Allemagne ; les charges de travail et les données du Node Pool restent toujours dans la région choisie, quoi qu'il arrive. Il s'agit du levier pratique derrière le principe de souveraineté-comme-emplacement de l'unité 1.4, et il diffère d'un Cluster public, dont le plan de contrôle géré s'exécute à Francfort ou dans l'un des trois centres de données américains.

Plusieurs choix faits au moment de la création sont des décisions de conception permanentes, et non des valeurs par défaut de la console. Le type de Node Pool (privé ou public) est immuable après sa création, et la région, la passerelle IP et le sous-réseau d'un Cluster privé ne peuvent pas être modifiés une fois provisionnés. Vous pouvez toujours basculer le type de serveur d'un Node Pool entre Dedicated Core et vCPU, mais le type et l'ancrage du réseau sont fixes. Assurez-vous de choisir la bonne région et les prérequis du réseau avant de cliquer sur créer ; la seule solution après coup est de reconstruire le Cluster.

Résumé

Un Cluster privé isole le plan de données Node derrière une passerelle NAT qui n'autorise que le SNAT, tout en laissant l'endpoint internet API géré par IONOS accessible, donc une construction conforme associe un Node Pools privé à une liste d'autorisation explicite API IP. La construction est axée sur le réseau : une IP réservée et une passerelle NAT (avec la route par défaut définie), ainsi qu'un Cross Connect privé de même région et de même contrat pour le trafic Node entre centres de données virtuels, doivent exister avant la création du Cluster. Le placement du plan de contrôle dans la région allemande choisie préserve la souveraineté, et comme le type de pool Node, la région, l'adresse IP de la passerelle et le sous-réseau sont tous fixes lors de la création, les décisions prises ici sont permanentes.

Points clés :

  • Le privé isole les nœuds, et non le API ; protégez l'endpoint API avec la liste d'autorisation IP comme une étape séparée et obligatoire.
  • La passerelle NAT (sortie, SNAT uniquement, IP réservée, route par défaut manuelle) et le Cross Connect privé (entre centres de données virtuels, même région et même contrat uniquement) sont des prérequis, et non des ajouts ultérieurs.
  • Pour un Cluster privé, le plan de contrôle est situé dans la région choisie, donc la sélection de la région est la décision de souveraineté.
  • La région, l'adresse IP de la passerelle, le sous-réseau et le type de pool Node sont immuables après la création ; le didacticiel du pool Node lui-même est le même que l'unité 6.2.