Retour sur la KubeCon/CloudNativeCon Europe 2019

Du 21 au 24 mai, avait lieu à Barcelone l’édition 2019 de la KubeCon/CloudNativeCon Europe. Zenika y était représenté par 7 consultants venus de différentes agences. L’occasion d’apprendre et d’échanger avec la grande communauté autour de Kubernetes.
Chaque édition est chargée en keynotes, conférences et confériencier.e.s. Presque 400 présentations données par 200 speakers sur plus de 20 tracks en parallèle ! Pas facile de choisir !
En plus de la conférence, beaucoup d’évènements gravitent autour comme différents summits dédiés à des produits en particulier, des “contre conférences” comme la Cloud Native Rejekts ou bien encore des soirées organisées par des sponsors de la KubeCon.

Présentation CNCF

Cet événement est organisé par la fondation mère de la CNCF, la Linux Foundation. La CNCF accompagne les projets open-source liés au cloud en fournissant un point de rencontre entre les développeurs, les utilisateurs et les fournisseurs de services.
L’objectif est d’identifier des projets prometteurs et de faciliter leur adoption par la communauté et les end-users. Un aperçu des projets hébergés par la fondation est disponible sur leur site.

La fondation fournit également des ressources pour aider les entreprises à migrer vers le cloud. Vous avez déjà certainement vu leur landscape qui permet de s’y retrouver plus facilement dans la galaxie des projets liés au cloud.
En complément, vous pouvez maintenant utiliser leur trail-map afin d’identifier les étapes à suivre pour devenir cloud native.

Sujets récurrents de la Kubecon 2019

Comme à chaque édition, il y avait un certain nombre de sujets récurrents :

Kubernetes en production

Mettre en production un cluster devient de plus en plus aisé. Par contre lors de la montée en charge sur un cluster, les problèmes commencent à apparaître. Beaucoup de discussions et de conférences tournent autour du sujet de la maintenance de Kubernetes en condition opérationnelle de production. De nombreux retours d’expérience présentent certains pièges à éviter.

Les services mesh

Les services mesh sont de plus en plus déployés sur les clusters Kubernetes. Ils permettent d’avoir un routage intelligent entre les services, de l’A/B testing, d’implémenter des patterns comme le circuit breaker… Istio a ouvert le bal et est actuellement le plus populaire, mais aussi le plus critiqué à cause de tous les problèmes rencontrés en production. Le principe du service mesh n’est pas remis en cause, mais l’implémentation est sujette à concurrence.

La diversité

Un gros focus est encore une fois mis sur le côté inclusif de la communauté Kubernetes, mais aussi de la communauté autour des produits de la CNCF. Beaucoup de personnes d’horizons divers participent au succès des produits de la CNCF et la volonté de faire contribuer tout le monde est rappelée à nombreuses reprises.

Keynotes

Chaque début de journée (et la fin de la première journée) est dédié aux keynotes. Les keynotes ont été l’occasion d’aborder plusieurs sujets qui sont ensuite traités plus en détail dans différentes conférences.
Voici les principaux sujets à retenir de ces différentes keynotes :

Le succès de kubernetes

Kubernetes est le produit de plus de 10 ans d’évolutions dans l’ingénierie pour faire tourner des applications en production. Il est issu de produits tels que Borg ou Omega de chez Google, a bénéficié des travaux sur les conteneurs Linux, s’est construit autour d’un produit tel que Docker, et est maintenu par plus de 31 000 contributeurs.
Il y a eu (et il y a encore) beaucoup d’autres systèmes d’orchestration, alors pourquoi une conférence sur Kubernetes plutôt que sur un autre orchestrateur ? Car c’est un produit qui est maintenant mature et qui est soutenu par une large communauté.

Une communauté inclusive

