Unité 6.2 : Provisionnement d'un Cluster public

Introduction

L'unité 6.1 a défini les décisions de conception : un plan de contrôle managé gratuit au-dessus de pools de nœuds payants, l'absence de mise à l'échelle à zéro, des groupes de sécurité liés aux interfaces réseau des nœuds de travail plutôt qu'au cluster, et la réalité incontournable qu'un Service de type LoadBalancer n'est pas un équilibreur de charge externe managé. Cette unité met en œuvre un cluster public dans Data Center Designer. La construction est courte ; les décisions déterminantes concernent le type et la version des serveurs du pool de nœuds (qui fixent des éléments que vous ne pourrez pas modifier ultérieurement), la manière dont le stockage persistant est provisionné via le pilote CSI, et la façon dont le trafic atteint réellement vos pods. FinCorp a besoin d'un cluster accessible publiquement pour héberger la couche d'API sans état qui fait face à sa nouvelle capacité IA, nous construisons donc exactement cela.

1. Les décisions figées par la configuration

Deux choix effectués dans l'assistant de création sont définitifs. Le type de pool de nœuds ne peut pas être basculé entre public et privé après la création, et un pool de nœuds public est ce qui permet d'utiliser un type de Service LoadBalancer (les pools privés ne le prennent pas en charge). La couche API de FinCorp est exposée sur Internet, donc un pool public est approprié ici ; la couche de données réglementées reste sur le cluster privé construit dans l'Unité 6.3.

Le type de serveur est sélectionné pour chaque pool de nœuds, soit Dedicated Core, soit vCPU. La correspondance des ressources CPU est fixe : un cœur provisionné équivaut à deux CPU Managed Kubernetes. La limite recommandée est de 20 Node par pool de nœuds (maximum absolu de 100), et un Node peut porter jusqu'à 110 pods et jusqu'à 20 volumes attachés. FinCorp utilise Dedicated Core pour la couche API afin d'obtenir un cœur exclusif et une planification prévisible sous charge.

L'emplacement du plan de contrôle détermine la souveraineté. Pour un cluster public, le plan de contrôle géré IONOS CLOUD fonctionne à Francfort ou dans l'un des trois centres de données américains (Lenexa, Newark, Las Vegas) ; le choix de Francfort conserve les données du plan de contrôle en Allemagne, la seule option acceptable pour FinCorp conformément au BSI et au RGPD. Les charges de travail et les données des pools de nœuds restent toujours dans la région client choisie, indépendamment de cela. Notez également les limites honnêtes de la section 6.1 : les attestations BSI couvrent la couche d'infrastructure IONOS CLOUD, et non les charges de travail sur le cluster, et les événements du plan de contrôle Kubernetes ne transitent pas par le Logging Service IONOS CLOUD.

2. Stockage persistant via le pilote CSI

Le cluster provisionne des volumes Block Storage en tant que Persistent Volumes Kubernetes via le pilote CSI IONOS CLOUD, dont le provisionneur est cloud.ionos.com. Vous contrôlez l'emplacement et le type en définissant une StorageClass. L'exemple ci-dessous fixe le stockage SSD à une zone de disponibilité et active l'extension en ligne :

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ionos-enterprise-ssd-zone-1
provisioner: cloud.ionos.com
parameters:
  type: SSD
  fstype: ext4
  availabilityZone: ZONE2
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

WaitForFirstConsumer retarde la liaison jusqu'à ce qu'un pod soit planifié, de sorte que le Volume est placé dans la même zone que le nœud consommateur. Les volumes provisionnés dynamiquement sont gérés par le pilote CSI : avec la politique de réclamation Retain, un Volume survit à la suppression du PV et apparaît comme un volume résiduel dans le VDC ; la politique de réclamation est donc une décision de cycle de vie délibérée, et non un paramètre par défaut à ignorer.

3. Ingress : il n'existe pas d'équilibreur de charge managé automatique

