Unité 6.1 : conception de la plateforme Kubernetes

Introduction

La décision qui régit une conception Managed Kubernetes n'est pas "quel Kubernetes" mais "où IONOS cesse de gérer et où vous commencez". IONOS gère le plan de contrôle pour vous et ne vous facture pas pour cela ; vous êtes propriétaire de la capacité de travail, de l'équilibrage de charge, de la politique de réseau in-Cluster et de la posture de conformité de tout ce qui s'exécute au-dessus. Traiter cette limite avec précision est ce qui sépare une conception qui se comporte en production d'une conception qui suppose des commodités hyperscaler que la plateforme ne fournit pas.

Cette unité est réservée à la conception. Elle établit l'architecture et les compromis ; le Cluster public est construit dans le Data Center Designer à l'unité 6.2 et la variante privée à l'unité 6.3. Lisez cette unité pour les limites, puis construisez contre elles.

1. La limite gérée : plan de contrôle gratuit, Node Pools payant

Managed Kubernetes est structuré en deux couches avec une propriété différente, 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 et est caché : ses composants ne sont pas visibles pour vous et ne peuvent pas être modifiés directement, et le kube-apiserver n'est accessible qu'à travers son REST API. La valeur de la matrice pour le modèle de facturation est simple : le plan de contrôle est gratuit. Le qualificatif est important et doit accompagner l'affirmation : la couche de service est gratuite, mais vous payez toujours pour les ressources de calcul et de stockage sous-jacentes de la Node-pool. Une affirmation selon laquelle « Managed Kubernetes est gratuit » sans ce qualificatif est trompeuse.

Les Node Pools sont la capacité de travail. Leurs serveurs sont des instances Compute Engine ordinaires provisionnées dans votre centre de données virtuel ; dans une Node pool, tous les serveurs sont identiques en configuration. Vous choisissez le type de serveur par pool à partir de Dedicated Core ou vCPU. Le mappage CPU est cohérent pour les deux : un noyau provisionné équivaut à deux Managed Kubernetes CPUs (deux threads logiques par unité CPU).

Les deux couches ont des SLA séparés, et ceci est un point aveugle fréquent de la conception :

L'SLA du plan de contrôle est limité aux Kubernetes API du plan de contrôle uniquement, et non à vos charges de travail et non à la disponibilité de la Node. Les Node Pools, étant construits sur Compute Engine, héritent de l'SLA Compute Engine comme un engagement séparé et supplémentaire. La conception pour la disponibilité signifie donc concevoir vos Node Pools et votre charge de travail pour la résilience ; l'SLA du plan de contrôle géré ne s'étend pas à l'un ou à l'autre.

Opérationnellement, IONOS 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 maximum de décalage de version mineure d'un 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 est le substrat pour les politiques de réseau discutées dans la section 4.

2. Node Pools en tant que capacité autoscaling et immuable

Un pool Node est l'unité de capacité et l'unité de cycle de vie. Deux propriétés déterminent la conception.

Les nœuds sont immuables. Les nœuds ne sont jamais corrigés en place. Lorsqu'un pool Node est mis à niveau, que ce soit automatiquement pendant la fenêtre de maintenance hebdomadaire ou déclenché manuellement pour un changement de version, chaque Node du pool est reconstruit : un vieux Node est remplacé par un nouveau. Deux faits de planification découlent de cela. Premièrement, une reconstruction peut ajouter un Node actif supplémentaire facturable pendant le remplacement, donc le quota de serveurs du contrat doit avoir une marge ou la reconstruction stagne. Deuxièmement, tout ce qui doit survivre à un Node doit vivre en dehors du Node : l'état persistant appartient aux volumes persistants Block Storage via le provisionneur CSI (cloud.ionos.com), et non sur le disque local. La fenêtre de maintenance est limitée à quatre heures par exécution ; dimensionnez vos PodDisruptionBudget et les comptes de répliques de sorte qu'un remplacement progressif ne fasse jamais passer la charge de travail en dessous du quorum.

