Premier choc pour Olivier et Jean-Pascal en arrivant dans la salle de keynote vide :

• Mais… elle est immense la salle de keynote !
  
• Oui oui
• …
• J’ai l’impression qu’on est quand même vachement plus que les 4 500 de l’année dernière

Après vérification, ce sont en effet 7 700 personnes qui ont participé à cette KubeCon + CloudNativeCon EU 2019 ! De quoi faire une jolie salle de keynote.

Allons aujourd’hui encore à l’essentiel : des résumés rapides de ce que nous avons humblement trouvé pertinent et des liens pour ceux qui voudraient approfondir. Nous allons tâcher de structurer chaque journée de la manière suivante afin d’éviter le surplus d’informations inutiles :

1. Résumé des keynotes pertinentes et annonces
2. Présentation des 3 talks qui nous ont marqués, étant donné que nous sommes 3 Xebians à avoir assistés à cette KCCNC
3. Partage de nos ressentis en fin de journée

Voici le sommaire correspondant :

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 d’ores et déjà disponibles sur YouTube.

Commençons ainsi par le point le plus logique : les keynotes d’ouverture !

Keynotes d’ouverture

Stitching Things Together – Dan Kohn, Executive Director, Cloud Native Computing Foundation

Tout comme l’année dernière, Dan Kohn ouvre le bal en nous parlant du rôle de Kubernetes et de la Cloud Native Computing Foundation dans l’écosystème, de comment ils en sont arrivés là et des challenges à venir.

Il nous présente tout ceci sous un angle surprenant mais néanmoins intéressant : une comparaison avec le jeu Civilization V et ses arbres de choix technologiques.

Opening keynote of this #KubeCon #CloudNativeCon by @dankohn1 (Who else if not for @kelseyhightower or @lizrice ?)
Really interesting comparisons with Civilization V technology trees.
Also talking about simultaneous invention history and why we only talk about #Kubernetes now pic.twitter.com/EZBHlssaL1

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

En parallèle, il mentionne également la notion d’invention simultanée et de comment plusieurs scientifiques ont, dans l’histoire, fait les mêmes découvertes indépendamment. Appliqué à l’orchestration, on peut en effet constater qu’une très très TRÈS grande quantité d’orchestrateurs ont été inventés par le passé :

• Alibaba Sigma
• Amazon Appolo
• Apache Mesos
• Baidu Matrix
• Cloud Foundry Garden & Diego
• CoreOS Fleet
• Docker Swarm
• Facebook Tupperware
• Google Borg & Omega
• Hashicorp Nomad
• IBM Platform Symphony
• Joyent Triton, Lyft v3 Infra
• Microsoft Service Fabric
• Netflix Titus
• Rancher Cattle
• Red Hat OpenShift v2 Broker
• Spotify Helios
• Tencent Gaia
• Twitter Aurora
• Uber Peloton

Toutes ces entreprises ont développé des approches similaires à leurs problèmes de scaling. Mais alors, pourquoi ne parle-t-on plus que de Kubernetes aujourd’hui ?

Pour lui, 3 raisons se cachent derrière l’émergence de Kubernetes comme la plateforme d’orchestration de choix :

1. It works really well – Kubernetes n’est pas seulement construit sur des décennies d’expérience de Google avec Borg & Omega, il inclut également des contributions notoires d’autres entreprises.
2. Vendor-Neutral Open Source – Aujourd’hui, les entreprises qui vont construire sur une plateforme existante veulent que celle-ci soit soutenue par d’autres entreprises. Depuis le début de Kubernetes, Google encourage les certifications Kubernetes pour d’autres fournisseurs de Kubernetes-as-a-Service et pousse d’autres entreprises à prendre des rôles de leader sur le projet.
3. It’s the people – Discours cher à notre coeur de Xebian, une des raisons ayant fait de Kubernetes la solution dominante concerne les personnes impliquées sur le projet : les contributeurs open source, l’onboarding facilité des nouveaux contributeurs, etc.

2.66 Million – Cheryl Hung, Director of Ecosystem, Cloud Native Computing Foundation

Cheryl Hung enchaîne sur une présentation de l’écosystème Cloud Native et de quelques chiffres. En voici les principaux.

La Cloud Native Computing Foundation totalise 2,66 millions de contributions réalisées par 56 214 contributeurs.

