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 des nœuds) et ce qu'il n'isole pas (le point d'accès de l'API Kubernetes), et protéger correctement l'API.
  • Ordonner les deux dépendances réseau (une passerelle NAT et, pour le trafic inter-VDC des nœuds, un Private Cross Connect) qui doivent exister avant la création du Cluster.
  • Placer le plan de contrôle dans la région pour des raisons de souveraineté et raisonner sur les champs qui deviennent permanents à la création.
  • Provisionner un Cluster privé et un pool de nœuds privés dans 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 la configuration par défaut en production pour un environnement réglementé : les nœuds de travail ne disposent d'aucune carte réseau publique, de sorte que le plan de données n'est accessible que via votre réseau privé. Cette isolation est réelle, mais plus restreinte que ce que le nom laisse supposer, et c'est précisément cette nuance qui pose problème aux équipes. Cette unité clarifie cette limite, corrige les prérequis réseau qui doivent être en place au préalable, puis construit la variante privée dans Data Center Designer en s'appuyant sur le modèle de cluster public présenté dans l'unité 6.2.

1. Ce que « privé » isole, et ce qu'il n'isole pas

La décision de confidentialité s'applique au pool de nœuds, et non à l'ensemble du service. Un pool de nœuds privé est déployé dans un LAN privé derrière une passerelle NAT : le trafic sortant vers Internet est autorisé via la passerelle, tandis que le trafic entrant ne l'est pas. Les nœuds ne disposent d'aucune adresse publique, et le trafic entre les nœuds et les services Kubernetes reste sur votre réseau privé. C'est l'isolation du plan de données que FinCorp souhaite pour les charges de travail accédant aux données de compte sous le contrôle du RGPD et de la BSI.

Ce que le mode privé ne fait pas, c'est masquer le serveur d'API Kubernetes. Le plan de contrôle est géré par IONOS CLOUD et le point d'accès API reste accessible depuis Internet, quel que soit le type de pool de nœuds. Considérer un « cluster privé » comme s'il protégeait également l'API par un pare-feu est la méconception centrale de cette unité. La plateforme vous offre un contrôle distinct à cet effet : le cluster dispose d'une liste d'autorisation d'IP pour l'API (le paramètre « Restrict Access by IP »), de sorte que vous protégez l'API en listant les plages de sources autorisées à y accéder, par exemple les IP de sortie CI/CD de FinCorp et la sortie VPN de l'équipe d'exploitation. L'isolation des nœuds et la liste d'autorisation de l'API sont des décisions indépendantes ; un cluster privé conforme nécessite les deux.