Beaucoup d’effort sont déployés par la CNCF et la communauté autour des produits de la fondation pour inciter toujours plus de personnes à contribuer chacune à son niveau. Un investissement substantiel est mis en place (770 000$), par exemple avec des bourses pour aider des personnes de tout horizon à assister à des conférences comme la KubeCon. Des SIGs (Special Interest Group) ont pour objectif d’améliorer l’expérience des contributeurs.
Nous avons eu le retour de Nikhita Raghunath et de Lucas Käldström qui nous ont expliqué comment les programmes de la fondation les ont aidé à rentrer dans le projet Kubernetes. Maintenant tous deux sont contributeurs actifs du projet.

Service Mesh Interface

L’un des sujets du moment dans le monde de Kubernetes est le service mesh. Le projet phare actuellement est Istio, mais d’autres projets existent aussi comme Linkerd. Chaque projet de service mesh propose son approche pour implémenter des principes qui restent communs. Pour éviter le “vendor locking”, une nouvelle initiative a été annoncée : le Service Mesh Interface. L’idée est de définir un set de features des services mesh via une interface commune et standardisée.

Kubernetes at CERN

 
Une des keynotes a été présentée par 2 chercheurs au CERN qui nous ont fait une démo live assez impressionnante sur leur utilisation de kubernetes pour une analyse de données pour (re)découvrir le boson de Higg. Ce traitement met en place 25 000 jobs pour traiter 70 TB de données.
Lien vers la vidéo : https://www.youtube.com/watch?v=CTfp2woVEkA

Autres sujets

Beaucoup de keynotes ont été dédiées à nous présenter les dernières nouveautés des projets CNCF. Les keynotes ont été aussi l’occasion de remercier des ambassadeurs de la communauté.

Présentations

Comme dit en introduction, presque 400 conférences ont été données lors de cette KubeCon. Voici un aperçu de quelques-unes auxquelles nous avons assisté.

Building images efficiently and securely on Kubernetes with BuildKit par Akihiro Suda, NTT

Ce talk a tout d’abord présenté les concepts de BuildKit, builder d’image docker (entre autres) nouvelle génération. Celui-ci permet d’avoir de meilleures performances pour le build d’image grâce à une gestion du parallélisme et du cache.
La seconde partie était sur le déploiement et l’utilisation de BuildKit pour la construction d’images Docker dans un cluster Kubernetes. Plusieurs approches ont été présentées pour montrer que la problématique de la sécurité n’est pas encore totalement résolue.
L’une des solutions abordées est l’utilisation de Tekton, projet dédié à l’intégration continue basé sur kubernetes qui permet d’utiliser BuildKit en tant que builder d’image.
Lien vers la vidéo : https://youtu.be/JKbPzUnAZ1Y
 

Unit Testing Your Kubernetes Configurations Using Open Policy Agent – Gareth Rushgrove, Docker

 
L’Open Policy Agent (OPA) est un outil permettant d’opérer une validation sémantique des descripteurs Kubernetes. Outre la validation classique, il est possible de définir ses propres règles (erreur/warning), liées aux contraintes spécifiques au projet ou à l’organisation. Ceci peut être utilisé sur un cluster déjà opérationnel, mais l’intérêt majeur est de l’introduire dès la phase de développement, dans l’esprit devOps « Shift Left ». Le conférencier rappelle le caractère contraignant des règles, et présente l’intérêt avec un pragmatisme inspirant : « Make it very easy for developers to be compliant and very hard not to be compliant ».
L’outil permettant de vérifier les policies s’appelle « conftest ». Il permet notamment d’écrire des tests unitaires de ses propres règles et de récupérer facilement des jeux de règles partagées sur le net, facilitant le partage de bonnes pratiques. Il peut être installé sous forme de plugin Kubectl.
Lien vers la vidéo : https://youtu.be/AfTuzonH93U

Service Meshes: At What Cost? – Lee Calcote, Layer5 & Girish Ranganathan, SolarWinds

La bataille des Services Meshes fait rage, pour un usage qui devient essentiel dans nos clusters. Au-delà des fonctionnalités, quel est le coût au Runtime ? Difficile de comparer à la lecture d’un article, car les fonctionnalités ne sont pas les mêmes. C’est là où intervient Meshery : un outil qui permet de mesurer et comparer l’empreinte de plusieurs Services Meshes sur votre propre cluster.
À prendre avec des pincettes vu les disparités de fonctionnalités, mais l’on voit dans le cas d’étude que Istio a un fort impact mémoire sur les pods comparé à Linkerd & Consul, plus normalisé en CPU. De même, côté Control Plane, Istio reste le plus gourmand en mémoire et CPU, et de très loin.
Lien vers la vidéo : https://youtu.be/LxP-yHrKL4M

