KubeCon + CloudNativeCon EU 2019 – Day 3

Après les articles sur le Jour 0, Jour 1 et Jour 2 de la KubeCon + CloudNativeCon EU 2019, le temps est venu de nous pencher sur la troisième et dernière journée de cette conférence !

Comme pour les articles sur les journées précédentes, nous gardons la formule la formule « keynotes pertinentes + 3 talks + take away ».

Note : si vous souhaitez en découvrir plus sur les présentations dont nous vous parlons dans cet article, la plupart des vidéos de cette KubeCon + CloudNativeCon EU 2019 sont disponibles sur YouTube.

C’est parti pour les keynotes d’ouverture de la journée !

Keynotes

Kubernetes – Don’t Stop Believin’ – Bryan Liles, Senior Staff Engineer, VMware

Après une rapide ouverture de keynote par Janet Kuo, c’est à nouveau Bryan Liles qui annonce la couleur de la journée.

Repartant du message « Kubernetes est une plateforme pour construire des plateformes » qu’il n’avait fait qu’évoquer la veille, il nous parle en ce début de matinée de l’impérieuse nécessité pour Kubernetes de continuer à aller de l’avant et de relever les challenges qui se posent à nous au quotidien.

Kubernetes est maintenant accepté par tous pour les applications stateless, mais le débat est plus fourni dès que l’on parle d’applications stateful (bases de données, files de messages, etc.). Sa vision des choses est la suivante : il y a encore peu de temps, la réponse à la question « Peut-on raisonnablement exécuter des applications stateful sur Kubernetes en production ? » était clairement Non. Maintenant ? « Ça dépend » nous dit Bryan. Pas de quoi clore le sujet et plutôt de nature à l’alimenter, cette faible variation de perception est pourtant parfaitement adaptée au chemin qui est parcouru progressivement par Kubernetes. Et n’oublions pas : « Kubernetes n’est pas la destination ; c’est une partie du voyage ».

Fun fact : Olivier Cloirec, un des Xebians sur place, a eu la surprise d’être mentionné sur scène par Bryan (pas nominativement ceci dit). La raison ? Un thread lancé sur Twitter la veille au sujet de la paternité de cette vision « Une plateforme pour des plateformes », auquel Kelsey Hightower a humblement participé. Bryan a donc mentionné ce thread lors de sa keynote pour appuyer ses propos.

Bryan nous partage également une autre vision : « Le client-go de Kubernetes n’est pas pour les mortels » car il nécessite une compréhension de la mécanique interne de Kubernetes pour être correctement utilisé et c’est un problème. Allant plus loin, il évoque le fait que l’expérience utilisateur d’un développeur qui souhaite parler aux APIs de Kubernetes est très différente d’un langage à l’autre : c’est quelque chose qui doit changer.

Pour conclure, il présente kind en termes élogieux. On ne vous en dit pas plus sur kind, vous trouverez plus bas davantage d’informations à ce sujet grâce à un talk dédié. Une chose à retenir cependant : kind est une des grandes nouveautés dans l’écosystème direct de Kubernetes qui va permettre d’améliorer l’expérience développeur !

 

From COBOL to Kubernetes: A 250 Year Old Bank’s Cloud-Native Journey – Laura Rehorst, Product Owner – Stratus Platform, ABN AMRO Bank NV & Mike Ryan, DevOps Consultant, backtothelab.io

Le message principal de cette keynote est résumé dans son titre : passer d’une infrastructure et d’applications vieillissantes dans un contexte bancaire à des choses plus modernes, c’est possible !

En revanche, si ce genre de sujet vous intéresse, nous vous conseillons plutôt de regarder la keynote de Sarah Wells de l’année dernière, dont les messages sont plus complets et transposables à d’autres contextes.

 

Metrics, Logs & Traces; What Does the Future Hold for Observability? – Tom Wilkie, VP Product, Grafana Labs & Frederic Branczyk, Software Engineer, Red Hat

Rappelons Martelons les 3 piliers de l’observabilité moderne :

  • Logs
  • Metrics
  • Traces

