Kubernetes en vaut-il le coup ?

En dévoilant “Project Pacific“, VMWare a reconnu que Kubernetes sera une base de vSphere, son offre de virtualisation.

Cet événement marque le début d’une nouvelle ère : Kubernetes est désormais une norme de facto dans les plateformes informatiques pour exécuter des charges de travail de conteneurs en production, et est considéré comme égal aux machines virtuelles.

Pourquoi devrais-je m’en soucier (en tant qu’ingénieur en informatique, chef de projet, chef de service ou vendeur) ?

Conteneurs, Conteneurs, Conteneurs…

Jetons un coup d’œil à l’année 2013 : Docker a été présenté à la PyCon par dotCloud, un fournisseur de Paas.

Six ans plus tard, cet outil technique avait été largement adopté par les développeurs, bouleversant notre secteur en innovant dans la manière dont les développeurs conditionnent, partagent et livrent les applications.

L’idée centrale de Docker est d’exécuter des applications avec une isolation légère, packagées avec leurs dépendances pour être auto-servies. Plus de conflits entre les versions de PHP ou de JDK entre les anciennes et les toutes nouvelles applications : chaque “conteneur” contient les siennes et ne se marche pas sur les pieds.

Tant de bruits pour un outil de développement ? L’industrie informatique a déjà connu ce genre de vagues technologiques : Quel est l’intérêt ?

Docker est un outil qui automatise certaines préoccupations : sur quel port les applications écoutent-elles ? Quels sont les répertoires requis ? Quel est le modèle de sécurité sous-jacent ? Ces éléments pourraient être documentés, mais vous risquez un décalage entre les attentes et la réalité.

En rendant ces métadonnées (presque) obligatoires, il n’a jamais été aussi facile de partager les préoccupations par équipe, et de permettre un apprentissage opportuniste “uniquement quand vous en avez besoin” : vous pouvez commencer par un serveur viable minimaliste, puis itérer sur les répertoires, puis sur le réseau, ou tout ce qui est nécessaire.

Ce comportement est parfaitement aligné avec les principes Agile : se concentrer sur la valeur qui compte. Docker a fait (ou essayé de faire) la prémisse de la culture “DevOps”, qui consiste à appliquer les principes Agile du développement aux opérations.

 

“Laissez-vous convaincre : valider des hypothèses commerciales sans mettre en danger la production, cela en vaut vraiment la peine. Et ce n’est qu’un des nombreux avantages…” Damien Duportal

… Mais qu’en est-il de Ops/Sysadmin ?

L’itération sur de minuscules morceaux de logiciel n’est pas souvent réalisable lorsque votre préoccupation quotidienne est la stabilité et la sécurité : Les principes Agile peuvent être compris, mais sont plus difficiles à appliquer dans ce domaine.

En délaissant certaines tâches qui étaient habituellement traitées par le monde des “ops”, Docker pose de nombreuses questions sur les défis d’une production bien rodée : qu’en est-il de la sécurité, des déploiements, de l’utilisation des ressources, etc. Bien sûr, ces défis ont été partiellement (ou pas du tout) relevés.

Kubernetes est issu de ce monde, en tant que modèle opérationnel basé sur ce que nous avons appris au cours d’une décennie de gestion de la configuration. Il tente de rendre les conteneurs (Docker mais pas seulement) capables de fonctionner en production.

Favoriser la prise de conscience intersilos

Kubernetes (avec Docker) est un moyen de partager la connaissance des préoccupations de l’équipe, c’est-à-dire de partager des informations. “Traduire la définition de l’optima local pour collaborer à en faire un optima global”.

Si vous êtes prêt à aligner toutes les équipes sur les activités de votre organisation, la définition d’OKRs devrait être une priorité. Et si les départements informatiques disposaient d’un outil permettant d’automatiser l’OKR en tant qu’atout technique ? Arrêtez de chercher cette licorne : Kubernetes pourrait être un moyen d’y parvenir !

Les communautés open source parlent souvent de Docker comme d’un outil d'”empathie en tant que code” : c’est exactement le but recherché !

