Unité 6.1 : Conception de la plateforme Kubernetes

Introduction

La décision qui régit la conception d'une solution Managed Kubernetes ne porte pas sur « quel Kubernetes », mais sur « où IONOS CLOUD cesse d'assurer la gestion et où vous commencez ». IONOS CLOUD exploite le plan de contrôle à votre place et ne facture pas ce service ; vous êtes responsable de la capacité des nœuds de travail, de la couche d'équilibrage de charge, de la politique de réseau intra-cluster et de la posture de conformité de tout ce qui s'exécute au-dessus. Définir précisément cette frontière est ce qui distingue une conception qui fonctionne en production d'une conception qui suppose des facilités propres aux hyperscalers que la plateforme ne fournit pas.

Cette unité est consacrée uniquement à la conception. Elle établit l'architecture et les compromis à prendre en compte ; le cluster public est créé dans Data Center Designer à l'unité 6.2, et la variante privée à l'unité 6.3. Lisez cette unité pour comprendre les limites, puis construisez en vous y conformant.

1. La frontière de gestion : plan de contrôle gratuit, Node Pools payants

Managed Kubernetes est structuré en deux couches avec des responsabilités distinctes, une facturation différente et des SLA différents.

Le plan de contrôle (kube-apiserver, kube-scheduler, kube-controller-manager, etcd) est entièrement géré par IONOS CLOUD et est masqué : ses composants ne sont pas visibles pour vous et ne peuvent pas être modifiés directement, et le kube-apiserver n'est accessible que via son API REST. La valeur de la matrice pour le modèle de facturation est simple : le plan de contrôle est gratuit. La précision est importante et doit accompagner l'affirmation : la couche de service est gratuite, mais vous payez toujours le calcul et le stockage des Node Pools sous-jacents. Une affirmation selon laquelle « Managed Kubernetes est gratuit » sans cette précision est trompeuse.

Les Node Pools constituent la capacité de travail. Leurs serveurs sont des instances Compute Engine ordinaires provisionnées dans votre centre de données virtuel ; au sein d'un Node Pools, tous les serveurs sont identiques en configuration. Vous choisissez le type de serveur par pool parmi Dedicated Core ou vCPU. La correspondance CPU est cohérente entre les deux : un core provisionné équivaut à deux CPU Managed Kubernetes (deux threads logiques par unité CPU).

Les deux couches ont des SLA distincts, et c'est un point aveugle fréquent dans la conception :

Le SLA du plan de contrôle est limité à l'API Kubernetes du plan de contrôle uniquement, et non à vos charges de travail ni à la disponibilité des Node. Les Node Pools, étant basés sur Compute Engine, héritent du SLA Compute Engine en tant qu'engagement distinct et supplémentaire. Concevoir pour la disponibilité signifie donc concevoir vos Node Pools et votre charge de travail pour la résilience ; le SLA du plan de contrôle géré ne s'étend à aucun des deux.

Sur le plan opérationnel, IONOS CLOUD maintient le plan de contrôle à jour : les versions Kubernetes prises en charge sont 1.34, 1.33, 1.32 et 1.31, avec un écart maximal d'une version mineure entre le plan de contrôle et les Node Pools. Le CNI est Calico, fixe, sans option pour choisir un CNI différent, et il constitue le substrat des politiques de réseau discutées à la section 4.

2. Node Pools en tant que capacité immuable et à mise à l'échelle automatique

Un Node Pools est l'unité de capacité et l'unité de cycle de vie. Deux propriétés guident la conception.

