Concerning Kubernetes : « combien de problèmes ces stacks ont générés ? »

Posted by

La hype, c’est de dire que Kubernetes c’est nul (parce que c’est hype ?)

Youpi ! Encore un billet d’humeur cette année ;-)

J’espère que comme moi, quand vous lisez dans votre tête "Concerning Kubernetes", vous avez l’air de "Concerning Hobbits" de Howard Shore dans la tête :)

Aujourd’hui je vais parler de Kubernetes mais rien de technique, seulement un question que je me pose :

Pourquoi c’est devenu à la mode de dire que Kubernetes c’est pas bien ?

Alors forcément, en "full disclosure", pour ceux qui ne me connaissent pas, je suis obligé d’indiquer que j’utilise Kubernetes dans mon travail d’Ops depuis environ 2 ans (++). J’en ai d’ailleurs abondamment parlé ces deux dernières années.

J’ai également utilisé Kubernetes à titre personnel pendant 6 mois, notamment pour héberger mon blog. L’objectif était uniquement d’apprendre Kubernetes par l’usage et je n’ai à aucun moment considéré que ce mode d’hébergement convenait à mes besoins (d’ailleurs, je ne l’utilise plus à titre personnel, maintenant que je sais comment ça marche).

Car oui, Kubernetes c’est un outil

Et comme tout outil, il faut :

  • l’utiliser idéalement dans les cas qui correspondent à son usage
  • savoir l’utiliser
File source: https://commons.wikimedia.org/wiki/File:Sledgehammer_(3586724830).jpg

Et donc, le cœur du sujet ?

Donc je l’ai déjà dis, mais ça fait quelques semaines que je vois de nombreuses attaques de personnes différentes qui expliquent que Kubernetes, c’est naze.

J’ai classé ces personnes en 4 types d’intervenants sur le sujet.

1, des Ops

D’abord, des confrères. La plupart du temps, il s’agit de gens qui n’ont pas utilisé l’outil, ne travaillent pas dans des environnements où Kubernetes pourrait rapidement leur apporter des gains, ou qui n’ont juste pas envie de changer leurs habitudes.

Oui, Kubernetes c’est (modérément) complexe. Même Kelsey Hightower, évangeliste Kubernetes niveau super Rockstar de chez GCP (Google) et auteur du guide "Kubernetes the hard way" le clame haut et fort :

Utiliser Kubernetes impose d’assimiler un certain nombre de concepts techniques, pour une part inhérents aux architectures microservices containerisées, pour l’autre part spécifiques à Kubernetes lui-même. De même, il faut composer avec un certain nombre de limitations et accepter de travailler différemment (on ne gère pas un serveur web de la même façon dans une VM et dans un container sur un orchestrateur managé).

Autant dire que quand un confrère Ops me parle de passer directement d’un environnement bien massif de type IBM AIX et ERP propriétaire vers l’installation d’un Openshift, la première chose que je lui dis c’est "Tu es sûr ? Tu ne veux pas plutôt tester un peu les containers Docker d’abord ?".

Dans des cas comme ça, échouer puis reprocher à Kubernetes d’être complexe est un peu malhonnête. Car quand on passe directement d’un mainframe à Kubernetes, on a loupé plusieurs changements dans la façon de travailler dans l’IT de ces 10 dernières années (++).

2, des hobbyists

Quasiment à chaque fois que j’écris un article sur Kubernetes, même quand il s’agit d’un truc aussi simple à déployer que l’offre Kubernetes as a Service d’OVH, je me retrouve avec un commentaire du style

Alors, déjà merci, parce que ça me fait toujours sourire ce genre de commentaires sur le blog ;-)

Ensuite : mais par rapport à quoi ?

  • A héberger tes photos de vacances sur ton NAS Synology ? Certainement !
  • A gérer une plateforme de domotique sur ton raspberry pi ? Sans aucun doute.
  • A publier tes 3 billets de blog sur Medium ?

Là c’est déjà un peu plus contestable, sachant que tu ne sais pas comment Medium fait pour obtenir un site web utilisé par un grand nombre d’auteurs et de lecteurs, résilient, accessible worldwide et sans plage de maintenance.