Pour ce qui est du programme de cette conférence, il a été concocté par un comité de sélection de 107 personnes ayant eu à choisir parmi 1 535 soumissions au CFP !

CNCF Project Update – Bryan Liles, Senior Staff Engineer, VMware

Comme il est désormais habituel lors des KCCNC, un tour des nouveautés majeures des projets de la CNCF est présenté. Cette fois-ci c’est Bryan Liles qui orchestre les différents speakers sur chaque sujet.

Sujets mentionnés :

• OpenEBS, rapidement évoqué pour ouvrir le sujet du stockage sur Kubernetes.
  
• Linkerd, avec une démonstration live et la mention des features récentes : zero-config mutual TLS en avril et trafic shifting en juin.
  
• Helm, avec notamment l’arrivée de la v3. Au programme :
  • Suppression de Tiller, apportant ainsi une approche client only à Helm
    
  • Nom des releases désormais scopées par namespace
  • Validation des valeurs dans les Charts avec JSON Schema
  • Stockage des Charts dans des registres OCI-compliant
  • … et bien plus encore. On en reparle dans les jours à venir.
• Harbor, le registre d’images Docker et plus généralement d’images OCI, avec notamment la sortie de la version 1.8 qui supporte la connection via OpenID Connect, les « robot accounts » et des améliorations autour de la réplication.
• Rook, dont la version 1.0 est sortie il y a peu et qui peut désormais être considéré comme production ready. De nouvelles features dans les Operators pour Ceph, EdgeFS et Minio, l’ajout du support de CSI, et encore plus. A découvrir dans le blogpost dédié.
• CRI-O, qui pour rappel est un moteur de conteneurs qui implémente la CRI (Kubernetes Container Runtime Interface). Il supporte toutes les images au format OCI, en faisant ainsi un candidat de choix pour le remplacement de Docker en tant que container engine notamment via le support de tous les anciens formats d’images Docker. Côté runtime, il supporte tous les runtime OCI-compliant, dont runc, kata et gvisor. Un message à retenir : CRI-O est l’engine de choix pour le futur des clusters Kubernetes.
• Fluentd est désormais parmi les quelques projets au niveau « Graduated«  de la CNCF, et fait désormais partie des images officielles du Docker Hub (permettant un simple docker run fluentd). Il est par conséquent et grâce aux récentes évolutions du Docker Hub disponible pour plusieurs architectures sur le Hub : x86-64 évidemment, mais aussi ARM.

Ces informations sur les projets de la CNCF se terminent sur une belle annonce : OpenTracing et OpenCensus se regroupent pour devenir OpenTelemetry.

YEAH, @OpenTracing and @OpenCensus merging into a single thing : Open Telemetry. Best news of the #KubeCon #CloudNativeCon so far! pic.twitter.com/SFMLbNF1sK

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

Comme quoi… nous avions vu juste l’année dernière :

Nice slot about @opencensusio and @IstioMesh there at #KubeCon + #CloudNativeCon with some interesting challenges to come (sample only traces that concern errors or slow requests anyone?)
But come one, we need a compatibility with @opentracing … just sayin’ pic.twitter.com/WIcaTmTUvZ

— Alexis « Horgix » Chotard (@Horgix) May 2, 2018

Si vous souhaitez en savoir plus sur OpenTelemetry, un post Medium y est dédié.

Network, Please Evolve – Vijoy Pandey, VP/CTO Cloud, Cisco

Cisco annonce rapidement son Network Service Mesh, qui semble vouloir appliquer les concepts des services mesh aux couches plus basses, notamment les layers 2 & 3 du modèle OSI. Le slogan « No IPs, No Routes, No Subnets » laisse songeur quant à la réalité. À voir.

Getting Started in the Kubernetes Community – Lucas Käldström, CNCF Ambassador, Independent & Nikhita Raghunath, Software Engineer, Loodse

La keynote la plus inspirante de cette première journée pour nous tournait autour d’un sujet tout autre que la technique elle même : la contribution et la communauté.

Plus tôt dans la journée, Cheryl Hung parlait du chemin que les participants à l’écosystème Cloud Native suivent : Use → Share → Contribute → Lead. Lors de cette dernière keynote matinale, Lucas Käldström et Nikhita Raghunath nous présentent le chemin qu’ils ont suivi dans la communauté de la CNCF.