Kubernetes failure stories par Henning Jacobs, Zalando

Cette présentation est un retour sur 8 problèmes que l’équipe de production de Zalendo a rencontré avec leurs clusters kubernetes de production. Ceux-ci vont de l’erreur humaine au bug d’infrastructure AWS en passant par des out of memory qui par effet boule de neige crashent un cluster.
Très intéressant exercice de partage pour faire progresser sur la gestion d’un cluster kubernetes. Henning Jacobs a un repo github qui répertorie les failure stories : https://github.com/hjacobs/kubernetes-failure-stories, à lire pour comprendre que Kubernetes en production, ce n’est pas magique !
Lien vers la vidéo : https://youtu.be/6sDTB4eV4F8

10 Ways to Shoot Yourself in the Foot with Kubernetes, #9 Will Surprise You – Laurent Bernaille & Robert Boll, Datadog

Une autre présentation sur des problèmes rencontrés en production. Datadog est une société qui propose une solution managée de monitoring, logging et alerting. Leur backend tourne sur du Kubernetes avec des centaines de noeuds.
Beaucoup de problèmes sont liés au DNS et à la manipulation des Daemonsets. Bien que les containers soient isolés, les IOs restent partagés, mais aussi comme toujours des erreurs humaines !
La présentation rentre dans les détails techniques des erreurs, très intéressants de voir ce que c’est de pousser Kubernetes dans ces derniers retranchements !
Lien vers la vidéo : https://youtu.be/QKI-JRs2RIE

Let’s Try Every CRI Runtime Available for Kubernetes. No, Really! – Phil Estes, IBM

Kubernetes est architecturé pour pouvoir choisir son runtime de container sans changer le reste du cluster. Le prérequis pour qu’un container runtime fonctionne avec Kubernetes est de respecter la CRI (Container Runtime Interface). De ce fait, il existe beaucoup de containers runtime compatibles avec Kubernetes.
Chacun de ces CRI Runtime ont leurs intérêts. Phil Estes revient sur chacun d’entre eux en faisant une rapide démo et listant leurs forces et faiblesses. Ce qui aussi est intéressant de noter, c’est tous ne font pas forcément du container. Comme firecracker par exemple qui vient de AWS.
Lien vers la vidéo : https://youtu.be/FKoVztEQHss

Fool-Proof Kubernetes Dashboards for Sleep-Deprived Oncalls – David Kaltschmidt, Grafana Labs

Lorsque l’on surveille son application Kubernetes par dashboards Grafana, l’on tombe rapidement dans des travers d’organisation, sans une stratégie adaptée : des centaines de dashboards, des séquences de clics inefficients, etc.
David donne ici quelques conseils pour améliorer l’UX et réduire le coût cognitif de la supervision, notamment :

• Définir des filtres avec listes déroulantes en tête de dashboard (« template variables »)
• Construire des dashboards méthodiques
  • Méthode USE (Utilization, Saturation, Errors)
  • Méthode RED (Request rate, Error Rate, Duration)

• Utiliser les dashboards créés et maintenus par la communauté : https://github.com/kubernetes-monitoring/kubernetes-mixin
• Construire des dashboards hiérarchiques : par exemple une vue agrégée du cluster, puis les services, puis les pods
• Committer, faire relire et versionner les sources de ses dashboards
• Utiliser des librairies de génération de dashboards tel que Grafonnet et Grafanalib, pour maintenir une cohésion transverse

Lien vers la vidéo : https://youtu.be/YE2aQFiMGfY

Tutorial: Bullet-Proof Kubernetes: Learn by Hacking – Luke Bond, ControlPlane & Ana-Maria Calin, Paybase

