Cloud

Tout savoir sur Kubernetes en vidéos

Share this post:

Cet article présente en vidéos des technologies majeures autour de la conteneurisation des applications : Kubernetes, Istio, Knative, Red Hat OpenShift.

Voici la table des matières :

  • Qu’est-ce que Kubernetes ?
  • Et les conteneurs alors ?
  • L’orchestration de conteneurs avec Kubernetes.
  • L’architecture et le déploiement Kubernetes.
  • Le maillage de services Istio.
  • Knative et l’informatique Serverless.
  • Kubernetes et IBM Cloud.

Qu’est-ce que Kubernetes ?

Kubernetes – aussi connu sous le nom « K8S » ou « kube » – est une plate-forme d’orchestration de conteneurs open source pour la planification et l’automatisation du déploiement, la gestion et mise à l’échelle des applications conteneurisées.

Kubernetes a d’abord été mis au point par les ingénieurs de Google avant de devenir open source en 2014. Kubernetes est le mot grec pour barreur ou pilote, d’où la barre dans le logo.

En tant que projet open-source, Kubernetes est dirigé par la Cloud Native Computing Foundation (CNCF), une agence de la Linux Foundation. IBM Cloud en est membre Platinum et contribue activement à des projets open source tels que Kubernetes et Istio.

Pour les entreprises, s’adapter rapidement est fondamental pour maintenir croissance et compétitivité. Les technologies relatives au cloud natif, et en particulier Kubernetes, ont vu le jour pour répondre à ce besoin, en fournissant l’automatisation et l’observabilité nécessaires pour gérer les applications à l’échelle tout en améliorant la vélocité des équipes de développement. Les entreprises qui devaient auparavant se limiter à des déploiements trimestriels d’applications critiques peuvent désormais déployer en toute sécurité plusieurs fois par jour. Ce qui permet aux équipes de développement de se concentrer sur la programmation et l’innovation.

Dans la vidéo suivante (sous-titrée en français), Sai Vennam, IBM Cloud Developer Advocate, explique les bases de Kubernetes :

Et les conteneurs alors ?

Un conteneur d’application est une méthode de virtualisation qui permet de regrouper le code d’une application et toutes ses dépendances dans une seule et même unité indépendante (le conteneur ou container, en anglais). Les applications deviennent ainsi indépendantes de l’environnement dans lequel elles s’exécutent. La virtualisation se fait donc au niveau de l’application et non au niveau de l’infrastructure ce qui lui permet d’être déployée correctement sur n’importe quel environnement. Cette indépendance vis-à-vis de l’environnement permet également d’obtenir une application aux comportements prévisibles.

La popularité des containers a largement profité de l’apparition d’outils open-source tels que Docker ou Kubernetes.

Les conteneurs, les machines virtuelles et les infrastructures traditionnelles – quelles principales différences ?

Il peut être plus facile ou plus utile de comprendre les conteneurs comme le dernier point du continuum de l’automatisation et de l’abstraction de l’infrastructure IT.

Dans l’infrastructure traditionnelle, les applications fonctionnent sur un serveur physique et saisissent toutes les ressources qu’elles peuvent obtenir. Cela vous laisse le choix d’exécuter plusieurs applications sur un seul serveur, en espérant que l’un ne monopolise pas les ressources au détriment des autres, ou de dédier un serveur par application, ce qui gaspille les ressources et ne peut pas être mis à l’échelle.

Les machines virtuelles (VMs) sont des serveurs issus du matériel informatique physique, vous permettant d’exécuter plusieurs VMs sur un serveur physique ou une seule VM qui couvre plus d’un serveur physique. Chaque VM exécute sa propre instance OS, et vous pouvez isoler chaque application dans sa propre VM, réduisant ainsi les chances que les applications fonctionnant sur la même machine physique sous-jacente s’impactent les unes les autres. Les VMs font une meilleure utilisation des ressources et sont beaucoup plus faciles et plus rentables que les infrastructures traditionnelles. Et elle sont « jetables » — lorsque vous n’avez plus besoin d’exécuter l’application, vous supprimez la VM.

Les conteneurs prennent cette abstraction à un niveau plus élevé, en particulier, en plus de partager le matériel virtualisé sous-jacent, ils partagent un noyau OS virtualisé sous-jacent. Les conteneurs offrent la même isolation, la même évolutivité et la même capacité d’élimination que les VMs, mais parce qu’ils ne transportent pas la charge utile de leur propre instance OS, ils sont plus légers (c’est-à-dire qu’ils prennent moins d’espace) que les VMs. Ils sont plus économes en ressources : ils vous permettent d’exécuter plus d’applications sur moins de machines (virtuelles et physiques), avec moins d’instances OS. Les conteneurs sont plus facilement portables dans les environnements de postes de travail, de data center et de cloud. Et ils s’adaptent parfaitement aux pratiques de développement Agile et Devops.

