Débuter avec Kubernetes

Le système d'exploitation du Cloud

a marqué ce sujet comme résolu.
Auteur du sujet

Tout le monde se secoue ! :D

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.

Édité par nohar

I was a llama before it was cool

+9 -0
Auteur du sujet

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.

Édité par nohar

I was a llama before it was cool

+0 -0

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.

Édité par SpaceFox

Auteur du sujet

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.

SpaceFox

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. :)

Édité par nohar

I was a llama before it was cool

+1 -0

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é"

+0 -0
Auteur du sujet

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é"

depfryer

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

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.

Édité par nohar

I was a llama before it was cool

+0 -0
Auteur du sujet

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").

Édité par nohar

I was a llama before it was cool

+2 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte