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.

« We can’t really say ‘Hey we’re stable and we’ll stagnate there’, we have to keep moving » – @bryanl on the opening keynote of this last day at #KubeCon #CloudNativeCon pic.twitter.com/xkTrF5Zlut

— Alexis « Horgix » Chotard (@Horgix) May 23, 2019

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.

I’ll admit I’m tempted to troll a bit by completing it with « … Rust is better ».
But @bryanl actually have a really valid point here: people are using multiple languages and developer experience and interfaces should be similar#KubeCon #CloudNativeCon #Golang #Rustlang pic.twitter.com/En4RTkXplh

— Alexis « Horgix » Chotard (@Horgix) May 23, 2019

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.

Last afternoon at the #KubeCon #CloudNativeCon and happy to be at @matei _radu deep dive on Brigade, a lightweight framework for event centric scripting based on containers and centered on #Kubernetes
Cool stuff with deep dives: the real stuff comes up after only 2 minutes pic.twitter.com/Dm5xEuvuea

— Alexis « Horgix » Chotard (@Horgix) May 23, 2019

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 2^e 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é kind – Kubernetes 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 3^e journée qui nous ont passionné et auraient mérité leur place dans cette shortlist sont les suivants (allez voir les vidéos !) :

• Helm 3: Navigating To Distant Shores – Bridget Kromhout & Jessica Deen, Microsoft [vidéo] : un tour d’horizon des nouveautés de Helm3 que nous avons tenté de vous résumer en live dans un thread Twitter.
• Securing Kubernetes with Trusted Platform Module (TPM) – Alex Tcherniakhovski & Andrew Lytvynov, Google [vidéo] : un talk tout en profondeur sur l’utilisation des puces TPM pour sécuriser des secrets Kubernetes ou encore les certificats permettant aux nœuds de s’authentifier mutuellement auprès de Kubernetes. Présenté par des ingénieurs de Google, on y retrouve tous les points habituels d’un bon talk orienté sécurité : les threat models qu’ils cherchent à adresser, les remédiations possibles, le tout dans un talk 100% tech.
• Fool-Proof Kubernetes Dashboards for Sleep-Deprived Oncalls – David Kaltschmidt, Grafana Labs [vidéo] : le dernier talk de cette KCCNC parlait… d’UX ! Plus précisément, il parlait d’UX appliquée aux dashboards : comment construire des dashboards qui ont du sens et qui vous donnent l’essentiel des informations de manière claire, même lorsque vous n’avez pas les yeux en face des trous à 3h du matin en pleine astreinte.

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 !