DevOps Cloud

Il y a 3 ans -

Temps de lecture 17 minutes

KubeCon + CloudNativeCon EU 2020 – Day 1

Nous vous présentions hier le « Day 0 » de cette KubeCon + CloudNativeCon EU 2020, c’est donc désormais logiquement le tour du Day 1 !

Petite nouveauté cette année : l’événement n’étant pas en présentiel, les keynotes n’ont pas lieu le matin et en fin d’après-midi comme d’habitude, mais en plein milieu de l’après-midi ! De quoi garder notre attention pendant les 6h de conférences de l’après-midi  

Comme l’année dernière, nous vous proposons d’aller à 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-4 talks qui nous ont le plus marqués
  3. Partage de nos ressentis en fin de journée

Voici le sommaire correspondant :

  • Keynotes
    • Introduction – Priyanka Sharma, General Manager, Cloud Native Computing Foundation
    • CNCF Updates – Cheryl Hung, Director of Ecosystem, Cloud Native Computing Foundation
    • CNCF Projects Update – Constance Caramanolis, KubeCon + CloudNativeCon Europe 2020 Co-Chair & Principal Software Engineer, Splunk
    • Open Source Intrusion Detection for Containers at Shopify – Shane Lawrence, Senior Security Infrastructure Engineer, Shopify & Kris Nóva, Chief Open Source Advocate, Sysdig
    • The Beginner’s Guide to the CNCF TOC – Liz Rice, VP Open Source Engineering, Aqua Security
  • Talks
    • [Horgix] CloudEvents – v1.0 and Beyond – Discovery/Subscriptions – Doug Davis, IBM & Clemens Vasters, Microsoft
    • [Olivier] Intro: SIG Scalability – Wojciech Tyczynski & Matt Matejczyk, Google
    • [Rami] Deliver Your Cloud Native Application with Design Pattern as Code – Jun Makishi & Rintaro Sekino, NTT Communications
    • [Jonathan} Progressive Delivery in Kubernetes – Carlos Sanchez, Adobe & Viktor Farcic, CloudBees
  • Take Away

Keynotes

Introduction – Priyanka Sharma, General Manager, Cloud Native Computing Foundation

Cette année, Dan Kohn laisse la place à Priyanka Sharma pour l’ouverture du bal, qui nous présente la désormais traditionnelle introduction rappelant le rôle de la Cloud Native Computing Foundation dans l’écosystème, de comment la CNCF en est arrivée là, ainsi que des challenges à venir.

 

Elle a su trouver des mots justes et qui ont été droit à nos petits cœurs de développeur avec des messages tels que :

  • La CNCF est une fondation de “doers” – et en effet, la grande majorité des speakers de la conférence sont de réels acteurs de l’écosystème, d’une manière ou d’une autre
  • Les projets de la CNCF et son orientation de manière générale sont open-source et guidés par les utilisateurs finaux (“End-users driven open-source”)

Pour rappel, la CNCF en quelques chiffres à ce jour :

  • 50+ projets
  • 97 000 contributeurs de 177 pays
  • 1,3 Milliards de lignes de code
  • 550+ membres
  • 15 000 certifiés Kubernetes (CKA & CKAD) – dont 5 personnes de Publicis Sapient Engineering  

CNCF Updates – Cheryl Hung, Director of Ecosystem, Cloud Native Computing Foundation

Cheryl Hung prend la suite avec un message similaire : “End Users are more than Passive Consumers” et un rappel de l’existence du CNCF End User Technology Radar. L’idée est bien sûr d’insister sur le fait que les projets de la CNCF sont portés par des cas d’utilisation concrets, venant d’entreprises variées et avec une approche pragmatique. On retrouve ainsi des concurrents qui collaborent, des vendeurs/fournisseurs qui deviennent utilisateurs ou encore contributeurs.

On ne résistera bien sûr pas à quelques blagues malgré l’aspect virtuel de la conférence – qui serions nous si nous abandonnions les bons vieux trolls sur les éditeurs de textes et autres window managers  

CNCF Projects Update – Constance Caramanolis, KubeCon + CloudNativeCon Europe 2020 Co-Chair & Principal Software Engineer, Splunk

