Ces derniers jours, nous vous présentions sur ce blog les retours sur la KubeCon + CloudNativeCon EU 2019, et plus précisément sur le « Jour 0 » ainsi que la première réelle journée de conférence.

Il est désormais l’heure de vous parler de la deuxième journée de cette KubeCon + CloudNativeCon, toujours sous 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.

Keynotes

Force est de constater que les keynotes de cette matinée ont été moins excitantes que celles de la veille ou encore que celle de l’édition 2018 de la KCCNC EU.

On se concentrera donc sur les plus intéressantes que ce soit en termes de contenu ou d’annonces !

Talks

M3 @ Uber + gRPC @ Spotify

Trichons un peu avec la règle que nous nous sommes imposés de « 3 talks par jour » et parlons de 2 talks en un :

• M3 and Prometheus, Monitoring at Planet Scale for Everyone – Rob Skillington, Uber
• The Story of Why We Migrate to gRPC and How We Go About It – Matthias Grüter, Spotify

Et oui, après vous avoir parlé hier de Uber avec Kraken, son registre d’images Docker P2P, nous allons à nouveau parler d’eux. Mais pas que ! Parlons en parallèle de Spotify.

M3 and Prometheus, Monitoring at Planet Scale for Everyone – Rob Skillington, Uber

D’un côté, nous avons Uber qui développe M3/M3DB, une base de données visant à stocker des séries temporelles (TSDB) – autrement dit des métriques. Le roi du monde sur le sujet en ce moment est Prometheus, soutenu massivement par la communauté et membre des 6 projets « Graduated » de la CNCF. Nous évoquions hier les problématiques de scalabilité que rencontraient Uber avec les registres d’images Docker classiques. Devinez quoi ? Ils rencontrent également des problématiques de scalabilité avec Prometheus ! Plus particulièrement, avec le stockage d’une quantité énorme de métriques couplé à une période de rétention longue de ces métriques. Mais de quelle échelle parle-t-on exactement ? Concernant Uber, c’est plus de 4 000 microservices stockant 35 millions de métriques chaque seconde pour un total de 9 milliards d’IDs de métriques uniques ; le tout stocké dans un modeste cluster M3DB de plus de 1 000 nœuds.

Quick peak at how @Uber is handling metrics from 4000+ microservices with @robskillingtonpresenting #M3 (https://t.co/Oy7RMFw1S8) – essentially @PrometheusIO that scales
1. Runs anywhere
2. Scalable to billions of metrics
3. Focus on simple operability#KubeCon #CloudNativeCon pic.twitter.com/dE7w9X70Bw

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

Bien sûr, dès lors que l’on parle de systèmes distribués, on retrouve les bénéfices de Kubernetes et des Operators : Uber fournis gracieusement un Operator M3DB pour le déployer en un clin d’œil.

Tout comme nous évoquions hier Kraken et sa compatibilité avec l’écosystème via l’exposition des mêmes APIs que n’importe quel registre d’images Docker, M3 est complètement compatible avec Prometheus ainsi qu’avec Graphite. On constate une nouvelle fois la volonté d’Uber de s’inscrire dans une certaine interopérabilité avec les interfaces déjà établies dans la communauté. Pour plus de détails techniques, voir l’article de blog dédié.

The Story of Why We Migrate to gRPC and How We Go About It – Matthias Grüter, Spotify

Prenons maintenant le cas de Spotify. Nous en parlions l’année dernière, Spotify est dans une démarche aussi saine qu’impressionnante. Spotify avaient déjà implémenté des solutions d’orchestration, de RPC, de monitoring, etc. avant que celles-ci émergent dans la communauté et gagnent en popularité. Ils ont néanmoins jugé que cet écosystème est désormais suffisamment mature pour qu’ils commencent à remplacer leurs solutions maison par ces implémentations open source et maintenues par la communauté.