Cette année, des sessions « tutorial » étaient organisées lors de la première journée. Celles-ci sont présentées sous forme de TP et permettent de pratiquer afin de s’approprier les concepts évoqués.
Une session très intéressante, organisée sous forme de Capture The Flag (CTF), proposait aux participants de trouver et d’exploiter les failles d’un cluster mal configuré afin d’accéder aux machines hôtes du cluster.
Les participants étaient par équipe de 6 avec un cluster pour chaque équipe. La composition des équipes a été faite au hasard en fonction du placement dans la salle et a permis d’échanger avec d’autres utilisateurs de Kubernetes tout en ayant un objectif commun.
Lien vers la vidéo : https://www.youtube.com/watch?v=NEfwUxId1Uk

Auto-scaling multi-cluster observability with Thanos and Linkerd – Andrew Seigner, LinkerD and Frederic Branczyk , RedHat

Lors de cette conférence, Andrew et Frederic nous ont introduit LinkerD et Thanos, qui sont respectivement un service mesh et une boîte à outils permettant d’étendre l’usage de Prometheus à l’échelle.
La première version de LinkerD a été développée en interne chez Twitter pour répondre aux besoins de routing entre services. L’outil est cependant devenu assez volumineux avec le temps : le sidecar de proxy pouvait consommer plus de 1Gb de mémoire vive (JVM faisant tourner du Scala).
La seconde version a été entièrement redéveloppée en Rust pour se focaliser sur la performance et l’usage de l’outil, elle s’intègre aujourd’hui avec Kubernetes et Prometheus.
Par ailleurs, la démonstration à laquelle nous avons assisté sur le stand LinkerD était convaincante : installation du service mesh en quelques secondes, accès facilité aux logs, possibilité de venir écouter directement sur le proxy d’un service, dashboard avec une vue temps réel du trafic, etc.
Thanos permet de répondre aux problématiques qui se posent lors de l’utilisation de Prometheus sur un ou plusieurs clusters de taille conséquente et donc avec une forte production de métrique :

• Rétention d’un large volume de métrique dans le temps
• Moteur de requête sur l’ensemble des métriques
• haute disponibilité
• Utilisation du Store API pour l’interopérabilité Prometheus
• Capacité de sous-échantillonnage des métriques

La démonstration lors de la présentation consistait à installer et configurer LinkerD et Thanos sur quatres clusters chez les principaux fournisseur de service Cloud (AWS, GCP, Azure et DigitalOcean), puis d’utiliser les différentes fonctionnalités pour identifier rapidement et corriger un problème de production sur l’un des services.
Une idée intéressante émise lors de cette démo est l’usage de la latence des services du système comme métrique pour gérer le dimensionnement automatique: en effet, bien que la consommation CPU et mémoire soit des métriques valides, il est intéressant de se focaliser sur l’expérience utilisateur.
Cette démonstration est disponible ici si vous souhaitez vous lancer : https://github.com/linkerd/linkerd-examples/tree/siggy/thanos-autoscale/thanos-demo
Plus de détails sur le fonctionnement des composants de Thanos sont disponibles dans la documentation.

Communauté

La #KubeCon, c’est aussi l’occasion de rencontrer et d’échanger avec des gens qui travaillent sur les mêmes sujet que nous.
On a pu voir que la communauté francophone était bien représentée !
Merci à Laurent Grangeau, Alexis Chotard, Reda Benzair et tous ceux qui ont permis de faire ces belles photos de groupe 🙂

Conclusion

Vous pouvez retrouver l’intégralité des slides sur le programme de la conférence : https://events.linuxfoundation.org/events/kubecon-cloudnativecon-europe-2019/schedule/
Vous pouvez aussi retrouver l’intégralité des conférences sur la chaîne youtube de la CNCF : https://www.youtube.com/playlist?list=PLj6h78yzYM2PpmMAnvpvsnR4c27wJePh3
À l’année prochaine !
Cet article a été co-rédigé par Éric Briand, Baptiste Gauduchon, Benoît Couetil, Sébastien Nahelou, Ilyes Semlali, Pierre-Yves Aillet et Vincent Gramer