C’est ensuite au tour de Constance Caramanolis d’enchaîner avec les habituelles news des projets de la CNCF. Au menu en ce mardi 18 août :

  • ArgoCD, qui a ajouté des intégrations aux Argo Rollouts, et a profité d’une réécriture totale du serveur et de l’interface de la partie Workflows
  • SPIFFE/SPIRE, qui a été intégré dans Envoy et a amélioré l’interopérabilité et la fédération afin de pouvoir désormais gérer différentes plateformes en même temps
  • Contour, qui intègre désormais de la rotation automatique de certificats TLS et de l’authentification par certificat client
  • TiKV, ayant bénéficié d’une croissance conséquente sur tous les aspects : contributions, utilisateurs, fonctionnalités, …
  • Jaeger, qui a désormais 5 ans (et pourtant, le tracing distribué n’est malheureusement pas encore si répandu que ça…), et a subit d’importantes transitions pour désormais s’inscrire dans le standard que devient OpenTelemetry, comme nous vous en parlions il y a quelques semaines dans un de nos TechAway.

 

Bien sûr, la plupart des ces projets ont également évolué en terme de “maturité” au sein de la CNCF.

Open Source Intrusion Detection for Containers at Shopify – Shane Lawrence, Senior Security Infrastructure Engineer, Shopify & Kris Nóva, Chief Open Source Advocate, Sysdi

Les keynotes se poursuivent avec (enfin) un peu plus de technique : la célèbre Kris Nóva nous parle de Falco, un agent/runtime qui surveille les appels système dynamiquement, allant jusqu’à s’intégrer avec eBPF, afin d’être en mesure de déclencher des alertes en cas de comportement indésirable. Falco s’inscrit dans la même approche de la sécurité que beaucoup d’autres outils ces derniers temps : une approche autour de la définition de policies et de la détection de leur violation, grandement facilitée par la tendance à l’interopérabilité de tous les composants de l’écosystème Cloud Natif.

The Beginner’s Guide to the CNCF TOC – Liz Rice, VP Open Source Engineering, Aqua Security

Enfin, Liz Rice (que vous avez déjà pu voir à de multiples reprises au Paris Container Day !) clos ces keynotes en nous parlant du rôle du Technical Oversight Committee de la CNCF, chargé d’admettre (ou non) de nouveaux projets au sein de la CNCF ainsi que de superviser ceux-ci, s’assurant qu’ils tendent bel et bien vers les objectifs que tout projet de la CNCF doit idéalement atteindre, à savoir être :

  • Scalable
  • Dynamique
  • Résilient
  • Faiblement couplé
  • Gérable
  • Observable
  • Automatisé

Mais ce n’est pas tout, le TOC s’assure également que les projets soient d’un haut niveau de qualité et aient une grande vélocité/traction, ce qui est sans aucun doute la raison derrière la réputation positive de tous les projets de la CNCF. Tout ceci, bien sûr, de manière neutre et aussi ouverte que possible !

Talks

Tout au long de l’après-midi, nous nous sommes répartis les différents talks, pour environ 5 heures de présentations chacun. Vous l’imaginez bien, un résumé complet ici serait tout aussi titanesque à écrire qu’à lire.

Nous vous proposons donc ici chacun le talk qui nous a le plus marqué en ce début de conférence : 4 Sapients, 4 talks, let’s go !

[Horgix] CloudEvents – v1.0 and Beyond – Discovery/Subscriptions – Doug Davis, IBM & Clemens Vasters, Microsoft

Il y a 2 ans, à la KubeCon + CloudNativeCon EU 2018, CloudEvents était annoncé – nous vous le relations d’ailleurs sur ce même blog.

Depuis, CloudEvents a fait son petit bonhomme de chemin. Revenons-donc rapidement sur sa raison d’être et parlons des évolutions récentes et à venir évoquées lors de cette présentation de Doug David et Clemens Vasters.

Rappel – Qu’est-ce-que CloudEvents ?

Le constat initial est simple : nous avons de plus en plus de composants qui se notifient les uns les autres, à travers différentes applications, différents fournisseurs de cloud, pour travailler de manière de plus en plus réactive. Afin de s’assurer de pouvoir créer des outils standards, cross-plateformes et pérennes, Cloud Events se veut être le standard qui définira un format commun pour les métadonnées de tels événements.

CloudEvents définit donc des metadata communes pour des événements/messages, ainsi que la représentation de ces metadata dans les messages eux-mêmes, et ce peu importe le format du message/payload lui-même ou le vecteur de transport. Cela peut par exemple se manifester de la sorte pour du JSON transitant via HTTP :

Les nouveautés : Discovery & Subscriptions

Une fois ces éléments standardisés, il devient aisé de définir des spécifications d’API d’outils les manipulant. Par exemple, les questions suivantes sont fréquentes lorsque l’on travaille avec une approche événementielle à l’échelle de plusieurs équipes/applications :

  • Qui produit un événement qui nous intéresse ?
  • Quels événements sont produits ?
  • Comment peut-on souscrire à ces événements ?

CloudEvents définit donc également une spécification pour une Discovery API, permettant d’aller découvrir les événements mis à disposition par un service, leur format, ainsi que la manière de les consommer. Tout ceci étant bien sûr utilisable aussi bien humainement qu’automatiquement !