Les Nodes sont immuables. Les Nodes ne sont jamais corrigés sur place. Lorsqu'un Node Pools est mis à niveau, que ce soit automatiquement pendant la fenêtre de maintenance hebdomadaire ou manuellement pour un changement de version, chaque Node du pool est reconstruit : un ancien Node est remplacé par un nouveau. Deux faits de planification en découlent. Premièrement, une reconstruction peut ajouter un Node actif supplémentaire facturable pendant le remplacement, de sorte que le quota de serveurs du contrat doit disposer d'une marge de manœuvre, sinon la reconstruction est bloquée. Deuxièmement, tout ce qui doit survivre à un Node doit résider hors du Node : l'état persistant doit se trouver sur des volumes persistants de Block Storage via le provisionneur CSI (cloud.ionos.com), et jamais sur le disque local. La fenêtre de maintenance est limitée à quatre heures par exécution ; dimensionnez votre PodDisruptionBudget et le nombre de répliques de manière à ce qu'un remplacement progressif ne fasse jamais passer la charge de travail sous le quorum.

Les Node Pools sont à mise à l'échelle automatique, mais il n'y a pas de réduction à zéro. L'autoscaler de cluster agrandit un pool lorsque des Pods ne peuvent pas être planifiés pour manque de CPU ou de mémoire, et le réduit lorsque les Nodes restent sous-utilisés et que leurs Pods peuvent être déplacés ailleurs. Il ne dépassera pas le maximum que vous avez défini (ni le quota du contrat), et il ne peut pas réduire un pool à zéro. La limite pratique est un Node chaud : un cluster qui existe coûte au moins un Node par pool que vous maintenez actif. Concevez les coûts autour de cette limite en consolidant les charges de travail intermittentes sur un pool partagé plutôt que de maintenir de nombreux pools à usage unique, chacun fixé à un seul Node chaud.

Limites de dimensionnement à respecter lors de la conception (les maximums recommandés et les plafonds stricts sont distincts et ne doivent pas être confondus) :

Le schéma consiste à prévoir un Node Pools par classe de charge de travail (par exemple, un pool pour les services généraux et un pool séparé pour les charges de travail gourmandes en mémoire ou limitées par les cœurs dédiés), chacun avec sa propre plage de mise à l'échelle automatique, reposant sur une base d'un Node.

3. Les quatre frontières

Ce sont les éléments fondamentaux de l'unité. Chacune est un point où Managed Kubernetes ne se comporte pas comme une offre gérée par un hyperscaler, et chacune possède un modèle natif à utiliser pour la composition.

3.1 Un service LoadBalancer est une IP statique sur un seul Node, et non un Load Balancer géré

C'est la frontière la plus susceptible de provoquer une interruption de service si elle est mal comprise. L'implémentation actuelle d'un service de type LoadBalancer n'implémente pas un Load Balancer véritable devant le cluster. Au lieu de cela, IONOS CLOUD réserve une adresse IP publique statique et l'assigne comme IP secondaire à un seul Node worker, qui agit ensuite comme nœud d'entrée. Si le pod cible ne s'exécute pas sur ce Node, kube-proxy effectue un NAT du trafic vers l'endroit où le pod réside.

Trois conséquences en découlent directement :

• Aucune haute disponibilité provenant du service lui-même. Un seul Node porte l'IP. S'il tombe en panne, ce point d'accès est indisponible jusqu'à ce que l'IP soit réassignée.
• L'IP source est perdue sauf si vous configurez externalTrafficPolicy: Local, car kube-proxy effectue un NAT du trafic.
• Le débit est limité par l'interface publique de ce seul Node, soit jusqu'à 2 Gbit/s. Vous n'obtenez pas la bande passante agrégée du cluster sur l'IP du service.

Le modèle natif consiste à exposer uniquement le contrôleur d'entrée comme un service LoadBalancer et à acheminer tout le reste via l'entrée interne au cluster. Pour dépasser la limite d'un seul Node, vous réservez plusieurs IP statiques et les répartissez sur plusieurs nœuds d'entrée (une IP par Node, distribuée par DNS), en réservant ces IP en dehors du cluster afin qu'elles subsistent après une reconstruction des Nodes. Notez également que le type de service LoadBalancer est pris en charge uniquement sur les pools de Nodes publics ; les pools de Nodes privés ne le prennent pas en charge et ne disposent pas d'IP statiques de Node. Lorsque vous avez besoin d'un routage géré de niveau 7 authentique avec terminaison TLS, il s'agit du Managed Application Load Balancer provisionné séparément du Module 3, placé devant le cluster ; il n'est pas provisionné automatiquement à partir d'un manifeste. L'Unité 6.2 couvre le câblage de cette entrée gérée.