Tom Wilkie de Grafana Labs nous livre dans sa keynote ses prédictions sur l’évolution de l’observabilité en 3 points :

  1. Plus de corrélation entre ces différents piliers ! C’est par exemple ce qu’essaye de proposer Grafana Labs avec Loki, un équivalent de Grafana mais dédié à la visualisation de logs. Le futur nous permettra de passer d’une trace aux logs correspondants puis à une métrique en un clin d’œil et d’avoir des corrélations intelligentes et cohérentes.
  2. L’observabilité ne va pas s’arrêter à ces 3 pilliers et d’autres vont apparaître. Par exemple, le profiling de code est aujourd’hui encore limité ; le choix le plus populaire consiste à être en capacité de rejouer certaines requêtes et à profiler l’exécution de leur rejeu. Mais pourquoi n’aurait-on pas du profiling en live de manière continue ? D’autres points comme celui-ci pourraient apparaître à l’avenir.
  3. La montée en puissance des agrégateurs de logs sans index. Beaucoup de développeurs, de SRE, etc. réagissent à la centralisation de logs actuelle habituellement mise à disposition via Kibana par « donnez moi des fichiers et grep ». Il verrait donc des solutions comme OKLogs (deprecated), kubectl logs ou encore Loki émerger de plus en plus. C’est peut-être le point qui, à notre avis, est le plus discutable dans ses prédictions.

Closing Remarks – Bryan Liles, Senior Staff Engineer, VMware & Janet Kuo, Software Engineer, Google

Enfin, Bryan Liles clos cette dernière session de keynotes de la conférence avec une information à ne pas rater : la date et le lieu de la prochaine KCCNC !

La prochaine KubeCon + CloudNativeCon Europe se tiendra donc… à Amsterdam du 30 mars au 2 avril 2020 ! On espère vous y retrouver.

Talks

Deep Dive: Brigade – Radu Matei, Microsoft

Brigade commence à être connu pour être un « moteur d’intégration continue événementiel » – c’est en réalité bien plus, comme j’ai pu le découvrir lors de cette présentation.

Il faut davantage voir Brigade comme un framework pour faire du scripting en JavaScript de manière event-driven sur Kubernetes. Notre interprétation est que nous y voyons ici une version plus simple à gérer que ce que l’on pourrait autrement construire soi même avec : des Functions-as-a-Service, un broker de messages et le développement d’une gateway.

Matei Radu commence logiquement par nous expliquer l’architecture de Brigade. Comment ça marche ? C’est en réalité plus simple qu’il n’y paraît :

  • Brigade lui-même est principalement un Controller tournant sur Kubernetes, qui parle aux APIs de Kubernetes pour y créer des workers. Le Controller surveille les objets Secrets qui servent de déclencheurs et sont créés par les Gateways.
  • Des Workers pods qui éxecutent des « scripts » Brigade qui ne sont autre que votre propre code JavaScript. Chaque worker gère exactement un script, et se détruit lorsque celui-ci est terminé, échoue, ou timeout.
  • Des Gateways qui vont servir d’interfaces entre le monde extérieur et le déclenchement des scripts/workflows. Par exemple, il existe une gateway qui reçoit des webhooks GitLab pour s’inscrire dans un contexte d’intégration continue (celle pour GitHub est built-in !), mais il y en a également pour se brancher directement sur des brokers de message comme Azure EventGrid. C’est là une des forces principales de Brigade : l’extensibilité via la création de ces gateways et celles déjà existantes. On notera d’ailleurs que Brigade semble être le premier projet visible à utiliser le format open-source CloudEvents annoncé il y a un an lors de la KCCNC EU 2018.
  • Il existe également des dashboards pour Brigade : Kashti, qui est la WebUI développée par Microsoft, et Brigadeterm, une interface en ncurses pour votre terminal