C'est la limite qui surprend le plus souvent les équipes arrivant d'un hyperscaler. Un Service de type LoadBalancer ne déploie pas un équilibreur de charge externe véritable devant le cluster. IONOS CLOUD alloue une IP publique statique et l'assigne en tant qu'IP secondaire à un seul nœud de travail, qui devient le nœud d'ingress ; si le pod cible s'exécute ailleurs, kube-proxy applique le NAT du trafic vers celui-ci. Deux conséquences en découlent. Le débit est limité par le plafond public de ce nœud unique, de sorte que pour dépasser cette limite, vous réservez plusieurs IP et les répartissez sur plusieurs nœuds d'ingress (équilibrage de charge DNS). Et le NAT remplace l'IP source, de sorte que l'adresse du client est perdue à moins que vous ne définissiez externalTrafficPolicy: Local.

Le modèle de production consiste donc à exposer un unique contrôleur d'ingress au sein du cluster en tant que Service LoadBalancer et à lui laisser router le HTTP à l'intérieur du cluster, plutôt que d'exposer chaque Service d'application. Réservez l'IP d'ingress dans la gestion des IP en dehors de Kubernetes afin qu'elle ne soit pas libérée lorsque le Service est supprimé, puis attachez-la à un nœud d'ingress dédié.

Lorsque FinCorp a besoin d'un équilibrage de charge managé de couche 7 authentique devant le cluster, la réponse est un Managed Application Load Balancer provisionné séparément (Unité 3.3), et non un manifeste. L'ALB requiert une IP publique réservée, termine le TLS (son écouteur accepte exactement un certificat de feuille, éventuellement avec sa chaîne CA dans le même fichier) et est connecté aux nœuds du cluster en tant que cibles. Rien dans un manifeste Kubernetes ne le provisionne ou ne le configure ; c'est une ressource distincte que vous construisez et à laquelle vous pointez les nœuds d'ingress.

Déroulement de la mise en œuvre de DCD

Vous allez créer un cluster Managed Kubernetes public avec un pool de nœuds Dedicated Core, récupérer son kubeconfig, définir une classe de stockage CSI, et le placer derrière un contrôleur d'ingress exposé via une IP réservée. Prérequis : la permission Create Kubernetes Clusters (propriétaires de contrat, administrateurs et utilisateurs autorisés), ainsi qu'une adresse IPv4 publique réservée dans IP Management pour le point d'accès d'ingress.

Objectif de construction : Construire un cluster public de bout en bout.

Étapes (dans Data Center Designer) :

1. Accédez à Menu > Containers > Managed Kubernetes, puis sélectionnez + Create Cluster. Saisissez un nom de cluster conforme aux conventions de nommage Kubernetes et choisissez la version Kubernetes. Pour FinCorp, sélectionnez un plan de contrôle adossé à Francfort afin de conserver les données du plan de contrôle en Allemagne.
2. Ouvrez le nouveau cluster, accédez à l'onglet Node pools in Cluster, puis sélectionnez Create node pool.
3. Dans Pool Settings, saisissez un Pool Name, sélectionnez le Data Center où se trouvent les nœuds (créez-en un au préalable si nécessaire), choisissez la Node pool version et définissez le Node count.
4. Facultatif : activez Autoscale et fournissez un nombre minimal et maximal de nœuds. Le minimum est d'un nœud chaud ; il n'y a pas de mise à l'échelle à zéro.
5. Dans le Node Template, définissez Server type sur Dedicated Core (par défaut) ou vCPU, puis choisissez Cores, RAM et Availability Zone. Retenez qu'un cœur provisionné correspond à deux CPU Managed Kubernetes.
6. Sous Reserved IPs, ajoutez l'IP publique réservée qui servira de support au point d'accès d'ingress, et attachez les LAN privés nécessaires. Provisionnez le pool de nœuds et attendez que les nœuds atteignent l'état ACTIVE.
7. Récupérez l'accès : dans l'onglet Cluster Settings, téléchargez kubeconfig.yaml (ou .json), ou utilisez l'interface en ligne de commande : ionosctl k8s kubeconfig get --cluster-id CLUSTERID. Pointez kubectl vers le fichier.
8. Appliquez la StorageClass CSI de la section 2 (provisioner: cloud.ionos.com), puis déployez un contrôleur d'ingress et n'exposez que son Service avec le type LoadBalancer, ancré sur votre IP réservée. Placez les Services applicatifs derrière ce contrôleur, et non directement sur Internet.