Des outils techniques pour les entreprises (et non l’inverse)

L’outillage technique est amusant pour les ingénieurs logiciels (dev et ops), mais il doit servir un objectif pour l’organisation, sinon il ne s’agit que d’un hobby.

En tant qu’homme d’affaires, qu’est-ce que Kubernetes (et les conteneurs) mettent sur la table ?

Considérons l’adage “De l’idée à la production”. Cette phrase illustre le flux de valeur de nos entreprises : une fonctionnalité n’apporte de la valeur seulement lorsqu’elle est utilisée en production.

Le temps nécessaire à l’élaboration d’une hypothèse commerciale et à sa validation ralentit la création de valeur. Mais n’essayez pas d’aller vite pour autant : les fonctionnalités doivent fonctionner correctement en production, ce qui exige de la stabilité ! Bien sûr, il s’agit d’une mesure commerciale qui vaut la peine d’être mesurée pour s’assurer que vous suivez toute variation (augmentation ou diminution) afin de prendre des décisions.

Si vous ajoutez Kubernetes dans l’équation, vous bénéficierez d’un système où la métrique est un citoyen de première classe. En tant qu’outil d’ingénierie de pointe, les métriques sont essentielles à toute décision : comment utiliser efficacement les ressources informatiques ? Comment faire évoluer et équilibrer la charge des applications ? Comment assurer la sécurité et le suivi de toute action automatisée ? Vous avez besoin des métriques !

Kubernetes permet également de nouveaux modèles de déploiement qui étaient auparavant coûteux à mettre en œuvre. Par exemple, considérons les “déploiements progressifs“, où l’idée est de fournir des changements progressivement à des sous-ensembles de nouveaux utilisateurs, ou sans les activer immédiatement.

Avec Kubernetes, vous pouvez activer le “routage Canary” soutenu par le système de métriques centralisé : vous pouvez déployer une fonctionnalité uniquement pour 2% des utilisateurs, et laisser le système se replier si plus de 10% de ces utilisateurs sont en erreur.

Laissez-vous convaincre : valider des hypothèses commerciales sans mettre en danger la production, cela en vaudrait vraiment la peine.

Et ce n’est qu’un des nombreux avantages…

Qu’est-ce que Kubernetes ?

  • Kubernetes est un mot grec qui signifie “gouverneur” ou “timonier”. Ce projet est un orchestrateur open-source pour les charges de travail en conteneurs.

    Basé sur les principes de Borg, l’ordonnanceur de conteneurs de Google, il a été dévoilé en 2014 par 3 ingénieurs de Google.

    Depuis sa version v1.0 en 2015, ce projet est désormais détenu par la Cloud Native Computing Foundation, dépendant de la Fondation Linux elle-même.

    Écrit en Golang, Kubernetes fournit un ensemble de primitives faiblement couplées pour gérer les charges de travail des conteneurs. Vous pouvez le voir comme une grappe distribuée de blocs de construction de base.

    Pour faire simple, il s’agit d’une grappe de machines permettant d’exécuter des conteneurs de manière distribuée.

    Construit autour d’une API centralisée, Kubernetes est un modèle opérationnel basé sur le concept de machine à états : vous décrivez l’état dans lequel vous voulez que le système se trouve, et il est chargé de converger vers cet état à partir de l’état actuel par itérations.

    La différence avec Docker? Kubernetes ajoute une couche d’orchestration avec des éléments faiblement couplés. Par exemple, le déploiement d’une application nécessite de définir différents objets à des fins différentes :

    • Définir un “Déploiement” pour décrire l’état de vos instances d’application.
      • Exemple : “Je veux que mon application web ait toujours 2 répliques saines en fonctionnement pour gérer la charge de travail de la production.”
    • Définir un “service” pour exposer l’application et assurer l’équilibrage des charges :
      • Exemple : “Je veux que cette application soit toujours joignable via cette IP privée hautement disponible, sur le port 80. Elle s’équilibre en charge sur toutes les répliques”.
    • Définir un “Ingress” pour publier l’application en externe :
      • Exemple : “Je veux que toutes les requêtes HTTP entrantes dont le nom d’hôte est ‘www.company.org’ soient transmises au service sur le port 80”.

    Kubernetes offre une extensibilité à ce modèle d’objet, de sorte que vous pouvez définir votre propre objet à couplage lâche pour votre logiciel : par exemple, JenkinsX fournit des “Builds” et des “Jobs”.

    Plus d’objets signifie plus puissant, mais aussi plus difficile à apprendre : prenez le temps de comprendre la signification de chaque objet avant de vous lancer à fond dans Kubernetes !

