Unité 6.2 : Provisionnement d'un Cluster public

Introduction

L'unité 6.1 a réglé les décisions de conception : un plan de contrôle géré gratuit sur un Node Pools payant, pas de mise à l'échelle à zéro, des groupes de sécurité liés aux NIC des workers plutôt qu'au Cluster, et la dure réalité qu'un service LoadBalancer n'est pas un Load Balancer externe géré. Cette unité met en œuvre un Cluster public dans le Data Center Designer. La construction est courte ; les décisions conséquentes sont le type et la version du serveur Node-pool (qui fixent les choses que vous ne pouvez pas changer plus tard), la façon dont le stockage persistant est provisionné via le pilote CSI, et la façon dont le trafic atteint réellement votre Pods. FinCorp a besoin d'un Cluster public pour héberger le niveau API sans état qui fait face à sa nouvelle capacité d'intelligence artificielle, nous construisons donc exactement cela.

1. Les décisions qui fixent les corrections

Deux choix effectués dans l'assistant de création sont effectivement permanents. Le type de pool Node ne peut pas être commuté entre public et privé après la création, et un pool Node public est ce qui permet un type de service LoadBalancer (les pools privés ne le supportent pas). Le niveau API de FinCorp est orienté vers Internet, donc un pool public est correct ici ; le niveau de données réglementées reste sur le Cluster privé construit dans l'unité 6.3.

Le type de serveur est choisi par pool Node à partir de Dedicated Core ou vCPU. La mise en correspondance des ressources CPU est fixe : un noyau provisionné équivaut à deux processeurs Managed Kubernetes CPU. Le plafond recommandé est de 20 nœuds par pool Node (maximum dur de 100), et un pool Node peut contenir jusqu'à 110 Pods et jusqu'à 20 volumes attachés. FinCorp utilise Dedicated Core pour le niveau API pour obtenir un noyau exclusif et une planification prévisible sous charge.

La disposition du plan de contrôle décide de la souveraineté. Pour un Cluster public, le plan de contrôle géré par IONOS s'exécute à Francfort ou dans l'un des trois centres de données américains (Lenexa, Newark, Las Vegas) ; le choix de Francfort permet de maintenir les données du plan de contrôle en Allemagne, la seule option acceptable pour FinCorp en vertu de la BSI et du GDPR. Les charges de travail et les données du pool Node restent toujours dans la région cliente choisie, quel que soit le cas. Notez également les limites honnêtes de 6.1 : les attestations BSI couvrent la couche d'infrastructure IONOS, et non les charges de travail sur le Cluster, et les événements de plan de contrôle Kubernetes ne transitent pas par le Logging Service d'IONOS.

2. Stockage persistant via le pilote CSI

Le Cluster provisionne des volumes Block Storage en tant que volumes persistants Kubernetes via le pilote CSI d'IONOS, dont le provisionneur est cloud.ionos.com. Vous contrôlez le placement et le type en définissant une classe de stockage. L'exemple ci-dessous attribue le stockage SSD à une zone de disponibilité et active l'expansion 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 l'association jusqu'à ce qu'un pod soit planifié, donc le Volume se trouve dans la même zone que le Node 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 restant dans le VDC, donc la politique de réclamation est une décision de cycle de vie délibérée, et non une option par défaut pour ignorer.

3. Ingress : il n'y a pas de Load Balancer géré automatiquement

Ceci est la limite qui surprend le plus souvent les équipes arrivant d'un hyperscaler. Un Service de type LoadBalancer ne déploie pas un véritable Load Balancer externe devant le Cluster. IONOS alloue une adresse publique statique IP et l'attribue en tant qu'adresse secondaire IP à un seul worker Node, qui devient le Node d'entrée ; si le pod cible s'exécute ailleurs, kube-proxy NAT les trafics vers celui-ci. Deux conséquences suivent. Le débit est limité par le plafond public de ce Node, donc pour mettre à l'échelle au-delà de celui-ci, vous réservez plusieurs adresses IP et les répartissez sur plusieurs nœuds d'entrée (DNS équilibrage de charge). Et le NAT remplace l'adresse source IP, donc l'adresse du client est perdue à moins que vous n'ayez défini externalTrafficPolicy: Local.

Le modèle de production consiste donc à exposer un seul contrôleur d'entrée ingress controller en tant que service LoadBalancer et à le laisser acheminer les HTTP à l'intérieur du Cluster, plutôt que d'exposer chaque service d'application. Réservez l'adresse d'entrée IP dans la gestion IP en dehors de Kubernetes afin qu'elle ne soit pas libérée lorsque le service est supprimé, puis attachez-la à un Node d'entrée dédié.

Lorsque FinCorp a besoin d'un véritable gestionnaire de couche 7 géré 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 nécessite une adresse publique IP réservée, met fin à TLS (son écouteur accepte exactement un certificat feuille, éventuellement avec sa chaîne d'autorités de certification dans le même fichier), et est connecté aux nœuds Cluster en tant que cibles. Rien dans un manifeste Kubernetes ne provisionne ou configure celui-ci ; c'est une ressource distincte que vous créez et pointez vers les nœuds d'entrée.

DCD Procédure de mise en œuvre

Vous allez créer un Managed Kubernetes Cluster public avec un pool de Node dédiés, récupérer son kubeconfig, définir une classe de stockage CSI, et le mettre à l'avant avec un contrôleur d'entrée exposé via une IP réservée. Prérequis : la permission Create Kubernetes Clusters (propriétaires de contrats, administrateurs et utilisateurs autorisés), et une IPv4 publique réservée dans la gestion de IP pour le point de terminaison d'entrée.

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

Étapes (dans le Data Center Designer) :

