KubeconEU CNCF

Pause Cloud & DevOps – édition spéciale KubeCon / CloudNativeCon – Barcelone 2019

Jour 2

Vous n’êtes pas à Barcelone pour assister à KubeCon / CloudNativeCon, à votre grand regret ?

Pour cette édition, Objectif Libre s’est déplacé en force pour vous permettre de suivre le Summit comme si vous y étiez !

Au menu :

  • Keynotes
  • Transparent Chaos Testing with Envoy , Cilium and BPF – Thomas Graf, Isovalent 
  • Ready? A Deep Dive into Pod Readiness Gates for Service Health Management – Minhan Xia, Google & Ping Zou, Intuit
  • Zero Trust Service Mesh with Calico, SPIRE, and Envoy – Shaun Crampton, Tigera & Evan Gilman, Scytale
  • Resize Your Pods w/o Disruptions aka How to Have a Cake and Eat a Cake – Karol Gołąb & Beata Skiba, Google
  • M3 and Prometheus monitoring at planet scale for every one
  • Build a Kubernetes Based Cloud Native Storage Solution From Scratch Sheng Yang, Rancher Labs

Bonne lecture !


Keynotes

 

Ce deuxième jour commence également par un ensemble de keynotes présentées par Bryan Liles.

La première keynote est un retour d’expérience d’une suppression accidentelle d’un cluster Kubernetes présentée par David Xia de chez Spotify.

 

Spotify utilise des clusters GKE localisés sur 3 zones (Europe, Asie et USA). Le REX débute sur l’explication du contexte, la création d’un cluster GKE de test. Une fois les tests terminés, la suppression du cluster est effectuée. Malheureusement ils n’ont pas supprimé le cluster de test mais l’un des clusters de production d’environ 50 nœuds par mégarde et ce, à deux reprises. La restauration du cluster de production a pris 3h30. Mais pourquoi ?

  • La documentation n’était pas à jour et elle était incomplète
  • Il y avait des bugs dans les scripts de restauration : « Si vous ne testez pas la restauration c’est comme si vous n’avez pas de backup »
Afin de ne plus reproduire ce type d’incident et d’améliorer le mécanisme de restauration, Spotify a développé des procédures et a revu ses processus de déploiement :
  • Mise en place d’une politique de sauvegarde et de restauration avec ARK
  • Utilisation d’une approche infra-as-code avec Terraform
  • Mise en place de tests pour simuler des accidents

Aujourd’hui, ils sont capables de reconstruire leur cluster Kubernetes en 1h. Il ont pour volonté de migrer de plus en plus de leurs applications vers Kubernetes

Ensuite Bob Quillin d’Oracle est monté sur scène en évoquant un âge d’or pour les développeurs suivant :

  • L’essor de la culture DevOps
  • La communauté et tout particulièrement l’open source pour partager
  • Le cloud public et la facilité de déploiement qu’il a introduit

Tous ces changements culturels vont encore prendre du temps même si la transition semblerait bien avoir débuté. Il a ensuite étayé ses propos avec une vidéo présentant la collaboration entre le CERN & Oracle.

Katie Gamanji, Cloud Platform Engineer chez Condé Nast International (groupe de presse international avec Vogue, Vanity Fair, GQ, etc.) est ensuite entrée en scène pour présenter sa vision de l’utilisation de Kubernetes.

En quelques chiffres, Condé Nast c’est 62 sites web sur 11 marchés avec 300 millions de visiteurs uniques et 1,5 milliards de lecteurs.

Ils ont choisi d’utiliser Kubernetes pour faire évoluer l’approche technique du groupe. Kubernetes dans sa forme cloud public n’était pas disponible dans tous les pays où ils sont présents. Afin d’y remédier, ils ont donc décidé de déployer de façon unifiée des clusters de la distribution Tectonic de RedHat CoreOS.

En terme de stack technique ils utilisent :

  • CircleCI pour gérer les déploiements
  • Quay.io comme registry docker
  • Helm pour déployer les applications sur leurs clusters

Ensuite, Jason McGee d’IBM est monté sur seine pour parler de Kubernetes chez IBM.

Chez IBM, Kubernetes est la base de leur cloud public comme privé. IBM dispose d’une équipe de 25 SRE pour gérer plusieurs milliers de clusters.

