L’histoire de Kubernetes

En ce qui concerne l’infrastructure informatique moderne, le rôle de Kubernetes, la plateforme open-source d’ orchestration de conteneurs qui automatise le déploiement, la gestion et la montée en charge des applications logicielles et des services conteneurisés, ne peut être sous-estimé.

Selon un rapport de la Cloud Native Computing Foundation (CNCF) (lien externe à ibm.com), Kubernetes est le deuxième plus grand projet open source au monde (après Linux) et le principal outil d’orchestration de conteneurs pour 71 % des entreprises du Fortune 100. Pour comprendre comment Kubernetes s’est imposé sur les marchés du cloud computing et des microservices, il faut rappeler son histoire.

L’histoire de Kubernetes, dont le nom vient du grec ancien pour « pilote » ou « timonier » (la personne à la barre qui dirige le navire) remonte à 2013, lorsqu’un trio d’ingénieurs de Google – Craig McLuckie, Joe Beda et Brendan Burns – a lancé l’idée de créer un système de gestion de conteneurs open source. Ces pionniers de la technologie cherchaient des moyens d’intégrer l’expertise de Google en infrastructure interne dans le domaine du cloud computing à grande échelle, et de permettre à Google de concurrencer Amazon Web Services (AWS), le leader incontesté parmi les fournisseurs de cloud à cette époque.

Infrastructure informatique traditionnelle ou infrastructure informatique virtuelle

Mais pour vraiment comprendre l’histoire de Kubernetes, également appelé « Kube » ou « K8 » (un « numéronyme » (lien externe à ibm.com)), nous devons examiner les conteneurs dans le contexte de l’infrastructure informatique traditionnelle par rapport à celui de l’infrastructure informatique virtuelle.

Auparavant, les organisations exécutaient leurs applications uniquement sur des serveurs physiques (également appelés serveurs bare metal). Il n’y avait alors aucun moyen de maintenir les limites des ressources système pour ces applications. Par exemple, chaque fois qu’un serveur physique exécutait plusieurs applications, une seule application pouvait consommer toute la puissance de traitement, la mémoire, l’espace de stockage ou d’autres ressources sur ce serveur. Pour éviter cela, les entreprises exécutaient chaque application sur un serveur physique différent. Cette configuration présente plusieurs inconvénients : des ressources sous-utilisées et un manque d’évolutivité. En outre, le grand nombre de machines physiques prend de l’espace et représente une charge financière.

Virtualisation

Arrive ensuite la virtualisation, un processus qui est à la base du cloud computing. Bien que la technologie de virtualisation remonte à la fin des années 1960, elle n’a été largement adoptée qu’au début des années 2000.

La virtualisation repose sur un logiciel connu sous le nom d’ hyperviseur. Un hyperviseur est une forme légère de logiciel qui permet à plusieurs machines virtuelles (VM) de s’exécuter sur l’unité centrale de traitement (CPU) d’un serveur physique unique. Chaque machine virtuelle a un système d’exploitation (OS) invité, une copie virtuelle du matériel dont le système d’exploitation a besoin pour fonctionner et une application (avec ses bibliothèques et ses dépendances associées). 

Bien que les machines virtuelles permettent une utilisation plus efficace des ressources matérielles que les serveurs physiques pour exécuter des applications, elles consomment tout de même une grande quantité de ressources système. C’est particulièrement vrai lorsque de nombreuses machines virtuelles sont exécutées sur le même serveur physique, chacune ayant son propre système d’exploitation invité.

Conteneurs

C’est là que la technologie des conteneurs entre en scène. En 1979, le développement de chroot (lien externe à ibm.com), qui fait partie du système d’exploitation Unix version 7, a été un cap dans l’histoire du développement des conteneurs. Chroot a lancé le concept d’isolation des processus en limitant l’accès aux fichiers d’une application à un répertoire spécifique (la racine) et à ses enfants (ou sous-processus).

Les conteneurs modernes sont définis comme des unités de logiciel dans lesquelles le code d’application est empaqueté avec toutes ses bibliothèques et ses dépendances. Les applications peuvent ainsi être exécutées rapidement dans n’importe quel environnement, que ce soit sur site ou hors site, à partir d’un ordinateur de bureau, d’un centre de données privé ou d’un cloud public.

Plutôt que de virtualiser le matériel sous-jacent comme les VM, les conteneurs virtualisent le système d’exploitation (généralement Linux ou Windows). L’absence de système d’exploitation invité est ce qui rend les conteneurs légers, plus rapides et plus portables que les machines virtuelles.

Au début des années 2000, Google avait besoin d’un moyen de tirer les meilleures performances de ses serveurs virtuels pour soutenir le développement de son infrastructure et fournir sa plateforme de cloud public. Cela a conduit à la création de Borg, le premier système unifié de gestion des conteneurs. Développé entre 2003 et 2004, le système Borg tire son nom d’un groupe d’extraterrestres de Star Trek, les Borgs, des organismes cybernétiques qui fonctionnent en partageant un esprit de ruche (conscience collective) appelé « Le Collectif ».