Comment passer à Kubernetes ?

Bon, alors vous êtes convaincu de la valeur. Mais comment passer de votre infrastructure actuelle en métal nu ou en conteneurs ?

Commencez par sélectionner un projet candidat, pour lequel vous avez des parrains dans chaque équipe : au moins un développeur, une personne chargée des opérations, mais aussi une personne chargée de la gestion, car vous avez besoin de l’acceptation de toute l’organisation pour permettre le travail collaboratif.

Mettez tout le monde dans la même pièce (ou dans une salle de discussion virtuelle si vous pratiquez le travail distribué) et laissez-les travailler sur l’exécution du projet dans une preuve de conformité Kubernetes. Donnez-leur les moyens d’accomplir cette tâche : des machines, du temps pour apprendre et pratiquer.

Dès que le prototype minimum viable émerge, commencez la boucle de rétroaction et itérez sur une autre pièce, jusqu’à ce que vous ayez obtenu :

  • Un pipeline de déploiement complet (“de l’idée à la production Kubernetes”)
  • Observabilité sur le système (“collecte de métriques et de logs au moins, éventuellement traçage”)
  • Test Crash & Restore (“Combien de temps avez-vous besoin pour restaurer le cluster en cas de crash”)

Vous êtes maintenant prêt à évaluer la valeur, et à commencer à ajouter d’autres projets, avec l’équipe initiale comme sponsors pour responsabiliser les autres équipes et les faire démarrer.

Veillez à ne pas utiliser cette validation initiale du concept comme une mesure du temps pour les projets suivants :

le coût initial de l’apprentissage et de la découverte diminuera avec chaque nouveau projet ajouté et avec l’émergence de bonnes pratiques.

N’oubliez pas que cet investissement n’est pas perdu dans un trou noir si vous choisissez de ne PAS utiliser Kubernetes. Parce que vos équipes auront toujours appris et amélioré vos applications actuelles : le déploiement d’une application dans Kubernetes nécessite que certains (et peut-être tous) des 12 facteurs soient remplis. Prendre conscience des points faibles d’une application et de son processus de livraison est toujours une leçon précieuse pour l’amélioration.

Pour conclure

En adoptant pleinement Kubernetes et son modèle, votre organisation bénéficiera d’un modèle puissant et extensible pour exploiter des applications en production à l’aide de conteneurs.

L’investissement dans la courbe d’apprentissage est toujours un avantage : au moins, vos applications gagneront en maturité opérationnelle. Et si vous l’utilisez en production, votre entreprise bénéficiera de nouveaux modèles, qu’il s’agisse de mesures commerciales supplémentaires ou de nouvelles façons de déployer des fonctionnalités pour vos utilisateurs finaux.

Une dernière chose : n’oubliez pas de reverser ce que votre organisation a appris.

Comme vous le découvrirez en cours de route, vos équipes ont acquis beaucoup de connaissances,

Redonner à la communauté est également une démarche d’amélioration pour vos employés : pensez à la réputation positive et à la position de leader !

Auteur

Par Damien DUPORTAL, un freelance qui a récemment animé un atelier Kubernetes dans les bureaux d’Arexo à Liège.

Contact:

Freelance, ancien défenseur des développeurs pour Traefik @ Containo.us, ancien ingénieur de formation Jenkins @ CloudBees, mentor de 🐳Docker.

Pile humaine concentrée. Escaladeur. Ingénieur logiciel passionné. Parlez-moi !