Slack est au centre de l’utilisation de Kubernetes chez IBM. Les équipes d’IBM ont recours au concept de « Chat Bot » pour informer l’ensemble des équipes de toutes les actions : incidents, statuts, changements de configuration, etc.

Les clusters d’IBM fonctionnent en mode pull : chaque cluster récupère sa configuration depuis un point central.

Enfin Saas Ali, Software Engineer chez Google, nous a présenté la difficulté de la mise en œuvre du stockage avec Kubernetes en posant la problématique suivante :

« Est-ce qu’un cluster Kubernetes est le bon endroit pour gérer des applications stateful ? »

 

Découpons le problème :

 

Etape 1 : Il faut choisir le type de stockage en fonction de la disponibilité, du coût, de la performance et de la résilience pour répondre à nos besoins. Kubernetes supporte maintenant un large éventail des solutions de stockage que ce soit de type données, bloc ou fichier.

 

Etape 2 : Il faut déployer la solution en le faisant soit en interne soit en choisissant une solution managée.

 

Etape 3 : Il faut intégrer le stockage dans le cluster. Kubernetes propose de plus en plus d’outils avec la CSI (Container Storage Interface) et des opérateurs. Mais cela implique de gérer une application stateful en plus.

 

Etape 4 : Il ne reste plus qu’à l’utiliser. Kubernetes propose des solutions pour monter les volumes dans les conteneurs avec les PersistentVolume et les PersistentVolumeClaim.

 

En conclusion, le stockage reste fastidieux mais Kubernetes permet d’aborder la question plus facilement.

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

Thomas Graf, fondateur et CTO de la société Isovalent, présente le concept de test de chaos.

 

En introduction du talk, Thomas Graf réalise un sondage, la question étant :

 

« Dans l’assemblée, qui utilise le chaos testing ? »

 

Peu de personne ont levé la main. A contrario, quand il a demandé qui connaissait la notion de chaos testing, toute l’assemblé a levé la main. Car  tout le monde connait le concept qui a été popularisé par Netflix avec Chaos Monkey. Aujourd’hui, le test de chaos est devenu une condition au préalable lors d’une mise en production d’une application.

 

Pour résumer, le chaos testing c’est :
  • Une discipline d’expérimentation de panne sur un logiciel ou un système en production
  • La validation de la confiance dans un système en sa capacité à résister à des conditions de pannes inattendues.
Pour réaliser le chaos testing, Thomas Graf s’appuie sur les logiciels suivants :
  • Envoy : Service proxy, load balancing, sécurité (TLS), observabilité (métrique).
  • Envoy extension : Service  pour faire exécuter du code Go par Envoy
  • Cilium : Container Network Interface pour Kubernetes
  • eBPF : Outil pour intercepter les échanges dans le noyau Linux
Il réalise deux démonstrations dont les prérequis sur l’applicatif sont les suivants :
  • Possibilité de contrôler la communication entre les services : Man in the Middle
  • Possibilité de simuler une défaillance (réponse, délai, etc.)
  • Aspect de probabilité, panne dans 50% des tentatives
  • Le contrôle, éviter de redémarrer les services
  • Visibilité, l’échec était-il simulé ou réel ?
Ci-dessous les deux démonstrations réalisées :
    
1. Modifier le code de retour d’un service web :
  • Substituer  le code 200 OK par le code d’erreur 504 Application Error
  • Appliquer un pourcentage sur le nombre d’erreurs renvoyées (de 0 à 100%)
         
 2.  Modifier le temps de réponse d’une application :
  • Ajouter du délai dans la réponse du serveur (+ 2s) alors qu’il répond en 10 ms.
  • Appliquer un pourcentage sur la durée du délai renvoyé (80% des réponse en 20ms et 20% des réponse en 1s) 
La démonstration nous a permis de constater qu’avec la stack présentée durant ce talks, nous pouvons facilement mettre en place du chaos testing.

Ready? A Deep Dive into Pod Readiness Gates for Service Health Management – Minhan Xia, Google & Ping Zou, Intuit

Si vous utilisez Kubernetes v1.14, vous avez probablement remarqué que la commande kubectl get po -o wide affiche un nouveau champ readiness gate.

 

Minhan Xia, Software Engineer chez Google, et Ping Zou, Principal Software Engineer chez Intuit, nous présentent comment est utilisée la solution Foremast.

 

Jusqu’à la version 1.13, deux types de sondes, liveness et readiness, ont été utilisées pour vérifier l’état d’un pod et de ses conteneurs.

 