Deux limites issues de l'Unité 6.1 sont plus importantes ici. Le type de service LoadBalancer n'est pas disponible sur les pools de nœuds privés, de sorte que le motif du nœud d'entrée unique n'existe plus ; l'entrée est un équilibreur de charge provisionné séparément, associé à un contrôleur d'entrée au sein du cluster (le motif de l'Unité 6.2). Et les groupes de sécurité réseau sont liés aux interfaces réseau des nœuds de travail, et non à l'abstraction du cluster, de sorte que les politiques réseau au sein du cluster restent votre contrôle au niveau des pods.

2. Les deux dépendances réseau (à créer en premier)

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

Passerelle NAT pour la sortie. Les nœuds privés ont toujours besoin d'un accès sortant à Internet pour les téléchargements d'images, les mises à jour de paquets et de sécurité, NTP et le trafic de Backup Service. Ce chemin est assuré par la Managed NAT Gateway, qui est uniquement en SNAT : elle ne fournit aucun accès entrant (pas de DNAT), ce qui est précisément la propriété qui maintient le plan de données privé. La passerelle nécessite une adresse IPv4 publique réservée, et cette IP réservée devient l'adresse IP de la passerelle du cluster. Un détail critique : la route par défaut vers la passerelle n'est pas injectée automatiquement. Pour les VM privées, la table de routage doit être modifiée afin que la route par défaut (ou une route dédiée par destination) pointe vers la passerelle NAT ; l'intégration du pool de nœuds privés gère la sortie des nœuds via la passerelle, mais vous êtes responsable de l'IP réservée et de l'intention de routage. Une seule passerelle NAT peut servir jusqu'à six LAN privés.

Cross Connect privé pour le trafic inter-VDC des nœuds. Lorsque les nœuds doivent atteindre des ressources dans un autre centre de données virtuel (pour FinCorp, la couche de données privée du Module 5 dans un VDC distinct), ce chemin est-ouest est un Cross Connect privé. Ses contraintes sont des règles d'éligibilité, pas des options : il est limité à la même région et au même contrat (pas d'inter-région, pas d'inter-contrat), chaque carte réseau de chaque VDC connecté doit partager la même plage 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 il n'est pas gratuit. Établissez-le avant que les pools de nœuds qui dépendent de l'accessibilité inter-VDC ne démarrent, sinon ces nœuds seront provisionnés dans un réseau qui ne peut pas voir leurs dépendances.

Déroulement de la mise en œuvre de DCD

Objectif de construction : Construire la variante privée en réutilisant les schémas du cluster public, en commençant par le réseau.

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

Prérequis : une adresse IPv4 réservée pour la passerelle NAT (DCD > Menu > Network Services > IP Management) ; une passerelle NAT attachée au LAN privé avec la route par défaut du LAN pointant vers celle-ci ; et, lorsque les Node nécessitent un autre VDC, un Cross Connect privé en place. Le VDC et sa région sont réutilisés depuis des modules antérieurs.

Étapes (dans Data Center Designer) :

  1. Réservez une adresse IPv4 sous Menu > Network Services > IP Management. Cela devient l'IP de la passerelle, il faut donc la réserver avant d'ouvrir la boîte de dialogue du cluster.
  2. Construisez la passerelle NAT : sélectionnez le centre de données, assurez-vous qu'un réseau privé avec le LAN des workers existe, ajoutez la passerelle NAT, connectez son interface source à ce LAN privé et assignez l'IP publique réservée dans l'onglet Inspector > Settings. Configurez la route par défaut du LAN privé pour qu'elle pointe vers la passerelle.
  3. Allez dans Menu > Containers > Managed Kubernetes et sélectionnez + Create Cluster. Saisissez un Nom en suivant la convention de nommage Kubernetes (63 caractères maximum, début et fin alphanumériques).
  4. Sélectionnez la Version Kubernetes dans la liste déroulante.
  5. Dans le champ Type de pool de Node, choisissez Private.
  6. Sélectionnez une Région dans la liste déroulante. Vous ne pouvez créer les VDC du cluster privé que dans la même région que le cluster, ce qui fixe donc le placement de souveraineté dès maintenant.
  7. Dans Gateway IP, sélectionnez l'IP réservée assignée à votre passerelle NAT.
  8. (Facultatif) Définissez un Sous-réseau pour le LAN privé : un CIDR /16 qui ne doit pas se superposer aux réseaux de pods et de services du cluster (pour Kubernetes 1.30 et les versions ultérieures, 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 + Create Cluster. Une fois le cluster 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 situé au même endroit que le cluster, ainsi qu'un LAN privé attaché et des IP réservées.
  10. Configurez la liste d'autorisation des IP de l'API (Restrict Access by IP) pour les plages de source autorisées à atteindre l'API Kubernetes, puis récupérez le kubeconfig pour vous connecter avec kubectl.

Erreurs courantes :

  • Considérer « private » comme protégeant l'API. Il protège les Node ; l'API reste gérée et accessible depuis Internet. Configurez la liste d'autorisation des IP séparément, sinon le plan de contrôle est ouvert au monde entier.
  • Créer le cluster avant la passerelle NAT. Le champ Gateway IP nécessite une IP réservée qui existe déjà sur une passerelle déployée.
  • Supposer que l'émission fonctionne automatiquement. La route par défaut du NAT n'est pas injectée automatiquement ; configurez la route par défaut du LAN privé vers la passerelle, sinon les téléchargements d'images et les mises à jour échouent silencieusement.
  • Choisir une région américaine pour le plan de contrôle sur une charge de travail soumise à des contraintes de souveraineté. Pour un cluster privé, le plan de contrôle est créé dans le centre de données choisi, la sélection de la région est donc la décision de souveraineté.
  • Compter sur un Service LoadBalancer. Il n'est pas disponible sur les pools de Node privés ; utilisez un équilibreur de charge provisionné séparément ainsi qu'un contrôleur d'ingress dans le cluster.
  • Oublier que les champs sont permanents. La Région, l'IP de la passerelle et le Sous-réseau ne peuvent pas être modifiés après le provisionnement, et le type de pool de Node ne peut pas être basculé entre privé et public.

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

Pour un cluster privé, le plan de contrôle est créé dans le centre de données que vous choisissez, de sorte que les métadonnées du plan de contrôle restent dans la région sélectionnée. Le choix de l'emplacement Allemagne (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 et de l'Allemagne ; les charges de travail et les données des pools de nœuds restent toujours dans la région choisie, indépendamment de tout autre facteur. C'est le levier pratique derrière le principe de souveraineté par le placement présenté dans l'Unité 1.4, et cela diffère d'un cluster public, dont le plan de contrôle managé s'exécute à Francfort ou dans l'un des trois centres de données situés aux États-Unis.

Plusieurs choix effectués lors de la création sont des décisions de conception permanentes, et non des valeurs par défaut de la console. Le type de pool de nœuds (privé ou public) est immuable après la création, et la Région, l'IP de la passerelle et le sous-réseau du cluster privé ne peuvent pas être modifiés une fois le déploiement effectué. Vous pouvez toujours changer le type de serveur d'un pool de nœuds entre Dedicated Core et vCPU, mais le type et l'ancrage réseau sont fixes. Assurez-vous de bien définir la région et les prérequis réseau avant de cliquer sur créer ; le seul correctif possible par la suite est de reconstruire le cluster.

Résumé

Un cluster privé isole le plan de données des nœuds derrière une passerelle NAT en mode SNAT uniquement, tout en laissant l'endpoint API géré par IONOS CLOUD accessible depuis Internet. Une configuration conforme associe donc des pools de nœuds privés à une liste d'autorisation d'IP API explicite. Cette configuration est centrée sur le réseau : une IP réservée et une passerelle NAT (avec la route par défaut configurée), ainsi qu'un Private Cross Connect dans la même région et sous le même contrat pour le trafic inter-VDC des nœuds, doivent exister avant la création du cluster. Placer le plan de contrôle dans la région allemande choisie préserve la souveraineté, et comme le type de pool de nœuds, la région, l'IP de la passerelle et le sous-réseau sont tous figés à la création, les décisions prises ici sont définitives.

Points clés :

  • Le mode privé isole les nœuds, pas l'API ; protégez l'endpoint API à l'aide de la liste d'autorisation d'IP comme étape distincte et obligatoire.
  • La passerelle NAT (sortie, SNAT uniquement, IP réservée, route par défaut manuelle) et le Private Cross Connect (inter-VDC, uniquement même région et même contrat) sont des prérequis, et non des ajouts ultérieurs.
  • Pour un cluster privé, le plan de contrôle se situe dans la région choisie ; le choix de la région est donc la décision de souveraineté.
  • La région, l'IP de la passerelle, le sous-réseau et le type de pool de nœuds sont immuables après la création ; le parcours du pool de nœuds lui-même est identique à celui de l'Unité 6.2.