FAQ – Foire aux questions

Le terme « DevOps » est un acronyme pour « Development » (développement) et « Operations » (opérations).
Le DevOps ou DevSecOps est une approche, une démarche ou une pratique visant à améliorer la collaboration entre les équipes de développement et les équipes opérationnelles afin d’exploiter un projet logiciel.
Ce terme reflète bien la philosophie de cette méthodologie qui a pour objectif de rapprocher ces deux métiers, souvent perçus comme antagonistes, afin de favoriser une meilleure collaboration et une plus grande efficacité.

Les deux termes sont très proches. DevOps ou DevSecOps est une démarche, intégrant une culture, des pratiques et des outils, qui consiste à améliorer la communication et la collaboration entre les développeurs (Dev), le service qualité (QA), la Sécurité (Sec), les opérations (Ops) et tout autre département qui intervient dans la livraison du logiciel pour aider les entreprises et organisations de toutes tailles et de tous secteurs d’activités (banque, finance, industrie, collectivité publique, association, …) à déployer de nouveaux logiciels plus rapidement, plus efficacement et de manière plus sécurisée.

S’inspirant des approches de développement Agile, le concept DevOps / DevSecOps met en avant une collaboration renforcée entre les développeurs et les membres de l’équipe chargée des opérations (administrateurs système, exploitation, …) afin d’optimiser la livraison du code, les tests et les infrastructures de production. 

Pour plus d’agilité, les développeurs et les opérateurs travaillent sur de petites mises à jour du logiciel et des infrastructures qui sont mises en ligne indépendamment les unes des autres.

Pour déployer le code applicatif structuré en micro-services, les équipes DevOps utilisent des technologies de CI (Continuous intégration) de CD (Continuous Delivery), de conteneurs telles que Docker, Kubernetes, OpenShift, … (On-Premise ou dans du Cloud) indispensables pour assurer la cohérence des environnements de déploiement et d’hébergement mais également pour optimiser la gestion de la sécurité, scalabilité et de la résilience des applications.
L’observabilité joue aussi un rôle très important via du logging, des métriques et du tracing afin de toujours avoir une vue complète du système.

Également, les problèmes identifiés lors de la mise en production conduisent à des améliorations du code, au travers d’un cycle en rétroaction continue.

C’est ce qu’on appelle la boucle de feedback DevOps ou le 8 DevOps :

Une équipe DevOps / DevSecOps est composée de collaborateurs issus des services Développement (chef de projet, développeur, …), de Sécurité, de déploiement (ingénieur IT, administrateurs système, …) et de toute autre équipe qui participe au cycle de vie du logiciel qui travaillent ensemble pour améliorer la communication et la collaboration entre les deux disciplines. L’objectif est de permettre aux équipes de développement et de déploiement de mieux travailler ensemble afin d’accélérer le cycle de développement et de déploiement des applications logicielles tout en le fiabilisant !

Un ingénieur DevOps doit comprendre la philosophie DevOps / DevSecOps mais aussi les outils et logiciels qui le compose. Donc cela implique de comprendre les perspectives de développement, de sécurité, de production et d’exploitabilité. 

Il doit avoir certaines expertises en automatisation, en Infra-as-Code, en intégration continue, en déploiement, en orchestration de containers, en sécurité, en observabilité, …. Il travaille en collaboration avec les différentes équipes de développement et d’infrastructure pour améliorer les processus de développement et de livraison des applications tout en assurant la stabilité et la sécurité.

Destinée à améliorer la productivité du cycle de vie de développement d’une application logicielle, l’approche DevOps / DevSecOps peut être imagée comme une boucle infinie, comprenant 8 étapes qui se répètent.

1.Planification : Dans un premier temps, l’équipe identifie les exigences et besoins des utilisateurs finaux (clients, directions ou utilisateurs internes) et travaille à la rédaction d’un cahier des charges et d’un planning de développement associé afin d’identifier le MVP (Minimum Viable Product) c’est à dire la version d’un logiciel qui permet d’obtenir un maximum de retours avec un minimum d’effort, puis de construire un backlog en suivant les méthodes agiles.