L’orchestration de conteneurs avec Kubernetes

À mesure que les conteneurs ont proliféré — aujourd’hui, une organisation en a peut-être des centaines ou des milliers —, les équipes opérationnelles ont dû planifier et automatiser le déploiement des conteneurs, le réseautage, l’évolutivité et la disponibilité. Ainsi est né le marché de l’orchestration des conteneurs.

Alors que d’autres options d’orchestration de conteneurs, notamment Docker Swarm et Apache Mesos, ont gagné en popularité dès le début, Kubernetes est rapidement devenu le projet le plus largement adopté (à un moment donné, c’était le projet qui a connu la croissance la plus rapide dans l’histoire des logiciels libres).

Les développeurs ont choisi (et continuent de choisir) Kubernetes pour son étendue de fonctionnalités, son écosystème vaste et croissant d’outils de support open source, et son support et sa portabilité à travers les principaux fournisseurs de cloud (dont certains offrent maintenant des services Kubernetes entièrement gérés – dont IBM Kubernetes Service).

Pour plus d’informations sur l’orchestration des conteneurs, voir la vidéo suivante, sous-titrée en français :

Kubernetes ou Docker ? Inutile de choisir.

Si vous avez lu jusqu’ici, vous comprenez déjà que si Kubernetes est une alternative à Docker Swarm, ce n’est pas (contrairement à l’idée persistante) une alternative ou un concurrent à Docker lui-même.

En fait, si vous avez adopté Docker avec enthousiasme et que vous créez des déploiements de conteneurs à grande échelle basés sur Docker, l’orchestration Kubernetes est une prochaine étape logique pour gérer ces charges de travail. Pour en savoir plus, regardez la vidéo suivante sous-titrée en français :

L’architecture et le déploiement de Kubernetes

L’architecture Kubernetes repose sur plusieurs concepts et abstractions.

Un cluster Kubernetes – à savoir le groupe de machines exécutant Kubernetes et les containers qu’il gère – doit avoir un nœud maître (master node) : le système qui commande et contrôle toutes les autres machines du cluster.

Chaque cluster contient des noeuds Kubernetes. Il peut s’agir de machines physiques ou virtuelles. Les noeuds quant à eux exécutent des pods : les objets Kubernetes les plus basiques pouvant être créés ou gérés.  Les pods sont des groupes de conteneurs qui partagent les mêmes ressources de calcul et le même réseau. Ils sont également l’unité d’évolutivité dans Kubernetes : si un conteneur dans un pod reçoit plus de trafic qu’il peut gérer, Kubernetes va répliquer le pod à d’autres nœuds dans le cluster. Pour cette raison, c’est une bonne pratique de garder les pods compacts afin qu’ils ne contiennent que des conteneurs qui doivent partager les ressources.

Le déploiement contrôle la création et l’état de l’application conteneurisée et le maintient en fonctionnement. Il spécifie combien de répliques d’un module doivent fonctionner sur le cluster. Si un module échoue, le déploiement en créera un nouveau.

Pour en savoir plus sur les déploiements Kubernetes, regardez la vidéo suivante sous-titrée en français :

 

Le maillage de services Istio (Service Mesh en anglais)

Kubernetes peut déployer et mettre à l’échelle des pods, mais il ne peut pas gérer ou automatiser le routage entre eux et ne fournit pas d’outils pour surveiller, sécuriser ou déboguer ces connexions. À mesure que le nombre de conteneurs dans un cluster augmente, le nombre de voies de connexion possibles entre eux augmente de façon exponentielle (par ex., deux conteneurs ont deux connexions potentielles, mais 10 pods en ont 90), ce qui crée un cauchemar potentiel de configuration et de gestion.

Istio est une couche de maillage de services open source pour les clusters Kubernetes.

À chaque cluster Kubernetes, Istio ajoute un conteneur « sidecar » — essentiellement invisible pour le programmeur et l’administrateur — qui configure, surveille et gère les interactions entre les autres conteneurs.

Avec Istio, vous définissez une politique unique qui configure les connexions entre les conteneurs de sorte que vous n’avez pas à configurer chaque connexion individuellement. Cela facilite le débogage des connexions entre les conteneurs.

