qu'on le veut ou non, il y a eu un avant et un après Docker.
Même si Docker aujourd'hui est en perte de vitesse,
les conteneurs nous apportent finalement un outil en plus pour gérer nos applications.
Avant on avait les serveurs, les VM, etc. et aujourd'hui on a les conteneurs.
Mais est-ce qu'on peut se contenter...
Mais dit que l'on ne peut plus se contenter d'un seul serveur
et que l'on veut passer à la haute disponibilité,
il faut utiliser ce qu'on appelle des orchestrateurs de conteneurs.
Alors qu'est-ce que c'est ? À quoi ça sert ?
Et est-ce qu'on peut se passer de Kubernetes ?
Voilà ce qu'on va voir aujourd'hui dans ce podcast.
Bonjour à toi chers compagnons et bienvenue dans ce 20ème numéro de Radio DevOps,
ton émission où on traite d'un sujet particulier.
Et aujourd'hui c'est Kubernetes, les orchestrateurs de conteneurs.
Et ce qu'on peut faire sans Kubernetes comme tu l'as vu avec l'introduction.
Je te rappelle que tu peux t'abonner au podcast ou à la chaîne YouTube
pour être notifié à chaque fois qu'on sort un podcast
et sur la chaîne YouTube à chaque fois que je sors une vidéo.
Petit disclaimer dans ce épisode de podcast, on ne va parler que des conteneurs.
Et on va parler que des orchestrateurs de conteneurs et pas des conteneurs.
Et surtout les conteneurs ne sont pas des machines virtuelles.
On va définir un tout petit peu ce que c'est les conteneurs juste avant de commencer.
Et on va se focaliser sur les solutions libres que l'on peut opérer nous-mêmes,
pas sur les services en ligne qui sont basés sur les orchestrateurs de conteneurs
parce que sinon ce serait vraiment trop long.
Et pour en parler avec moi aujourd'hui j'ai Nicolas.
Bonsoir à tous.
Bonjour Nicolas.
J'ai aussi René.
Bonjour René.
Bonjour Christophe.
Et enfin j'ai Mathieu.
Bonjour Mathieu.
Bonjour.
Et je pense qu'on peut commencer à vendre définir tout ça.
Non non, on le fera juste après la définition.
On va d'abord commencer par définir ce qu'est un conteneur et Nicolas je crois que tu as une petite introduction à faire là-dessus.
Oui en fait beaucoup parlent de conteneurs et pour faire très très simple en gros c'est juste le processus d'une application.
Donc par exemple le processus Tomcat, le processus Ruby qui va faire tourner toute l'application
et la même chose pour tous les langages.
Et si vous commencez à avoir deux process dans le même contexte, on va sortir du modèle conteneur.
Donc voilà c'est juste un seul process pour faire tourner notre service dans un conteneur.
Je peux préciser aussi que ça a été apporté pour pouvoir isoler les processus entre eux sur une même machine.
Et donc on va arriver à l'orchestration de conteneurs.
Finalement c'est quoi une orchestration de conteneurs ? Qui est-ce qui veut se lancer dans cette définition ?
Je peux me lancer.
Un orchestrateur de conteneurs c'est un composant qui va être là pour démarrer des conteneurs.
Il est redémarré s'il tombe ou si on perd un oeuf à un autre endroit.
Pourquoi pas les placer sur des oeufs en fonction de contraintes particulières.
Bref en fait c'est un outil qui va gérer le cycle de vie de notre conteneur.
La création, la suppression, le scaling etc.
Voir beaucoup de choses en plus selon les orchestrateurs mais on aura le temps d'en parler un peu plus tard.
Justement, puisqu'on parle d'orchestrateur de conteneurs il est peut-être bon de dire à notre auditeur
qu'est-ce que c'est notre expérience avec les orchestrateurs de conteneurs et avec les conteneurs.
Pourquoi est-ce qu'on en parle aujourd'hui tous les quatre et quel retour on a ?
Brievement finalement c'est quoi votre expérience avec les orchestrateurs de conteneurs ?
On va commencer par René.
Ah ça tombe mal.
Je suis quand même un petit peu cet acteur-là.
Je suis de mon point de vue.
Alors après je suis peut-être un peu exigeant par un gros spécialiste de Kubernetes.
Pour le moment je n'ai pas eu à le pratiquer au jour le jour.
Après j'ai fait pas mal dans le passé une autre solution Swarm.
Je connais les concepts etc.
Mais je pense que ici vous êtes tous beaucoup plus familiarisés que moi je pense
dans l'usage au jour le jour de Kubernetes.
Nicolas ?
Alors moi j'ai connu les conteneurs avec l'arrivée de Docker et quelques trucs un petit peu avant comme LX et ainsi de suite.
Dès le début beaucoup sont précipités avec du Docker en production.
A l'époque je disais encore que c'était pas mature pour de la production.
Maintenant je pense qu'on peut dire que c'est mature pour de la production.
On a énormément de problèmes qui sont arrivés avec.
On va parler de ce sujet-là aujourd'hui puisque les orchestrateurs sont justement là pour régler tous ces problèmes-là.
Effectivement j'ai fait du Docker Swarm, j'ai fait du Docker tout seul orchestré à la main avec des petits scripts sur les serveurs.
Quand j'ai vu Nomad arriver j'ai trouvé que c'était une excellente alternative.
On en parlera plus en détail tout à l'heure mais pour vous donner un contexte je l'utilise assez massivement.
Dans mon statut de freelance pour mes clients mais aussi dans ma société qui m'emploie aujourd'hui,
qui est Squarespace et en fait on développe une solution qui déploie massivement les infrastructures en 3 clics
pour schématiser avec notamment du Nomad pour pouvoir déployer les conteneurs assez facilement.
Mathieu toi ton retour.
Moi j'ai commencé avec les conteneurs avec l'apparition de Docker également.
Sur l'orchestration j'ai travaillé un peu avec Mesos Marathon en 2015.
J'ai découvert Q&A TIS en 2017 et j'ai travaillé au déploiement de Cluster, notamment à 26 balles à l'époque.
J'utilise Q&A TIS maintenant depuis 3 ans et demi en production et c'est également mon équipe.
Je travaille chez un cloud provider, c'est mon équipe qui a monté l'offre Q&A TIS à la service de l'entreprise.
Moi mon expertise sur l'orchestration c'est surtout Q&A TIS depuis maintenant assez longtemps.
Et moi j'ai commencé à entendre parler de Docker à sa sortie.
J'ai trouvé ça génial. Je me disais pouvoir isoler des process c'est quand même pas mal.
Surtout qu'à l'époque j'étais en train de me poser des questions là-dessus.
Je connaissais pas les conteneurs avant en fait pour tout vous dire et donc du coup ça m'a ouvert un petit peu là-dessus.
J'ai beaucoup joué avec et j'ai découvert l'orchestration de conteneurs en 2016-2017
et j'ai fait un événement redat puisque moi je suis rentré à travers les orchestrateurs avec OpenShift.
Donc je suis venu à Kubernetes avec OpenShift et peut-être qu'on pourrait en parler.
Et du coup j'ai opéré une plateforme OpenShift en production depuis l'or.
J'ai déployé aussi sur OpenShift et aujourd'hui je fais du Kubernetes
parce que OpenShift suivez pas forcément assez rapidement.
En tout cas la version LIM ne suivez pas assez rapidement en Kubernetes et OpenShift sous licence.
Et donc on va pouvoir parler de à quoi ça sert finalement un orchestrateur
parce que bon ça reste un petit peu obscur je pense pour nos auditeurs et auditrices.
Et on va peut-être parler tout de suite de quel problème on va résoudre avec un orchestrateur
et pourquoi finalement on est venu à utiliser ou à créer des orchestrateurs
qui veulent se lancer, donner des bonnes idées là-dessus.
De pourquoi on en est là ?
Je peux commencer sur le fait de pouvoir déclarer quelles sont les conteneurs qui vont tourner
puisque avec les conteneurs et arriver une deuxième mode c'est les microservices.
Et finalement toute la philosophie DevOps qui est arrivée avec
où j'ai envie de faire un guide push et j'ai envie que tout mon interface déploie de manière automatique.
Tous mes conteneurs vont se pousser en production ou se mettre à jour
et toute mon application va se gérer entre guillemets toute seule.
C'est un petit peu simpliste de dire ça comme ça mais globalement c'est à peu près ce qu'on a envie de faire
et finalement quand on avait une galaxie assez complète de microservices
c'était aussi complexe de gérer toute cette galaxie parce que tout le monde sait faire un docker run
mais le faire à chaque mise à jour c'est pénible et comme le disait Mathieu tout à l'heure
on a aussi envie que tout se gère de manière automatique.
On en reparlera un petit peu plus tout à l'heure quand on parlera de tolérance de panne et ainsi de suite.
Et il y a un autre aspect qui est vraiment intéressant c'est le côté déclaratif.
C'est on a envie d'avoir un fichier qui va décrire de manière assez complète.
Je veux tel conteneur qui va dialoguer avec tel autre conteneur
qui va avoir telle variable d'environnement et ainsi de suite
et j'ai un fichier qui déclarent tout et je pousse ça dans mon orchestrateur
et tout se fait automagiquement.
Mais si je peux me permettre tout ça on pouvait le faire avec Docker Compose
puisque dans un Docker Compose pour ceux qui ne savent pas c'est un fichier dans lequel on décrit nos services
et dans lequel on pouvait mettre tel conteneur il va faire tourner ça, tel conteneur il va faire tourner ça et ils sont liés comme ça.
Et ça tourne sur une seule machine finalement. Pourquoi est-ce qu'on a besoin de ça avec un orchestrateur ?
Un Docker Compose c'est très facile on installe pouffrons l'ence.
Oui Docker Compose répondait à la problématique qui a été décrite par Nicolas
de pouvoir faire tourner tous les processus liés à tous les conteneurs qui tournent les processus d'une application.
Par contre manifestement c'est ce que tu dis c'est scotcher à une machine.
Il a des transports à une machine du coup si la machine a un problème
il n'y avait pas la notion de qui est ce qu'on recherche d'autres disponibilités pour garder nos applications vivantes.
Et voilà donc les conteneurs apportent tout un ensemble de solutions pour gérer la haute dispo.
Donc ce que tu veux dire c'est finalement si le serveur tombe nos conteneurs
il fallait une solution pour les envoyer sur un autre serveur ?
Oui c'est ça, il faut les redémarrer entre guillemets.
Aujourd'hui ce qui est fait c'est qu'ils vont être redémarrés sur un autre membre du cluster s'il y a plus vraiment.
J'ajouterai également deux choses, c'est très bien pour des microservices mais même sur des infrastructures en orienté services classiques
c'est à dire pas du microservice mais juste quelques services, on va dire un découpage assez simple, ça a un intérêt.
Et l'intérêt également, Nicolas a parlé de manière déclarative de déclarer son infrastructure
c'est que ça permet d'avoir une manière un format commun, quel que soit le langage utilisé finalement
du Java, du Python ou le type d'application ou de process pour décrire son infrastructure.
Décrire son infrastructure ça va être décrire ce qu'on veut comme stockage, ce qu'on veut exploser comme port,
ce qu'on veut comme ressource ou des choses plus évoluées avec du lebancing ou autre.
Il y a aussi ça, c'est vraiment ce langage commun qu'apporte un orchestrateur
où toutes les applications seront sous le même format et on saura finalement à quoi s'attendre quel que soit la stack utilisé derrière.
Et puis il y a un autre aspect pour ajouter, donc il y a l'aspect effectivement haut de dispose
mais aussi avec Docker Compose on est limité à une machine, on peut faire scaler des containers, c'est à dire on lance plusieurs
mais forcément ça reste sur la même machine, du coup l'orchestrateur on va pouvoir faire scaler par exemple des frontales web
et donc l'outil va se débrouiller à nous les placer sur les ressources disponibles
donc on peut aller très loin si on a beaucoup de serveurs, il va nous démarrer X container par serveur jusqu'à ce qu'il ne puise plus
et donc accepter des charges très variables.
Alors du coup il y a aussi un truc, c'est quand on utilise Docker Compose sur une machine
si finalement notre stack elle tient pas sur une seule machine mais sur plusieurs
même si on ne veut pas de la haute dispose, Docker Compose évite limiter parce qu'il va falloir faire communiquer les containers entre eux
imaginons qu'on est plein de microservice, qu'on ne veut pas de l'aute dispose, donc on n'a pas forcément besoin de 4, 5, 10 servers
même si on n'en a besoin que de 2, Docker Compose il est un peu limité là dessus
et du coup il faut faire communiquer tous ces containers et s'assurer que le réseau soit sécurisé
et donc c'est probablement là que l'orchestrateur de container il fait aussi son apparition
si on veut éviter le côté haute dispose.
En fait si je résume c'est des consorts du monoserver il nous faut un orchestrateur de container
quoi que ce soit la réponse qu'on veut adresser.
Oui et donc en fait l'orchestrateur c'est le chef d'orchestre un petit peu de tout ça
où finalement on a plein de petits composants qui viennent autour du container
et il faut orchestrer tout ça pour que tout puisse fonctionner ensemble.
Je rajoutais juste rapidement que c'est possible de se passer d'orchestrateurs
si par exemple on déploie des containers sur des machines virtuelles classiques
mettons trois containers d'une même application.
S'il y a une machine qui tombe on en aura plus que deux
mais peut-être que c'est pas grave, peut-être que ça peut attendre jusqu'au lendemain matin
que quelqu'un redébarre une machine etc.
Mais aujourd'hui comme on l'a dit il y a plus en plus de services, plus en plus de composants
on va dire d'applications qui tournent etc.
Donc les orchestrateurs fournissent une interface commune.
Oui et puis les orchestrateurs il faut en utiliser des services
que tu n'as pas avec ton pauvre petit docker compose et que tu dois forcément faire
toi à la main j'imagine.
Exactement. Alors ça dépend des orchestrateurs
ça c'est aussi le gros débat de ce podcast.
Certains ont fait beaucoup de fausse, peut-être que d'autres vont faire moins
mais peut-être que c'est bien de faire moins, essayer de tout faire
peut-être que c'est pas une bonne idée au final.
Enfin bref c'est toujours un équilibre à trouver
mais on va en discuter je pense.
Il y a peut-être juste un autre aspect intéressant c'est que
souvent la répartition les faits quand même par le logiciel
et donc voilà les outils sont bien faits pour essayer d'optimiser au maximum
les ressources disponibles sur le cluster.
Plus que ce qu'on pourrait probablement faire avec des méthodes plus traditionnelles
sans orchestrateur.
Ouais notre orchestrateur comme disait Nicolas c'est un chef d'orchestre
qui va dire toi ce contenu là tu vas aller sur cette machine
toi tu vas aller là parce qu'elle est moins chargée toi tu vas aller là
ah bah y'a cette machine qui tombe à temps je vais aller lancer ces
contenu à droite à gauche c'est vraiment ça son travail
enfin son travail premier en fait.
Il y a d'autres trucs en effet, il y a d'autres services mais on n'en parlera.
Vous voulez juste dire qu'il y avait des fois plus ou moins d'intelligence
dans les orchestrateurs on va dire ça.
Exactement.
Alors y'a l'un de vous qui a laissé un message, enfin laissé une note
que j'ai du mal à comprendre on parle de convergence de l'état du monde.
Je pense c'est comment est-ce que les orchestrateurs ils font
vas-y elle en va tuer.
Il faut savoir que comme je dis je travaille chez un cloud
et en fait sans parler de conteneurs on écrit des orchestrateurs
pour tous nos produits et c'est toujours le même principe et ça ressemble
aussi à ce que font des orchestrateurs de conteneurs c'est qu'on va déclarer
ce qu'on veut finalement quelque part à une API notamment
c'est peut-être l'API on va parler de Kubernetes par exemple
la API de Kubernetes on met aussi d'autres orchestrateurs
on va dire je veux ça je veux tel conteneurs donc qui utilise
tel image avec qui doit utiliser telle ressource en CPU et en RAM
je veux par exemple 4, 5 ou 6 instances de ce conteneur
bref on décrit ce qu'on veut finalement
et l'orchestrateur va être là pour faire converger
l'infrastructure vers cet état voulu finalement
il va dire ah bah tiens là j'en ai zéro des réplicats
pour ce conteneur bah je vais en créer 5
et si on perd un nœud il va détecter ça et dire ah bah j'en ai plus 4
il faut que je vienne créer un nouveau donc sur un autre nœud
donc voilà c'est vraiment ça quand je parle de boucles de réconciliation
dans ma note c'est ça c'est on va toujours vérifier l'état du monde
vérifier que finalement l'infrastructure qui existe vraiment
qu'on a déployé le nombre de conteneurs et leurs caractéristiques
correspond à ce que nous utilisateurs avons déclaré à l'orchestrateur
c'est vraiment ça le fonctionnement d'un orchestrateur c'est je déclare ce que je veux
et ensuite c'est des logiciels qui vont travailler bah pour faire
converger l'état du cluster donc il est à du monde ici
bah dans l'état voulu dans l'état qu'on veut et faire en sorte que cet état
soit toujours maintenu c'est le plus important
du coup on en revient un petit peu à cette notion d'infrastructure à scode
qu'on a déjà un peu abordé dans un autre épisode
c'est qu'on va décrire notre infrastructure et là c'est une infrastructure à base de conteneurs
mais ça pourrait être comme tu dis une infrastructure autre à base de VM etc
exactement
j'ai l'impression que la pays est un nœud central non dans les orchestrateurs
oui pour moi c'est le travailler via une API c'est quasiment obligatoire aujourd'hui
c'est vraiment un point central le fait d'avoir une API sur laquelle on peut
atterragir pour déclarer son infrastructure
comment est-ce que les orchestrateurs continuent à faire ça et on a vu un standard
qui a émergé finalement depuis quelques années
le conteneur network interface le CNI de son petit nom
Nicolas tu veux nous en dire un peu plus ?
oui alors en fait il y a une problématique qui est arrivée assez rapidement
c'est la gestion des réseaux
donc on a parlé tout à l'heure des conteneurs qui devaient pouvoir interagir les uns avec les autres
l'idée des conteneurs c'est aussi de les cloisonner dans des environnements totalement à part
pour que mon conteneur A ne puisse pas dialoguer avec mon conteneur B qui est sur un autre projet
et pour pouvoir faire ça il faut mettre les boncables entre les conteneurs
et comme on a tout virtualisé il a fallu aussi virtualiser le réseau à un moment donné
et en fait on a énormément de solutions au niveau réseau
donc on peut partir sur des trucs entre guillemets simples
c'est des réseaux virtuels donc c'est les overlay networks de Docker par exemple
il y a des overlay networks chez d'autres constructeurs donc on a du Calico, on a du Wave etc
et qui on a aussi des virtualisations de réseaux qui existaient il y a très longtemps
c'est les VLAN et finalement si on a déjà un réseau physique existant
et la possibilité d'avoir accès au VLAN, pourquoi s'en priver ?
et finalement ces Kubernetes et tout son écosystème qui a ramené ça
et donc c'est les standards comme CienAi
donc CienAi c'est quoi ?
il y a deux parties
il y a la partie c'est à la fois un protocole de déclaration qui va dire
je veux créer un réseau, je veux lister mes réseaux, je veux supprimer mon réseau
je veux attacher un conteneur sur tel réseau et ainsi de suite
et à la fois des binaires
donc un binaire pour configurer un réseau
donc tous les réseaux que j'ai cités précédemment
les overlay networks, les VLAN et ainsi de suite
pour différents composants
et ce qui est vraiment intéressant dans ce standard
c'est que c'est arrivé avec la communauté Kubernetes
mais n'importe qui peut utiliser ce plugin-là
et là on parle de CienAi mais il y a son pendant qui est CSI pour la partie stockage
et ce qui est intéressant dans ces deux composants-là
c'est que ça va aussi être la possibilité d'utiliser des fournisseurs spécifiques à un provider
par exemple pour la partie stockage on peut avoir au accès au stockage AWS
donc du mode bloc ou du mode plus NFS
et sur les réseaux, je n'ai pas trop creusé la partie réseau
mais j'imagine qu'on doit pouvoir avoir accès à des réseaux privés
un petit peu spécifiques côté différents fournisseurs IaaS
donc j'imagine qu'on doit pouvoir connecter des conteneurs directement à des VPN
via ces protocoles CienAi
après peut-être que Mathieu a un petit peu plus d'expérience que moi sur la partie réseau
En effet certains cloud providers fournissent leur propre plugin CienAi
qui permet de s'interfacer avec leur solution de réseaux privés
après comme tu l'as dit il y a des tonnes d'outils et de solutions
via des routes juste ajoutées aux machines, jusqu'au VXLAN etc
ça ça va être aux utilisateurs de faire des choix mais en effet il y a aussi des solutions
spécifiques à certains cloud providers
qu'il est possible d'utiliser
ou de remplacer d'ailleurs
on n'est pas forcé d'utiliser la solution de cloud provider
on peut utiliser Syllium, Calico ou autre
par exemple, Humanities si on le veut
parce que ça reste un standard
on peut enlever le composant et en mettre un autre à la place
En fait je pense que c'est une défense de Kubernetes
c'est qu'il est très modulaire
donc toute cette notion de plugin et de définition standard
permet d'avoir une abstraction
on peut parler globalement de la même manière à tout le monde
et puis derrière c'est un peu comme un driver
ça va faire les bonnes interactions avec le matos qui est derrière
il me semble, dites moi si je dis pas de bêtises
pour moi c'est ça
je viens de regarder vite fait, il y en a à peu près 27
peut-être un petit peu plus dans ceux qui sont référencés
et ça va de des fournisseurs YAS comme Amazon, Azure
et aussi des fournisseurs comme VMware
qui sont des alternatives au cloud provider
mais il y a aussi du juniper pour ceux qui ont du matos
entre guillemets un petit peu plus propriétaire
et du coup ça ouvre des perspectives super intéressantes
pour ceux qui veulent opérer eux-mêmes des trucs plus ou moins exotiques
mais qui vont s'intégrer dans un autre écosystème
que ça soit dans du cloud ou en premise
parce que c'est aussi un truc qu'il faut pas oublier
c'est qu'il y a encore des gens qui veulent pouvoir avoir des fonctionnalités similaires au cloud
mais dans leur propre data center, dans leur propre infrastructure
justement, puisqu'on parle de ça
on peut parler des solutions d'orchestrateurs qu'on peut installer dans nos propres data centers
qu'est-ce que vous en pensez, R
évidemment on va évacuer tout de suite Kubernetes
pour ceux qui connaitraient pas Kubernetes
en fait c'est sorti en 2015
donc la version 1 est officiellement sorti en juillet 2015, le 21 pour être exact
c'est un projet qui a été libéré par Google
et en fait c'est un projet qui a inspiré d'un autre projet interne à Google
qui s'appelait le projet Borg
et le nom interne du projet chez Google avant que ce soit libéré
c'était pas Kubernetes, c'était le projet 7
et le projet 7 faisait référence à un personnage de Star Trek
qui est un Borg devenu amical
on peut se poser la question de pourquoi Google a choisi ça
peut-être que Borg était passée avec quelque ça à l'époque
et donc pour la petite anecdote
les 7 rayons que vous voyez sur le logo de Kubernetes
donc Kubernetes c'est un terme grec qui désigne un Gouvernei
donc pour ceux qui n'ont jamais vu le logo de Kubernetes c'est un Gouvernei
à cette branche, à 7 rayons
et il y a 7 rayons justement en référence avec 7 pour ce nom original
donc Kubernetes, qu'est-ce que c'est ?
pourquoi on a autant parlé et pourquoi est-ce que tout le monde l'utilise presque ?
je vous lance la patate chaude
c'est l'orchestrateur qui a eu la plus grosse croissance
où les gens ont le plus adhéré, la plus grosse communauté
et c'est devenu quasiment un standard de facto
après pour de bonnes ou de mauvaises raisons
ça c'est chacun jugera
mais il y a eu un engouement vraiment fort
il y a eu un engouement fort aussi parce que je pense que c'était propulsé par Google
les gens ont, je pense qu'il y a eu un effort très important de Google
pour à la fois développer le produit
mais aussi beaucoup le faire de marketing autour
et voilà c'est devenu un petit peu la solution dont tout le monde parle
et avec un écosystème qui n'a rien envoyé à envier à celui de Java Strip
c'est un vrai boxon, il y a plein de projets dans tous les sens
mais du coup c'est extrêmement vivant
et puis voilà je pense que ça correspondait aussi un peu avec les microservices
ça répond malgré tout quand même à un certain nombre de problématiques
donc ça explique le succès
parfois au détriment peut-être à mon regret d'autres solutions
qui ça a un peu éclipsé d'autres solutions qui étaient peut-être pas si mal aussi
mais bon ça c'est la vie
Oui justement on parlera d'autres solutions
on parait des autres solutions un petit peu après
on d'abord ne va pas c'est qu'ils sont abandonnés
pour certaines parce qu'il y en a certaines qui sont vraiment abandonnées
vas-y Nicolas
Ouais ce que j'allais dire je vais pas m'étendre trop longuement sur Kubernetes
parce que je le connais pas aussi bien que vous
mais le peu que j'en ai vu ça m'a pas vraiment donné envie de creuser
mais mon côté Parano me dit que c'est peut-être un plan maciavélique de Google
pour plomber ses concurrents en réellisant un truc open source
qui est très difficile à opérer
mais ça c'est mon côté un petit peu maso, Parano
Alors je dirais pas ça
Tu veux y aller tout de suite ?
Très rapidement juste pour le côté Parano et Google
je pense que aujourd'hui c'est difficile en tant que concurrent de Google
si on parle de l'aspect cloud de se passer de Kubernetes
parce que moi je l'ai vu des clients qui débarquent
qui disent bah ouais bah moi je vous faites du cloud
je parle même pas de IAS, PAS, IAS etc.
juste vous faites du cloud oui on fait du cloud
vous faites du cloud Kubernetes ?
bah non on fait pas de Kubernetes
ok bah on viendra pas chez vous
c'est comme ça que ça se passe aujourd'hui en 2021
il faut le savoir
je pense que c'est important de le mentionner Galant
Comme étant un acteur un petit peu concurrent
c'est un sujet que je connais très très bien
mais bah c'est malheureusement c'est la vie
et moi j'ai préféré être maso et choisir un des concurrents
donc moi je parlerai un petit peu plus tout à l'heure
Alors je sais quel concurrent tu vas parler
mais Kubernetes a aussi un avantage par rapport aux autres
c'est que historiquement il est quand même arrivé pratiquement
un tout petit peu après Docker
et ça ça fait beaucoup aussi
et il a plein des avantages Kubernetes
mais il a plein d'avantages
et justement on pourrait citer
autre que le fait qu'il y ait des Kubernetes
managés un peu de partout
ce qui n'est pas le cas des autres distributions Kubernetes
on en parlera après ou des autres solutions
parce que en fait dans un orchestrateur de contenant
on n'a pas dit mais il y a deux grosses parties
il y a la partie installation maintenance infrastructure
comment est-ce qu'on maintient l'orchestrateur
et la partie création des ressources dans l'orchestrateur
qui reste encore pour moi une partie Ops
qui n'est pas encore au développeur
parce que comment on fait communiquer les microservices
comment on les architecture tout ça
c'est un autre métier par rapport à celui qui va installer l'orchestrateur
ça fait déjà deux bons gros métiers d'ops
finalement notre métier est pas prêt de partir
mais il y a encore pas mal d'avantages
mais je vais vous laisser en citer quelques-uns des avantages
parce que je sens que Nicolas et René
ont un petit peu envie de troller
et puis Mathieu je suis sûr que t'en vois plein
et après on parlera des problèmes parce qu'il y en a plein aussi
Non pourquoi troller ?
Je pense qu'on a déjà vu un des aspects
c'est l'aspect vraiment modulaire de la solution
plugin etc.
donc ça s'adapte à plein de fournisseurs de stockage
plein de types de réseaux etc.
L'origine d'ailleurs c'est quand même assez probre
ça se gérer que des réseaux à place
si je dis pas de bêtises
et du coup les besoins
il fallait faire des choses un peu sérieuses
niveau sécurité réseau pour isoler certains containers
d'où c'est de volonté d'avoir des nouvelles solutions
et d'avoir standardisé ce qu'on a vu tout à l'heure
le CNA etc.
d'autres avantages on l'a dit c'est du descriptif
quand même ça c'est quand même plutôt cool
donc du coup ça veut dire que les développeurs
si ils peuvent décrire leur stack
et logiquement utiliser Kubernetes
pour déployer toutes leurs applications
donc ça c'est quand même un gros avantage
voilà je pense qu'il y en a certainement d'autres
mais je vais passer la main
En toute objectivité je vais quand même
sortir quelques avantages
donc ça a quand même établi une norme
dans l'orchestration des containers
donc malgré tout le mal qu'on peut penser
des chartes OL
il y a au moins un standard sur ce côté là
il y a tout l'écosystème qui vient autour
qui apporte quand même énormément
à la gestion des containers
puisque tout à l'heure on citait
CNA, CSI, ça peut largement être utilisé
par d'autres trucs
et un autre gros avantage de Kubernetes
c'est que c'est un système Lego
donc un autre projet similaire
qui me fait souvent penser c'est OpenStack
OpenStack on peut monter son propre YAS
voilà on peut monter son propre orchestrateur de containers
et chaque composant peut être installé
ou pas installé mais aussi être remplacé par un autre
je ne connais pas suffisamment tout l'écosystème
pour savoir à quel point
quel composant peut être remplacé ou pas
mais en gros pour gérer les certificats
TLS à l'intérieur du système
si j'ai bien compris il y a quelques alternatives
qui peuvent être utilisées ou pas
si on veut gérer du stockage
on peut mettre certains composants
pour avoir du stockage distribué
du stockage MFMR et ainsi de suite
et tout ces trucs là c'est un écosystème hyper vaste
où on peut aller piocher à volonté
en fonction de ses propres besoins
oui alors justement je vais approfondir un petit peu
et je laisserai la parole à René après
les deux composants qui pour moi sont essentiels
au coeur de Kubernetes peuvent en effet être changés
on parlait tout à l'heure des CNI
donc de l'interface réseau
donc on peut choisir en fait notre interface réseau
comme on veut
et on peut choisir aussi notre run time de containers
donc comment est-ce que les containers sont gérées
et ça c'est très intéressant
parce que du coup on n'est pas lié à Docker
ou on n'est pas lié à CRI
ou à Acraio
on peut vraiment choisir
et le truc qui pour moi est
le top du top
en termes d'avantage c'est les CRD
les Custom Resources Definition
qu'en gros Kubernetes a une API
et on peut surcharger cet API
et ajouter des points dans cet API
j'ai envie de dire de manière assez facile
et donc ça fait que l'API est étendable
et elle a fini pour ce qu'on veut faire
et donc on peut faire des tonnes de choses
René je te laisse la parole
Non je voulais juste ajouter
c'est dans le préambule que t'as dit
voilà c'est que ça reste quand même
une solution libre donc les sources sont disponibles
on peut aller creuser, on peut voir comment c'est fait
donc ça c'est aussi un avantage majeur
une raison du succès
J'en voudrais deux choses
très rapidement sur la standardisation
ça a aussi standardisé sur les containers
les plugins cnc, cacx et autres
mais aussi la partie low-balancing
la partie gestion des logs, gestion des métriques
et placement sur les nœuds
la finity, anti-finity
utilisation du GPU
on peut faire des workloads GPU
très facilement
même la gestion des ressources
et comme tu disais Christophe, il faut vraiment voir ça
les CRD c'est quelque chose de très intéressant de Kubernetes
c'est vraiment son point fort
je dirais même si on prend en quoi l'après
peut-être aussi son point faible
c'est que c'est extensible à l'infini
et c'est une grosse boîte au outil en fait
on peut définir une ressource
et ensuite écrire un contrôleur qui va écouter
pour faire des actions
ça peut être des choses qui ne sont même pas des containers
je pourrais créer très bien une ressource
demain pour jurer je sais pas
ce que vous voulez
et derrière écrire un contrôleur
qui n'interagira même pas avec les nœuds
qui fera des choses complètement délirantes
et c'est ça qu'il faut avoir en tête
c'est que c'est vraiment pas que la partie container
que Kubernetes c'est vraiment l'écosystème autour
la partie CRD
et les intégrations, voilà on parlait de stockage
mais le l'obam bouncer avec
on crée un l'obam bouncer, on est sur un cloud ça on crée
ça utilise l'appli du cloud provider
pour le provisionner, pareil pour les volumes
pareil pour les certificats
pareil pour plein de choses
c'est vraiment ça aussi sa force
c'est standardisation mais aussi pour l'étendre
moi je voulais juste ajouter quelque chose aussi
c'est peut-être au-delà un petit peu de la technique
c'est aussi je pense que
un des avantages de cette standardisation
c'est que ça apporte un sop commun
entre les équipes de dev et les équipes d'ops
et donc du coup ça permet peut-être
des fois de mieux se comprendre
et de résoudre certaines difficultés
voilà
je suis pas certain
pour retravailler avec des dev
c'est encore moi qui me tape
l'intégralité des yamers
et le déploiement
parce qu'ils connaissent pas Kubernetes
ils connaissent pas OpenShift
selon moi
c'est quand même le travail d'un ops
de pouvoir décrire
l'infrastructure
des microservices
et comment est-ce qu'on les gère
après en effet on peut les confier à des dev
il n'y a pas de problème
mais pour moi ça devrait rester le travail
d'un ops qui travaille avec des dev
je pense que ça permet peut-être
c'est évident que c'est pas tout rose
et que c'est pas facile mais
au moins je pense que ça donne des éléments
de langage commun et des choses qui permettent
de mieux se comprendre à mon avis
là je suis d'accord avec toi
c'est en effet que comme
on va versionner
souvent la manière dont on va
faire l'infrastructure dans peut-être
les mêmes dépôts ou des dépôts frères
on va pouvoir parler avec les devs
et les ops vont vraiment partager
un langage commun en effet
et potentiellement
des méthodes communes parce que
les ops vont apprendre
à versionner la
partie DSL de l'infrastructure
pour déployer les conteneurs
ce qui ne faisait pas forcément
avant ils vont apprendre
à automatiser et surtout
c'est suivant les organisations
ça va être du partage
du partage de responsabilité
parce que si tout le monde peut éditer
le fichier Elm qui va déployer
l'infrastructure pour schématiser
on va partager la responsabilité
et le jour où ça va pas marcher
ce n'est pas la faute des devs
ce n'est pas la faute des ops, c'est la faute de l'équipe
il faut à falloir que l'équipe va
façon sorte que ça soit
à nouveau opérationnel
et trouve des solutions pour que ça ne se reproduise pas
et ainsi de suite
et pour moi c'est peut-être un des
meilleurs points positifs
c'est que ça va faire travailler toutes les équipes ensemble
et comme tu le dis Christophe
aujourd'hui c'est encore toi qui fais les fichiers
de description yamolle des
infrastructures mais c'est peut-être un bien
mais peut-être que les devs qui s'y intéressent
vont aller regarder ce que tu as fait pour monter
en compétence et peut-être que pour le projet
d'après ils vont s'inspirer de ce que tu as fait
pour la phase initiale du projet
et toi tu arriveras à la fin pour vérifier si tout est bon
et si c'est ok pour partir en prod
j'aimerais bien, j'aimerais bien
mais pour l'instant c'est pas encore le cas
on va pouvoir parler des inconvénients
parce que Kubernetes c'est pas un monde qui est tout rose
c'est un monde qui est
très très vaste et on a de quoi se perdre
dans un désert d'inconvénient
je dis un désert parce qu'en effet il y en a
beaucoup, c'est un désert de sable
chaque inconvénient s'implique un de sable
je vais vous laisser
en citer quelques uns
et puis moi j'en cite très d'autres probablement
à Nicolas Comos, je sens que
t'envie
en fait je pensais vous laisser
donner des inconvénients
parce que je pense que
je suis pas suffisamment
objectif
et je n'ai pas suffisamment d'expérience
dessus
pour casser un petit peu du Kubernetes
de manière objective
ce qu'on lui reproche souvent c'est que
ça
nous titré modulaire donc forcément
beaucoup de possibilités qui apportent
une certaine complexité
c'est un trinsecement
c'est quand même pas
si complexe, il n'y a pas des milliers de services
pour faire marcher Kubernetes mais il y en a
quelques-uns, il faut bien comprendre comment
il s'architecture
c'est pas magique c'est-à-dire qu'il faut
quand même des gens pour l'opérer
et le faire fonctionner
ça faut pas le négliger, c'est pas juste un truc qu'on installe
et ça marche bien
au début
alors je vais parler de mon expérience un petit peu
au début c'est vrai que la documentation
elle donnait pas trop envie parce que juste pour l'installer
il y avait 15 000 façons de faire
voilà c'était pas forcément
facile, la documentation au début
était aussi pas forcément génialissime
ça a beaucoup progressé pour le coup
voilà un petit peu
ce que je peux en dire
c'est pas un produit qui personnellement
m'a donné trop envie au début
et
par la force des choses aujourd'hui on est obligé
un petit peu d'y intéresser et de rentrer
dedans
mais c'est vrai que de prime abord
c'était pas forcément l'outil le plus engageant
encore une fois de mon point de vue
il y a un coup d'entrée
en effet il y a plein de composants
c'est un avantage parce qu'on peut les modifier
mais c'est aussi un inconvénient parce qu'il faut les gérer
et
installer ces composants c'est complexe
d'ailleurs je renverrai aussi vers
peut-être que tu pourrais mettre le lien Christophe vers le tool
que j'avais fait au compagnon du DevOps
sur les composants du cluster et sur la gestion du TLS
qui montrait également cette complexité
d'installation
qui n'était pas
c'est pas trivial mais c'est vrai qu'aujourd'hui
on a les offres cloud
qui y aident beaucoup mais forcément
c'est pas possible en prime
l'autre complexité pour moi
elle est réseau
déjà au niveau du contrôle plein
parce qu'il faut savoir que la PI server de Q1 et TIS
sont composants centrales par la beaucoup de monde
il va parler
déjà il y a des contrôleurs, le contrôleur manager
le scheduler, des choses comme ça qui vont parler à la PI server
la PI server va
même parler à Qubelet
dans le sens à PI server et Qubelet
il faut que le trafic soit ouvert
Qubelet doit être capable
je vais peut-être préciser, c'est Qubelet
ce qui tourne sur les noeuds Q1 et TIS
Qubelet doit également parler à la PI server
la PI server doit également
être en mesure de communiquer avec le réseau
interne du cluster
ce qui s'appelle l'aggregation layer
c'est-à-dire communiquer
avec des pods qui tournent dans le réseau privé
comme on parlait tout à l'heure de Cienaille
donc dans le réseau
dans l'overlay Q1 et TIS
ce qui amène utilisation de proxy
dans certains cas comme connectivity
il y a une très grosse complexité réseau pour moi
c'était d'ailleurs le plus gros point de douleur
pour appeler une autre Q1 et TIS manager
ça doit être pour moi la gestion du réseau
entre les composants du cluster
mais aussi entre les noeuds
ou quelqu'un qui n'a pas l'habitude
de gérer des réseaux VXLAN
c'est pas simple, alors bien sûr que Calico ou autre vont le faire pour vous
mais quand ça plante
c'est pas simple, c'est compliqué
c'est quand même des problématiques complexes
il faut garder ça en tête
c'est pas juste comme avant on avait notre réseau privé
sur le cloud
nos services systemd qui parlent entre eux
tout marche, là il y a des trucs dans tous les sens
il y a de l'IPTB, de l'encapsulation
tout ce que vous voulez, des bridges
sur les machines, enfin bref c'est complexe
quand ça bug c'est complexe
moi j'ai l'impression qu'il y a un peu 3 niveaux
il y a le niveau où on installe ça
et puis
qui arrive un petit peu out of the box
et voilà
mais après je pense qu'il y a vraiment 2 marches importantes
la première marche c'est vraiment faire les bonnes pratiques
pour le sécuriser
et là il y a déjà je pense beaucoup de boulot
et ensuite il y a une marche qu'on veut comme Mathieu
dans son entreprise de mettre
en production public utilisable
là je pense que le tourner vraiment
en proie de internet fixing et tout
là je pense que ça demande
une somme de connaissance qui est
colossale
c'est ce que j'allais dire en fait
pour l'avoir fait pratiquement seul
c'est
ultra dur d'apprendre Kubernetes
la courbe d'apprentissage est énorme
enfin moi j'avais l'impression
d'être devant les vrais
c'est à chaque fois que je regardais mes docs openshift
c'était pas Kubernetes mais c'était openshift
c'est pareil
je me voyais là et je me disais putain
mais ça va pas avancer
il y a chaque fois que j'installais des trucs
il y a encore ça à faire
il y a encore ça à faire
et encore quand on a réussi à installer Kubernetes
il faut le gérer
il faut gérer
les disques
parce que tous ces objets là dont on parle
ils génèrent des traces
des fichiers etc
et donc il faut purger ce genre de choses
il faut faire attention et ça c'est pas fourni par Kubernetes
il faut y aller
il faut gratter et il y a plein de trucs
comme dit Mathieu
en fait c'est la boîte de Pandore
on l'ouvre et ça y est
il y a tout qui sort
et on tire un bout et on se dit c'est la femme
mais non il y en a encore
pour moi c'est ça le gros problème
c'est Kubernetes c'est trop compliqué
il apporte plein d'avantage mais c'est trop compliqué
pourquoi est-ce qu'on peut pas faire plus simple
pour sans
alors ça
la question
oui
quand même la problématique auxquelle ça répond
est pas forcément simple
pour avoir vécu un petit peu
on parlait d'openstock
Nicolas est au open stack
le projet neutron d'open stack qui gère la partie réseau
c'est un truc de malin aussi
donc je pense que ça adresse des problématiques
vraiment
difficile
et voilà
ça engendre et en plus
de faire des plugins soit modulaire
pour s'adapter à beaucoup de monde
ça multiplie un petit peu
cette sensation-là
c'est exactement ça
exactement
pour moi Kubernetes
comme si t'as installé un cloud chez toi
sauf que tu te bases sur des conteneurs et autres
mais c'est aussi compliqué
que gérer
finalement un datation de turf-up
pas aussi compliqué mais le niveau de complexité
est quand même assez élevé
je trouve
René a dit quelque chose de très intéressant
c'est modulable, puis un tiss et ça veut s'adapter à tout le monde
et c'est pour ça que c'est complexe et c'est pareil pour open stack
c'est des solutions
où il faut que ça marche dans tous les contextes
cloud & primize avec tous les composants
réseau que vous voulez, tous les trucs de storage
de tout ce que vous imaginez
tous les protocoles réseaux
et au final
complexifient les choses
des fois des gens vont dire, on a écrit notre propre solution
pour remplacer Kubernetes c'est beaucoup plus simple
oui parce qu'ils avaient un besoin très précis
très limité
alors que là on est sur un outil qui va essayer de s'adapter à la masse
c'est à dire
à tous les besoins de tout le monde
et c'est ça qui va
complexifier énormément le code
et c'est pour ça qu'on se retrouve avec des projets avec
je sais pas combien de millions de lignes de code
etc etc parce que ça veut tout faire
pour tout le monde
d'ailleurs on peut aussi évoquer rapidement les alternatives
avec Kubernetes comme 4.3s
qui sont des réimplémentations un petit peu plus simples
et plus faciles à déployer
à maintenir
mais avec un spectre de fonctionnalité
beaucoup plus réduit
oui justement on pourra ajuster
les distributions après
j'aimerais qu'on finisse sur les inconvénients
et on passera juste aux distributions juste après
pour moi
comme il y a plein de trucs à gérer
évidemment il y a plein d'outils
qui viennent
dès qu'on a sorti Kubernetes
qu'on l'a installé pof on se pose des questions
c'est à nos images comment on va les déployer
donc je vais utiliser
un outil GitOps qui va me permettre
de déployer les images
comment je vais gérer mes upgrades
mes mises à jour
comment je vais récupérer mes métriques
comment je vais centraliser les logs
parce que chaque entity
qui tourne dans Kubernetes
a des logs mais elles sont pas tout agrégées
donc toutes ces questions
qui ne sont pas adressées par Kubernetes de base
il faut installer des outils
en plus dans notre agrégat Kubernetes
et donc pour moi ça apporte des complexités
en plus et à chaque fois je peste en me disant
mais pourquoi il n'y a pas
des packages
d'outils qu'on pourrait installer d'un coup
bon on a fini par en trouver quelques-uns mais
c'est dur quand même
quand on va sur les docs de Kubernetes
on n'est pas aidés là dessus
on est pas aidés
vas-y on est
moi ce que je voulais dire c'est que
ce que j'aime pas trop dans la solution
on l'a dit elle couvre beaucoup de choses
et j'ai toujours cette sensation
pour en avoir fait un petit peu quand même
je sais pas si ce que j'ai fait
est vraiment bien
je sais pas comment dire
c'est tellement poisonant et tellement de possibilités
qu'on se demande si ce qu'on a mis en place
c'est ce qu'il fallait faire
moi c'est ça qui me dérange un petit peu
moi de toute façon je recommande à des gens qui commencent avec Kubernetes
de rester sur des trucs simples
pas de CRD, utiliser des trucs standard
Diplomands, services, ingress
déjà utiliser ça
pas complétiser les clusters avec des trucs un peu bizarres
un peu louf
parce que c'est vrai que Christophe l'a dit
on peut trouver des boîtes à outils tout fait
à déployer et ça marche
mais c'est des gros bâtenoires
je prends l'exemple de certes managers
c'est le standard pour gérer les certificats
ça marche très bien, moi je l'utilise sur mon cluster
on l'utilise avec les sans-crypt, on l'utilise nous en interne
avec Vault
ça marche, mais par contre c'est un manifest
on va chercher le manifest, il fait
les 13000 lignes, je crois, diamèles, le quick start
un truc comme ça
on fait un cube cut à la play
c'est mieux gérer que ça
mais moi sur mon afra perso
je suis un cube cut à la play
et puis on va espérer que ça marche
et c'est vrai que beaucoup de grosses boîtes
à outils humanitises fonctionnent comme ça
on se retrouve avec 5000, 10000, 15000, 20000 lignes
de diamèles
personne en dehors du mainteneur de l'outil
va aller dedans, enfin il faut
on y va quand même, bien sûr, surtout quand on offre
du cubanitise à outils, ça servit
je veux dire la majorité des gens
doivent faire confiance
à celui qui fournit l'outil
mais le jour où il y a un problème
après qu'est ce qu'on fait ?
c'est un peu le problème de ces outils
de ces grosses boîtes noires
c'est le côté magique
effectivement
quand la magie opère c'est génial
quand ça n'y a rien à quoi que ça devienne vite
d'horreur pour débuguer
et du coup, comme il y a beaucoup d'outils
et que l'écosystème est énorme
ça évolue aussi très vite, il y a des projets
qui pop, qui sont abandonnés
petit à petit et
c'est dur à suivre
et je trouve que ça demande quand même beaucoup
de travail pour ce écosystème
donc si on peut mutualiser
ce truc là, c'est quand même pas mal
dans une boîte ou à plusieurs boîtes
parce que sinon on s'y cite
super vite
et le gros point noir
le truc que cubanitise n'arrive pas vraiment à gérer
que les conteneurs
de base n'arrivent pas vraiment à gérer
c'est ce qu'on appelle les applications stateful
les applications à état
en gros les applications qui gèrent de la donnée
un exemple tout bête
une base de données, c'est une application
qui gère de la donnée
et ben, ce genre de choses
c'est difficile
il y en a qui le font pas, il y en a qui le font
mais c'est difficile à mettre dans un orchestrateur
parce que cubanitise n'est pas vraiment pensé pour ça
est-ce que vous êtes d'accord avec ça ?
alors c'est moi qui ai mis le point
donc je vais...
à la base c'est quand même vraiment fait pour faire du
stateless
des applications sans état
des serverable etc
donc là ça marche plutôt bien
effectivement le stateful
jusqu'à rien encore pas très longtemps
je pense que les gens mettent toute leur base de données
par exemple quand ils utilisent du cloud
ils utilisent le service de database
managé parce qu'ils avaient pas forcément confiance
de mettre ça dans cubanitise
un peu compliqué
maintenant quand même les choses ont beaucoup évolué
les stateful set amènent des solutions
pour gérer les applications stateful
il y a les opérateurs aussi qui arrivent
donc je pense qu'aujourd'hui c'est quand même
plus
mature, je pense qu'il y a moyen de faire tourner
les choses intéressantes
pour du stockage par exemple il y a des outils
qui peuvent être d'utiliser SF, genre ROOC etc
donc il y a quand même vraiment
ça a bien bougé
donc je pense qu'aujourd'hui ça devient crédible
mais encore une fois ça devient
au prix d'une certaine complexité
je vais t'empérer un petit peu là-dessus
c'est pas parce qu'on peut déployer des applications
stateful donc cubanitise maintenant
que c'est une bonne idée parce que
on va quand même rappeler
que toute l'histoire des conteneurs c'est
aussi pour apporter de la haute disponibilité
une application stateful
c'est le meilleur moyen pour votre application
ne tombe pas en un moment donné
et si vous voulez creuser un petit peu
au-delà du stateful stateless
c'est les 12 factors
c'est les 12 facteurs
pour que votre application
reste bien
en haute disponibilité
j'en parle très souvent
je t'aime assez souvent mais regardez ça
avant de commencer votre projet
parce que c'est la seule garantie
pour que votre application tourne bien
quelle que soit les conditions
c'est pas parce que vous utiliserez les 12 facteurs
que votre application sera à haute disponibilité
mais ça sera plus facile de la mettre
dans un contexte entre
des mecs cloud ready
c'est
le fait que votre session
soit pas stockée au niveau du serveur
d'application vous allez pouvoir
mettre deux serveurs d'application avec un load balanceur
devant et le load balanceur
il peut être très bête en voyant un coup à gauche
un coup à droite ça va pas marcher
vos fichiers sont pas stockés en local
donc si jamais
l'hyperviseur sur lequel tourne
votre service cram c'est pas grave
on le redémarre ailleurs
si l'endroit où est stocké
le fichier cram
c'est pas grave parce que vous avez
de la réplication qui est mise en place
quand je dis stocké
c'est de l'object storage
parce que comme ça vous serez sûr que
vous allez pouvoir étendre à l'infini
et que ça peut cramer
mais la question
c'est l'object storage est-ce que tu le mets
dans Kubernetes ou pas
parce que la promesse de vraiment savoir faire du stateful
c'est par exemple ça
je propose qu'on ne réponde pas à cette question
et qu'on passe aux distributions de Kubernetes
je vois le temps qui file
du coup Kubernetes
comme on a dit c'est
quelque chose d'assez intéressant
mais il manque pas mal de choses
et il y a des gens qui se sont mis à sortir
ce qu'on appelle des distributions comme Linux
donc des Kubernetes un peu sous-stéroïdes
je vais commencer par parler d'openshift
parce que comme vous l'aurez compris moi je viens d'openshift
avant d'être arrivé sur Kubernetes
et donc OpenShift c'est
une version Kubernetes
fait par Redat
il faut savoir qu'à l'origine OpenShift
ça ne se basait pas sur Kubernetes
et pour la version 3
d'OpenShift Redat a fait
un shift complet et ils sont passés sur Kubernetes
et c'est pour ça que Redat est l'un des plus gros
contributeurs
à justement Kubernetes
et OpenShift c'est
en gros Kubernetes pour les
développeurs c'est ce qui promettent
ils nous promettent un pseudo pass
en gros
OpenShift arrive avec plein de trucs
en plus sur Kubernetes
comme une sécurité accrue
on peut pas faire tourner par exemple de conteneurs
en mode route ça c'est pas possible
les
dans Kubernetes il y a ce qu'on appelle les namespace
donc des endroits où on va mettre nos conteneurs et autres
dans OpenShift c'est ce qu'on appelle
des projets qui sont encore plus isolés
je sais pas comment ils ont fait ça mais
en tout cas c'est ce qu'ils promettent
et surtout on a des objets supplémentaires
comme les objets réseaux pour gérer
les URL et autres
assez facilement
en tout cas avec Kubernetes je trouve
et l'un des trucs
qui est pour moi
le top chez OpenShift
c'est la
gestion des builds de conteneurs
puisque OpenShift peut s'occuper pour nous
de builder les conteneurs et de les héberger
directement dans l'agrégat
et donc de ne pas aller appeler un
registre de conteneurs externes
donc voilà pour OpenShift
je pense que vous en serez beaucoup
il faut savoir que la version libre d'OpenShift s'appelle OKD
et je vous mets le lien en description
et on a d'autres distributions
qui veulent nous parler des autres distributions
moi je peux en parler de manière un peu générale
je pense que la distribution ce qu'elle apporte
c'est on a vu qu'il y a un écosystème
super large
je pense que l'idée de la distribution
c'est de faire confiance à des gens qui ont choisi
quelque chose, une solution cohérente
en prenant les modules qui sont les plus adaptés
et qui du coup nous réduisent un petit peu
le choix et la complexité
et nous permettent d'installer
Kubernetes de manière plus simple
notamment, cette de Rancher
c'est vrai que c'est
une chouette distribution
mise à disposition
qui permet de
de démarrer avec je pense
des choix et des configurations
qui sont plus appropriées
que ce qu'on pourrait faire
par soi-même
au départ en FromStratu
Nicolas, tu veux apporter une précision sur Rancher ?
oui
moi j'ai testé
mes premières préinstallations
que Kubernetes ont été faites via Rancher
et j'ai trouvé que c'était très intéressant
comme produit quand vous voulez
pouvoir déployer du Rancher assez facilement
parce que c'est multi provider
on peut déployer
sur la AWS, du GKE et ainsi de suite
on peut le déployer
sur du Onpreymise a priori
et c'est vraiment
tout manager, c'est vraiment super bien foutu
donc si vous voulez
déployer des clusters de dev
et que vous ne voulez pas trop vous embêter
avec la gestion
d'un cluster, regardez
Rancher, c'est vraiment super intéressant
et ce qui est assez marrant
c'est que c'était un des acteurs
de l'orchestration de conteneurs
avant que Kubernetes arrive
et qu'ils ont très rapidement pris le virage
et finalement
c'est même assez marrant
parce que c'est eux qui ont développé
la solution 4.es
dont la Nouveau va peut-être nous parler maintenant
je précise juste sur Rancher
Rancher est une solution aussi
qui permet de déployer
plusieurs agrégats, c'est à dire un agrégat Rancher
vous permet de déployer
d'autres agrégats
donc vous pouvez superviser toute votre infrastructure
de Kubernetes
avec Rancher
et donc faire des clics pour déployer votre Rancher
et je peux parler un peu de 4.es peut-être
donc
c'est fait par Rancher en effet
et son intérêt c'est que
ça se présente comme un simple binaire
qui paquette l'ensemble des composants de Kubernetes
donc facile à déployer
beaucoup plus facile que le Kubernetes
initial on va dire
et une autre chose intéressante
c'est qu'on n'a pas mentionné mais Kubernetes utilise
ETCD pour son stockage
donc qui est une base de données
clé-valeur
distribuée, on peut la déployer sur plusieurs nœuds
etc etc
et Rancher
permet d'utiliser des bases de données SQL
par exemple SQLite, Postgre
MariaDB
et c'est quelque chose qu'on verra de plus en plus
je pense dans mon Kubernetes
c'est à dire remplacer le TCD
par d'autres composants plus simple à gérer
ou plus calable ou des choses comme ça
c'est des choses qu'on commence à voir
et là Rancher en fait
4.es désolé
le fait de façon très intéressante parce que
juste un binaire et une base SQLite
embarquée permet de démarrer avec Kubernetes
qui est très bien pour tester mais ça peut être
aussi être utile pour d'autres usquets
pour éviter d'avoir à gérer de le TCD
on peut parler justement des objets connectés
ou
des petits serveurs ARM par exemple
je vois que ça a tourné sur ARM
il y a plein d'autres cas justement
pour des petites machines
ou pour l'embarquer qui ça pourrait être assez efficace
je pense
ça pour moi ça a été fait vraiment en visée
de l'embarquer en fait
je vous propose qu'on passe
aux autres conteneurs, aux autres orchestrateurs
on est déjà à l'heure
et je sens que
cette émission va durer longtemps
donc est-ce qu'on pourrait parler
des autres orchestrateurs et notamment
d'un qui fait beaucoup parler de lui
qui est Nomad
là ça va plus être ma partie
parce que du coup j'en opère
très régulièrement
quasiment au quotidien
j'en mange au petit déjeuner
donc quand je crois que c'est Mathieu
qui disait que
Kubernetes était sorti assez rapidement
donc j'ai regardé c'est sorti le 7
juin 2015
et le premier
comite de Nomad
c'était le 1er juin 2015
alors ils ont bien joué pour
faire un petit comite avant mais en réalité il n'y a pas rien dedans
donc c'est sorti
le 28 septembre 2015
et la petite
particularité par rapport à Kubernetes
c'est que Nomad
va s'occuper juste de la partie
orchestration
et il peut
orchestrer plusieurs types de Workload
donc là ce soir on parle principalement
de conteneurs mais il s'est aussi
lancé des binaires, des VM et ainsi de suite
et l'autre
particularité de Nomad
c'est que comme tous les outils d'Ashikorp
il va se concentrer
sur une petite partie
qui est juste l'orchestration du Workload
donc le binaire Nomad
sert à la fois en client
en serveur et ainsi de suite
comme tous les outils d'Ashikorp
ça permet de monter progressivement en gamme
donc on peut installer
le serveur Nomad
sur un serveur, sur un poste de développement
même on peut avoir
un environnement de développement Nomad
sur sa machine
et on peut monter en gamme très progressivement
et là
où dans Kubernetes
quand on tire la plot
on se retrouve à installer énormément de trucs
on peut faire la même chose avec toute la stack
Ashikorp
parce que pour moi
quand on parle de Nomad on ne peut pas utiliser le Nomad tout seul
il faut au minimum mettre Consul
par exemple
vous allez utiliser Consul et Nomad en même temps
et en fait
vous allez monter progressivement en gamme
sur les fonctionnalités
donc vous allez l'installer tout seul
après vous allez l'installer en cluster
et après vous allez mettre
de la discovery automatique
après vous allez vouloir mettre du TLS
après vous allez mettre des ACL
et en fait vous allez monter progressivement
dans
la complexité
en fonction des besoins de votre projet
et je trouve que ça
correspond bien aussi à la philosophie
Lean Startup
où finalement on commence avec des trucs très très simple
mais ça fonctionne
on a un MVP qui est vendable
et en fonction
du projet qui va grandir
de la société qui va grandir
on va pouvoir monter en gamme progressivement
en fonction des besoins
de l'entreprise
de l'infrastructure
Mathieu tu connais un petit peu
le Nomad en cas d'enquêteur
En tant qu'enquêteur
j'ai vu déjà des taux
qui sont à propos de Nomad
j'ai un peu regardé la doc etc mais j'ai pas vraiment eu l'occasion
de le tester personnellement mais j'ai beaucoup travaillé
avec Consul et Vault
donc c'est des briques que je connais assez bien
mais
moi j'ai toujours aimé les outils
à Chikorps qui sont généralement bien pensés
qui se composent en effet entre eux
qui s'intègrent entre eux
et nous d'ailleurs on utilise Kubernetes
mais on utilise aussi beaucoup Consul et Vault
parce que ça s'intègre très bien
avec Kubernetes
notamment Consul
qu'on utilise pour toute la partie DNS
donc je sais pas qu'on tape quelque chose qui est en dehors
de Kubernetes en fait
on résolve dans Consul
l'adresse
mais Nomad en lui-même
non je connais pas trop
donc c'est vrai que je peux pas trop en parler
mais j'aimerais bien qu'il y ait des confiants
en Kubernetes parce que je crois que
je sais plus qui l'a dit tout à l'heure mais c'est vrai que Kubernetes
a quand même axifixé
l'écosystème, conteneur
DevOps etc
et c'est un peu dommage
c'est bien de voir des alternatives
moi j'ai jamais utilisé Nomad
c'est aussi un truc qui m'interresserait
mais pour l'instant j'ai jamais eu le temps
de m'y procher dessus
et j'ai pas encore eu de cas d'usage
a priori sur Nomad
est-ce qu'on a d'autres alternatives
finalement
parce que Nomad c'est
le challenger mais est-ce qu'il y a d'autres alternatives ?
il y avait
pour avoir un petit peu
vu ça au début
donc la solution Docker qui s'appelait Swarm
qui au début était un produit
à part
puis finalement Docker
avait intégré
son
server client
et
à l'époque
il en a peut-être sorti un peu vite
en 2015
du coup
la solution manquait de maturité
et ça a peut-être déçu des gens
une des forces c'est peut-être un peu comme Nomad
c'est que c'était plus contraint
c'est à dire chercher à gérer moins de choses
que Kubernetes
en s'occupant
plus de la partie
comme l'a dit Nicolas
plus de la partie orchestration
par contre la force à l'époque
c'est que l'installation
c'était de ligne de commence
c'est à dire un init sur le master
et un init pour les
noeuforkers
et en fait
toute la mise en place
du TLS
entre les nodes
de la base
de données partagées
où quels valeurs partagées se faisaient
en fait
toutes ces intelligences-là étaient
complètement masquées
moi c'est ce qui me plaisait beaucoup
ils avaient un peu la philosophie
d'apporter ce que Docker a apporté pour les conteneurs
les rendre un petit peu
utilisables par tout le monde
ou du moins par le commandement mortel
ils ont essayé de faire un peu la même chose
sur l'orchestrateur
malheureusement
voilà
les gens ont pas forcément adhéré
il y a eu
peut-être cette sortie un peu active
avec un Kubernetes en face
qui était jugé plus mature
pour la production
et voilà c'est
malheureusement la solution a moins
percé
à moins moins succès
et c'est vraiment dommage
parce que tu veux dire
vas-y Christophe
en fait
pour moi ce qui m'avait vraiment marqué
et que j'ai trouvé super intéressant
dans Docker Swarm
c'est qu'on avait le Docker Compose
qui était le petit orchestrateur du pauvre
mais qui fonctionnait
pour démarrer un environnement
fonctionnel sur le poste du développeur
et éventuellement sur des petits serveurs de prods
mais ce qui était vraiment intéressant avec Swarm
c'est que les fichiers de configuration
étaient plutôt compatibles avec le Docker Compose
donc quand on se débrouillait bien
on pouvait avoir le Docker Compose
sur le poste du développeur
le Docker Compose qui instanciait
tout ce qu'il fallait sur la partie Swarm
pour le serveur de l'intégration
le serveur de staging etc
et avec des fichiers Compose
qui permettaient de compléter
les autres fichiers
et finalement on pouvait empiler
les fonctionnalités pour rajouter
de la sécurité, changer des mots de passe
des choses comme ça
et j'ai trouvé que c'était très intéressant
pour le cycle de vie global
des conteneurs
et je retrouve un petit peu moins ça
dans les autres solutions
Ouais c'était je pense
un peu mieux intégré
avec l'existent qui avait chez Docker
donc du coup ça limitait peut-être
le nouvel apprentissage
par rapport au YAMLFY
à prendre pour Kubernetes
un des autres aspects qui était intéressant au début
c'est qu'il y avait la gestion quand même
peut-être assez basique
mais on pouvait quand même s'égréguer
des conteneurs entre guillemets
des différents silos
ce qui au début
n'était pas forcément le cas
trop sur combien d'intesses
du moins
sans rajouter
le nombre de plugins etc
Est-ce que Swarm justement c'était pas aussi
intrinsèquement lié à Docker et le fait
qu'à un moment donné
il y a eu la guerre des conteneurs
Docker était un peu challenge
est-ce que ça n'a pas donné un coup à Swarm
parce que je pense qu'il ne peut pas s'intégrer
avec d'autres gestionnaires de conteneurs
alors à l'époque
assez vieux
à l'époque globalement quand même les conteneurs
c'était
je vais dire peut-être un bêtise mais il y avait
beaucoup d'au-ceur
oui je pense qu'ils ont développé
quelque chose pour leurs solutions
à eux ils n'ont pas forcément
enfin c'était un petit peu
voilà et c'est vrai qu'à ce moment-là ils étaient critiqués
justement en disant que c'était un peu tout lié
et d'où les
l'initiative de séparer en différents projets
etc
oui c'était peut-être
une des facettes
peut-être un peu négatives
Puisqu'on est finalement dans le cimetière des orchestrateurs
on va appeler cette partie-là comme ça
est-ce que quelqu'un a essayé mesos
et est-ce que c'est encore vivant
je l'ai utilisé en 2015
quand j'étais en stage de fin d'études
j'ai utilisé mesos et marathon
mesos c'est un gistnière de ressources
il n'y a aucun rapport avec les conteneurs pour mesos pur
c'était la grande mode du big data
quand mesos s'est apparu
c'est s'agir des ressources dont s'agir
de la cpu et le RAM
la RAM d'un cluster en gros
d'un cluster de machines et ensuite il y a des frameworks
qui se mettent au dessus pour allouer des ressources
donc il y avait des gens qui faisaient tourner du storm
du spark
un peu lié au big data là dessus
et il y a des gens qui avons sorti notamment marathon
qui étaient à fraymoire pour faire tourner
des conteneurs à mespaque
on pouvait également lancer que des procès
un peu comme dans nomade
sur mesos
ça date c'était en 2015
j'étais stagiaire donc j'avais pas l'expérience
je trouvais ça magique à l'époque
mais bon j'avais pas de recul
pour moi c'était la révolution
j'y croyais à mort
mais finalement c'est mort
récemment je crois que mesos
encore ont un truc qui sont plus même plus
dans la fondation à page je crois
enfin bref
c'est plus utilisé aujourd'hui
malheureusement peut-être
en fait docker storm
c'est encore un peu vivant
parce qu'il y a docker enterprise
donc c'est pas complètement mort
il y a encore des gros clients qui l'utilisent
notamment français
moi j'ai aussi un petit peu joué en 2015
aussi par là
et c'est vrai que c'est ambitieux
et effectivement
c'est pas que du container
je pense que ça allait encore plus loin
mais bon bah ça pas pareil
je pense que
Kubernetes y a eu un tel effort
aussi côté marketing
ces autres solutions là
elles ont été un peu eclipse
et c'est dommage
finalement est-ce qu'on a besoin d'autres solutions
parce que entre Kubernetes
et ses distributions on l'a vu
4S qui simplifie pas mal les choses
et nomades
est-ce qu'on a besoin encore de plein d'autres solutions
je me pose la question
où est-ce qu'on va avoir émergé d'autres trucs
ça c'est...
on y réfléchira peut-être
une autre fois
et je pense qu'il est temps de clôturer cette émission
déjà très très longue
et avant de
vous laisser le mot de la fin
je vais rappeler à nos chers auditeurs et auditrices
qu'ils peuvent nous rejoindre et discuter avec nous
sur la communauté des compagnons du DevOps
qui est un forum où on discute beaucoup
de Kubernetes
quand même, aux ordres de dire
parce qu'il y a une section dédiée à Kubernetes
où il y a plein de questions dedans
donc rejoignez-nous et venez discuter avec nous
ça nous fera plaisir, vous ferez partie des compagnons
si vous ne l'êtes pas déjà
et je vais vous laisser le mot de la fin
et je vais commencer par Mathieu
quel est ton mot de la fin
moi même si j'ai envie de croire à nomades
j'ai quand même l'impression que
Kubernetes est en train de gagner et en train de devenir
un standard sur lequel les gens
vont construire
je pense qu'on va avoir des offres de plus en plus évolués
des abstractions au-dessus de Kubernetes
où vous aurez de moins en moins de choses
à gérer
mais bon
pour moi j'aimerais quand même voir
des alternatives donc on verra
mais j'ai l'impression quand même qu'on se dirige vers ça
pour toutes les raisons qu'on a dit
et que plus le temps passera
plus on aura des abstractions au-dessus de Kubernetes
ou au-dessus des nœuds
mais ça
on peut pas le dire en avant
mes os à l'époque je m'en rappelle tout le monde disait que ça serait l'avenir
c'était utilisé par Twitter
notamment
et finalement c'est mort
tout le monde disait ça
au bon sac disait
qu'est-ce que ça a pris 8 ou non
parce qu'il n'y a pas de temps de CloudProvider
qu'il utilise donc on peut pas prédire l'avenir
mais je pense que ce qui est important quand même de revenir
c'est les concepts de Kubernetes
API déclarative
plus boucle de réconciliation pour faire converger
l'état du monde
ça c'est une façon
une bonne façon de faire de la phrase structure
avec l'appi-eye bien sûr pour interagir avec le système
ce concept là est important
on le retrouve à plein d'endroits aujourd'hui
et c'est ça qu'il faut garder en tête je pense
c'est vraiment ce concept de
déclaration de détail et de réconciliation
et bah sacré mot de la fin dis donc
René est-ce que tu es un mot de la fin
à nous partager
oui bah après
ce qu'on peut dire c'est que
on l'a vu
il y a une grosse hype
sur Kubernetes
les gens qui sont précipités là-dessus
donc du coup sur ce sujet là
je pense que
j'ai un peu l'impression que la messe est dite mais
comme Mathieu j'espère
qu'il y aura quand même d'autres alternatives
on n'est pas à la bricre
quelqu'un sur un truc génialisime
dans quelques temps
voilà après
je pense qu'il faut malgré tout
regarder parfois
sur d'autres sujets mais voilà les alternatives
et pas toujours suivre
le standard de facto
il y a des bonnes idées à prendre aussi sur d'autres
d'autres solutions
et voilà c'est ce qu'est ce que je vais dire
c'est ce que je vais dire
et bah Nicolas je te laisse clôturer
royalement cet épisode
je vais apporter
une petite note optimiste
moi j'aime bien la diversité
j'ai toujours été le mouton noir
qui utilisait des technos
un petit peu émergentes
où on jetait des cailloux aux gens
donc j'ai fait partie des premiers utilisateurs
de Linux et maintenant
regarder ce que ça donne
j'ai fait partie des premiers utilisateurs
à faire du rubis en France
regarder un petit peu
ce qui se fait sur
c'est Doptissimo qui est en train d'exposer un petit peu
en ce moment en faisant du rubis on raise
donc
si vous
merci
donc si vous êtes obligés de faire du kubernetes
je suis vraiment désolé pour vous
mais sinon regardez Nomad c'est une excellente alternative
et vous verrez ça va égayer vos journées
et bah merci
et à bientôt
merci à vous
merci