Mais ce n’est pas tout : CloudEvents veut aller plus loin en proposant une Subscription API qui serait implémentée par des Subscription Manager avec comme objectif de standardiser la manière de souscrire à des événements, facilitant encore une fois l’interopérabilité et la construction d’outillage commun.

La cerise sur le gâteau : CNCF Schema Registry

Enfin, une fois tous ces éléments définis, un élément clé reste à gérer : la validation du format des événements par rapport à un schéma donné.

L’idée est d’avoir un service, en l’occurrence une implémentation de la CNCF Schema Registry API, qui permettrait de faire de la validation à la demande de messages par rapport au format attendu/supposé, ainsi que de stocker les schémas (Protobuf, Avro, JSON Schema, peu importe) nécessaires.

Et le Kafka Schema Registy dans tout ça ?

Malgré le format virtuel, une part importante de cette conférence a pu être conservée : les échanges avec les speakers ! J’ai donc eu le loisir de pouvoir poser une de mes questions au speakers, en l’occurrence : “À quelle vitesse pensez-vous que les différents middleware vont s’intégrer avec les implémentations de cette Schema Registry API, au regard de l’existence déjà établie d’éléments comme le Kafka Schema Registry ?”

La réponse ne s’est pas faite attendre, et m’a rappelé un élément que j’avais complètement occulté de ma mémoire : le Schema Registry de Kafka (supportant Avro, et, depuis peu, Protobuf) ne fait pas partie intégrante du projet Apache Kafka, mais est développé indépendamment (bien que de manière open source) par Confluent. La CNCF Schema Registry API permettrait donc d’avoir une approche plus ouverte, communautaire et neutre du sujet, et des implémentations potentiellement plus variées.

En attendant la vidéo, vous pouvez retrouver les slides en ligne !

[Olivier] Intro: SIG Scalability – Wojciech Tyczynski & Matt Matejczyk, Google

Matt Matejczyk (Google) nous décrit le rôle du SIG Scalability (à ne pas confondre avec l’autoscaling !) et commence par une définition simple et parlante de la scalabilité : découvrir les limites de performance d’une application et travailler dans l’amélioration de ces limites.
Pour Kubernetes, il balaie l’idée reçue que la scalabilité d’un cluster est directement (et uniquement) liée au nombre de nœuds supportés et définit plus clairement ce qu’on entend par la scalabilité d’un cluster en termes de :

  • SLI : les indicateurs qui nous permettent d’évaluer la santé et la performance du cluster
  • SLO : les limites (objectifs) que l’on se fixe sur ces indicateurs.

Un cluster « scale » si tous les SLO sont satisfaits.

Ainsi, une forme de contrat existe entre l’utilisateur du cluster et le SIG Scalability :

  • l’utilisateur promet de rester dans un cadre d’utilisation raisonnable (en respectant des seuils limites du nombre de nœuds, de pods et de services décrite par « l’enveloppe de scalabilité »)
  • le SIG Scalability promet un comportement sain du cluster : cohérent et avec temps de réponse en dessous des SLO.

Comment tenir cette promesse ? En effectuant des tests de charge : certains à chaque PR, d’autres – plus gourmands – périodiquement. Certains tests sont bloquants pour les PR, dès lors qu’ils dégradent les performances ou la cohérence du comportement du cluster.

À l’instar de prow pour l’intégration continue, le SIG Scalability fournit deux outils faits maison pour la réalisation de ces tests :

  • ClusterLoader2 (CL2) qui effectue une série de tests décrits par un fichier YAML et fournit les résultats sous forme de métriques
  • Kubemark qui simule un cluster Kubernetes, chaque nœud étant simulé par un conteneur avec des parties non-essentielles fournies sous forme de mocks (Container runtime, Kube-proxy : peu significatifs quant à la performance du control plane), très utile pour réduire drastiquement les coûts générés par 10 heures de tests end-to-end sur un cluster de 5000 nœuds !

Ces tests sont inévitables pour garantir la scalabilité et l’absence de régressions dont l’origine peut être variée : n’importe quel élément du control plane mais également le système d’exploitation ou le langage Go ! Matt cite d’ailleurs quelques cas d’école de régressions qui ont pu être observés et traités par le SIG Scalability.

Enfin, le SIG Scalability ne veille pas seulement à l’absence de régressions mais aussi à l’amélioration des limites existantes. D’autres exemples viennent appuyer ces innovations.

Pour finir, Matt insiste également sur le support offert à la communauté Kubernetes car tout comme la sécurité, la scalabilité commence par la sensibilisation et un travail « main dans la main » avec les autres SIG. Le SIG Scalability est par ailleurs ouvert à toute personne désireuse d’en faire partie ou de s’informer.