Istio fournit également un tableau de bord que les équipes et les administrateurs Devops peuvent utiliser pour surveiller la latence, les erreurs de temps en service et d’autres caractéristiques des connexions entre les conteneurs. De plus, il renforce la sécurité — en particulier, la gestion de l’identité qui empêche les personnes non autorisées de « simuler » un appel de service entre des conteneurs — et les capacités d’authentification, d’autorisation et de vérification que les professionnels de la sécurité peuvent utiliser pour surveiller le cluster.

Pour tout savoir sur Istio, téléchargez l’eBook suivant: https://www.ibm.com/account/reg/fr-fr/signup?formid=urx-42260

Knative et l’informatique Serverless

Knative (prononcez « kay-native ») est une plate-forme open source qui se trouve au-dessus de Kubernetes et fournit deux avantages significatifs pour le développement cloud native :

Knative fournit une rampe d’accès facile à l’informatique Serverless.

L’informatique sans serveur est une façon relativement nouvelle de déployer du code qui rend les applications cloud native plus efficaces et rentables. Au lieu de déployer une instance continue de code qui reste inactif en attendant les demandes, le serverless fait apparaître le code « au besoin » — en le mettant à l’échelle à mesure que la demande fluctue — et retire ensuite le code lorsqu’il n’est pas utilisé. Le Serverless prévient le gaspillage de capacité et de puissance de calcul et réduit les coûts parce que vous payez seulement pour exécuter le code quand il fonctionne réellement.

Knative permet aux développeurs de construire un conteneur une fois et de l’exécuter comme un service logiciel ou comme une fonction sans serveur. Tout est transparent pour le développeur : Knative gère les détails en arrière-plan, et le développeur peut se concentrer sur le code.

Knative simplifie le développement et l’orchestration de conteneurs

Pour les développeurs, le code de conteneurisation nécessite beaucoup d’étapes répétitives, et l’orchestration de conteneurs nécessite beaucoup de configuration et de script (p. ex., génération de fichiers de configuration, installation de dépendances, gestion de la journalisation et du traçage, et rédaction de scripts d’intégration/déploiement continu (CI/CD). Knative facilite ces tâches en les automatisant.

Vous pouvez en savoir plus sur Knative en regardant la vidéo suivante (en anglais) :

Kubernetes et IBM Cloud

Solution d’orchestration de conteneurs managée, IBM Cloud Kubernetes Service automatise le déploiement, l’exploitation, la mise à l’échelle et la surveillance des applications conteneurisées dans un cluster, tout en ajoutant des capacités propres à IBM. Il permet la livraison rapide des applications et peut se connecter à des services avancés tels qu’IBM Watson et la blockchain.

Pour un aperçu de la façon dont un service Kubernetes managé peut vous aider dans votre transformation vers le cloud, regardez notre vidéo, « Avantages de Kubernetes managé » en anglais : ici

Red Hat Openshift sur IBM Cloud est un service complet qui propose des clusters Openshift entièrement gérés sur la plate-forme IBM Cloud. (Openshift est une plate-forme d’entreprise Kubernetes fonctionnant sur Red Hat Enterprise Linux / RHEL.)

Regardez cette vidéo sous-titrée en français pour une introduction à Red Hat Openshift sur IBM Cloud :

Developer Relations Marketing Leader IBM France

More Cloud stories
3 juillet 2024

Intégration par design : la clé de la réussite de la transformation cloud

La transformation cloud est un processus complexe qui nécessite une planification méticuleuse et une exécution soignée pour réussir. Alors que les organisations se lancent dans la transformation du cloud, elles se concentrent souvent sur la migration des applications et des données vers le cloud, négligeant un aspect critique : l’intégration. L’un des défis majeurs que […]

Continue reading

12 juin 2024

Comment bien préparer la migration d’un parc applicatif dans le cloud avec IBM Consulting (2/2) ?

Dans notre article « Comment bien préparer la migration d’un parc applicatif dans le cloud avec IBM Consulting (1/2) ? », nous avons présenté les différentes étapes du pré-assessment technique qui consiste à analyser l’ensemble des applications du patrimoine applicatif. Dans cette seconde partie, nous allons détailler l’assessment technique à réaliser pour chacune des applications.   Phase […]

Continue reading

12 juin 2024

Comment bien préparer la migration d’un parc applicatif dans le cloud avec IBM Consulting (1/2) ?

Contrairement aux applications conçues et développées spécifiquement pour un environnement cloud, un parc applicatif « on premises » a généralement été bâti au fil du temps, avec des technologies datant d’époques différentes. Il est par nature plus ou moins hétérogène. Pour différentes raisons (par exemple la scalabilité horizontale et verticale de manière automatique en fonction du besoin, […]

Continue reading