3.2 Les événements du plan de contrôle n'atteignent pas le Logging Service

Les journaux des pools de Nodes sont acheminés vers le Logging Service d'IONOS CLOUD (l'export vers Object Storage est pris en charge), mais les événements du plan de contrôle géré ne le sont pas. Étant donné que le plan de contrôle est masqué et exploité par IONOS CLOUD, les journaux de ses composants sont en dehors de votre plan de télémétrie. Vous ne trouverez pas les événements de kube-apiserver ou du planificateur dans votre pipeline de journalisation.

Concevez autour de cela en instrumentant ce que vous possédez : les journaux d'application et de niveau Node via la pile de journalisation interne au cluster vers le Logging Service ou Object Storage, et la visibilité d'audit de l'API Kubernetes construite à partir de vos propres ressources. Ne concevez pas un workflow d'alerte ou d'analyse forensique qui suppose que les journaux d'événements du plan de contrôle sont disponibles ; ils ne le sont pas, et l'Unité 7.2 traite cela comme l'un des points aveugles d'observabilité fixes de la plateforme.

3.3 Les groupes de sécurité ne peuvent pas être appliqués aux Nodes worker de Managed Kubernetes

Les pare-feu de niveau carte réseau (NIC) et les Network Security Groups ne peuvent tout simplement pas être appliqués aux Nodes worker de Managed Kubernetes : les Nodes des pools de Nodes sont explicitement exclus de l'adhésion aux NSG, et les NSG ne s'appliquent pas non plus au plan de contrôle géré ni aux Load Balancers gérés. Un groupe de sécurité n'a aucun point d'attache sur l'infrastructure du cluster.

Le seul mécanisme de segmentation disponible au niveau des pods et des espaces de noms est celui des politiques de réseau Kubernetes internes au cluster, appliquées par le CNI Calico fixe ; les pare-feu de carte réseau et les Network Security Groups ne sont pas une option pour le contrôle de périmètre de niveau Node sur Managed Kubernetes. Le trafic entre les Nodes et le plan de contrôle est lui-même sécurisé par TLS mutuel, de sorte que la confidentialité entre les Nodes et le plan de contrôle est gérée par la plateforme ; votre rôle est la politique de charge de travail est-ouest à l'intérieur du cluster.

3.4 L'attribution de la conformité couvre l'infrastructure, et non les charges de travail

Managed Kubernetes s'inscrit dans le certificat ISO 27001 basé sur IT-Grundschutz (délivré par le BSI le 2022-09-14, centres de données allemands). Il ne s'inscrit pas dans l'attestation BSI C5 : C5 (un Testat de type 1 délivré le 2023-11-07) couvre Compute Engine, Cloud Cubes et S3 Object Storage, mais pas Managed Kubernetes. Décrivez la portée avec précision et ne généralisez jamais en disant que « la plateforme est certifiée ».

Le point plus profond est la frontière d'attribution. Ces accréditations couvrent uniquement la couche d'infrastructure d'IONOS CLOUD : le service géré, les centres de données, les contrôles opérationnels. Elles n'attestent pas vos charges de travail. Vos images de conteneurs, votre configuration RBAC, vos politiques de réseau, la gestion des secrets et vos données d'application restent votre responsabilité et constituent les preuves que vous devez produire lors de tout audit. IONOS CLOUD chiffre les données de secret au repos et sécurise le canal entre les Nodes et le plan de contrôle par TLS mutuel, ce qui sont des contrôles d'infrastructure ; la sécurité de ce qui s'exécute dans les pods est celle du client. Pour une charge de travail soumise à réglementation, la portée IT-Grundschutz est le plancher de la ligne de responsabilité partagée, et non l'ensemble de l'histoire de la conformité.