Node Pools autoscale, mais il n'y a pas d'échelle à zéro. L'autoscaleur Cluster augmente un pool lorsque les Pods ne peuvent pas être planifiés en raison d'un manque de CPU ou de mémoire, et le réduit lorsqu'un nœud reste sous-utilisé et que ses 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. Le plancher pratique est de un Node chaud : un Cluster qui existe coûte au moins un Node par pool que vous gardez en vie. Concevez les coûts autour de ce plancher en consolidant les charges de travail intermittentes sur un pool partagé plutôt que de maintenir de nombreux pools à usage unique, chacun fixé à un Node chaud.

Limites de dimensionnement pour concevoir (recommandées versus plafonds durs sont distincts et ne doivent pas être confondus) :

Le modèle est un pool Node par classe de charge de travail (par exemple, un pool pour les services généraux et un pool distinct pour les charges de travail lourdes en mémoire ou liées à Dedicated-Core), chacun avec sa propre bande d'autoscaling, reposant sur un plancher d'un Node.

3. Les quatre limites

Ce sont les éléments essentiels de l'unité. Chacun est un endroit où Managed Kubernetes ne se comporte pas comme une offre gérée par un hyperscaler, et chacun a un modèle natif pour composer autour de lui.

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

C'est la limite la plus susceptible de causer une panne si elle est mal comprise. La mise en œuvre actuelle d'un service de type LoadBalancer ne déploie pas un vrai Load Balancer devant le Cluster. Au lieu de cela, IONOS réserve une adresse IP publique statique et l'attribue en tant qu'adresse IP secondaire à un seul worker Node, qui agit ensuite comme le point d'entrée Node. Si le pod cible n'est pas en cours d'exécution sur ce Node, kube-proxy NAT les trafics vers l'endroit où vit le pod.

Trois conséquences découlent directement :

• Aucune haute disponibilité à partir du service lui-même. Un Node transporte l'adresse IP. Si celui-ci échoue, cet point de terminaison est arrêté jusqu'à ce que l'adresse IP soit réattribuée.
• L'adresse IP source est perdue à moins que vous n'ayez défini externalTrafficPolicy: Local, car kube-proxy NAT les trafics.
• Le débit est limité par l'interface publique de ce Node, qui peut aller jusqu'à 2 Gbit/s. Vous n'obtenez pas le débit agrégé Cluster au niveau du service IP.

Le modèle natif est d'exposer uniquement le contrôleur d'entrée en tant que service LoadBalancer et de router tout le reste via l'entrée in-Cluster. Pour mettre à l'échelle au-delà du plafond d'un Node, vous réservez plusieurs adresses IP statiques et les répartissez sur plusieurs nœuds d'entrée (une adresse IP par Node, distribuée par DNS), en réservant ces adresses à l'extérieur du Cluster afin qu'elles survivent aux reconstructions de Node. Notez également que le type de service LoadBalancer est pris en charge uniquement sur les Node Pools publics ; les Node Pools privés ne prennent pas en charge cela et ne disposent pas d'adresses IP statiques Node. Lorsque vous avez besoin d'une gestion réelle de routage de couche 7 avec TLS, c'est le Managed Application Load Balancer séparément provisionné de la Module 3, placé devant le Cluster ; il n'est pas auto-provisionné à partir d'un manifeste. L'unité 6.2 couvre le câblage de cette entrée gérée.

3.2 Les événements de plan de contrôle ne atteignent pas le Logging Service

Les journaux de pool Node s'écoulent vers le Logging Service IONOS (l'exportation vers Object Storage est prise en charge), mais les événements du plan de contrôle géré ne le font pas. Puisque le plan de contrôle est caché et exploité par IONOS, les journaux de composants sont en dehors de votre plan de télémétrie. Vous ne trouverez pas les événements kube-apiserver ou les événements de 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 in-Cluster vers le Logging Service ou le Object Storage, et la visibilité d'audit Kubernetes API construite à partir de vos propres ressources. Ne concevez pas un flux de travail d'alerte ou de forensique qui suppose que les journaux d'événements de plan de contrôle sont disponibles ; ils ne le sont pas, et l'unité 7.2 traite cela comme l'une des lacunes d'observabilité fixes de la plateforme.

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