Dépassant la simple architecture, Matei nous parle également de la gestion des dépendances de vos scripts : comment les scripts que Brigade fait tourner pour vous se retrouvent-ils avec leurs dépendances installées ? 2 solutions :

  • Solution n°1 : par défaut, Brigade va installer lui-même vos dépendances dans le worker créé pour l’occasion au démarrage de celui-ci. Pas idéal d’un point de vue performances et trafic réseau... Mais rassurez-vous, il est possible de mettre en cache ces dépendances et bien d’autres choses encore.
  • Solution n°2 : fournir vos propres images de base pour les workers avec les dépendances déjà installées. On ressent une approche des concepts similaires à ce que fait Knative, comme par exemple celle des conteneurs temporaires à la demande.

Tous les workflows sont exécutés selon ce que vous donnerez dans le brigade.js . Un conseil particulièrement avisé de la part de Matei : évitez de mettre trop de logique dans ce brigade.js ; préférez mettre la logique dans le code de vos Jobs eux-mêmes. On ne répétera jamais à quel point la bonne utilisation de nos outils et la réflexion autour de la localisation de la complexité sont nécessaires.

Un certain nombre de bénéfices découlent directement du fait que Brigade soit construit autour de Kubernetes :

  • Accès aux objets et à la notion de Secret de Kubernetes
  • Stockage persistant, que ce soit entre les jobs d’un même workflow ou entre différentes exécutions d’un même workflow. Comment ? Via les PVC (Persistant Volume Claim) de Kubernetes évidemment ! Brigade nous l’abstrait d’ailleurs sous la forme .storage.enabled = true
  • Et bien d’autres...

Quelques exemples de cas d’utilisation pour conclure :

  • Workflows de CI/CD
  • Scans de sécurité applicatifs
  • Agrégation et analyse de données venant de différents systèmes pour construire des rapports
  • Lancer des environnements à chaque PR ou à la demande

Bref, on revient sur l’encapsulation de logique simple et versionnée, avec les usages historiquement adressés par des scripts bash mais sans les (nombreux) inconvénients de ceux-ci.

Le petit plus de ce slot ? Il fait partie de la track Maintainers et le speaker était donc un des mainteneurs de Brigade ; c’est toujours un plaisir d’écouter des gens passionnés et qui maîtrisent leur sujet. Par ailleurs, le côté Deep Dive du talk a permis de passer l’habituelle introduction en 2 minutes chrono et d’attaquer directement le vif du sujet.

Testing your K8s apps with KIND – Benjamin Elder, Google & James Munnelly, Jetstack.io

Si vous utilisez Kubernetes, vous connaissez certainement Minikube qui permet de lancer un cluster Kubernetes local (souvent sur votre poste de travail). Cette solution est particulièrement pratique pour s’essayer à Kubernetes sans avoir à payer une infrastructure chez votre fournisseur préféré.

Imaginons maintenant que vous souhaitiez développer un opérateur Kubernetes – par exemple en suivant les conseils que nous vous relations au sujet d’une conférence de la 2e journée de cette KCCNC. Vous allez probablement vouloir tester cet opérateur. Les tests unitaires vont être possible grâce au client-go, les tests d’intégration avec une instance de l’API Server de Kubernetes, mais quid des tests end-to-end ? Minikube peut s’avérer assez lourd pour recréer des clusters from scratch. Créer un cluster distant chez un fournisseur de cloud sera lent (10 min ou plus) et coûteux. Ne pas faire de tests end-to-end est un risque inconsidéré pour des éléments ayant la complexité d’un opérateur Kubernetes.

Pour répondre entre autres à ce besoin, Benjamin Elder et James Munnelly nous ont présenté kindKubernetes IN Docker. L’idée est simple, lancer un cluster Kubernetes avec tous les composants tournant dans des conteneurs Docker. Ainsi, il est possible de rapidement monter un cluster Kubernetes dans la version de votre choix avec la configuration que vous souhaitez, faire vos tests et supprimer le cluster. kind prévoit également la possibilité d’injecter des images de conteneurs dans le cluster, c’est-à-dire de mettre à disposition des images Docker dans les conteneurs formant le cluster. Ainsi, nul besoin de push les images sur un service tiers pour ensuite les pull depuis le cluster, facilitant grandement les workflows de test.