Le bon outil

Vous vous souvenez, au début de l’article, la métaphore de la mouche et du sledgehammer ? Bah on est en plein dedans là.

Bien sûr, utiliser Kubernetes pour toutes ces choses n’a pas de sens (publier 3 posts persos lu par 1000 personnes par jour et gérer ta domotique), en tant que particulier.

Ça me rappelle beaucoup le débat qu’il y avait eu lorsqu’un transformateur RTE avait brûlé en juillet 2018 et que la gare Montparnasse avait été dans le noir pendant des heures.

Tout le monde a hurlé au scandale ("pourquoi vous n’avez pas redondé le truc ???") et des types sont venus nous dire sur Twitter "nianiania arrêtez de dire que c’est pas normal de pas redonder. Est ce que vous avez 2 frigos chez vous, au cas où l’un d’entre eux tombe en panne ?"

Je pense que n’importe qui d’un peu honnête peut convenir que des outils d’entreprises comme Kubernetes répondent à des problématiques qu’on ne va pas avoir à gérer quand on est un particulier… Au même titre qu’on peut se permettre de n’avoir qu’un seul réfrigérateur chez soit.

Note : pour ceux qui n’ont pas suivi, dans le cas précis de Montparnasse en 2018, c’était la faute de RTE qui avait garanti à la SNCF que les 3 entrées électriques provenaient de 3 sources différentes, alors que c’était faux.

La 3ème catégorie

Ça fait titre de SF ce sous titre, non ? Ok, je sors => []

Dans les gens qui bashent le plus Kubernetes, on retrouve sans trop de surprise les gens dont le business est en concurrence plus ou moins directe avec Kubernetes. Et naturellement, ce sont eux qui font le plus de bruits (relayés par les autres).

Attention, je ne nie pas le fait que ces gens brillants (s’ils ont réussi, ce n’est pas pour rien) et que leur analyse est pertinente sur certains points.

Pour autant, on peut généralement trouver sans trop de difficultés une certaine mauvaise foi quand ils parlent de Kubernetes (que ce soit conscient ou pas)…

Quand Ian Eyberg écrit "Kubernetes is in Hospice" sur LinkedIn, on peut se demander s’il ne devrait pas demander à quelqu’un de le relire avant d’appuyer sur la touche entrée…

Je vous passe la grossièreté ("crap", etc), le mépris gratuit pour les "développeurs lambda qui font du JS parce que c’est plus simple"… Un type charmant, comme vous pouvez le voir.

k8s est juste une tentative de Google pour faire venir les gens sur Google Cloud

Tu la sens venir la théorie du complot reptilien ?

Facebook n’utilise pas Kubernetes car ça ne scale pas assez bien pour eux. Votre startup de 20 personnes ne devrait pas l’utiliser non plus.

Comparer les besoins de Facebook avec les besoins d’une startup de 20 personnes est une choix intéressant, en terme d’argumentaire je trouve. Et entre la startup et les GAFA, il n’y a rien d’autre ?

La sécurité dans les containers est un échec total

Parce que bien sûr la sécurité dans l’IT non containerisée est totalement maîtrisée. Il n’y a pas du tout d’exploits pour sortir d’une VM, les OS sont toujours à jour chez tout le monde, l’IOT c’est Fort Knox.

(Vous me connaissez, je vous ai forcément gardé le meilleur pour la fin )

Le site https://k8s.af est une collection d’histoires d’horreur sur la façon dont des sociétés ont échoué avec kubernetes. Ce n’est pas quelque chose qu’il faut applaudir ou dont il faut apprendre; c’est quelque chose à éviter. Vous ne pouvez pas dire que vous être ingénieur en génie civil et construire un pont qui risque de s’effondrer. Il y a des vies en jeu !!!!1!1!111

Est ce qu’on peut expliquer à ce monsieur que des fois des ponts s’écroulent et que JUSTEMENT, c’est parce qu’on essaye d’éviter que ça se reproduise qu’on apprend de nos erreurs et qu’on évite de les réitérer ?