Les pare-feu au niveau des interfaces réseau et Network Security Groups ne peuvent pas être appliqués aux Managed Kubernetes Worker Nodes du tout : les nœuds de pool Node sont explicitement exclus de l'appartenance aux groupes de sécurité, et les groupes de sécurité ne s'appliquent pas non plus au plan de contrôle géré ou aux équilibreurs de charge gérés. Un groupe de sécurité n'a aucun point d'attache sur l'infrastructure Cluster du tout.

Le seul mécanisme de segmentation disponible au niveau du pod et de l'espace de noms est les politiques de réseau in-Cluster Kubernetes, appliquées par le Calico CNI fixe ; les pare-feu d'interface réseau et Network Security Groups ne sont pas une option pour le contrôle de périmètre au niveau Node sur Managed Kubernetes. Les trafics entre les nœuds et le plan de contrôle sont eux-mêmes sécurisés par des TLS mutuels, donc la confidentialité Node-vers-plan de contrôle est gérée par la plateforme ; votre travail est la politique de charge de travail est-ouest à l'intérieur du Cluster.

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

Managed Kubernetes se situe dans le ISO 27001 basé sur IT-Grundschutz (accordé par le BSI le 2022-09-14, centres de données allemands). Il ne se situe pas dans l'attestation BSI C5 : C5 (un testat de type 1 accordé le 2023-11-07) couvre Compute Engine, Cloud Cubes, et S3 Object Storage, mais pas Managed Kubernetes. Déclarez précisément la portée et ne généralisez jamais à "la plateforme est certifiée".

Le point plus profond est la limite d'attribution. Ces informations d'identification couvrent uniquement la couche d'infrastructure IONOS : le service géré, les centres de données, les contrôles opérationnels. Ils ne certifient pas vos charges de travail. Vos images de conteneur, configuration RBAC, politiques de réseau, gestion de secrets et données d'application restent votre responsabilité et vos preuves à produire dans toute audit. IONOS chiffre les données secrètes au niveau REST et sécurise le canal Node-vers-plan de contrôle avec des TLS mutuels, qui sont des contrôles d'infrastructure ; la sécurité de ce qui s'exécute dans le Pods est celle du client. Pour une charge de travail réglementée, la portée IT-Grundschutz est le plancher de la ligne de responsabilité partagée, et non l'histoire de conformité complète.

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

L'endroit où s'exécute le plan de contrôle est une décision de souveraineté, et elle dépend du type de Cluster. 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). 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. Choisissez le plan de contrôle allemand (Francfort) et les données du plan de contrôle restent en Allemagne, en préservant ainsi la souveraineté de l'Union européenne et de l'Allemagne. Choisissez un plan de contrôle américain et les métadonnées du plan de contrôle résident 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 du Node Pool et leurs données restent dans la région choisie par le client, quel que soit l'emplacement du plan de contrôle.

Pour une charge de travail réglementée en Allemagne, c'est décisif : un Cluster public laissé à la disposition par défaut peut placer les métadonnées du plan de contrôle dans un centre de données américain, ce qui implique une exposition juridictionnelle américaine, même si les données des travailleurs ne quittent jamais l'Allemagne. La réponse 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 que aucune métadonnée du plan de contrôle ne quitte le pays. Cela se rattache directement à la fondation 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, la société de services financiers allemande sous les obligations GDPR et BSI, met en place sa plateforme de conteneurs pour les nouveaux services adjacents à l'IA. Les limites ci-dessus déterminent la conception.

Puisque le premier Cluster est exposé aux clients et fronts un API orienté client, il s'agit d'un Cluster public, donc les architectes fixent son plan de contrôle à Francfort plutôt que d'accepter le placement par défaut qui pourrait stocker les métadonnées dans un centre de données américain ; les Node Pools se trouvent dans la région allemande avec les charges de travail.

Ils définissent deux Node Pools : un pool de services généraux (vCPU, mise à l'échelle automatique de 1 à 6) et un pool de cœurs dédiés pour un service sensible à la latence (mise à l'échelle automatique de 1 à 4). Les deux respectent le plancher d'un Node chaud, et FinCorp accepte deux nœuds toujours actifs comme le prix de l'isolement des deux classes de charges de travail. L'état persistant est stocké sur des volumes Block Storage CSI, et une marge de quota est réservée pour que la reconstruction de maintenance ne bloque jamais en raison d'un coût supplémentaire pour les Node.