4. Placement et souveraineté du plan de contrôle

L'endroit où le plan de contrôle est exécuté constitue une décision de souveraineté, et il est dépendant du type de cluster. Pour un cluster public, le plan de contrôle géré par IONOS CLOUD est exécuté à Francfort ou dans l'un des trois centres de données américains (Lenexa, Newark, Las Vegas). Pour un cluster privé, le plan de contrôle peut être créé dans n'importe quel centre de données, c'est-à-dire dans la région choisie par le client.

La souveraineté suit l'emplacement choisi. Si le plan de contrôle allemand (Francfort) est sélectionné, les données du plan de contrôle restent en Allemagne, préservant ainsi la souveraineté de l'UE et de l'Allemagne. Si un plan de contrôle américain est choisi, les métadonnées du plan de contrôle sont hébergées aux États-Unis, de sorte que la souveraineté allemande n'est pas obtenue pour ces métadonnées. Dans tous les cas, les charges de travail des pools de nœuds et leurs données restent dans la région client choisie, indépendamment de l'emplacement du plan de contrôle.

Pour une charge de travail allemande soumise à des réglementations, cela est déterminant : un cluster public laissé à l'emplacement par défaut peut placer les métadonnées du plan de contrôle dans un centre de données américain, ce qui entraîne une exposition à la juridiction américaine, même si les données des workers ne quittent jamais l'Allemagne. La réponse en matière de conception consiste à fixer le plan de contrôle à Francfort pour un cluster public, ou à utiliser un cluster privé (plan de contrôle dans la région allemande choisie) lorsque l'exigence est qu'aucune métadonnée du plan de contrôle ne quitte le pays. Cela renvoie directement aux fondements de la souveraineté dans l'Unité 1.4 : la souveraineté est une propriété de l'endroit où les données sont exploitées, appliquée comme un filtre sur chaque décision de placement, y compris celle-ci.

Étude de cas d'entreprise (FinCorp)

FinCorp, une entreprise allemande de services financiers soumise aux obligations du RGPD et du BSI, met en place sa plateforme de conteneurs pour les nouveaux services liés à l'IA. Les limites décrites ci-dessus déterminent la conception.

Étant donné que le premier cluster est en tête d'une API destinée aux clients, il s'agit d'un cluster public. Les architectes fixent donc son plan de contrôle à Francfort plutôt que d'accepter un placement par défaut qui pourrait placer les métadonnées dans un centre de données américain. Les pools de nœuds sont situés dans la région allemande, au même endroit que les charges de travail.

Ils définissent deux pools de nœuds : un pool de services généraux (vCPU, mise à l'échelle automatique de 1 à 6) et un pool Dedicated-Core pour un service sensible à la latence (mise à l'échelle automatique de 1 à 4). Les deux respectent le minimum d'un nœud chaud, et FinCorp accepte deux nœuds toujours actifs comme le prix à payer pour isoler les deux classes de charges de travail. L'état persistant est stocké sur des volumes CSI Block Storage, et une marge de quota est réservée afin qu'un nœud supplémentaire facturable lors d'une reconstruction de maintenance ne provoque jamais de blocage.

À la périphérie, FinCorp n'expose qu'un contrôleur d'entrée et place un Managed Application Load Balancer provisionné séparément en amont pour assurer la haute disponibilité et la terminaison TLS qu'une IP d'entrée à nœud unique ne peut pas offrir. À l'intérieur du cluster, les politiques réseau Calico segmentent l'espace de noms destiné aux clients des services internes. Les Network Security Groups au niveau des cartes réseau ne peuvent tout simplement pas être appliqués aux nœuds de travail, car les nœuds des pools de nœuds sont exclus de l'adhésion aux NSG. À des fins d'audit, FinCorp consigne que l'IT-Grundschutz couvre l'infrastructure Managed Kubernetes, tandis que ses propres images, sa configuration RBAC et ses données d'application restent des preuves que FinCorp doit produire. Elle transmet les journaux d'application et des nœuds vers Object Storage, sachant que les événements du plan de contrôle n'y apparaîtront pas.