Leur histoire fait partie de celles qui perdent leur charme et leur conviction lorsqu’elles sont narrées par d’autres. Nous vous incitons donc à visionner la vidéo de leur présentation qui ne dure que 20 min et vaut sacrément le coup. Si vous n’avez qu’une keynote de cette matinée à regarder, c’est celle-ci !

Talks

Les keynotes de la matinée étant passées, place aux présentations de la journée.

Comme convenu : 3 Xebians, 3 talks, c’est parti !

P2P Docker Image Distribution in Hybrid Cloud Environment with Kraken – Yiran Wang & Cody Gibb, Uber

Quoi de plus banal qu’un registre d’images Docker ? Les implémentations ne manquent pas :

• Docker Registry officiel, utilisé par le Docker Hub
• Harbor, dont nous parlions plus haut dans les nouvelles des projets de la CNCF
• GitLab Container Registry
• GCP Container Registry
• AWS Elastic Container Registry
• Le Docker Registry d’Artifactory
• … et bien d’autres.

Toutes ces implémentations viennent du fait que l’API d’un registre d’images OCI-compliant est complète et largement adoptée. Mais alors, pourquoi en parlons-nous ici ?

Et bien parce qu’aussi simples que soient ces implémentations, elles rencontrent vite des problèmes de scalabilité.

Ces problèmes ont amené Uber à créer Kraken, un registre d’images Docker en peer-to-peer.