2.Création du Code : A cette étape, les équipes procèdent au développement à proprement parler de l’application en suivant des itérations Agile par Sprint.

3.Construction (Build) : Une fois les tâches de développement terminées, le code est déposé dans un référentiel partagé (Git Repository) et on procède alors à une phase d’intégration continue (CI) permettant de compiler le code source, valider la qualité du code, packager l’application, faire les différents niveaux de test (Tests unitaires, Tests d’intégrations, Tests Systèmes, …), construire l’image docker, valider les bonnes pratiques, s’assurer de ne pas avoir de vulnérabilités critiques dans l’image et déployer l’image dans un gestionnaire de d’artefacts.

4.Version : Le versionning peut être réalisé de plusieurs manières et être automatiquement fait avec une approche d’auto-versionning. 

Une fois la phase de test terminée et réalisée avec succès, le Build est préparé par les ingénieurs DevOps pour être déployé dans l’environnement de production. 

5.Test : Il est possible d’avoir une phase de test pour valider le comportement de l’application dans un environnement d’intégration (le plus proche possible de celui de Production) où des tests d’intégration, d’automatisation de l’interface utilisateur, ainsi que de tests manuels, tels que les tests d’acceptation par les utilisateurs, sont alors réalisés.

6.Déploiement : À ce stade, le build est déployé, testé et mis en œuvre en production afin d’être disponible pour les utilisateurs finaux.

7.Exploitation : Les personnes en charge de l’infrastructure informatique orchestrent alors les étapes de conception, de mise en œuvre, de configuration, de déploiement et de maintenance afin de garantir une disponibilité sans faille de l’application logicielle développée.

8.Surveillance : Les équipes DevOps surveillent chaque version et rédigent des préconisations techniques et fonctionnelles afin d’améliorer les futures versions du logiciel. 

Pour accélérer le temps de mise à disposition des applications et s’assurer de la conformité des versions, les équipes informatiques utilisent des pipelines CI/CD et d’autres moyens d’automatisation pour faire passer le code d’une étape de développement et de déploiement à une autre. 

La mise en œuvre d’une démarche DevOps permet d’améliorer plusieurs points fondamentaux. Voici les principaux bénéfices que vous pourrez en tirer.

Livraison plus rapide des logiciels

Avec un pipeline CI/CD, le déploiement est plus rapide et plus fréquent. Il faut moins de temps pour mettre à jour les services existants et déployer de nouveaux systèmes, de nouvelles fonctionnalités ou des corrections de bugs. Cela peut également apporter un avantage concurrentiel significatif et offrir une meilleure expérience aux utilisateurs.

Amélioration du travail collaboratif

Avec les pratiques DevOps, les développeurs et les équipes d’exploitation travaillent en étroite collaboration, avec un partage des responsabilités, ce qui augmente la visibilité du travail. D’avantage connecté, les équipes travaillent toutes vers les mêmes objectifs.

Meilleure productivité

En raison d’une communication améliorée, de l’utilisation d’outils adaptés et d’un processus de développement hiérarchisé prenant en compte les priorités, les équipes travaillent plus efficacement.

Automatisation des tâches répétitives

L’automatisation des tâches répétitives est l’un des aspects les plus importants du DevOps qui permettent aux équipes de développement et d’exploitation de se concentrer sur des tâches à plus forte valeur ajoutée et de réduire les erreurs humaines.

Qualité et fiabilité accrues

Les pratiques d’intégration et de livraison continues garantissent que les changements sont fonctionnels et stables, ce qui améliore la qualité d’un produit logiciel. La surveillance permet également aux équipes de se tenir au courant des performances en temps réel.

Une meilleure sécurité

En adoptant une approche « Security as Code », dès le début du cycle de développement, il est plus facile de mieux identifier et corriger les éventuelles vulnérabilités avant que les logiciels ne soient mis en production.

Des versions plus fréquentes

Les clients peuvent recevoir des mises à jour et des corrections de bugs plus fréquemment, ce qui se traduit également par une meilleure satisfaction des clients.

Les outils de DevOps permettent de faciliter et d’automatiser les tâches répétitives du cycle de développement logiciel. Ils aident également les équipes à collaborer efficacement et à suivre les modifications apportées au code au fil du temps. 