Une réponse de l’auteur de k8s.af à ce genre de personnes

Bon, une fois qu’on a lu tout ça, on prend une grande inspiration, on regarde l’entreprise que dirige Ian Eyberg et on voit qu’il est PDG de … NanoVMs.

Et au cas où vous doutiez encore un peu, NanoVMs est une société qui se positionne ouvertement comme une alternative à Docker.

Business is business.

Et les fournisseurs de service ?

Dans le même genre, je me suis pris la tête avec le fondateur d’une solution cloud qui propose aux Dev de gérer l’Ops pour eux, pour qu’ils se concentrent sur le Dev (business totalement pertinent et louable). Il vend un service bien marketé, UX bien pensée, etc, rien à redire de ce côté là.

Cette personne m’explique que c’est plus simple pour un Dev d’utiliser son service que quand je demande à mes collègues Dev d’écrire un template Helm (on y reviendra). Soit, je veux bien l’entendre.

Mais derrière, s’il n’utilise pas Kubernetes (probable vu l’opinion qu’il a de l’outil), il a forcément du déployer des stacks techniques pour résoudre les problématiques similaires (déploiement, provisionning, haute dispo, répartition de charge). Donc au final, il a juste implémenté d’une autre façon, quelque chose qui fait comme Kubernetes.

Et quand je lui fais remarqué ce point précis, devinez ce qu’il m’a répondu (avec les majuscules et tout) ?

RIEN A VOIR

Donc quoi ? Tu fais tout à la main ?

Je vous jure, des fois, la mauvais foi des gens me fatigue…

4, des devs

Et là, on tombe sur la catégorie de personnes dont les réactions négatives m’attristent le plus.

J’ai l’impression que ces gens là ne se rendent pas trop compte de l’effort qu’il faudrait déployer pour obtenir la même chose, sans Kubernetes.

En fait, c’est comme si, en rendant le service aussi résilient qu’il l’est devenu, les Devs pensent que c’est simple d’avoir aussi bien, sans Kubernetes (remplacez Kubernetes par tout autre outil permettant d’automatiser la gestion d’une infrastructure complexe et hétérogène).

Un peu plus de détails

Dans mon travail, nous hébergeons plusieurs plateformes Kubernetes. Ces plateformes sont à destinations des développeurs, pour leur fournir de l’infrastructure de manière "masquée", managée par nous.

Pour vous donner un ordre de grandeur, on parle d’une demi douzaine de clusters, avec entre 50 et 100 machines virtuelles, qui font tourner de manière résiliente plusieurs centaines d’applications chacun.

Ces applications (types microservices) sont hautement hétérogènes. On y dénombre pas moins de 5 ou 6 langages de programmation différents, deux ou trois fois plus de frameworks, des messages bus, des bases de données externes, …

Avec Kubernetes, nous ne leur demandons pas de gérer l’infra, ni même de nous demander de l’infra. Nous leur fournissons, au travers d’une chaîne d’intégration continue (IC), un self service pour consommer cette infrastructure. Les seules choses qu’on leur demande pour consommer cette infrastructure, c’est :

  • de créer leur propre image (aka "image Docker")
  • de rédiger les spécifications de leur application, interprétables par Kubernetes (via Helm, le langage de templating le plus répandu pour déployer sur Kubernetes)
