KubeCon + CloudNativeCon EU 2019 – Day 1

Nous vous présentions il y a quelques jours le « Day 0 » de cette KubeCon + CloudNativeCon EU 2019, c’est donc désormais logiquement le tour du Day 1 !

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.

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.

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

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 :

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.

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

Kubernetes Project Update – Janet Kuo, Software Engineer, Google

Tout comme pour les news des projets de la CNCF le matin, une keynote est dédiée aux nouveautés de Kubernetes. Peu de choses à retenir de cette keynote qui ne soient pas déjà dans tous les blogs liés à Kubernetes, mais néanmoins 3 axes qui se dégagent dans les évolutions de Kubernetes :

  • Extensibilité
  • Scalabilité
  • Fiabilité

 

Reperforming a Nobel Prize Discovery on Kubernetes – Ricardo Rocha, Computing Engineer & Lukas Heinrich, Physicist, CERN

WOW. Voici cette keynote décrite en un mot.

Un peu de teasing :

 

L’année dernière, le CERN avait déjà présenté une keynote sur la fédération de multiples cluster Kubernetes.
Cette année, l’objectif est encore plus ambitieux et impressionnant : et si nous reproduisions les calculs ayant mené au Prix Nobel lié à la découverte du boson de Higgs en live, pendant la keynote ?
Et en effet…

Quelques minutes plus tard et après les explications scientifiques de rigueur, nous voici à contempler un graphique prouvant l’existence du boson de Higgs, le tout dans un notebook Jupyter Lab traitant pas moins de 70TB de données issues des capteurs du LHC.

L’infrastructure derrière un tel calcul ? Un cluster Kubernetes d’une bagatelle de 25 000 cores couplés à Google Cloud Storage consommé à 200GB/s. La meilleure publicité dont Google Cloud puisse rêver !

Mais le postulat des speakers Ricardo et Lukas fait sens : le CERN met à disposition en Open Data toutes les données collectées par le LHC et permettant de reproduire de tels résultats. Mais quel en est l’intérêt s’il est nécessaire d’être le CERN ou un équivalent pour avoir la puissance de calcul nécessaire à la reproduction des calculs ? Une belle démonstration de l’utilité du cloud public en terme de scalabilité, même si nous n’aurions pas aimé être ceux qui payent la facture (bien qu’une telle démonstration est probablement offerte par Google).

 

Expanding the Kubernetes Operator Community – Rob Szumski, Principal Product Manager for OpenShift, Red Hat

Les Operators Kubernetes sont sans doute un enjeu majeur de cette année 2019.

Pour rappel, les Operators sont un moyen de déployer des applications sur Kubernetes qui sont bien plus complexes que de simples applications stateless, comme des bases de données ou des brokers de messages par exemple. Ces Operators vont permettre de fournir des informations supplémentaires au déploiement des applications qui leur permettront de conserver leur état, tout en abstrayant la logique complexe de déploiement et d’orchestration qui peut être très particulière sur certaines solutions distribuées.

Afin d’y voir plus clair et de se faciliter la vie, Red Hat « annonce » 2 projets déjà publics depuis un petit moment :

  • L’Operator Hub, un registre d’Operators qui est le bienvenu
  • L’Operator Framework, un ensemble d’abstractions plus haut niveau visant à faciliter le développement de ses propres Operators.

Democratizing Service Mesh on Kubernetes – Gabe Monroy, Microsoft

Au milieu des contributions récentes de Microsoft à l’écosystème Cloud Native, on trouve une annonce qui ne peut pas passer inaperçue : celle de Service Mesh Interface (SMI).

SMI semble avoir comme objectif de fournir une certaine standardisation et interopérabilité sur les interfaces et les features de base des solutions de Service Mesh. Une initiative bienvenue dans un monde où les solutions de Service Mesh se démultiplient chaque jour : Istio, Linkerd, Aspen Mesh, Consul Mesh, …

On pourrait s’inquiéter de voir de plus en plus de logique débarquer dans les solutions de Service Mesh ; certains seraient même inquiets que l’on revienne dans les travers des Enterprise Service Bus (ESB). Pour aller plus loin sur ce sujet, Sam Newman a réalisé un excellent thread Twitter autour du sujet « Keep the endpoints smart, the pipes dumb » en réaction à cette annonce de SMI.

Take Away

Que retenons-nous de cette première journée ?

  • La communauté est le pilier de toutes les solutions de l’écosystème Cloud Native et chacun peut œuvrer pour en faire pleinement partie ;
  • Les solutions de Service Mesh ont de beaux jours devant elles et l’annonce de SMI offre une nouvelle perspective intéressante au sujet ;
  • Des sujets pourtant simples comme les registres d’images sont encore sujets à des évolutions tout en restant dans l’interopérabilité avec l’existant ;
  • Les building blocks se multiplient mais gardent une certaine cohérence sans laquelle nous nous perdrions tous dans ce vaste océan de tech ;
  • Les Operators émergent comme un point central pour les systèmes distribués sur Kubernetes ;
  • La fiabilité, la scalabilité et l’extensibilité de Kubernetes ne sont plus à prouver.

Pour rappel, la plupart des vidéos de cette KubeCon + CloudNativeCon EU 2019 sont d’ores et déjà disponibles sur YouTube.

À bientôt pour la deuxième journée de cette KCCNC !

 

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.