Erreurs courantes :

• Considérer un Service LoadBalancer comme un équilibreur de charge managé. Il s'agit d'une IP statique sur un seul nœud avec NAT kube-proxy, limitée à la capacité d'un nœud. Exposez uniquement le contrôleur d'ingress de cette manière ; utilisez un Managed ALB provisionné séparément pour une vraie couche 7 devant le cluster.
• Oublier externalTrafficPolicy: Local lorsque l'application a besoin de l'IP client réelle. Le chemin NAT par défaut supprime l'adresse source.
• Laisser Kubernetes réserver automatiquement l'IP d'ingress. Réservez-la d'abord dans IP Management afin que la suppression du Service ne libère pas l'adresse (et ne casse pas vos enregistrements DNS).
• Choisir le mauvais type de pool de nœuds. Le passage de public à privé n'est pas possible après la création ; un pool privé ne prendrait pas en charge le Service LoadBalancer du tout.
• Placer le plan de contrôle dans un centre de données américain pour une charge de travail réglementée. Pour un cluster public, choisissez Francfort afin de conserver les données du plan de contrôle en Allemagne.
• S'attendre à trouver les journaux du cluster et les événements du plan de contrôle dans le Logging Service. Les événements du plan de contrôle n'y sont pas transmis ; prévoyez une redirection séparée.

Résumé

Un cluster Managed Kubernetes public est un déploiement rapide dont l'importance repose sur quelques choix irréversibles : le type de pool de nœuds et le type de serveur, le placement du plan de contrôle pour la souveraineté, et la manière dont le stockage persistant et l'ingress sont effectivement mis en œuvre. Le stockage est dynamique via le pilote CSI cloud.ionos.com à travers une StorageClass que vous définissez ; l'ingress n'est pas automatique, il faut donc placer un contrôleur d'ingress au sein du cluster sur une IP réservée et recourir à un Managed ALB provisionné séparément lorsque vous avez besoin d'une couche 7 gérée de manière véritable. FinCorp dispose désormais de sa couche API publique prête à être composée avec la couche de données privée construite ensuite.

Points clés :

• Un pool de nœuds public autorise le type de Service LoadBalancer ; les pools privés ne l'autorisent pas, et le type est immuable après la création.
• Le pilote CSI IONOS CLOUD (provisioner: cloud.ionos.com) provisionne le Block Storage sous forme de Persistent Volumes ; la StorageClass fixe le type, la zone, l'expansion et le comportement de récupération.
• Un Service LoadBalancer est une IP statique sur un seul nœud avec NAT via kube-proxy, et non un équilibreur de charge externe géré ; il faut mettre à l'échelle sur plusieurs IP d'ingress et les réserver en dehors de Kubernetes.
• L'IP source est perdue sans externalTrafficPolicy: Local ; un Managed ALB provisionné séparément fournit une couche 7 réelle et une terminaison TLS devant le cluster.
• Choisissez un plan de contrôle à Francfort pour les clusters publics afin de conserver les données du plan de contrôle en Allemagne ; les événements du plan de contrôle n'atteignent pas le Logging Service.

Terminologie importante :

• Pilote CSI : le plugin Container Storage Interface (cloud.ionos.com) qui provisionne dynamiquement le Block Storage IONOS CLOUD sous forme de Persistent Volumes Kubernetes.
• Nœud d'ingress : le nœud de travail unique qui reçoit l'IP statique d'un Service LoadBalancer comme IP secondaire et transfère le trafic via kube-proxy.
• StorageClass : l'objet Kubernetes qui définit la manière dont les volumes persistants sont provisionnés (type, zone de disponibilité, système de fichiers, expansion, mode de liaison).

Lectures complémentaires

• Unité 6.1 : Conception de la plateforme Kubernetes (les décisions de conception que cette construction met en œuvre)
• Unité 6.3 : Provisionnement d'un Cluster privé (la variante privée axée sur le réseau)
• Unité 3.3 : Équilibrage de charge - Couche 7 (application) (le front Managed ALB)