Mais il manque un indicateur pour savoir si un pod est prêt à recevoir du trafic. En effet, quand le pod est prêt, il faut créer le endpoint et mettre à jour le kube-proxy.

 

Cette information est essentielle lors des mises à jour des applications.

 

L’ajout des ReadinessGate dans la partie specs des pods permet d’ajouter des conditions qui devront être validées pour déclarer un pod comme prêt. 

 

L’outil Foremast est un gestionnaire d’état des applications dans un cluster Kubernetes. Il collecte des données de types métriques, logs et traces pour ensuite en déduire l’état des applications et lancer les actions appropriées. Dans cette chaîne, la sonde ReadinessGate garantit la validité de l’évaluation.

 

La démonstration présentait la mise à jour d’une application : Foremast suit l’état des deux versions de l’application déployée, il détecte l’échec du lancement de la nouvelle version et lance un rollback en conséquence.

 


Zero Trust Service Mesh with Calico, SPIRE, and Envoy – Shaun Crampton, Tigera & Evan Gilman, Scytale

La base dans un cluster c’est le zero trust, cette vision apporte un gain important de sécurité notamment en évitant la propagation d’une attaque.
Shaun Crampton et Evan Gilman présentent comment gérer le zero trust au niveau du réseau. Pour être efficace, il faut sécuriser l’unité la plus petite du cluster qui est le pod. Ainsi toute communication entre pods doit passer via un service Mesh offrant :
  • La découverte de service
  • Le load balancing

Il existe plusieurs implémentations, leur choix s’est porté sur Envoy, associé avec Spire/Spfiffe qui offrent en plus :

  • Une communication TLS
  • Une authentification
Le serveur Spire permet de centraliser les informations pour le chiffrement TLS et l’authentification, et Envoy utilise Spfiffe pour communiquer avec le serveur.
La dernière brique manquante de leur architecture porte sur la gestion des autorisations. Le plugin réseau choisi, Calico apporte la réponse avec son agent Felix, capable de traiter des Policies et d’interagir avec Envoy.

 


Resize Your Pods without Disruptions aka How to Have a Cake and Eat a Cake – Karol Gołąb & Beata Skiba, Google

 

Redimensionner les ressources de son pod en minimisant linterruption de service.

 

Aujourd’hui,  dans  Kubernetes, la limitation des ressources CPU et mémoire sont faites au travers du bloc spec de spécifications du conteneur. Or un principe de base de Kubernetes veut quun pod soit immutable. Pour changer ses spécificités, il doit être détruit et recréé avec donc une forte probabilité dinterruption de service. La limitation des ressources peut être vue comme un contrat entre le scheduler et le workload. La ressource est réservée si disponible mais ne peut pas dépasser lespace qui lui est assigné.

 

Mais tout change vite, les limites de dimensionnement aujourd’hui ne sont pas celles de demain : trafic, dimensions des base de données, cycle de vie des applications.. 

 

Or dans nos clusters Kubernetes, un pod qui consomme plus de ressources que les limites assignées, sera detruit, et qui ne s’est pas retrouvé dans ce cas ?

 

Une KEP (Kubernetes Enhancement Proposal) est en cours pour mettre en place en mécanisme de vertical pod autoscaling mais celle-ci entraîne un changement radical dans la philosophie Kubernetes. Le pod doit perdre sa propriété d’objet immutable !

 

Ce changement impacte le scheduler, kubelet et les quotas via le contrôleur d’admission avec l’ajout d’une politique de pod resizing ainsi que la gestion des ressources souhaitées, allouées et nécessaires.

 

Cette KEP n’est pas encore validée et ne sera pas pour la prochaine version de Kubernetes, à suivre donc.

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

Prometheus est une Time Series Database (TSDB) créée début 2014 par SoundCloud. Prometheus se présente comme une solution de monitoring mono-nœud. Elle ne gère pas le stockage des métriques de manière distribuée.

 

Pourquoi M3 ?

 

M3 est une TSDB distribuée qui a été créée début 2015 par Uber, le but de M3 est de pouvoir scale de manière horizontale leur monitoring.

 

Pourquoi utiliser M3 avec Prometheus :
  • Sauvegarder des métriques pendant des semaines, des mois voir des années
  • Gérer différents types de rétention
  • Pouvoir faire un scale-up uniquement en ajoutant un noeud

 

