KubeCon + CloudNativeCon EU 2019 – Day 2

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 !

Opening Remarks – Bryan Liles, Senior Staff Engineer, VMware

Bryan Liles ouvre à nouveau la journée, avec cette fois-ci un message clair : Kubernetes est une plateforme pour construire des plateformes. Nous vous laissons méditer là dessus, on en reparlera prochainement.

How Spotify Accidentally Deleted All its Kube Clusters with No User Impact – David Xia, Infrastructure Engineer, Spotify

Lors de la KCCNC EU 2018, nous avions eu le plaisir de voir Oliver Beattie (Head of Engineering @ Monzo) nous présenter en keynote le post-mortem magistral d’un incident de production lié à Kubernetes et Linkerd. Un retour qui s’était avéré très instructif et avait fait preuve d’une ouverture exceptionnelle, tant sur la dimension organisation que humaine et technique.

Cette année, c’est David Xia de chez Spotify qui monte courageusement sur scène pour expliquer comment il a par erreur supprimé un cluster Kubernetes de production… à deux reprises.

La morale de l’histoire ? On vous renvoie au lightning talk de Hannah Foxwell : « failure is normal, reliability is fundamental ». Dans le cas de Spotify, ils avaient prévu le cas d’échec en ne migrant que partiellement leur stack vers Kubernetes à l’époque de l’incident. La partie en dehors du cluster a donc repris la main lors de l’incident.

Désormais, ils sont à même de remonter les clusters plus rapidement grâce aux enseignements de cet épisode, ont rajouté quelques garde-fous pour éviter que cela se reproduise par inadvertance, et ont d’ailleurs officialisé leur stack Kubernetes comme la plateforme de production suffisante chez Spotify.

Nous trouvons que nous avons de la chance d’être dans un écosystème et une communauté où l’on peut partager ses échecs afin que tout le monde bénéficie de leurs enseignements. Nous avions d’ailleurs apporté notre pierre à l’édifice des fails cet été avec deux récits « Summer of Fail ». Et vous, quels échecs avez vous à partager ?

 

What I Learned Running 10,000+ Kubernetes Clusters – Jason McGee, IBM Fellow, IBM

Enfin, nous ne pourrions conclure cette matinée sans une annonce, et c’est IBM qui s’en charge.

Bienvenue à Razee, un outil mentionné en coup de vent durant la keynote mais qui semble vouloir faciliter le continuous delivery de Deployments sur Kubernetes au travers d’abstraction de workflow multi-clusters et d’un dashboard de visualisation des Deployments et de leur historique. Qu’est ce que ça apporte par rapport à Spinnaker ? La question reste en suspend jusqu’à ce que nous testions Razee par nous-même !

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 :

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.

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é.

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 sont disponibles sur YouTube.

A bientôt pour la troisième et dernière 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.