Le nom « Borg » convenait parfaitement au projet de Google. Le système de gestion des clusters à grande échelle de Borg agit essentiellement comme un cerveau central pour l’exécution des workloads conteneurisées dans ses centres de données. Conçu pour fonctionner avec le moteur de recherche Google, Borg a été utilisé pour créer les services Internet de Google, notamment Gmail, Google Docs, Google Search, Google Maps et YouTube.

Borg a permis à Google d’exécuter des centaines de milliers de tâches provenant de nombreuses applications différentes sur de nombreuses machines. Grâce à cela, Google a optimisé son utilisation des ressources, sa tolérance aux pannes, et est parvenu à une évolutivité élevée pour ses workloads à grande échelle. Aujourd’hui encore, Google utilise Borg comme système interne principal de gestion des conteneurs.

En 2013, Google a lancé Omega, son système de gestion de conteneurs de deuxième génération. Omega a repoussé les limites de l’écosystème Borg en proposant une solution de planification flexible et évolutive pour les clusters d’ordinateurs à grande échelle. C’est également en 2013 que Docker, un acteur clé de l’histoire de Kubernetes, a fait son apparition.

Développé par dotCloud, une société de technologie PaaS (Platform-as-a-Service), Docker a été publié en 2013 en tant qu’outil logiciel open source qui permettait aux développeurs de logiciels en ligne de créer, de déployer et de gérer des applications conteneurisées.

La technologie de conteneurs Docker utilise le noyau Linux (le composant de base du système d’exploitation) et les fonctionnalités du noyau pour séparer les processus afin qu’ils puissent être exécutés indépendamment. Pour dissiper toute confusion, le nom de Docker fait également référence à Docker, Inc. (anciennement dotCloud, lien externe à ibm.com), qui développe des outils de productivité construits autour de sa plateforme de conteneurisation open source, ainsi que l’écosystème et la communauté Docker open source (lien externe à ibm.com).

En popularisant une exécution de conteneur légère et en offrant un moyen simple de conditionner, de distribuer et de déployer des applications sur une machine, Docker a fourni le point de départ et l’inspiration aux fondateurs de Kubernetes. Lorsque Docker est arrivé sur le marché, Craig McLuckie, Joe Beda et Brendan Burns de Google ont été enthousiasmés par sa capacité à créer des conteneurs individuels et à les exécuter sur des machines individuelles.

Si Docker avait changé la donne pour l’infrastructure cloud native, il présentait des limites, car il était conçu pour fonctionner sur un seul nœud, ce qui rendait l’automatisation impossible. Par exemple, comme les applications étaient conçues pour des milliers de conteneurs distincts, leur gestion dans différents environnements est rapidement devenue une tâche difficile, dans laquelle chaque développement devait être empaqueté manuellement. L’équipe de Google a vu dans cette situation un besoin (et une opportunité) de disposer d’un orchestrateur de conteneurs capable de déployer et de gérer plusieurs conteneurs sur plusieurs machines. C’est ainsi que le système de gestion de conteneurs de troisième génération de Google, Kubernetes, a vu le jour.

De nombreux développeurs de Kubernetes avaient travaillé au développement de Borg et souhaitaient créer un orchestrateur de conteneurs qui intègrerait tout ce qu’ils avaient appris dans le cadre de la conception et du développement des systèmes Borg et Omega, le but étant de produire un outil open source moins complexe avec une interface conviviale. En guise d’ode aux Borgs, ils ont baptisé cet outil « Project Seven of Nine », du nom d’un personnage de Star Trek: Voyager, qui est un ancien drone borg. Bien que le nom original du projet n’ait pas été retenu, il a été immortalisé par les sept points sur le logo de Kubernetes (lien externe à ibm.com).

L’architecture de Kubernetes est basée sur l’exécution de clusters, qui permettent aux conteneurs de s’exécuter sur plusieurs machines et dans plusieurs environnements. Chaque cluster comporte généralement deux classes de nœuds :

• Des nœuds worker, qui exécutent les applications conteneurisées.
• Des nœuds de plan de contrôle, qui contrôlent le cluster.

Le plan de contrôle agit essentiellement comme orchestrateur du cluster Kubernetes et comprend plusieurs composants : le serveur API (qui gère toutes les interactions avec Kubernetes), le gestionnaire de contrôle (qui gère tous les processus de contrôle), le gestionnaire de contrôleurs cloud (l’interface avec l’API du fournisseur de cloud), etc. Les nœuds worker gèrent les conteneurs à l’aide de systèmes d’exécution de conteneurs tels que Docker. Les pods, les plus petites unités déployables d’un cluster, contiennent un ou plusieurs conteneurs d’applications et partagent des ressources, comme des informations de stockage et de réseau.