Rob nous montre ensuite plusieurs type d’intégration entre Prometheus et M3 :
  • Prometheus utilise M3 pour lire et écrire ses métriques et sert de Datasource à Grafana (pour la visualisation des dashboards)
  • Un second schéma très similaire, à la différence que le Datasource de Grafana est directement M3
  • Un dernier schéma où un composant M3 Query est utilisé en lecture seule par Grafana pour limiter l’impact sur l’écriture des métriques dans M3.

 

Dans un second temps Rob parle du déploiement Multi-Région de M3 en mettant en avant les points suivants :
  • Une collecte globale des métriques et des requêtes
  • Aucun trafic entre les différentes régions
  • Une réplication uniquement entre les zones de disponibilité dès que la mètriques est collectée

 

En terme de performance, Rob met en avant les chiffres de l’infrastructure d’Uber. Il utilise M3 pour plusieurs types de métriques :
  • Le monitoring temps-réel des applications
  • Le suivi de métriques métier (par exemple le nombre de course Uber à Berlin)
  • La surveillance du réseau et de la température des périphériques dans un datacenter 
  • Et beaucoup d’autres
Quelques chiffres :
  • Plus de 4 000 microservices lancés
  • 35 000 métriques par seconde
  • 700 00 métriques agrégées par seconde
  • Plus de 1 000 instances exécutant M3
  • 9 milliards de métriques collectées

Build a Kubernetes Based Cloud Native Storage Solution From Scratch – Sheng Yang, Rancher Labs

Le projet Longhorn est un système de stockage bloc distribué créé par Rancher Labs, entièrement open source, from scratch, pour Kubernetes.

 

La première motivation des développeurs est de s’affranchir des systèmes actuels, certes très répandus, mais écrits il y a plus de 10 ans comme Ceph. Selon eux, sur des infrastructures récentes basées sur des disques SSD ou M.2, les systèmes de stockage bloc distribués ne profiteraient pas entièrement des performances possibles. De plus, les développeurs préfèrent utiliser des librairies Kubernetes. L’opportunité est donc double ici, utiliser des librairies déjà conçues pour Kubernetes, récentes et bien écrites tout en profitant d’une communauté de contributeurs déjà très importante et très active.            

 

En plus de fournir un système à la pointe, Longhorn embarque une GUI où il est possible d’y effectuer toutes les actions de déploiement, de management mais aussi de supervision.

 

Un exemple de fonctionnalité développée se basant sur des librairies Kubernetes est le processus de self healing. Lors du déploiement, l’administrateur peut choisir le nombre de réplicats pour chaque volume. Le processus de self healing permet de créer un nouveau réplicat automatiquement, si jamais l’un d’eux n’est plus accessible par le cluster. Cette fonctionnalitée se base directement sur le concept de controller de Kubernetes, une tâche de fond dont la fonction est de faire tendre l’état actuel du cluster vers l’état attendu.

 

L’installation du système est très simple. Il suffit de lancer la commande suivante :

 

 

Le fichier manifeste ci-dessus contient la totalité des objets Kubernetes à crééer, pour avoir un système Longhorn prêt à l’emploi.

 

À travers la GUI de management de Rancher, le speaker procède à une démonstration et commence par déployer le système Longhorn, avec une version de retard sur la dernière disponible. Le but est ensuite de mettre à jour le produit et de constater s’il y a des effets de bord. Une fois installé, il déploit une application WordPress avec une base de données et commence à créer des articles. De la donnée est donc écrite sur le volume et le speaker retourne alors dans la GUI de Longhorn et montre que le statut des différents réplicats se met à jour en temps réel.

 

Ensuite, le speaker lance une mise à jour du produit (proposée par la GUI) et continue de créer des articles pendant ce temps.

 

La mise à jour est totalement transparente, les applications sont toujours utilisables et aucune donnée n’a été perdue dans le processus.                                                                                      

 

Le projet Longhorn est très prometteur, bien qu’en version beta, il offre déjà des performances similaires à Ceph sur des disques SSD et des fonctionnalités évoluées.                                    
Seulement, le positionnement du produit sur le marché peut créér des réticences à l’emploi. En plus de se vouloir distribué, le produit vise à offrir des fonctionnalités inter-clusters et inter-clouds.

 

Ceci est malheureusement déjà couvert par Rook, l’orchestrateur de stockage officiel de Kubernetes. Longhorn ne tend donc pas à être intégré comme un backend disponible sur Rook.