Why and how @Spotify is moving to gRPC by @mattgruter – Really clicks with @dzolotusky and James Wen talk last year (https://t.co/EVxpwcKiR5) about moving to Cloud Native technologies
I’m really impressed by the path that @Spotify is following.#KubeCon #CloudNativeCon pic.twitter.com/uzREz12GIX

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

Lors de cette KCCNC, c’est le système de communication inter-application qui y passe. Leur protocole de communication/RPC existant s’appelle Hermès. Mais avoir une solution home made implique :

• qu’il faut former les nouveaux arrivants dans l’entreprise ;
• que cette solution n’est pas interopérable nativement avec quoi que ce soit ;
• que toutes les intégrations (par exemple avec les load balancer pour le cas de Hermès), bibliothèques de développement, etc. sont à construire ;
• qu’on ne peut compter que sur les personnes internes à l’entreprise pour faire évoluer cette solution ;
• …

L’objectif du changement n’est donc pas tant d’adopter gRPC, mais plutôt d’adopter quelque chose qui ne soit pas Hermès. Pourquoi Spotify s’est tourné vers gRPC ? Pour les protos, pour la résilience, le load balancing, le routing, et surtout, pour la mascotte. Je vous présente Pancake :

On retrouve donc chez Uber et Spotify deux chantiers allant dans des sens opposés : les uns redéveloppent leur propre solution pour palier le manque de scalabilité d’une solution communautaire, tandis que les autres abandonnent leur solution maison pour se tourner vers des projets de la CNCF. Mais un point commun les unit : dans les 2 cas, l’important est l’interopérabilité avec le reste de l’écosystème. La CNCF a réellement réussi à unifier un ensemble de projets cohérents et à promouvoir ceux qui sont devenus des standards de facto.

Transparent Chaos Testing with Envoy , Cilium and BPF – Thomas Graf, Isovalent

Le chaos testing/engineering, c’est quand le CTO d’une boite d’édition d’application en SaaS s’amuse à débrancher aléatoirement les prises de courant dans sa salle serveur de production pour voir comment se comporte la dite application. Cela peut paraître violent comme approche, elle a cependant l’intérêt de tester la résilience de l’intégralité d’une plateforme, du matériel aux applications. Le fait que ces incidents soient provoqués en production est un facteur clé dans l’intérêt d’un tel exercice, popularisé grâce au Chaos Monkey de Netflix. L’idée est bien sûr de se servir des découvertes faites à l’occasion de ces incidents maîtrisés pour améliorer la qualité d’une plateforme.

Mais débrancher des prises électriques, c’est possible lorsque vous avez la main sur votre infrastructure matérielle, chose de plus en plus rares de nos jours. Comment pouvons nous réaliser du chaos testing de manière tout aussi pertinente dès les couches basses de notre infrastructure, mais sans intervention physique ?

Thomas Graf nous propose ici une solution élégante. À l’heure où beaucoup de plateformes s’orientent vers des architectures micro-services, le réseau est un bon levier pour modifier voir interrompre la communication entre différentes briques. Voyons donc comment nous pouvons tirer profit des interconnexions modernes entre services afin d’injecter de la latence, renvoyer des erreurs aléatoires, et plein d’autres joyeusetés.

Les protagonistes sont les suivants :

• Envoy, reverse proxy moderne intégrant des fonctionnalités avancées de contrôle du trafic et du load-balancing
• Les extensions Go de Envoy, permettant de venir directement brancher son propre traitement (dans notre cas de l’injection d’erreurs) en Go dans Envoy
• eBPF, permettant de venir se brancher directement au niveau du traitement des paquets réseau par le noyau Linux
• Cilium, qui se base sur eBPF et sait piloter Envoy pour nous abstraire de fonctions avancées d’injection

Une fois tout ce petit monde rassemblé, le chemin d’une requête entre deux services devient le suivant :

Ainsi, on pourra très simplement configurer l’injection d’erreurs directement dans nos manifestes Kubernetes :

Le chaos engineering est donc à la portée de tous dès lors que l’on a à portée de main un cluster Kubernetes et quelques éléments indispensables et probablement déjà présents sur votre cluster.

Keep the Space Shuttle Flying: Writing Robust Operators – Illya Chekrygin, Upbound

Parmi les grandes tendances sur Kubernetes, nous avons l’écriture et l’utilisation d’opérateurs dont nous commencions à vous parler hier. Aujourd’hui, la phase d’adoption est passée et le sujet est bel et bien les best-practices autour des opérateurs et de Kubernetes plus généralement.

Illia Chekrygin travaille pour Upbound et est contributeur principal de Crossplane, un opérateur qui sait gérer une multitude de ressources externes. Il nous fait part de son expérience après un an et demi de contribution à cet outil.

Bref rappel : qu’est-ce qu’on opérateur ? Il s’agit d’une « application Kubernetes », à savoir la somme de deux concepts. Le premier est le contrôleur : un client Kubernetes qui écoute des changements sur des objets et réagit en fonction de ces changements, tel un webhook. Le second est celui de Custom Resources Definition (CRD). Une CRD permet d’étendre l’API Kubernetes en ajoutant la définition d’une nouvelle ressource.

Écrire un contrôleur n’est pas aisé, il existe des frameworks pour nous faciliter ce travail : entre autres Kubebuilder et Operator-SDK (qui s’appuient tous deux sur controller-runtime) mais également une implémentation de référence sample-controller avec client-go.

Le contrôleur se résume à la séquence suivante qui se répète indéfiniment :

1. Observer
2. Analyser
3. Agir

Fort de son utilisation de Kubebuilder, Illia nous présente les concepts suivants :

• Les conditions, qui représentent l’observabilité d’un objet Kubernetes : tracer son statut, etc. La mise à jour de ces conditions est de la responsabilité de l’opérateur.
• Le statut d’un objet : il sert à propager les informations de l’objet, et permettent le formatage de la sortie de kubectl (colonnes pour les listes affichées par kubectl get)

Mais les concepts sans la pratique ne permettent pas d’aller très loin ; il nous partage donc son expérience autour des patterns de réconciliation :

• Avertissements et conseils avisés sur la gestion de la concurrence.
• Gestion de la suppression des objets, différentes options et quelques cas d’usage
• Les pièges à éviter y compris des conseils sur les tests

Il ne reste plus qu’à explorer et contribuer à Crossplane. L’équipe est très favorable à l’investissement de la communauté sur ce projet.

Take Away

Nous avons choisi 3 talks à vous présenter dans cet article, mais cette journée a aussi été l’occasion d’assister à nombre de talks sur Rook. Il s’agit d’un… opérateur (surprise !) qui a pour vocation d’orchestrer des solutions de stockage distribué. Il implémente les backends Ceph (depuis le démarrage du projet), et plus récemment EdgeFS et Cassandra. Rook est ainsi une belle démonstration de ce qu’un opérateur Kubernetes peut réaliser et à quel point il peut prendre le pas sur des systèmes autrement complexes à gérer. C’est aussi un grand pas pour échapper au Vendor lock-in. En effet le backend Ceph est aujourd’hui stable et peut s’avérer une alternative suffisante à des services de stockage mode bloc, fichiers ou objet fourni par un Cloud provider.

Rook était donc la pierre angulaire de cette journée. Pour le reste, nous retenons les choses suivantes :

• Les projets de la CNCF ont tous leur rôle à jouer dans l’écosystème et s’emboîtent à merveille les uns avec les autres
• L’orientation vers toujours plus d’extensibilité, que ce soit au niveau du kernel Linux ou des APIs de Kubernetes, permet de construire progressivement des abstractions puissantes et néanmoins compréhensibles et interchangeables
• Envoy garde sa place comme reverse proxy / load balancer de choix dès lors que l’on souhaite une interactivité poussée – ce n’est pas pour rien qu’il est utilisé par Istio !
• eBPF et Cilium semblent avoir de beaux jours devant eux

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

A bientôt pour la troisième et dernière journée de cette KCCNC !