Parmi les outils les plus populaires, on peut citer Puppet, Kubernetes, Docker, Chef, Ansible, SaltStack et Jenkins.

Azure DevOps est une plateforme de collaboration en ligne qui permet aux équipes de développement de gérer le cycle de développement complet d’un projet, du codage à la livraison. Azure DevOps offre un large éventail de services pour accompagner les équipes de développement et leur permettre de livrer leurs projets de manière fiable et en toute sécurité.

La mise en place d’une démarche DevOps peut s’avérer complexe et représenter un challenge pour les entreprises. En effet, il est nécessaire de prendre en compte plusieurs facteurs tels que la culture d’entreprise, les processus existants, les outils utilisés, etc.

La formation des collaborateurs est l’un des points de vigilance à prendre en considération pour pallier à une éventuelle déficience des membres d’une équipe relatif à la méthodologie de gestion de projet ou à la maîtrise des outils utilisés.

A cet effet une formation DevOps permet d’acquérir les compétences nécessaires pour mettre en place une approche DevOps dans son entreprise.

Un cadre Agile se traduit par un état d’esprit (des valeurs et des principes) ainsi que des pratiques. L’ensemble supporte une efficience de création de valeur ainsi qu’une efficacité opérationnelle. En remettant l’utilisateur final au centre des préoccupations de l’équipe de développement, en assurant une démarche empirique supportant un principe d’amélioration continue, le cadre Agile assure le sens de l’action collective des collaborateurs.

• Leadership et dynamiques collaboratives
• Vision produit & hypothèses de création de valeur
• Réalisation itérative et incrémentale
• Amélioration continue, apprentissage & feedbacks utilisateurs

Rédigé par un groupe de développeurs en 2001, le manifeste Agile a pour but de moderniser, fiabiliser et accélérer les processus de développement d’applications logicielles par la mise en œuvre de 12 principes de développement, fondés sur 4 valeurs.

Le manifeste Agile, lorsqu’il est incarné dans le cadre d’un processus de réalisation logicielle, traduit l’état d’esprit qui donne le sens aux principes Agiles fondamentaux que sont la collaboration, la communication, l’auto-organisation et l’ambition de toujours mieux satisfaire les attentes des utilisateurs & clients finaux par la mise à disposition rapide et régulière de fonctionnalités applicatives. 

En savoir plus :

• • https://agilemanifesto.org/iso/fr/manifesto.html
  • https://agilemanifesto.org/iso/fr/principles.html

1. Les individus et leurs interactions plus que les processus et les outils
2. Des logiciels opérationnels plus qu’une documentation exhaustive
3. La collaboration avec les clients plus que la négociation contractuelle
4. L’adaptation au changement plus que le suivi d’un plan

• Le Pourquoi : Établir la raison du changement
• Le Pour Quoi : Changer la culture et pas seulement se contenter d’adopter des pratiques
• Le Qui : Engager toutes les parties prenantes impliquées dans la transformation
• Le Quoi : Assurer la simplification du travail quotidien et y donner du sens
• Le Comment : Identifier et mettre en œuvre des équipes Produit, pérennes, autonomes et pluridisciplinaires 