En 2014, Kubernetes a fait ses débuts en tant que version open source de Borg, avec Microsoft, RedHat, IBM et Docker devenant les premiers membres de la communauté Kubernetes. L’outil logiciel comprenait des fonctionnalités de base pour l’orchestration de conteneurs, notamment les suivantes :

• Réplication pour déployer plusieurs instances d’une application
• Équilibrage de charge et découverte de services
• Vérification basique de l’intégrité et réparation
• Planification pour regrouper de nombreuses machines et leur attribuer des tâches de travail

En 2015, lors de la O’Reilly Open Source Convention (OSCON) (lien externe à ibm.com), les fondateurs de Kubernetes ont dévoilé une version étendue et perfectionnée de Kubernetes, Kubernetes 1.0. Peu après, les développeurs de l’équipe Red Hat OpenShift ont rejoint l’équipe Google et ont ainsi apporté au projet leur expérience en ingénierie et dans les environnements d’entreprise.

Au moment de la sortie de Kubernetes 1.0 en 2015, Google a fait don de Kubernetes à la Cloud Native Computing Foundation (CNCF) (lien externe à ibm.com), qui fait partie de la Linux Foundation, un organisme sans but lucratif. La CNCF a été créée conjointement par de nombreux membres des plus grandes sociétés informatiques mondiales, notamment Docker, Google, Microsoft, IBM et Red Hat. La mission (lien externe à ibm.com) de la CNCF est de « rendre l’informatique cloud native omniprésente ».

En 2016, Kubernetes est devenu le premier projet hébergé de la CNCF et, en 2018, Kubernetes était le premier projet de la CNCF à atteindre la maturité. En peu de temps, le nombre d’entreprises participantes actives a atteint les 700, et Kubernetes est devenu l’un des projets open source dont la croissance a été la plus rapide de l’histoire. En 2017, il a dépassé des concurrents (comme Docker Swarm et Apache Mesos) pour devenir la norme du secteur pour l’orchestration de conteneurs.

Avant le cloud, les applications logicielles étaient liées aux serveurs matériels sur lesquels elles s’exécutaient. Mais en 2018, lorsque Kubernetes et les conteneurs sont devenus la norme de gestion pour les fournisseurs de cloud, le concept d’applications cloud natives a commencé à s’imposer. Cela a ouvert la voie à la recherche et au développement dédiés aux logiciels hébergés dans le cloud.

Kubernetes aide à développer des programmes basés sur des microservices cloud natifs et permet la conteneurisation des applications existantes, l’objectif étant un développement plus rapide des applications. Kubernetes fournit également l’automatisation et l’observabilité nécessaires pour gérer efficacement plusieurs applications en même temps. L’infrastructure déclarative de Kubernetes basée sur des API permet aux équipes de développement d’applications cloud natives de fonctionner de manière indépendante et d’augmenter leur productivité.

L’histoire de Kubernetes et son rôle en tant que plateforme open source portable et extensible pour la gestion des workloads conteneurisées et des microservices se poursuit.

Depuis que Kubernetes a rejoint la CNCF en 2016, le nombre de contributeurs est passé à 8 012, soit une hausse de 996 % (lien externe à ibm.com). Le plus grand événement de la CNCF, KubeCon + CloudNativeCon (lien externe à ibm.com), attire des milliers de participants et propose un forum annuel qui permet aux développeurs et aux utilisateurs d’échanger des informations et des points de vue sur Kubernetes et d’autres tendances DevOps.

Sur les fronts de la transformation cloud et de la modernisation des applications, l’adoption de Kubernetes ne montre aucun signe d’essoufflement. Selon un rapport de Gartner, The CTO’s Guide to Containers and Kubernetes (lien externe à ibm.com), plus de 90 % des organisations du monde exécuteront des applications conteneurisées en production d’ici 2027.

En 2014, IBM a été l’une des premières grandes entreprises à s’associer à la communauté open source de Kubernetes et à amener l’orchestration de conteneurs dans l’environnement d’entreprise. Aujourd’hui, IBM aide les entreprises à poursuivre leur transition vers le cloud en mettant en œuvre l’orchestration de conteneurs Kubernetes et d’autres solutions de gestion dans le cloud.

Que votre objectif soit le développement d’applications cloud natives, le déploiement d’applications à grande échelle ou la gestion de microservices, nous pouvons vous aider à exploiter Kubernetes et ses nombreux cas d’utilisation.

Red Hat OpenShift on IBM Cloud offre aux développeurs OpenShift un moyen rapide et sécurisé de conteneuriser et de déployer des workloads d’entreprise au sein de clusters Kubernetes.

IBM Cloud Code Engine, une plateforme sans serveur entièrement gérée, vous permet d’exécuter vos conteneurs, le code de vos applications et vos tâches par lots dans un runtime de conteneur entièrement géré.