Deuxième jour de la KubeCon 2022, voici notre sélection de talks !

Par @vixsty, @eisenkremer, @aimbot31, @psclgllt, @launoirt

Keynotes

Kubernetes Project Updates - Jasmine James, Senior Engineering Manager-Developer Experience; Ricardo Rocha, Computing Engineer, CERN; Emily Fox, Security Engineer, Apple

La keynote de ce second jour de KubeCon débute avec une présentation des nouveautés de Kubernetes 1.24. Nous vous avons détaillé ces nouveautés dans un article complet ici

Conférences

Case Study: Bringing Chaos Engineering to the Cloud Native Developers - Uma Mukkara, ChaosNative & Ramiro Berrelleza, Okteto

Après une petite introduction au bien fait du chaos engineering dans un monde de micro services et de pratique DevOps en constante évolution:

S'ensuit une démo nous expliquant pourquoi et comment rendre ça accessible dès le développement.

La démo s'appuie sur 2 outils, Litmus Chaos qui est une plateforme open source de "Chaos Engineering" et Okteto qui est un outil permettant de créer rapidement un nouvel environnement pré-configuré.

L'ensemble permettant de réaliser des workflows de chaos testing dès la phase de développement et de pouvoir corriger directement les problèmes identifiés durant les tests.

The Soul of a New Command: Adding ‘Events’ to kubectl - Bryan Boreham, Grafana Labs

Bryan Boreham nous explique ici les limitations de la commande kubectl get events avec les issues remontées par la communauté:

kubectl get events doesn't sort events by last seen time kubernetes#29838 opened 1 Aug 2016

Improve watch behavior for events kubernetes#65646, kubectl#793

Improve events printing kubectl#704, kubectl#151

kubectl get events should give a timeline of events kubernetes#36304 

Pour palier à ça, Bryan ouvre une PR avec la création d’une nouvelle API ainsi que la commande kubectl events correspondante.

Une explication du process de validation des demandes de nouvelles fonctionnalités Kubernetes Enhancement Process (ou KEP) nous est alors détaillé:

Le KEP-1440 est alors ouvert pour demander l’ajout de l’api events et sera implémenté le 29 octobre 2021 et intégré à la version alpha 1.23 de Kubernetes.

La nouvelle commande kubectl events couvre tous les problèmes remontés par la communauté, notamment le tri des événements dans l’ordre chronologique.

Implementing Cert-Manager in K8s

Jose Manuel Ortega nous a présenté comment mettre en place cert manager dans un cluster k8s afin d'automatiser la génération de certificats pour les services avec Let's encrypt ou Hashicorp Vault.

Il nous a également présenté les autres fonctionnalités de Cert-manager comme la vérification de validité de certificats sur les différents environnements.

Better Reliability Through Observability and Experimentation - Julie Gunderson, Gremlin & Kerim Satirli, HashiCorp

Kerim Satirli, Sr. Developer Advocate, HashiCorp
Julie Gunderson, Sr. Reliability Advocate, Gremlin

Disclaimer: Si vous vous attendez à une conférence très technique, n’allez pas plus loin.

Dans cette conférence, Julie et Kerim vont essayer de démystifier l’observabilité dans nos systèmes informatiques. Cette dernière, comme dit plus haut, ne traitera pas le sujet de façon technique mais viendra vous aider à porter une réflexion sur certaines pratiques, notamment le Chaos Engineering.

Pour aborder ce point nous nous mettons dans un cas d’usage non technique; vous êtes le pilote d’un avion et vous perdez la connexion avec la tour de contrôle.
Que va-t-il se passer? Quel problème êtes vous en train de rencontrer?...

Tout d’abord, les piliers de l’observabilité :

Les logs:
si vous n’avez pas de log; vous ne pouvez pas investiguer
Les traces
si vous n’avez pas de trace, vous ne pouvez pas debugger
Les mesures
si vous n’avez pas de mesures, vous ne pouvez pas comprendre

Le but principal de l’observabilité est de réduire le temps de détection d’une erreur et si possible de la détecter avant le client.

Les techniques de Chaos Engineering permettent de valoriser ces piliers mais attention à bien avoir des backups et qu’ils soient fonctionnels; sinon ne faites pas ça !

Il peut être simple de faire des tests afin de trouver un point de rupture de votre application ou de votre architecture de façon relativement simple. Ci dessous quelques exemples de simulation que vous pouvez effectuer:

Engendrer de la latence
Créer volontairement des erreurs
Créer un goulet d'étranglement sur le réseau
Saturer et stresser l’application ou l’architecture

Tout cela permet de valider le point de rupture de votre application / architecture et de vous démontrer, si cela se présente, comment elle réagit à ce genre de problématique.

En conclusion, pour effectuer ces tests il existe plusieurs technologies et toutes ont leur intérêt mais assurez-vous de bien comprendre leurs fonctionnements et leurs retours. Enfin documentez tout ce que vous pouvez afin de réduire le temps de résolution.