Résumé de la décision

Résumé

Managed Kubernetes vous offre un plan de contrôle entièrement géré et gratuit, soumis à son propre SLA API de 99,95 %, et vous laisse la responsabilité des pools de Node facturés (avec leur SLA hérité de Compute Engine), de l'extrémité d'équilibrage de charge, de la politique réseau intra-cluster, de l'observabilité de ce que vous exécutez, et de la conformité de vos charges de travail. Concevez les pools de Node comme une capacité immuable et à mise à l'échelle automatique avec un plancher d'un Node chaud, et architecturez délibérément autour des quatre frontières, car chacune d'entre elles est un endroit où supposer un comportement de type hyperscaler entraîne une interruption de service, un angle mort, ou un échec d'audit.

Points clés :

• Le plan de contrôle est gratuit et géré sous un SLA de 99,95 % limité à l'API ; les pools de Node sont une capacité Compute Engine facturée sous un SLA distinct hérité de 99,95 %. Conservez la précision « vous payez pour l'infrastructure » sur toute affirmation de « gratuité ».
• Les Node sont immuables et reconstruits à chaque mise à niveau ou exécution hebdomadaire de maintenance ; conservez l'état sur des volumes Block Storage CSI et maintenez une marge de quota serveur pour le Node de reconstruction supplémentaire facturable.
• Il n'y a pas de mise à l'échelle à zéro ; le plancher de mise à l'échelle automatique est d'un Node chaud par pool, il est donc préférable de consolider les charges de travail intermittentes plutôt que d'exécuter de nombreux pools à usage unique.
• Un service LoadBalancer est une IP statique sur un seul Node (pools publics uniquement, jusqu'à 2 Gbit/s, sans HA, IP source perdue sans externalTrafficPolicy: Local) ; utilisez un contrôleur d'ingress derrière un Managed ALB provisionné séparément pour un comportement d'extrémité réel.
• Les événements du plan de contrôle n'atteignent jamais le Logging Service, les groupes de sécurité au niveau des NIC ne peuvent pas être appliqués aux nœuds de travail (utilisez les politiques réseau Calico pour la segmentation des charges de travail), et le périmètre IT-Grundschutz couvre la couche infrastructure, et non vos charges de travail. C5 ne couvre pas Managed Kubernetes.
• Le placement du plan de contrôle dépend du type de cluster et détermine la souveraineté : fixer Francfort (public) ou utiliser un cluster privé dans la région allemande choisie pour conserver les métadonnées du plan de contrôle dans le pays.

Terminologie importante :

• Pool de Node : Un ensemble de nœuds de travail identiquement configurés, provisionnés en tant qu'instances Compute Engine dans votre VDC ; l'unité de capacité, de type de serveur et de mise à l'échelle automatique, et immuable car les Node sont remplacés plutôt que patchés.
• Node d'ingress : Le nœud de travail unique auquel l'IP statique d'un service LoadBalancer est attachée en tant qu'IP secondaire ; il transporte le trafic externe de ce service et kube-proxy effectue le NAT vers le pod cible.

Pour aller plus loin

• Unité 6.2 : Provisionnement d'un Cluster public (la construction de la conception publique ici)
• Unité 6.3 : Provisionnement d'un Cluster privé (plan de contrôle privé, réseau en priorité)
• Unité 1.4 : Souveraineté et conformité en tant qu'entrées de conception
• Unité 7.2 : Observabilité et opérations (le manque de journalisation du plan de contrôle dans son contexte)