Kubernetes est un orchestrateur de conteneurs, le cloud est l’endroit où on le fait le plus souvent tourner. L’expression « Kubernetes cloud » recouvre donc deux réalités liées : exécuter Kubernetes sur une infrastructure cloud, et s’appuyer sur un service Kubernetes managé opéré par un fournisseur.
Kubernetes n’est pas un cloud
Kubernetes est un orchestrateur de conteneurs open source. Le fonctionnement de Kubernetes repose sur l’orchestration de conteneurs répartis sur un ensemble de machines : il planifie leur placement, les déploie, supervise leur cycle de vie, gère leur mise à l’échelle et leur exposition réseau. Ces conteneurs sont souvent construits avec Docker, et la distinction entre Kubernetes et Docker prête d’ailleurs elle-même à confusion.
Ce que Kubernetes ne fait pas, c’est fournir les machines, le stockage et le réseau sous-jacents. Il a besoin d’une infrastructure pour s’exécuter, et cette infrastructure peut prendre plusieurs formes : des serveurs physiques (bare metal), des machines virtuelles, un cloud privé ou un cloud public. C’est cette couche que fournit un fournisseur cloud.
De là vient une confusion fréquente, celle qui consiste à comparer « Kubernetes » et « AWS », ou Kubernetes et un fournisseur cloud en général. Les deux n’occupent pas la même couche. Un fournisseur cloud vend de l’infrastructure, et propose fréquemment un Kubernetes managé par-dessus. Kubernetes, lui, orchestre les conteneurs qui tournent sur cette infrastructure. On ne choisit pas entre Kubernetes et le cloud : on peut faire tourner Kubernetes sur un cloud, ou utiliser le service Kubernetes managé que ce cloud propose.
Autrement dit, choisir une infrastructure et choisir qui opère le cluster sont deux décisions distinctes. C’est ce qui structure les familles d’offres que nous allons décrire ensuite.
Faire tourner Kubernetes dans le cloud : managé ou auto-géré
Une fois posée cette relation, deux modèles d’exploitation se présentent. Soit vous installez et opérez Kubernetes vous-même sur des machines louées à un fournisseur cloud, soit vous passez par un service managé, où le fournisseur opère le control plane à votre place.
Le control plane est la ligne de partage entre les deux. Il regroupe les composants qui pilotent le cluster : l’apiserver, etcd (le datastore qui conserve l’état du cluster), le scheduler et le controller-manager. L’opérer soi-même implique de gérer les montées de version, que le projet Kubernetes impose de suivre puisqu’il ne maintient en support que ses trois versions mineures les plus récentes, la rotation des certificats TLS internes, la haute disponibilité de ces composants sur plusieurs nœuds, la sauvegarde et la cohérence d’etcd, ainsi que les correctifs de sécurité sous contrainte de temps. Un service managé retire cette couche de vos responsabilités : vous conservez la maîtrise de vos workloads, de vos node pools et de leur sécurité, mais n’administrez plus l’infrastructure critique du cluster.
Tous les besoins ne justifient pas un cluster complet. Des distributions plus légères, comme K3s, existent et méritent d’être évaluées selon la charge et le contexte. Et Kubernetes, managé ou non, reste un modèle opérationnel parmi d’autres. Un PaaS relève d’un autre modèle : vous livrez du code, la plateforme se charge du build, de l’exécution et de la mise à l’échelle, sans que vous ayez à opérer d’orchestrateur. PaaS et Kubernetes répondent à des besoins différents et complémentaires, et une même organisation peut recourir aux deux.
Les trois familles d’offres pour faire tourner Kubernetes dans le cloud
Les offres se répartissent en trois familles : selon que vous opérez le cluster vous-même ou qu’un fournisseur s’en charge, et, dans ce second cas, selon que ce fournisseur est un hyperscaler mondial ou un acteur européen.
Le self-managed sur infrastructure cloud
Vous louez le calcul, le stockage et le réseau auprès d’un fournisseur, puis installez et opérez Kubernetes vous-même. Cette approche offre le contrôle le plus complet sur le cluster et sur l’infrastructure sous-jacente, au prix de la charge opérationnelle décrite plus haut. Elle a du sens lorsque des contraintes précises d’infrastructure, de réseau ou de conformité ne sont pas couvertes par les offres managées disponibles. C’est aussi l’approche des équipes qui veulent garder la main sur chaque composant du cluster, du runtime de conteneurs à la configuration de l’ordonnancement et du réseau interne.
Le managé chez un hyperscaler
Les grands fournisseurs cloud mondiaux proposent des services Kubernetes managés : Amazon EKS, Google GKE, Microsoft AKS. Le fournisseur opère le control plane, et vous déployez vos workloads avec l’outillage standard de Kubernetes. Ces offres sont étroitement intégrées à l’écosystème de chaque fournisseur, ce qui fait leur intérêt lorsque vos autres services y résident déjà, et le point de vigilance si vous envisagez d’en changer. Leurs opérateurs relèvent en revanche de juridictions non européennes, y compris pour les régions qu’ils exploitent en Europe. Ces offres ne répondent donc pas à une exigence de souveraineté européenne, critère déterminant pour certains secteurs et certains types de données.
Le managé chez un fournisseur européen
Plusieurs fournisseurs européens proposent un Kubernetes managé sur une infrastructure située dans l’Union européenne. La localisation compte, mais elle ne fait pas la souveraineté. Un datacenter installé en Europe reste soumis aux législations extraterritoriales si l’entreprise qui l’exploite relève d’une juridiction étrangère : la région européenne d’un fournisseur américain demeure exposée au Cloud Act. Ce qui détermine la souveraineté, c’est le contrôle juridique et capitalistique de l’opérateur, pas l’emplacement des serveurs.
Sur ce terrain, plusieurs acteurs proposent un Kubernetes managé : OVHcloud (Managed Kubernetes Service) ou Scaleway (Kubernetes Kapsule). Clever Cloud propose Clever Kubernetes Engine, un Kubernetes managé opéré par une entreprise française. Au-delà de la localisation, ces offres se distinguent par le niveau réel de souveraineté, qui dépend de l’opérateur et de la chaîne de sous-traitance, et par leur compatibilité avec les outils déjà en place. Pour aller plus loin, les offres françaises de Kubernetes managé font l’objet d’un article dédié.
Kubernetes cloud : ce qu’il faut retenir
« Kubernetes cloud » désigne le fait de faire tourner Kubernetes sur une infrastructure cloud, ainsi que les services managés que les fournisseurs proposent pour éviter d’opérer le cluster soi-même. La ligne de partage entre auto-géré et managé passe par le control plane, cette couche que le fournisseur prend ou non en charge. Trois familles d’offres se présentent alors : le self-managed sur infrastructure cloud, le managé chez un hyperscaler, et le managé chez un fournisseur européen, étant entendu que la localisation en Europe ne suffit pas à elle seule à rendre une offre souveraine. Laquelle convient dépend de vos contraintes d’infrastructure, de l’outillage déjà en place, et de vos exigences en matière de données et de souveraineté. L’essentiel tient en une distinction : le cloud fournit l’infrastructure, Kubernetes orchestre ce qui tourne dessus, et le modèle managé détermine qui, du fournisseur ou de vous, opère le cluster entre les deux.
Reste ensuite à déterminer quand un Kubernetes managé se justifie et comment le choisir, et à préciser ce que recouvre réellement un Kubernetes souverain.
FAQ
Kubernetes est-il un cloud ?
Non. Kubernetes est un orchestrateur de conteneurs, pas un fournisseur d’infrastructure. Un cloud fournit les serveurs, le stockage et le réseau ; Kubernetes orchestre les conteneurs qui s’exécutent dessus. On peut le faire tourner sur un cloud, ou utiliser le service Kubernetes managé qu’un cloud propose.
Peut-on faire tourner Kubernetes en dehors du cloud, sur du bare metal ou de l’on-premise ?
Oui. Kubernetes est agnostique de l’infrastructure : il fonctionne sur des serveurs physiques, des machines virtuelles, un cloud privé ou public, et sur des environnements hybrides combinant plusieurs de ces options. Le cloud est le contexte le plus courant, pas une obligation.
« Kubernetes cloud » et « Kubernetes managé », est-ce la même chose ?
Pas exactement. « Kubernetes cloud » désigne au sens large le fait de faire tourner Kubernetes sur une infrastructure cloud, ce qui inclut aussi bien un cluster que vous opérez vous-même qu’un service managé. « Kubernetes managé » désigne spécifiquement l’offre dans laquelle un fournisseur opère le control plane à votre place. Tout Kubernetes managé est du Kubernetes dans le cloud, mais l’inverse n’est pas toujours vrai.
Quelle différence entre Kubernetes et un fournisseur cloud comme AWS ?
Ils opèrent à des couches différentes. AWS est un fournisseur cloud : il vend de l’infrastructure et propose, par-dessus, un Kubernetes managé (Amazon EKS). Kubernetes est l’orchestrateur qui pilote les conteneurs sur cette infrastructure. Les opposer revient à confondre l’entrepôt et le système qui organise ce qu’on y range.