1. Allez dans Menu > Conteneurs > Managed Kubernetes, puis sélectionnez + Créer Cluster. Entrez un nom de Cluster suivant les conventions de nommage de Kubernetes et choisissez la version de Kubernetes. Pour FinCorp, sélectionnez un plan de contrôle à Francfort pour conserver les données du plan de contrôle en Allemagne.
2. Ouvrez le nouveau Cluster et allez à l'onglet Node Pools dans Cluster, puis sélectionnez Créer un pool de Node.
3. Dans les paramètres du pool, entrez un nom de pool, sélectionnez le centre de données où se trouvent les nœuds (créez-en un si nécessaire), choisissez la version du pool de Node, et définissez le nombre de Node.
4. Activez facultativement la mise à l'échelle automatique et fournissez un nombre minimum et maximum de Node. Le plancher est un Node chaud ; il n'y a pas de mise à l'échelle à zéro.
5. Dans le modèle de Node, définissez le type de serveur sur Dedicated Core (par défaut) ou vCPU, puis choisissez Cœurs, RAM, et zone de disponibilité. N'oubliez pas qu'un cœur provisionné correspond à deux Managed Kubernetes CPUs.
6. Sous IP réservés, ajoutez la IP publique réservée qui sera utilisée pour le point de terminaison d'entrée, et attachez les LAN privés requis. Mettez à disposition le pool de Node et attendez que les nœuds atteignent l'état ACTIF.
7. Récupérez l'accès : dans l'onglet Paramètres de Cluster, téléchargez kubeconfig.yaml (ou .json), ou utilisez la CLI : ionosctl k8s kubeconfig get --cluster-id CLUSTERID. Pointez kubectl vers le fichier.
8. Appliquez la classe de stockage CSI de la section 2 (provisioner: cloud.ionos.com), puis déployez un contrôleur d'entrée et exposez uniquement son service de type LoadBalancer, épinglé à votre IP réservée. Placez les services d'application derrière ce contrôleur, et non directement sur Internet.

Erreurs courantes :

• Traiter un service LoadBalancer comme un équilibreur de charge géré. Il s'agit d'une adresse IP statique à un seul Node avec kube-proxy NAT, limitée à un débit de Node. Exposez uniquement le contrôleur d'entrée de cette façon ; utilisez un équilibreur de charge géré ALB distinct pour la couche 7 réelle devant le Cluster.
• Oublier externalTrafficPolicy: Local lorsque l'application nécessite la véritable adresse IP du client. Le chemin NAT par défaut supprime l'adresse source.
• Laisser Kubernetes réserver automatiquement l'adresse IP d'entrée. Réservez-la dans la gestion de IP avant de supprimer le service, afin de ne pas libérer l'adresse (et de rompre vos enregistrements DNS).
• Choisir le mauvais type de pool de Node. Les pools publics et privés ne peuvent pas être commutés après leur 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 pour conserver les données du plan de contrôle en Allemagne.
• S'attendre à ce que les journaux de Cluster et les événements du plan de contrôle soient dans le Logging Service. Les événements du plan de contrôle ne s'y trouvent pas ; planifiez un transfert séparé.

Résumé

Un Managed Kubernetes Cluster public est une construction courte dont le poids repose sur quelques choix irréversibles : le type de pool Node et le type de serveur, le placement du plan de contrôle pour la souveraineté, et la façon dont le stockage persistant et l'entrée sont réellement mis en œuvre. Le stockage est dynamique via le pilote cloud.ionos.com CSI par le biais d'une classe de stockage que vous définissez ; l'entrée n'est pas automatique, vous devez donc placer le Cluster avec un contrôleur d'entrée dans le Cluster sur un IP réservé et utiliser un Managed ALB provisionné séparément lorsque vous avez besoin d'une véritable couche 7 gérée. FinCorp a maintenant son niveau public API prêt à composer avec le niveau de données privé construit à côté.

Points clés :

• Un pool public Node permet le type de service LoadBalancer ; les pools privés ne le permettent pas, et le type est immuable après la création.
• Le pilote IONOS CSI (provisioner: cloud.ionos.com) provisionne les Block Storage en tant que volumes persistants ; la classe de stockage fixe le type, la zone, l'expansion et le comportement de réclamation.
• Un service LoadBalancer est un IP statique à un seul Node avec kube-proxy NAT, et non un équilibreur de charge externe géré ; mettez à l'échelle sur plusieurs adresses IP d'entrée et réservez-les à l'extérieur du Kubernetes.
• La source IP est perdue sans externalTrafficPolicy: Local ; un Managed ALB provisionné séparément fournit une véritable couche 7 et une terminaison TLS devant le Cluster.
• Choisissez un plan de contrôle de Francfort pour les clusters publics afin de maintenir les données du plan de contrôle en Allemagne ; les événements du plan de contrôle ne parviennent pas au Logging Service.

Terminologie importante :

• Pilote CSI : le plugin d'interface de stockage de conteneur (cloud.ionos.com) qui provisionne dynamiquement les Block Storage IONOS en tant que volumes persistants Kubernetes.
• Entrée Node : le worker Node unique qui reçoit l'adresse IP statique d'un service LoadBalancer en tant qu'adresse IP secondaire et achemine le trafic via kube-proxy.
• Classe de stockage : l'objet Kubernetes qui définit la façon dont les volumes persistants sont provisionnés (type, zone de disponibilité, système de fichiers, expansion, mode d'association).

Lecture supplémentaire

• Unité 6.1 : conception de la plateforme Kubernetes (les décisions de conception que cette construction réalise)
• Unité 6.3 : mise à disposition d'un Cluster privé (la variante privée en premier lieu pour le réseau)
• Unité 3.3 : équilibrage de charge - Couche 7 (Application) (le front Managed ALB)