James nous donne l’exemple du désormais célèbre contrôleur cert-manager dont il est le créateur : récemment, les APIs de cert-manager ont subi un refactoring majeur. Naturellement, il était malgré tout nécessaire de maintenir une certaine compatibilité descendante. Afin de s’en assurer, cert-manager possède toute une suite de tests end-to-end nécessitant un cluster Kubernetes totalement fonctionnel. D’un côté, des actions liées à cert-manager sont effectuées, de l’autre la suite de tests vient directement parler au cluster Kubernetes pour s’assurer que les objets pertinents y ont bien été créés. On est réellement dans une situation de test « black box » ou le fait d’avoir un cluster Kubernetes tout neuf rapidement grâce à kind représente un avantage de taille.

Le fait que kind repose sur des conteneurs Docker s’intègre par ailleurs très bien dans un pipeline d’intégration continue dans la mesure où tous les outils de CI modernes permettent désormais de lancer des conteneurs voire se basent intégralement dessus.

Vous n’avez maintenant plus d’excuse pour ne pas avoir testé vos opérateurs et autres applications liées à Kubernetes !

Pour en savoir plus et voir kind en action, rendez-vous au Paris Container Day le 4 juin 2019 où un talk y sera dédié.

Intro + Deep Dive: Kubernetes (Network) SIG – Tim Hockin, Google

Ce talk est (une fois de plus) un deux-en-un puisqu’il s’agit d’une Intro + Deep Dive.

L’introduction est assurée par Vallery Lancey tandis que Tim Hockin s’occupe du Deep Dive.

Contrairement à ce qu’on peut penser, l’introduction est très utile même pour un gourou du réseau car Vallery reparle des bases du réseau dans Kubernetes : ce qui est abstraction et ce qui ne l’est pas et comment ces abstractions (Services et Endpoints) sont mises en œuvre via des contrôleurs. Pour chaque concept, elle a également la bonne idée de nous pointer le code source correspondant. Elle continue cette introduction en s’attardant un peu sur Kube-proxy, pièce majeure de ses contributions. Finalement, Kube-proxy est très loin de l’abstraction et plus proche des implémentations réseaux, il est exécuté côté host et manipule des règles de firewall bas niveau spécifiques selon le mode utilisé (parmi userspace, iptables, IPVS ou Windows). Elle finit en indiquant les différentes manières de contribuer au SIG Network (Special Interest Group, un groupe de travail communautaire autour du réseau dans Kubernetes).

Après quelques questions, Tim Hockin prend le relai et aborde cinq sujets prioritaires du SIG Network :

  • L’Ingress V1 entre en GA (General Availability, considéré comme stable) : pourquoi aussi tard (3 ans en beta) alors que de nouvelles APIs d’Ingress sont déjà en cours d’élaboration pour le remplacer ? Parce qu’il est utilisé par des milliards d’utilisateurs et que pour nombre d’entre eux, l’utilisation d’une API stable a beaucoup de valeur. Parmi les améliorations ciblant la GA de l’Ingress V1, on note l’IngressClass (à l’instar du StorageClass pour les volumes) et le support des wildcards dans les règles d’Ingress. Tout le détail des améliorations est disponible dans une KEP (Kubernetes Enhancement Proposal) dédiée : ingress-api-group. Selon Tim, il faudrait encore un an avant que l’Ingress V1 arrive en GA.
  • Cache DNS par nœud : qui n’a jamais souffert de problèmes DNS passagers avec Kubernetes ? L’inconvénient avec le protocole DNS (basé sur UDP) est principalement le temps de retour avant de constater une erreur. Ce genre de problème peut se révéler très ennuyeux pour de la production et Tim propose de l’éviter en utilisant un cache DNS local par nœud. Comment ? à l’aide d’un DaemonSet CoreDNS ! Évidemment, le seul DaemonSet n’est pas suffisant, il faut également propager la configuration DNS côté client aux pods du nœud.
  • Topologie de service : lorsque l’on contacte un Service depuis un pod, il peut être intéressant de spécifier des préférences sur les pods à contacter, par exemple un pod du même nœud, pour réduire la latence et le trafic réseau. Si cela n’est pas possible aujourd’hui, le SIG Network prévoit d’ajouter un champ topologyKeys qui permettra de définir ce type de stratégie dans le manifeste du Service. Tim donne un exemple de design possible ainsi que la KEP associée. Avis au lecteur : les travaux sont gelés, faute de ressources, toute contribution est donc plus que bienvenue !
  • Dual stack IPv4 / IPv6 : si Kubernetes supporte depuis longtemps l’IPv6 lorsque cette stack est utilisée seule, l’utilisation conjointe d’IPv4 et IPv6 est bien plus compliquée à implémenter. C’est aujourd’hui un chantier qui demande beaucoup d’efforts. Et oui, changer l’implémentation d’une stack réseau demande beaucoup de tests, doit se faire en plusieurs phases et est un sujet transverse qui touche de nombreuses parties du code source.
  • Repenser l’implémentation des Endpoints : les Endpoints associés à des pods sont aujourd’hui des objets monolithiques et induisent facilement des goulots d’étranglements lors de la mise à l’échelle d’applications. À titre d’exemple, une rolling-update d’un Service qui pointe vers 1000 pods répartis sur 1000 nœuds génère 250 GB de trafic réseau depuis l’API Server ! L’idée pour réduire ces échanges est de ne plus sérialiser des informations concernant chaque Endpoint mais plutôt des regroupements de Endpoints, qu’on nomme Slices.