Pour la série de questions réponses, Matt est rejoint par Wojciech Tyczynski (Google également) qui est le technical lead du SIG.

[Rami] Deliver Your Cloud Native Application with Design Pattern as Code – Jun Makishi & Rintaro Sekino, NTT Communications

Problème

L’utilisation de plusieurs outils (Terraform, Kubernetes, CloudFormation, …) peut rapidement introduire un couplage fort entre ces composants et surtout une certaine quantité de “boilerplate” pour les brancher ensemble.

L’utilisation de ce genre d’outils doit rester assez limitée pour éviter d’introduire une trop grande complexité et du code à maintenir.

Solution

Pour avoir de l’infrastructure-as-code réutilisable et modulaire et afin de garder une certaine cohérence entre la pipeline et la configuration, NTT communications a utilisé Cuelang qui permet de générer des templates réutilisables pour des manifests de plusieurs type (Kubernetes, CloudFormation, Ansible, Terraform …).

Ils ont aussi utilisé Tekton pour créer rapidement des pipelines CI/CD cloud natifs via la définition de TektonCD Pipelines.

Résultat

  • Les développeurs peuvent se concentrer uniquement sur le développement de l’application.
  • Une certaine cohérence et ré-utilisablité des manifests d’infrastructure et de leur pipeline de livraison

J’ai trouvé la solution pertinente et très utile pour éviter de dupliquer des manifests et réutiliser une configuration centralisée d’une manière propre.

La solution proposée peut aussi faciliter beaucoup la migration d’un cloud provider à un autre par exemple, il faut juste mettre à jour les templates/valeurs pour pointer le nouveau provider. Du point de vue application, cela reste complètement transparent.

[Jonathan] Progressive Delivery in Kubernetes – Carlos Sanchez, Adobe & Viktor Farcic, CloudBees

Lors de ce talk, Carlos Sanchez et Viktor Farcic nous ont présenté comment déployer progressivement son application sur Kubernetes grâce à Flagger, un outil créé par Weaveworks permettant de faire notamment du canary deployment basé sur des métriques Prometheus. Il introduit la CRD Canary :

apiVersion: flagger.app/v1beta1
kind: Canary

Avant de promouvoir la canary release en primary release, l’opérateur va progressivement augmenter le trafic vers la canary release (20%, 40%, 60% puis 100%) avant la promotion. En cas de détection d’anomalies dans la canary release (métriques Prometheus ou webhooks pour des KPIs personnalisées), l’opérateur sera capable d’annuler la promotion et de revenir en arrière pour garder la primary release telle quelle. Un système d’alerting est intégré à l’outil, permettant de notifier dans Slack lors des différentes étapes de la promotion.

Hormis le canary deployment présenté en démo, plusieurs stratégies sont disponibles pour le déploiement progressif de son application :

  • Canary Release
  • A/B Testing
  • Blue/Green

Flagger nécessite idéalement un Service Mesh comme Istio ou Linkerd pour fonctionner pleinement, sauf pour le blue/green deployment. Notons aussi que le canary deployment peut se faire simplement avec un Ingress Nginx :

Take Away

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

  • Notary v1 n’est définitivement pas satisfaisant, et la v2 se fait attendre avec impatience – elle se base sur une introspection et une remise en question aussi profonde que rare sur les problèmes existants dans Notary à ce jour
  • NATS évolue dans la bonne direction, mais se limite toujours à du at most once delivery si l’on ne le couple pas avec JetStream. On attend avec impatience l’intégration de JetStream dans NATS Core pour que le pattern commun de at least once delivery soit présent « out of the box ». Les notions avancées de topologie (leaf nodes, super clusters, etc) et de multi-tenancy font quant à elle rêver pour des cas d’usage autour de l’IoT !
  • L’outillage autour de la vérification de policies ne cesse de croître, eBPF prenant une place de plus en plus centrale
  • Backstage, en provenance directe de Spotify, rejoint la CNCF ! Cela fait un moment que nous voulions l’essayer avec certains clients – voilà qui va probablement nous faire sauter le pas !

Pour rappel, les vidéos de cette KubeCon + CloudNativeCon EU 2020 seront disponibles après la conférence sur YouTube.

Enfin, quelques liens que nous nous sommes partagés entre nous au fil de la journée, bruts de forme :

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

 

 

Published by , , et

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 Olivier Cloirec

Publié par Jonathan Norblin

Data Engineer & Software Craftsman

Publié par Rami Rekik

Commentaire

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Nous recrutons

Être un Sapient, 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.

REJOIGNEZ-NOUS