‫Alors, quelle est la prochaine pour Kubernetes?
‫C'est une question qui préoccupe beaucoup d'entre nous
‫lorsque nous examinons la rapidité avec laquelle elle a grandi et l'ensemble
‫de l'écosystème qui l'entoure, et que c'est trop difficile à
‫gérer pour une seule personne.
‫Quel est l'avenir?
‫Eh bien, la bonne nouvelle est que si je devais
‫le prédire, je pense que l’avenir est qu’il doit
‫commencer à devenir ennuyeux. Vous entendrez beaucoup de fondateurs en parler
‫à chaque fois que vous les verrez en public.
‫Vous savez, ils vont juste parler de la nécessité de
‫rendre l'infrastructure aussi ennuyeuse que possible afin que nous
‫puissions compter davantage sur ce que nous faisons
‫en plus de cela. Parce que vraiment, tout cela est là pour que
‫nous puissions diffuser nos applications, correctement.
‫Le but de Kubernetes n'est pas d'être Kubernetes lui-même.
‫C'est pour vous permettre de faire les choses que vous voulez faire plus rapidement.
‫Je pense que pour
‫Kubernetes, si vous avez regardé les
‫dernières versions, cela a vraiment commencé
‫à mettre l’accent sur la fiabilité, la
‫stabilité, la sécurité.
‫Tu n'as pas à t'inquiéter autant.
‫Vous n'avez pas à le réparer autant.
‫Ils ont des versions régulières, vous devez
‫donc absolument consulter le calendrier des versions, ainsi que les notes
‫de publication, auxquelles je suis lié dans cette vidéo.
‫Une chose qui s’est produite cette année, en 2019, a été une grande
‫vérification de la sécurité d’une grande partie du code
‫principal qui a révélé beaucoup de choses.
‫En fait, ils ont sur leur blog une analyse complète et détaillée
‫de ce qui s’est passé.
‫Je pense que c’est vraiment bien qu’un projet open
‫source aussi important et aussi volumineux ait non seulement réalisé l’analyse
‫de la sécurité par une tierce partie, mais également révélé tous les problèmes
‫et résultats potentiels.
‫Je pense que cela a eu pour résultat un grand nombre de relations publiques
‫qui visaient dès le départ à apporter des solutions rapides, mais aussi certaines
‫choses qu’elles régleraient éventuellement avec le temps.
‫Ce n’est pas tellement qu’il était nécessairement basé sur la vulnérabilité, mais une
‫plus grande partie de ce domaine pourrait être améliorée et nous allons
‫le changer au fil du temps.
‫Une autre chose que vous verrez est que certains de ces concepts plus
‫anciens, du fait qu’il s’agissait d’un outil plus simple, commenceront à s’effacer au fur
‫et à mesure de leur élimination. Je pense que les plug-in de
‫stockage qui ne sont pas CSI finiront par être retirés, de sorte que
‫vous devrez compter sur CSI pour vos plug-in de stockage plutôt
‫que pour les éléments intégrés.
‫Vous verrez différentes commandes telles que kubectl run change et
‫cesser de nous donner des avertissements, car il s'agira par
‫défaut d'un simple gestionnaire de pod au lieu de disposer de
‫tous les générateurs intégrés.
‫Ensuite, vous verrez d'autres choses que j'ai
‫mentionnées ici, comme le test de service, la stabilité
‫et d'autres fonctionnalités. Parce que je pense qu'il y a
‫une forte pression pour une meilleure vérification, une meilleure compréhension du
‫changement au fil du temps. Qu'est-ce qui va changer avant de
‫le faire, qu'est-ce qui a changé après, et ce
‫genre de métrique de rapport.
‫En ce qui concerne les tierces parties, elles vont continuer
‫à augmenter et à croître, et c'est vraiment plus que tout le
‫monde pourrait le savoir.
‫Helm 3. 0 est sur le point d'être fini.
‫Nous aurons certainement plus d'opérateurs qui utiliseront des outils
‫tiers pour faciliter leur déploiement et leur
‫gestion dans Kubernetes.
‫C'est vraiment plus un espoir, mais je pense que
‫nous allons nous concentrer davantage sur les flux
‫de travail déclaratifs.
‫Parce que ce nouveau thème autour de DevOps, et plus spécifiquement de git-op,
‫ce sont des git
‫ops, dont j'ai parlé dans mon podcast.
‫Le workflow git-ops est un concept relativement nouveau, mais l’idée selon
‫laquelle nous, les opérateurs, et
‫c’est les personnes qui gèrent ces
‫clusters Kubernetes, agissons réellement en tant qu’opérateurs.
‫Les opérateurs profitent des avancées des équipes logicielles où
‫ils ont dû gérer le code, et
‫les modifications de code au fil du temps, et les versions,
‫qui ont donné naissance à des outils tels que GitHub,
‫à droite, pour utiliser ces mêmes outils de gestion de notre infrastructure dans
‫d'une manière déclarative. Vous m'avez entendu parler de ça.
‫Je pense que lorsque vous examinez l'ensemble de fonctionnalités
‫au fil du temps de Kubernetes, vous pouvez voir
‫comment le style devient plus déclaratif, et l'ensemble de fonctionnalités et l'accent est mis
‫sur ce flux de travail déclaratif.
‫J'espère que nous aurons un meilleur outillage et que ceux dont
‫nous disposons auront plus de fonctionnalités avec le temps.
‫Une autre grande chose ici est le support de Windows Server.
‫L'année 2019 a été marquée par l'annonce de
‫la prise en charge par Windows Server du serveur
‫2019, qui n'en est qu'à ses débuts.
‫Swarm est techniquement plus avancé que
‫Kubernetes.
‫Docker et Swarm bénéficient de la prise en charge de Windows Server par Windows Server
‫depuis des années, et cette technologie s’est définitivement améliorée avec le temps.
‫Mais ils ont commencé cela avec Server 2016 et l'ont poussé
‫vers l'avant pour l'améliorer.
‫Tandis que Kubernetes dans Windows Server 2019
‫vient tout juste de dire qu’ils ont un support.
‫Parmi les personnes que j'ai entendues parler
‫de Server en production, Windows Server pourrait encore utiliser beaucoup
‫plus de travail dans le monde de Kubernetes pour être
‫égal à Linux. Je pense donc que
‫ce sera un sujet de préoccupation majeur à mesure que de plus en
‫plus d'entreprises Windows adopteront ces orchestrateurs de conteneurs.
‫Un dernier point concerne les dossiers
‫Edge.
‫Des choses comme l'apprentissage automatique.
‫Des choses comme Edge et la petite infrastructure vont toutes
‫être ciblées car au début de Kubernetes, c’était très volumineux
‫et très encombrant,
‫mais elles en retirent une
‫grande partie et facilitent leur déploiement.
‫C'est pourquoi des outils tels que kubeadm apparaissent et permettent de déployer
‫des grappes haute disponibilité.
‫Il est entièrement sécurisé et prêt à l'emploi, s'il
‫est tolérant aux pannes. Ce sont toutes des choses qui sont
‫en train de se concrétiser maintenant.
‫Une partie de cet avenir consiste à connaître d’autres projets
‫connexes. Ceci est
‫juste une liste rapide des choses que vous ne
‫voudrez peut-être pas vérifier dans ce cours. Parce que Kubernetes lui-même est
‫devenu la plate-forme sur laquelle tout commence
‫à être construit. En fait, c’était vraiment
‫les objectifs initiaux des auteurs du projet.
‫Ils n’avaient jamais vraiment voulu utiliser Kubernetes directement
‫en termes de Kubernetes brut et
‫open source.
‫Ils voulaient vraiment que les autres construisent des abstractions pour que
‫nous puissions gérer notre charge de travail.
‫C'est pourquoi vous voyez des distributions sortir,
‫dans beaucoup de cas, parce qu'elles construisent une autre couche pour
‫le faire. Dans ce cas, nous
‫voyons toutes sortes d’infrastructures se développer pour faire autre
‫chose. La première place est Knative.
‫C’est autour des listes de serveurs, et
‫c’est vraiment un projet officiel de la CNCF, donc c’est étroitement lié
‫au monde Kubernetes.
‫Si vous êtes intéressé par les listes de serveurs, c'est certainement
‫l'un des projets que vous souhaitez vérifier.
‫Ensuite, quelques projets de Rancher sont K3
‫et K3os.
‫K3s est essentiellement
‫leur équipe qui prend en charge le déploiement et la gestion
‫complexes de Kubernetes et les simplifie, éliminant ainsi
‫tout ce qui est inutile qui va avec.
‫Peut-être certaines des commandes et du code hérités.
‫Peut-être que certains des pilotes de stockage dont vous n’avez plus besoin
‫si vous avez CSI.
‫Ce genre de choses. Ils se contentent de tout extraire
‫et vous fournissent une base de données vraiment facile.
‫Il n'utilise même pas etcd prêt à l'emploi.
‫Il utilise une base de données plus simple.
‫C'est vraiment fait pour des choses à l'origine comme l'IdO.
‫Mais maintenant, avec leur objectif de rendre Kubernetes aussi simple
‫que Swarm, ce que Darren Shepherd, leur
‫CTO et cofondateur, a déclaré à DockerCon
‫cette année. C'était une déclaration assez intéressante.
‫Il disait vraiment que, vous savez, Swarm réussit
‫si bien dans le déploiement, la facilité d'utilisation et
‫l'impact minimal. C'est un très petit binaire.
‫Il y a très peu
‫de frais généraux d’infrastructure. Kubernetes est
‫l'opposé total de cela. Ils essaient de trouver le juste milieu.
‫Est-il possible si nous en retirons suffisamment et que nous
‫en faisons toujours de véritables Kubernetes, pouvons-nous le rendre très facile à
‫déployer sur de petits systèmes comme ARM,
‫Raspberry Pis, etc. Donc, c'est un projet à regarder.
‫K3os est un système d'exploitation sur lequel
‫se trouvent des K3.
‫C'est une installation très minimale de Linux
‫conçue pour exécuter des K3 sur de
‫petites appliances. C'est un joli nouveau mais
‫un projet intéressant néanmoins. Un autre grand domaine
‫d’intervention, que vous entendrez beaucoup plus parler de mon
‫podcast, est le service mesh, qui est un nouveau concept des
‫dernières années et un nouveau terme.
‫Nous n'avons pas vraiment utilisé ce mot dans l'industrie auparavant.
‫Le maillage de
‫service est l'idée de cette couche proxy dans l'ensemble
‫du cluster, non seulement pour les connexions entrantes provenant d'Internet, mais
‫également pour toutes les parties de votre application.
‫Cela devient un moyen de contrôler, en termes de sécurité,
‫de surveillance et de routage vers les emplacements
‫appropriés, tout le trafic de
‫toutes les parties de votre application distribuée.
‫C'est une série de projets issus du
‫problème des microservices. Si vous
‫avez déjà effectué des microservices, l’un des véritables défis est que ce
‫qui était dans un seul binaire sur un seul serveur
‫et relativement facile à dépanner devient des dizaines de
‫conteneurs, sur des dizaines de serveurs.
‫Cela devient très difficile à résoudre à moins d’avoir
‫d'excellents outils de réseautage.
‫Ainsi, le maillage de service est
‫orienté vers ce problème et tente de devenir une
‫norme, avec des normes derrière, afin
‫de mettre en place une couche pour améliorer la visibilité, la
‫surveillance, le dépannage et la sécurité autour de nos applications distribuées et
‫de nos microservices.