Dans un contexte « VUCA » (https://en.wikipedia.org/wiki/Volatility,_uncertainty,_complexity_and_ambiguity ) ou complexe du point de vue de la matrice de Stacey (https://www.wikiberal.org/wiki/Matrice_de_Stacey) , les approches empiriques sont plus efficaces. En effet, dans un contexte où tout problème rencontré peut trouver sa source dans de multiples causes, il convient d’avancer pas à pas et de confronter avec la réalité ce que nous pensons être la meilleure solution. La prise de décision ne peut se faire qu’après des expérimentations et acquisition de connaissance.

Il convient en premier lieu de clairement définir pourquoi nous voulons changer. Faire évoluer une organisation vers une approche Agile n’est pas un objectif en soit. Il faut donc convenir de l’objectif de performance organisationnelle recherché.

Ensuite, au lieu d’une transformation globale touchant principalement l’utilisation de pratiques Agiles, il est préférable de travailler à la mise en place d’une approche itérative et incrémentale faisant évoluer la culture de l’organisation, simplifiant le travail quotidien et alignant ce travail avec la stratégie de l’organisation.

 Scrum https://www.scrum.org/ & https://www.scrumalliance.org/ est un cadre de travail qui met en œuvre les valeurs et principes du Manifeste Agile. Au travers de 3 rôles, 3 artefacts et 5 rituels, ce cadre permet aux équipes pluridisciplinaires et autonomes de se focaliser sur la réalisation itérative d’un incrément de valeur « Produit ». Sa mise en œuvre est supportée par 5 valeurs (courage, focus, ouverture, respect et engagement) et une démarche empirique d’amélioration continue.

Le Scrum Master est l’un des 3 rôles du cadre de travail Scrum. Fondamentalement, son but premier but est d’accompagner l’équipe Scrum à s’améliorer. Pour ce faire, il est garant du respect du cadre Scrum par l’équipe. Formateur, facilitateur, coach et mentor, il a la charge d’adresser les obstacles que rencontre l’équipe Scrum et est un agent du changement au sein de l’organisation.

Les 3 artefacts de Scrum (Backlog Produit, Sprint Backlog et Incrément) ont pour but d’aider l’équipe à gérer ses travaux (priorisation par la valeur, planification et suivi des avancements). Ainsi, l’ensemble des parties prenantes concernées par le produit peuvent voir ce que l’équipe est en train d’accomplir. D’autres pratiques Agiles, comme l’objectif du Sprint, le Burndown Chart et la Définition du Terminé, enrichissent le cadre agile Scrum lorsque le contexte l’impose.

Le cadre de travail Kanban qui prend sa source dans les approches Lean et le TPS (Toyota Production System) regroupe un ensemble de pratiques Agile qui visent l’optimisation du flux de création de valeur. Se basant sur le management visuel, Kanban se concentre sur la réduction des travaux en cours, la diminution des temps d’attente pour accélérer le Time to Market,  temps qui sépare la prise en compte d’un besoin et sa mise en service au sein d’une expérience utilisateur.

XP est un cadre de travail Agile qui traduit un style de développement logiciel mettant l’accent sur l’excellence des techniques de programmation, une communication simple et efficace (3C) et la recherche des solutions les plus simples possibles. Cela se traduit par des valeurs et des pratiques de développement logiciel éprouvées telles que le « Pair Programming », le « Collective Code Ownership », le « Test Driven Development » ou encore l’intégration continue.

SAFe https://www.scaledagileframework.com/  est un cadre de travail de mise à l’échelle de l’agilité qui intègre de très nombreuses pratiques Lean, Agile et DevOps. Il propose plusieurs configurations possibles pour s’adapter aux différents niveaux de complexité des organisations. Sa mise en œuvre vise l’alignement des efforts de 50 à 125 collaborateurs sur une même intention de création de valeur, les Agile Release Trains ou ART. SAFe se caractérise également par de nouveaux rôles et rituels (RTE & PI Planning).

Les principaux bénéfices d’un cadre de travail Agile sont : 

1. Se focaliser sur la création de valeur pour l’utilisateur final 
2. Optimiser le processus opérationnel par une démarche empirique supportant l’amélioration continue (Être plus efficace) 
3. Favoriser l’innovation en amplifiant les dynamiques collaboratives et l’intelligence collective

Le Modèle « Spotify » reflète un pattern de structure organisationnelle d’agilité à l’échelle mis en œuvre au sein de Spotify. Il est composé de Tribus, Squads, Chapitres et Guildes. Il ambitionne l’optimisation du delivery, de la circulation de l’information et du partage de compétences/connaissances au sein de l’organisation. Il faut garder à l’esprit que Spotify a construit ce modèle pour ses propres besoins et aucunement pour inciter les entreprises à appliquer ce même modèle. Henrik Kniberg, coach Agile chez Spotify, a notamment indiqué que le chemin ayant permis à Spotify d’aboutir à ce modèle est bien plus important que le modèle en lui-même.

Une chaine de valeur représente la séquence d’activités que doit réaliser une organisation pour concevoir, réaliser et délivrer une demande client. Elle implique un double flux d’information et de matériel. La cartographie d’une chaine de valeur offre une vue holistique et mesurée de la manière dont le flux de création de valeur est opéré au sein d’une organisation. C’est une pratique très efficace pour établir des décisions stratégiques d’optimisation organisationnelle.

La pensée « Lean » reflète une approche d’amélioration des organisations au travers de 5 grands principes : 

1. Spécifier précisément la valeur créée pour un produit donné ;
2. Identifier la chaine de valeur de chaque produit ;
3. Éliminer toutes les interruptions éventuelles du flux de création de valeur ;
4. Faire en sorte que la demande du client déclenche la création de valeur ;
5. Et s’inscrire dans une quête de perfection au travers d’une démarche d’amélioration continue.

Le Lean Startup se caractérise par la validation, rapide et peu coûteuse, d’hypothèses de création de valeur. Cette démarche se traduit par la réalisation d’un MVP (Minimum Viable Product) et un cycle d’apprentissage itératif (Construire – Mesurer – Apprendre) qui débouche sur une prise de décision de type : Continuer – Pivoter – Abandonner.

Les OKRs sont une démarche de formalisation d’objectifs et de résultats clés afin d’aligner les efforts opérationnels d’une organisation sur les intentions stratégiques. Chaque objectif (stratégique ou opérationnel) traduit la qualification d’un but à atteindre alors que les résultats clés reflètent la quantification de la réalisation d’un objectif en particulier. Les résultats clés permettent ainsi d’évaluer les progrès réalisés dans l’atteinte de l’objectif, au travers de cycle d’OKRs d’une durée de 3 mois.

Kubernetes, aussi connu comme Kube ou K8s (à prononcer « Kates »), est une plateforme Open Source d’orchestration de conteneurs. Initialement développée par Google, Kubernetes permet d’automatiser le déploiement, la mise à l’échelle et la gestion des applications conteneurisées, dans des environnements de clouds privés, publics et hybrides.

Intégré en mars 2016 par la Cloud Native Computing Foundation (CNCF), partie intégrante de la fondation à but non lucratif Linux, Kubernetes  est classifié comme un projet Graduated gage d’un niveau de maturité globale notamment en termes de diversité de contribution et d’adoption par la communauté.

Kubernetes gère automatiquement les besoins variables de chaque conteneur s’exécutant sur un groupe de serveurs ou « cluster » en allouant dynamiquement les ressources requises.

Au travers de sondes, Kube est par exemple capable de déterminer si votre application doit être redémarrée, doit être déplacée sur un autre nœud (pour mieux gérer les capacités de ressources) ou s’il est nécessaire de créer une ou plusieurs instances supplémentaires pour mieux gérer la charge. 

Tous les comportements de k8s sont décrits au travers de fichiers YAML ou JSON ingérés par un centre de contrôle qui informe et déclenche les actions nécessaires.

Kubernetes cherche continuellement à réconcilier l’état désiré, décrit par ces fichiers YAML, avec l’état réel de ce qui est déployé.

Une architecture d’un cluster Kubernetes se décompose généralement en 2 parties : Le centre de contrôle (API serveur, Scheduler, les Controllers et la base etcd) appelé « Control Plane » ou « Master Nodes » ou « Server Nodes » et les nœuds de travail appelés les « Worker Nodes » ou « Agent Nodes ».

Les nœuds peuvent être des VM (Virtual Machine) ou des serveurs physiques dans lesquels tournent les containers représentés par une notion logique : le Pod.

L’API Server est le point central de toutes les communications administratives du cluster nous permettant ainsi d’interagir avec ce dernier via des commandes et des fichiers de Manifest (en YAML ou JSON) qui seront en autres interprétés par les Controllers pour s’assurer que les objets k8s sont bien créés et correspondent bien à l’état souhaité qui est stocké dans la base de données Kubernetes appelée ETCD.

Le Scheduler est en charge de déployer les pods sur les bons nœuds kube en fonction de la disponibilité des ressources (CPU, RAM ,…) et des contraintes de placement que l’on aura défini.

Les « Worker Nodes » ou « Agent Nodes » contiennent, en plus des pods applicatifs, 2 composants importants qui sont Kubelet et Kube-proxy. 

Kubelet est le composant qui surveille, arrête, démarre les containers, il reçoit ces instructions du Scheduleur et des Controllers au travers de l’API Server.

Kube-proxy est un proxy réseau qui gère les communications réseau dans et en dehors du cluster. 

Kubernetes est composé de différents éléments (API serveur, un scheduleur, des controllers une base etcd, kubelet, kube-proxy ,…) qui sont chacun des binaires qu’il faut déployer sur des VM ou des machines physiques.

Selon les distributions Kubernetes on-premise (Vanilla, RedHat Openshift, Rancher RKE ou K3S, VMWare Tanzu, D2iQ, Nutanix Karbon, …) ou Kubernetes cloud managed (Amazon EKS, Microsoft AKS, Google GKE, Exoscale Kubernetes, OVH cloud kubernetes, …) les étapes d’installations et de configurations sont différentes.

Ces installations ou configurations peuvent se faire via des outils d’IaC (Infra-as-Code) comme Ansible ou Terraform, via des scripts customs ou plus récemment via la Cluster API (CAPI) permettant de gérer le cycle complet d’un cluster k8s.

Un pod est la plus petite unité de ressources déployable sur un seul nœud, partageant des ressources telles que le stockage et l’accès au réseau.
Un pod est donc une définition logique qui peut contenir 1 ou plusieurs conteneurs applicatifs partageant des ressources de stockage ainsi qu’une même identité réseau (adresse IP) plus un certain nombre de configurations influençant la manière dont s’exécutent les conteneurs.

Un cluster est un ensemble de nœuds, ou machines de travail, sur lesquels fonctionnent des applications conteneurisées. Ces nœuds peuvent être des machines physiques ou des machines virtuelles.

Docker est une société qui développe, entre autres, un produit du même nom qui permet de builder et d’exécuter des containers de manière unitaire sur une machine.

Kubernetes se place au-dessus comme un orchestrateur de containers permettant de gérer le cycle de vie d’un ensemble de containers sur plusieurs machines (virtuelles ou physiques).

Pour cela Kubernetes s’appuie sur la « Runtime specification de Open Container Initiative » avec 2 implémentations phares : Containerd et CRI-O.

Lorsque l’on compare Docker et Kubernetes on parle souvent de « Pet vs Cattle » pour exprimer la différence de traitement entre un animal domestique pour lequel il a un nom, un lieu d’habitation, qu’on traite avec grande précaution et du bétail qui est géré de manière plus industrielle.

Kubernetes est un système open-source dont il existe plusieurs implémentations.

Des implémentations « on-premise » comme :

• Vanilla : c’est la distribution open-source de base
• RedHat Openshift : 
• Rancher RKE ou K3S
• VMWare Tanzu, 
• Nutanix Karbon
• D2iQ, 
• …

Ou des implémentations en mode Cloud managé comme :

• Amazon EKS, 
• Microsoft AKS, 
• Google GKE, 
• Exoscale Kubernetes, 
• OVH cloud kubernetes
• …

Ces listes ne sont pas du tout exhaustives mais représentent une bonne partie du marché actuelle.

A noter aussi que toutes ces distributions sont certifiées par la Cloud Native Computing Foundation (CNCF), la fondation qui gère Kubernetes.

A la différence de Kubernetes, projet Open Source, la solution Red Hat OpenShift est un produit commercial nécessitant la souscription d’un contrat d’abonnement payant.

En complément d’un service d’assistance, la solution Red Hat OpenShift intègre une version du projet Kubernetes certifiée par la Cloud Native Computing Foundation, avec un ensemble de composants et de services supplémentaires orientés solution d’entreprise avec un axe sécurité important. 

On y retrouve en particulier des pipelines CI/CD (projet Tekton), un solution GitOps (ArgoCD) un Service Mesh (Istio), une solution d’observabilité (Promotheus, Grafana, EFK), des fonctions serverless, de virtualisation et plein d’autres fonctionnalités.

En savoir plus sur Red Hat OpenShift : https://www.redhat.com/fr/technologies/cloud-computing/openshift/features 

Destinés à regrouper et exécuter des applications, les conteneurs doivent être gérés afin d’éviter les arrêts de services. 

La mise en œuvre de Kubernetes permet d’optimiser la gestion résiliente de systèmes distribués basés sur les containeurs ainsi que la mise en place d’une architecture hautement disponible.

Kubernetes permet, par exemple d’équilibrer la charge et de distribuer le trafic réseau pour stabiliser le déploiement lors des pics de trafic. 

De plus, Kubernetes offre la possibilité de déployer et d’opérer des applications “cloud-native” indépendamment de l’environnement que vous soyez hébergés sur un cloud public (tel que Google Cloud, AWS ou encore Microsoft Azure), cloud privé ou sur une architecture locale.

Kubernetes gère aussi la possibilité d’automatiser le retour à un environnement stable, de redémarrer des conteneurs défaillants, d’arrêter ceux qui n’offre pas le niveau de performance souhaité.

Kubernetes est aujourd’hui un standard de facto qui amène une manière homogène et standard de déployer et gérer des containers. De par sa manière de déclarer et de fonctionner c’est une solution permettant aussi de faciliter la mise en place d’approches DevOps ou DevSecOps.

En théorie un container peut faire tourner n’importe quelle application et être orchestré par Kubernetes.

Dans la pratique les choses sont plus compliquées car pour pouvoir bénéficier au maximum des fonctionnalités de kube comme la montée en charge, la haute disponibilité, l’observabilité, la sécurité, … il est nécessaire d’architecturer et développer vos applications d’une certaine manière, c’est ce que nous appelons les Cloud Native Applications (CNA).

Pour des raisons de coûts, il n’est pas toujours possible de revoir complètement le design d’une application mais il est possible de l’adapter pour en faire une « Cloud Ready Application ».

Reste que les applications dîtes « Legacy » peuvent avoir un intérêt à être containérisées avec peu d’effort pour au moins bénéficier du standard de déploiement d’un container et de la gestion de son cycle de vie sans par exemple tirer parti du scaling…

Dans une optique d’optimisation d’un environnement comprenant des applications cloud-native, le principal bénéfice apporté par la solution Kubernetes est réellement celui lié à l’orchestration automatisé des conteneurs et l’élimination du facteur humain.

De plus, le fait d’administrer seulement le serveur maître et non plus chaque nœud individuellement confère une simplicité d’utilisation, un gain de temps significatif tout en limitant le risque d’erreurs associées.

L’automatisation de l’allocation élastique de ressources supplémentaires (autoscaling), la gestion du trafic dynamique, la redondance, la résilience, apportées par une plateforme Kubernetes permettent de répondre aux enjeux d’industrialisation des DSI tout en assurant l’agilité des opérations et du business (fiabilisation et accélération du « time to market » des applications).

Enfin, la portabilité induite de Kubernetes offre une réelle indépendance vis-à-vis des plateformes et donc des opérateurs Cloud permettant ainsi de pouvoir changer facilement de fournisseur.

Kubernetes, qui s’inscrit totalement dans une approche DevOps, se positionne donc comme l’orchestrateur de conteneurs de référence en amenant un standard de facto sur la gestion du cycle de vie complet des conteneurs du développement jusqu’à la production. 

La Cloud Native Computing Foundation (CNCF) détient le projet Kubernetes depuis 2016 qui est considéré comme un projet « Graduated » (le plus haut degré de maturité des projets CNCF).

Au travers de cette fondation, Kubernetes évolue régulièrement en proposant des nouvelles versions tous les 4 mois apportant soit de la stabilité soit des nouvelles fonctionnalités.

K8s prend une place de plus en plus importante dans les entreprises de toutes tailles et permet de répondre à des besoins de plus en plus variés.

La création de multiples clusters devrait devenir une commodité que ce soit On-prem, Multi-Cloud ou Hybrid-cloud le tout avec des approches « plateforme » pour des déploiements à grande échelle.

Il y a fort à parier que les domaines comme la virtualisation de VM dans Kube, le MLOps (Machine Learning), l’IA (Intelligence Artificiel) ou la Blockchain se développent de plus en plus.