À la limite, FinCorp n'expose qu'un contrôleur d'entrée et place un Managed Application Load Balancer provisionné séparément à l'avant pour la haute disponibilité et la terminaison TLS, ce qu'un seul Node d'entrée IP ne peut pas offrir. À l'intérieur du Cluster, les politiques de réseau Calico segmentent l'espace de noms orienté client des services internes ; les règles de pare-feu au niveau NIC ne peuvent pas être appliquées au Worker Nodes, puisque les nœuds du pool Node sont exclus de l'appartenance au groupe de sécurité NSG. Pour l'audit, FinCorp enregistre que l'IT-Grundschutz couvre l'infrastructure Managed Kubernetes, tandis que ses propres images, RBAC, et les données d'application restent les preuves à produire par FinCorp, et il transmet les journaux d'application et les Node à Object Storage, sachant que les événements du plan de contrôle n'apparaîtront pas là.

Résumé de la décision

Résumé

Managed Kubernetes vous offre un plan de contrôle entièrement géré et gratuit sous sa propre SLA de 99,95 % API, et vous laisse posséder des Node Pools facturables (avec leur SLA Compute Engine hérité), l'équilibrage de charge, la politique de réseau dans les Cluster, l'observabilité de ce que vous exécutez, et la conformité de vos charges de travail. Conceptionnez les Node Pools comme une capacité autoscaling immuable, avec un plancher d'un Node chaud, et architectez délibérément autour des quatre limites, car chacune d'elles est un endroit où supposer un comportement hyperscaler produit une panne, un angle mort, ou un audit échoué.

Points clés :

• Le plan de contrôle est gratuit et géré sous une SLA de 99,95 % API uniquement ; les Node Pools sont des capacités Compute Engine facturables sous une SLA héritée distincte de 99,95 %. Conservez le qualificatif « vous payez pour l'infrastructure » sur toute revendication « gratuite ».
• Les nœuds sont immuables et reconstruits à chaque mise à jour ou exécution d'entretien hebdomadaire ; conservez l'état sur les volumes Block Storage CSI et conservez la tête de file pour le serveur pour la reconstruction facturable Node.
• Il n'y a pas de mise à l'échelle à zéro ; le plancher d'autoscaling est d'un Node chaud par pool, donc consolidez les charges de travail intermittentes plutôt que d'exécuter de nombreux pools à usage unique.
• Un service LoadBalancer est un Node statique unique IP (pools publics uniquement, jusqu'à 2 Gbit/s, sans haute disponibilité, source IP perdue sans externalTrafficPolicy: Local) ; utilisez un contrôleur d'entrée derrière un ALB géré provisionné séparément pour un comportement réel de bordure.
• Les événements du plan de contrôle ne atteignent jamais le Logging Service, les groupes de sécurité au niveau des cartes réseau ne peuvent pas être appliqués aux Worker Nodes (utilisez les politiques de réseau Calico pour la segmentation des charges de travail), et la portée IT-Grundschutz couvre la couche d'infrastructure, et non vos charges de travail. C5 ne couvre pas Managed Kubernetes.
• Le placement du plan de contrôle est dépendant du type Cluster et décide de la souveraineté : épingler Francfort (public) ou utilisez un Cluster privé dans la région allemande choisie pour garder les métadonnées du plan de contrôle dans le pays.

Terminologie importante :

• Pool Node : Un ensemble de Worker Nodes configurés de manière identique provisionnés en tant qu'instances Compute Engine dans votre centre de données virtuel ; l'unité de capacité, de type de serveur et d'autoscaling, et immuable dans la mesure où les nœuds sont remplacés plutôt que corrigés.
• Entrée Node : Le worker Node unique auquel un service LoadBalancer est attaché comme IP secondaire ; il transporte le trafic externe de ce service et kube-proxy NAT vers le pod cible.

Lecture supplémentaire

• 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 premier)
• Unité 1.4 : Souveraineté et conformité en tant qu'entrées de conception
• Unité 7.2 : Observabilité et opérations (l'écart de journalisation du plan de contrôle dans le contexte)