Débuter avec Kubernetes

Tout le monde se secoue ! 

J’ai commencé (mardi 08 septembre 2020 à 09h45) la rédaction d’un tutoriel au doux nom de « Débuter avec Kubernetes » et j’ai pour objectif de proposer en validation un texte aux petits oignons. Je fais donc appel à votre bonté sans limites pour dénicher le moindre pépin, que ce soit à propos du fond ou de la forme. Vous pourrez consulter la bêta à votre guise à l’adresse suivante :

Merci !

Ça fait un moment que j’en parle. Il est maintenant temps de joindre l’action à la parole.

Comme vous le voyez, tout reste à faire. Cependant le but du jeu est de rendre les lecteurs capables :

• De savoir quand Kubernetes est utile et magique, et quand il n’est pas adapté
• D’avoir une compréhension au moins superficielle, mais juste, de son fonctionnement interne
• De conteneuriser correctement une application (c’est-à-dire éviter les horreurs qui valent à Docker sa mauvaise réputation de nos jours)
• De savoir la déployer sur un cluster Kubernetes, en gérant plusieurs trucs très courants :
  • Comprendre les notions de base : pod, deployment, service
  • La configuration des conteneurs et les valeurs secrètes
  • Savoir déployer une application stateful qui repose sur un espace disque persistant
  • Configurer un ingress pour réaliser la terminaison TLS, et servir d’API Gateway
  • Les bonnes pratiques "imposées" par Kubernetes :
    • Répondre à des healthchecks
    • Faire des rolling updates
  • Les bases de l’observabilité (utiliser Prometheus et Grafana…)

Ainsi que, peut-être, des choses plus "avancées" :

• Se servir de Helm.
• Quelques patterns courants que l’on utilise avec les conteneurs, comme le sidecar, parce que c’est un terme que l’on croise très souvent.

Ce dont je ne parlerai PAS

Comment déployer et administrer soi-même Kubernetes sur ses machines : c’est un sujet avancé et très intéressant en soi, mais en réalité, très, très peu de gens ont réellement besoin de savoir faire ça. Tout l’intérêt du cloud est d’externaliser son infrastructure afin qu’elle soit maintenue par d’autres.

Pour expérimenter, je vais me contenter de diriger les lecteurs vers une offre Kubernetes managée gratuite (celle d’OpenShift), qui est faite pour ça.

Bonjour sujet très intéressent

mais tu comptes parlé aussi de l’automatisation (même succin) des tests et déploiement automatisé ? il y a une diff face a docker ? et docker composer ?

Cordialement

Bonjour sujet très intéressent

mais tu comptes parlé aussi de l’automatisation (même succin) des tests et déploiement automatisé ?

Pas dans ce tutoriel a priori. Tout cela dépend en grande partie des technologies que l’on utilise, voire de la façon et de l’endroit où on héberge notre code (on ne le fait pas de la même manière dans github ou dans gitlab, ni en Java, en Python, en Node ou en Go…). Du coup je préfère éviter d’en parler et partir du moment où on a des images de conteneurs disponibles dans un registry (public comme Dockerhub, ou privé comme gcr.io…), en expliquant rapidement comment ça se passe avec Docker.

Spoiler : ça se fait en une simple ligne de commande.

il y a une diff face a docker ? et docker composer ?

On ne se situe pas au même niveau d’abstraction : tu peux très bien orchestrer tes conteneurs Docker avec Kubernetes (c’est même ce qui se passe par défaut)… ou bien avoir un autre runtime pour exécuter tes conteneurs (containerd, CRI-O…), parce que leur format est aujourd’hui standardisé. En d’autres termes, Kubernetes ne remplace pas Docker, il l’exploite et le complémente.

Par contre, par rapport à docker-compose, oui, il y a un monde de différence, parce que le but ici n’est pas juste d’orchestrer ou d’ordonnancer des conteneurs sur une seule machine : il permet de définir des services, des load balancers, des stratégies de réplication et de scaling automatique, il se charge d’équilibrer tout cela sur un nombre arbitraire (et dynamique) de machines disponibles, il se débrouille pour que l’application soit persistante, même quand des machines tombent en panne, il vérifie aussi la bonne santé et la disponibilité des conteneurs en cours d’exécution, élimine ceux dont le comportement est anormal (ceux qui utilisent plus de CPU ou de mémoire qu’ils n’en ont déclaré)…

Pour résumer simplement : j’utilise docker-compose pour développer et tester en local sur mon laptop, mais quand vient le moment de déployer mon appli en staging ou en prod, c’est Kubernetes qui prend le relais.

Est-ce que tu prévois de parler des cas où Kubernetes n’est pas une solution ?

Je pense notamment aux gros plats de spaghettis ou de lasagnes qui sont incapables de scaler horizontalement, ou aux applications scalable à l’ancienne, où tu peux ajouter des serveurs mais moyennant de la configuration non-triviale.

Clairement, je ne compte pas mentir : Kubernetes est une solution parfaite du moment que notre application est découpée en micro-services et proprement conteneurisée. C’est la base. Vouloir y rentrer de force un monolithe serait une gigantesque perte de temps et d’argent.

Un autre cas où Kubernetes n’est pas forcément le plus adapté, c’est par exemple celui d’une grosse base de données : c’est possible, mais compliqué, et j’ai prévu un chapitre pour montrer comment ça se passe quand certains de nos composants ne sont pas interchangeables (comme les répliques d’une base de données).

Je compte bien sûr parler de tout ça, parce que je ne suis pas là pour vendre une silver bullet.

j’avais pensé a parler a propos d’une BDD