Cody Gibb and @mono_ian from @Uber telling us about Kraken (https://t.co/pDHBMDQbJ1) at #KubeCon #CloudNativeCon with a cool peers graph!
Kraken is actually more of a P2P caching layer, it doesn’t do the images storage itself and can suffer full data loss pic.twitter.com/5jGvFKsP4d

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

Quelques points intéressants concernant Kraken :

• Kraken ne stocke pas lui-même les données. Il s’agit plus d’une sorte de cache distribué.
• Les données sont toujours stockées dans un véritable registre d’images Docker s’appuyant potentiellement sur de l’Object Storage. Ainsi, Kraken en lui-même est là pour encaisser la charge de distribution des images, et peut supporter une perte totale de ses données, étant à même de les reconstruire à partir du véritable registre.
• Kraken est plutôt léger, nécessite très peu de dépendances et est évidemment hautement disponible de par sa nature.
• Il est possible de faire de la réplication multi-clusters.

Et les résultats sont là : l’infrastructure d’Uber est désormais capable de distribuer 20 000 blobs de 100MB-1G en l’espace de 30sec, là où l’ancienne stack (sans Kraken) aurait simplement fini à terre face à une telle charge.

Ce qui est à retenir de ce talk n’est probablement pas Kraken en lui-même. Bien que très intéressant techniquement, la plupart des entreprises n’ont pas (encore) l’échelle nécessaire pour que ce soit réellement pertinent. Ce qui est à retenir, c’est surtout cette échelle propre aux entreprises comme Uber qui construisent des systèmes modernes et avec une scalabilité horizontale. Ce qui est encore plus passionnant que cette scalabilité, c’est le fait que des utilisateurs finaux tels qu’Uber s’attachent à une compatibilité avec les protocoles, formats et outils qui ont émergé dans la communauté.

Il y a quelques années, un tel problème de scalabilité avec les registres Docker aurait probablement donné lieu à la création de solutions sur mesure dans beaucoup d’entreprises. Aujourd’hui, l’interopérabilité avec le reste de l’écosystème et les apports de cet écosystème sont jugés comme apportant suffisamment de valeur pour mériter de se reposer dessus et d’y rester compatible.

Writing kubectl Plugins for Everyone: Develop, Package & Distribute – Ahmet Alp Balkan, Google & Maciej Szulik, Red Hat

kubectl est la CLI officielle pour interagir simplement avec un cluster Kubernetes, traduisant un grand nombre de sous-commandes en appels gRPC. Ces sous-commandes couvrent la quasi totalité des APIs de Kubernetes. Mais est-ce suffisant ? Kubernetes est censé être extensible, alors qu’en est-il de sa CLI ?

Comme décrit sur la documentation de Kubernetes, la CLI est facilement extensible grâce à la création et à l’utilisation de plugins.

Si vous décidez de créer ou d’utiliser un plugin, rien de bien compliqué. Voici la recette de cuisine !

Votre plugin doit :

• être un exécutable dans le langage de votre choix
• avoir un nom préfixé par kubectl-, par exemple kubectl-foobar
• être accessible depuis le PATH de kubectl

La commande kubectl plugin list vous permettra de lister les plugins ainsi pris en charge.

Il ne vous restera plus qu’a l’utiliser : kubectl foobar

Une fois que vous aurez développé votre plugin, vous allez certainement vouloir le partager. Pour faciliter ce partage, la communauté a développé un gestionnaire de plugins appelé Krew, qui est d’ailleurs lui-même un plugin. Une fois installé, Krew vous permet d’installer/désinstaller des plugins facilement.

Si vous le souhaitez, il vous est possible d’ajouter vos plugins dans ceux référencés par Krew en ouvrant une PR sur le dépôt GitHub servant de registry/index.

Attention cependant, comme nous le rappellent les speakers Ahmet et Maciej, Krew est jeune et certaines fonctionnalités sont manquantes. Ils en appellent à la communauté pour contribuer à son bon développement : c’est par ici !

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

Open Policy Agent (OPA) permet d’écrire des tests de conformité, via un DSL dédié : Rego.

C’est un très bonne chose : dans le monde des Ops, l’idée de tester son infra est encore trop peu pratiquée.

Gareth Rushgroove nous parle aujourd’hui de tests unitaires et insiste aussi sur l’utilité du test : en Java, l’utilisation de JUnit est un non sujet, alors pourquoi pas sur un cluster Kubernetes ?

Et surtout, pourquoi test unitaire, maintenant qu’on sait qu’OPA est avant tout dédié aux tests de conformité ?

Le problème des tests, c’est souvent le temps qu’il faut pour les exécuter. Et Gareth insiste : plus on s’éloigne du poste de dev et se rapproche de la prod, plus le feedback d’un cycle de tests est important. Ce qu’il y a d’unitaire dans ces tests, c’est de les lancer en local sur un poste de dev. Un outil pour cela : conftest.

Les test sont donc écrits en Rego et s’appuient sur des champs de manifestes Kubernetes. Exemples :

• refuser qu’une ressource de type Deployment puisse tourner en root ;
• interdire l’utilisation d’un Service ;
• obliger l’utilisation de certains labels ou valeurs de labels sur une ressource.

Pour faciliter l’écriture, il est aussi possible d’écrire des helpers qui s’apparentent aux macros d’un bon vieux préprocesseur C.

Et comme ces jeux de tests peuvent servir sur d’autres projets, Rego vient avec bon nombre d’outils dont un « bundler » pour packager un ensemble de tests ou helpers sous la forme d’une archive tar.gz. Et cerise sur le gâteau, les dernières spécifications de registry d’images par l’OCI prévoient de pouvoir stocker d’autres types de contenu que des images et layers ! Il devient donc aussi simple de partager des jeux de tests que des images ! conftest supporte en ce sens l’opération « pull » pour aller importer un jeu de tests distant.

L’utilisation de l’entrée standard offre à conftest une interopérabilité avec entre autres les sorties de kustomize, de helm template ou de tout autre outil générant des manifestes en sortie standard. Cela permet aussi, à l’aide d’un snippet de tester tous les manifestes présents sur un cluster actif. Et finalement, maintenant que nous savons que la CLI kubectl peut être enrichie via des plugins, nous apprenons que conftest vient avec son plugin Krew pour l’intégrer à kubectl.

Mais OPA et conftest s’arrêtent-ils ici ? Si Terraform génère des sorties JSON, alors il est aussi possible d’en tester la conformité ! Voilà de quoi ravir la plupart des SRE qui veulent se réconcilier avec les tests.

Nous verrons plus tard que la nouveauté concernant le format de contenu des registres est une des nombreuses évolutions qui tend à rationaliser l’écosystème des conteneurs plutôt que d’amener de nouveaux outils qui pourraient l’alourdir. Cette rationalisation et standardisation est d’ailleurs l’objet de la conférence Paris Container Day ce mardi 4 juin.

Autres conférences

Ces 3 conférences ne sont bien évidemment pas les seules auxquelles nous ayons assisté; mais c’est sur elles que s’est jeté notre dévolu pour cette article. Si vous souhaitez en savoir plus sur ce que nous avons pu découvrir ou redécouvrir à cette KCCNC, venez nous rencontrer (chez Xebia, à un Meetup, en conférence, …) ou laissez un commentaire sur cet article !

Passons aux keynotes de clôture.

Keynotes de clôture