Un extrait d’un chart Helm (https://github.com/helm/charts/blob/master/stable/bitcoind/templates/deployment.yaml)

Pour ces choses, ils peuvent se baser sur des exemples de projets existants et/ou demander de l’aide à mes collègues Ops ou mes collègues de l’intégration continue.

Hashtag DevOps.

Ces deux choses qu’on leur demande sont donc ni plus ni moins que de la configuration et un genre de "code" simpliste, au même titre qu’ils renseignent déjà un pom.xml ou autre packages.json. Pour un développeur, on peut s’attendre à ce que ça ne soit pas un souci.

Et que gagnent ils en échange de ce travail ?

De l’autonomie, du temps

Surtout de l’autonomie sur le déploiement de nouvelles applications, au sens large du terme.

D’abord, pas besoin d’avoir un Ops pour aider et manipuler des problématiques complexes de configuration de serveurs, la redondance/haute disponibilité, répartition de charge, …

Tout ce qu’ils ont besoin de faire, c’est remplir un fichier texte YAML (certes très verbeux) avec les caractéristiques qu’ils souhaitent pour leur application (donne moi 3 instances identiques de telle container, avec tant de CPU/RAM). De base, l’application est alors déployée de manière reproductible, résiliente, se régule d’elle même en cas d’incident, …

Pas besoin de demander aux OPS une nouvelle paire de serveurs webs à la moindre modif et surtout… pas besoin d’attendre pour l’avoir !!

"Le futur et toutes les raisons d’y croire"

Pour illustrer, je peux vous parler d’un exemple personnel. Dans une autre vie pas si lointaine, j’ai été OPS pour un grand opérateur. Pour chaque nouveau projet, je recevais des demandes (aka. un ticket) de la part des Dev pour configurer des serveurs web. Mes collègues et moi avions 3 semaines pour traiter ces demandes.

TROIS… SEMAINES…

Autant dire que j’ai eu un paquet de fois à tout refaire car entre temps, un nouveau modèle (master) avec la mise à jour de l’application était sorti le temps que la demande d’environnement soit traitée.

Avec Kubernetes, en quelques secondes (5 minutes max si on compte toute la chaîne d’intégration continue), c’est livré.

Des Ops plus disponibles

De même, pour gérer ces plateformes, il faut X fois moins de gens pour les administrer que si on devait déployer ces serveurs à la main, à la demande, sur des VMs par exemple. A l’heure actuelle, côté Ops, 2 personnes suffiraient pour maintenir l’ensemble de ces clusters.

Je dis "suffiraient" car nous gérons beaucoup d’autres plateformes en plus de Kubernetes. En terme de "charge homme", 2 ETP auraient encore pas mal de marge pour absorber de nombreux projets (aka applications déployées) en plus. Les autres membres de l’équipe ont le temps de gérer d’autres plateformes.

Je n’ose pas imaginer le nombre d’Ops qu’il faudrait pour maintenir un équivalent "VM" contenant 250 applications hétérogènes, les loadbalancers, etc. 5 ? 10 ? 15 ? Bien plus que 2, c’est sûr…

Et ce temps que l’équipe Ops a de disponible, c’est du temps qui peut servir à améliorer l’infrastructure pour coller le mieux aux besoins des développeurs, maintenir les bonnes pratiques sur l’ensemble du périmètre, les assister en cas de bug, …

Faire du DevOps, en somme.

Moins d’incidents

Là, c’est LA partie qui devrait leur tenir le plus à cœur normalement.

J’ai travaillé sur tous types d’infrastructures. Des bons gros Mainframe, des infrastructures virtualisés, convergées, HYPERconvergées, des SAN, des NAS et depuis 2 ans, sur Kubernetes.

Et bien, laissez moi vous dire qu’il n’y a pas photo. Mais genre, pas du tout.

Le fait de travailler en microservices containerisés, en s’astreignant à suivre quelques bonnes pratiques, permet réellement d’obtenir un service de qualité. 95% des incidents, qu’ils viennent de plantages imprévus de l’application ou de problèmes sur l’infrastructure, se résolvent d’eux même en quelques secondes, la plupart du temps sans notification à l’astreinte lorsque ça n’est pas nécessaire (ce qui n’empêche de débugger a posteriori, juste pas en pleine nuit).

C’est extrêmement impressionnant.

Mes 6 derniers mois d’astreinte se résument quasiment exclusivement à des incidents sur la partie legacy et/ou non containerisée. La partie Kubernetes se gère toute seule, j’ai très rarement eu à intervenir, que ce soit sur la plateforme elle-même, ou sur les applications hébergées dessus.

Au final, les premiers fans de Kubernetes, ce sont les membres de ma famille, que je ne réveille plus la nuit pour redémarrer un serveur web ou basculer un cluster qui s’est mal déclenché.

Donc les devs sont contents ?

Et ben non…

Je ne compte plus le nombre de gens brillants qui m’ont dit :

nan mais attend ton truc, c’est super compliqué

le go template/YAML c’est incompréhensible

c’est pas mon job de faire ça

Et là, je suis hyper déçu.

Venant de gens qui sont capables de m’expliquer avec force de détails pendant 30 minutes ce qu’est une Monad, qu’un Monoid ce n’est du tout la même chose, je trouve ça culotté de venir m’expliquer qu’un bout de GOtemplate, c’est le summum de la complexité.

Je réitère une dernière fois… Oui, Kubernetes, c’est modérément complexe. Non, c’est pas trop complexe. Bien moins que tous les autres concepts que ces gens là manipules tous les jours. C’est juste que le DevOps, au fond, ça ne les intéressent pas vraiment.

Ça se résume d’ailleurs assez bien dans le "c’est pas mon job de faire ça".

C’est le job de qui alors ? De savoir ce que fait l’application, comment elle interagit avec les autres, de quelles ressources elle a besoin ?

Moi je dirais que c’est celui qui l’a développée, EN ÉQUIPE avec celui qui maintient l’infrastructure.

Et je conclurai mon propos par un petit tweet de @bitfield qui a fait pas mal sauter des Devs de leur chaise il y a 3 ans et qui n’a malheureusement pas pris une ride.

¯\_(ツ)_/¯

12 comments

  1. Je suis partiellement d’accord avec l’article.
    Kubernetes est intéressant, et permet en effet beaucoup de choses, et a sa place dans l’écosystème actuel.

    Par contre (et c’est un truc que je revois souvent lorsque je discute avec des gens de Kubernetes), il y a souvent une comparaison de faite avec « l’avant kubernetes » et l’après Kubernetes, du type avant « Mes collègues et moi avions 3 semaines pour traiter ces demandes » et maintenant on a du déploiement facile etc…

    Pourtant, du Consul, Ansible, les outils cloud comme l’autoscaling, Terraform, Packer ou autre permettent aussi de faire des déploiement « le dev clique sur un bouton et ça part en prod », de façon assez simple d’ailleurs.
    J’ai mis ça en place avant que Kubernetes existe, j’ai pas la sensation que Kubernetes m’aurait aidé à mieux le faire à l’époque (surtout quand le besoin c’est juste en gros scaler + faire du rolling update).

    Et finalement c’est plutôt ça mon gros reproche aujourd’hui: Kubernetes a cannibalisé l’écosystème devops, et les solutions alternatives (qui sont parfois plus simples à mettre en place, apportent des choses différentes…) ne sont plus mentionnées.

    Ayant participé à la mise en place de Kubernetes en prod dans une ancienne expérience, et l’utilisant également toujours aujourd’hui, la bête est quand même complexe (surtout si on le met en place soit même, ce qui est mon cas), et le coût de maintenance est quand même assez important.

    En conclusion: Oui pour Kubernetes, mais dommage qu’on ne voit plus que ça (et c’est pour moi ça le problème numéro 1).

  2. Merci pour ce retour !

    Bien vu, tu prouves que moi aussi, je peux être de mauvaise foi ;) (quand je compare la livraison d’un env en 3 semaines en 2010 avec Kubernetes en 2019).

    Blague à part, oui nous sommes d’accord en fait. Évidemment, il n’y a pas que Kubernetes pour automatiser la livraison et la gestion de l’infrastructure. C’est un peu noyé dans mon propos mais d’ailleurs j’en parle :

    En fait, c’est comme si, en rendant le service aussi résilient qu’il l’est devenu, les Devs pensent que c’est simple d’avoir aussi bien, sans ~~Kubernetes~~ (remplacez Kubernetes par tout autre outil permettant d’automatiser la gestion d’une infrastructure complexe et hétérogène).

    Sur le fait que c’est dommage que Kube est tout cannibalisé, on est d’accord aussi. Je suis très très fan d’Ansible (et dans une moindre mesure de Terraform) et je suis un peu frustré de ne pas pouvoir l’utiliser autant que je voudrais ;).

  3. Oui finalement on est d’accord ;)

    De manière générale, je trouve que c’est aujourd’hui compliqué de trouver des gens sachant vraiment comparer le pour et le contre des technologies (et donc faire des choix pertinents).

    On a comme tu le décris les haters de mauvaise foi, les gens qui veulent pas évoluer, les fanboy qui veulent absolument pousser leurs technos partout, les gens qui ont peur d’être à la traine sur leur cv et donc là aussi vont éventuellement pousser des choses pour de mauvaises raisons etc…

    Pour moi, la faute revient aussi à la communauté. je trouve que l’on a assez peu d’articles détaillant les pour et les contre des technos (pour Kubernetes ou autre), les solutions alternatives etc… D’ailleurs de manière générale, on se focalise trop sur les technos et non sur le besoin/le service que l’on veut rendre. On est poussé à faire de la techno pour la techno.

    Les conférences arrangent rien. Les talks sur pas mal de technos montrent généralement des POC. C’est très bien, mais cela donne de fausses impressions au public (on avait la même chose avec le big data et le NoSQL il y a quelques années, résultat tout le monde pleurait quand on se rendait compte qu’en fait Mongo c’était pas pour remplacer les bases SQL).

    J’ai fait une conf cette année, et clairement enchainer les talks Kubernetes toute la journée où personne ne parle du besoin initial, des contraintes en prod, du monitoring, du réseau etc… mais vend que la magie du truc c’est assez lourd. Et je pense qu’une partie des trolls anti Kubernetes vient aussi de là: trop de projets partent dessus sans savoir expliquer pourquoi, sans étudier d’alternatives et où finalement quand tu débarques sur le projet tu te rends compte qu’en fait ça permet juste aux SSII du coin de placer 10 consultants pour gérer le cluster.

    En conclusion, je trouve que notre industrie manque de pragmatisme :p

  4. Merci pour cet article !
    Je suis complètement d’accord avec toi, surtout sur un point, étant moi-même développeur : je ne comprends pas pourquoi j’entends des développeurs me sortir « ah ouais mais attends, pour le fichier deployment, je comprends pas comment ça marche et puis j’ai pas eu la formation ». Alors ok, pour me parler de ta super nouvelle techno magique que t’a vu ya deux jours et dont tu sembles déjà tout connaitre ya pas de soucis, mais pour faire un fichier de configuration en yaml, tu vas me faire croire que t’en es pas capable ?
    Comme tu dis, c’est juste de la flemme et ça ne les intéresse pas. Pourtant mais quel pied ! J’ai appris k8s « The Very Hard Way » en partant de zéro il y a quelques mois (merci Rancher) et je ne comprends pas comment on peut critiquer une telle révolution. Aujourd’hui, on a 1 et 1 seul devops qui gère toute notre infrastructure et on a l’impression d’être enfin libres. Libres de pouvoir déployer ce qu’on veut comme on veut avec un simple fichier de configuration. Comment est-ce possible, en tant que développeur de ne pas embrasser cela avec amour ?
    Je ne connais pas un seul dev qui n’a pas critiqué, même si ce n’est pas sans un peu d’humour, les « sys » à cause du temps qu’ils mettent à monter un serveur, à en gérer la maintenance, à faire les mises à jour… Sans compter les problèmes d’accès, les configurations à gérer, l’adressage réseau, les problèmes d’accès disque, etc, etc… C’est trop facile de critiquer un groupe de personnes et quand on parle de partager ces responsabilités, de botter en touche en mode « l’infra, c’est pas mon problème ».

    Coté perso, il est clair que Kubernetes n’est pas envisageable mais docker est tout à fait indispensable. Et si un orchestrateur n’a de sens qu’a partir du moment où on possède une infrastructure de plusieurs noeuds, docker lui a du sens absolument partout. Dans ma boite, on ne travaille déjà plus sur nos propres machines mais dans des images docker. Plus besoin d’installer quoi que ce soit en dehors d’un IDE : une machine et un OS et c’est parti. Là où je veux en venir c’est que je pense que cette catégorie de personne aura beau critiquer, la seule chose qu’on peut leur répondre c’est que d’autres on aussi essayé de défendre le Minitel à une époque. Ça reste du troll quand même mais je pense qu’on en est pas si loin.

  5. Bonjour,

    Article vraiment intéressant et pertinent dans son ensemble.
    Cela fait 2 ans que je fais du DevOps en utilisant majoritairement Kubernetes et en le couplant avec du Jenkins et Ansible.
    L’infra que j’avais à gérer était de l’hyperconvergé avec VMware en interne de l’entreprise et majoritairement sans internet ni sans service type cloud comme aws, Google cloud, azure, etc.

    Dans ce cas, je trouve que Kubernetes devient de modérément complexe à complexe à administrer pour les Ops. Pourquoi ? Parce qu’il manque des services importants à Kubernetes qui sont importées nativement dans les cloud (Load balancer, stockage, réseau, etc.).
    Cela reste vrai sans utiliser Kubernetes bien entendu.
    Il faut également reconnaître que Kubernates commence à arriver dans des versions « stable », ce qui n’était pas le cas il y a 2/3 ans. Quand je dis stable, je parle par exemple à l’appel aux APIs kubernetes qui ont pas mal changés au niveau des versions, à certain mécanisme qui ont disparu (heapster, cadvisor, l’externalisation du stockage : CSI, etc.). Disons que la stratégie Kubernetes arrive à une certaine maturité qu’il n’y avait pas il y a quelques années.

    La où je suis d’accord avec toi c’est que Kubernetes est un outil vraiment intéressant quand on manipule des containers voir même indispensable aujourd’hui pour la haute disponibilité. J’en suis aujourd’hui convaincu.

    Cependant, pour moi, Kubernetes n’est pas incompatible avec d’autre outils de CI/CD comme Jenkins et Ansible. Je dirais même qu’il est important de les coupler notamment pour la partie build et tests applicatives.

    J’ai également testé la techno Cloud Foundry. Ils sont en train d’incorporer Kubernetes dans leur produit…

    Voilà pour mon retour d’expérience.

  6. Merci pour ce retour. Ca fait plaisir d’avoir l’avis d’autres personnes, en particulier des développeurs, sur le sujet :-)

  7. Super retour ! Merci pour ton avis. Effectivement, difficile de marier Kubernetes avec les outils qui étaient là avant.
    A l’exception de Jenkins tout de même (mais je vois qu’on est d’accord) qui reste incontournable pour le build (ou équivalent bien entendu)

  8. Le métier de l’ombre des OPs . Le DEV développe sur son poste la plupart du temps et ne comprend pas les enjeux de résilence qui nous sont demandés au niveau des infrastructures.
    Merci pour le feedback très intéressant ;)

  9. Article très agréable à lire et super retour d’expérience. Merci pour le partage.

    Concernant, les devs, je pense que c’est un effet collatéral du management…

    Pour info je ne l’utilise pas encore mais ce ne devrait tarder … ;)

  10. Merci pour l’article.

    Une alternative (que j’utilise) est portainer / swarm.
    Je travaille pour une petite stucture et nous développons un produit composer de plusieurs briques. C’est une infrastructure riche, suffisamment complexe pour être un vrai casse tête en imaginant un déploiement à l’ancienne.

    J’ai trouvé que pour le besoin que j’avais (un produit, composé de webservice, base de donnée, redis, rabitmq, ldap etc) kubernetes c’etait quand même trop.

    Cette alternative m’a permit d’avoir un entre deux, simple à mettre en place, scalable. Le défaut, c’est que juste de par sa simplicité, il faut rajouter un temps d’intégration des fonctionnalités manquantes, et un peu de dev pour lier tout ça.

  11. Merci pour le retour !

    L’article n’est pas forcément hyper clair là dessus, mais je ne dis pas du tout que Kubernetes convient à tout le monde (même en entreprise). Au contraire ! En revanche, je voulais répondre à ceux qui disent que Kubernetes n’est une bonne solution pour personne, comme j’ai pu le lire.

    C’est super si vous avez trouvé une solution à base de portainer, j’avais justement envie de tester :).

Leave a Reply

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.