mais quelque recherche, microsoft propose le systeme et c’est plus pour le coté bug et l’appli crash que le coté scalable

après, j’ai l’impression que ça peut induire un effet pervers "roh ça crash mais ça reboot automatiquement, c’est bon pas besoin de s’en préoccupé"

Je ne suis pas sûr que ce soit un effet pervers. Si le crash d’un serveur à 3 heures du matin peut attendre que j’aie fini ma nuit pour que je m’en préoccupe (parce qu’il a redémarré entre temps et que les utilisateurs ne s’en sont même pas rendu compte, tout en produisant des tas de logs et de métriques que je peux dépiauter pour comprendre l’incident), ça me va, hein.

D’ailleurs, des programmes ou des machines qui tombent, ça arrive tout le temps. Et ce n’est pas toujours de notre faute. Pire encore, ça peut être volontaire : Netflix a même développé un service qui fait tomber des machines volontairement en production, pour s’assurer que son système est résilient (d’ailleurs on peut installer ce genre de service sur Kubernetes…), mais sans aller jusque là, on peut très bien vouloir implémenter un système résilient qui tourne sur des VM préemptibles et pas cher, qui peuvent disparaître et réapparaître à tout instant…

Le problème que tu décris est un problème humain qu’aucune solution technique ne saurait résoudre.

Bonjour @nohar, pas de remarques particulières de mon côté, je voulais juste te remercier pour ce cours que j’ai hâte de lire !

Bon courage !

Bonjour les agrumes !

La bêta a été mise à jour et décante sa pulpe à l’adresse suivante :

Merci d’avance pour vos commentaires.

Vous constaterez que je suis en train de prendre soin du tout premier chapitre, parce que son enjeu est assez lourd :

• Poser le décor,
• Introduire la techno.

La difficulté, ici, c’est que les gens, d’après mes propres observations :

• sont désabusés du cloud (car échaudés par le bouillon de bullshit permanent que l’on peut voir sur LinkedIn, au point de perdre de vue la seule notion qui compte : tout est service, tout est décentralisable),
• ont généralement une première expérience "meh" avec Docker, généralement dans un cadre où il fait plus de mal que de bien, ce qui donne un apriori très négatif ("j’y comprends rien", "ça sert à rien", "c’est le nouveau XML/PHP/…"),
• sont sceptiques sur le sujet.

Il ne s’agit pas tant d’intéresser un public de débutants (si on ne sait pas développer, ça ne sert à rien de lire ce tuto) que de fournir une porte d’entrée progressive et qui leur parle à des gens qui ont déjà dû se frotter à des problématiques complexes : d’après mon expérience, le "wow moment" que l’on a avec Kubernetes, c’est quand on s’aperçoit qu’avec une poignée d’abstractions bien pensées, on solutionne by design des problématiques douloureuses et très courantes ("punaise, si j’avais connu ça l’année dernière avec le projet Machin, j’aurais peut-être pas eu aussi mal").

Bonjour les agrumes !

La bêta a été mise à jour et décante sa pulpe à l’adresse suivante :

Merci d’avance pour vos commentaires.

Je reprends le travail sur ce tutoriel, après avoir mûri tant ma pratique que mes idées. Le plan du tutoriel est maintenant à peu près établi. Il n’y a plus qu’à remplir tout ça.

Bonjour les agrumes !

La bêta a été mise à jour et décante sa pulpe à l’adresse suivante :

Merci d’avance pour vos commentaires.

La partie 1 est maintenant suffisamment remplie pour que les relecteurs en bêta puissent suivre.

Si vous empruntez une voie différente de celle décrite dans le tutoriel pour installer docker ou avoir accès à un cluster gratuitement, cela m’intéresse. Cette partie est systématiquement l’une des plus ennuyeuses à rédiger, quel que soit le tutoriel, et j’avoue que je préfère ne pas m’attarder plus longtemps dessus pour me concentrer sur l’essentiel qui arrive maintenant.

Bonjour les agrumes !

La bêta a été mise à jour et décante sa pulpe à l’adresse suivante :

Merci d’avance pour vos commentaires.

Je viens de créer le chapitre qui explique les concepts clés du fonctionnement de Kubernetes.

Pour moi, c’est le chapitre le plus important de tout le tuto. Une fois qu’on a bien pigé et intériorisé ce fonctionnement, tout le reste devient facile à expliquer et à comprendre : ce sont juste de nouvelles ressources (et le comportement des contrôleurs associés) à découvrir, des outils et des bonnes pratiques à appliquer à des situations concrètes.

Bonjour les agrumes !

La bêta a été mise à jour et décante sa pulpe à l’adresse suivante :

Merci d’avance pour vos commentaires.

Ajout d’un chapitre où l’on programme, conteneurise, publie sur Dockerhub et déploie sur Kubernetes un serveur HTTP minimaliste.

on ne l’arrête plus

Bonjour les agrumes !

La bêta a été mise à jour et décante sa pulpe à l’adresse suivante :

Merci d’avance pour vos commentaires.

Je viens d’ajouter une section au dernier chapitre pour expliquer comment fonctionnent les requêtes et les limites de ressources.

Avant de passer au chapitre sur les services, je vais ajouter un nouveau chapitre dans lequel on adapte le serveur HTTP pour que kubernetes soit capable de le sonder, et donc déterminer quand il est prêt ou pas à répondre à des requêtes et aussi comment on fait passer ce serveur à l’échelle en faisant varier son nombre instances.

Ça nous permettra d’expliquer en détail la stratégie de rolling upgrade que Kubernetes applique avec les deployments.