Conclusion : il y a beaucoup de travail en cours sur le SIG Network, Tim compare d’ailleurs au début du talk le SIG Network à la Sagrada Familia… au début de sa construction ! Toute aide est évidemment très appréciée. Avis aux hackers !

Autres

La sélection des 3 talks à vous présenter pour cette dernière journée de conférences fut la plus ardue de cette série d’articles.

Les autres talks de cette 3e journée qui nous ont passionné et auraient mérité leur place dans cette shortlist sont les suivants (allez voir les vidéos !) :

Take Away

Que retenir de cette journée ?

  • Kubernetes n’est plus seulement à voir comme un orchestrateur mais comme une plateforme à part entière sur et autour de laquelle nous pouvons construire bien plus.
  • Le réseau, tout comme le stockage évoqué hier, a encore de la place pour bien des améliorations et continuera de nous apporter toujours plus de fonctionnalités pour une complexité utilisateur toujours moindre. Du moins, on l’espère.
  • Le Craftsmanship n’est pas en reste, et tout comme l’année dernière, un fort accent de test est omniprésent tout au long des conférences.
  • Les leitmotivs de cette conférence sont la communauté et la contribution : tous les projets que nous avons cité ou presque sont open-source et apprécieront toute contribution à bras ouverts. Le meilleur moment pour commencer à y contribuer ? C’est maintenant !

Pour rappel, la plupart des vidéos de cette KubeCon + CloudNativeCon EU 2019 sont disponibles sur YouTube.

On vous donne rendez-vous bientôt sur ce même blog pour un take away global sur cette conférence. Qu’en avons-nous retenu ? Qu’est ce qui nous a le plus marqué ? Qu’allons-nous tester prochainement suite à la conférence ? On vous raconte tout ça dans une semaine. En attendant, nous espérons vous voir nombreux ce mardi 4 juin 2019 au Paris Container Day !

Publié par Alexis "Horgix" Chotard

Alexis "Horgix" Chotard est DevOps chez Xebia et s'intéresse particulièrement à tout ce qui est infrastructure moderne et dynamique (infra-as-code, containérisation, automatisation, self-healing, déploiement continu, ...). Alexis est également formateur au sein de Xebia Training .

Publié par Jean-Pascal Thiery

Java Craftsman et agiliste pratiquant. Jean-Pascal a arpenté les voies de l'intégration continue jusqu'à intégrer la mouvance DevOps. Il aime : Java, Docker, Mesos, et la qualité des livrables. Il n'aime pas : les phrases qui commence par "Normalement, ...".

Commentaire

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Nous recrutons

Être un Xebian, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.