KubeconEU CNCF

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

Jour 3 – dernier jour !

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
  • Grafana Loki: Like Prometheus, but for logs.
  • Testing your K8s apps with KIND
  • Scaling Edge Operations at Onefootball with Ambassador: From 0 to 6000 rps
  • You Might Just be a Functional Programmer Now
  • Helm 3 : Navigating to distant shores

Bonne lecture !


Keynotes

Dernier jour et dernières keynotes présentées par Janet Kuo, Software Engineer, Google
La première keynote commence par un message fort : Don’t Stop Believin’ par Bryan Liles, Senior Staff Engineer, VMware.
Kubernetes vient de fêter ses 5 ans, la question qui se pose est la suivante : les extensions du projet et de son écosystème sont-elles finies ?
Bien sûr que non ! Durant ce talk, le speaker revient sur l’historique de Kubernetes et évoque de nouvelles possibilités d’évolution à venir.

Pour ne citer qu’une partie, Kubernetes est un projet Open Source maintenant présent sous plusieurs distributions : Hyperkube, Minikube, K3s, OpenShift, etc.
Plusieurs communautés se sont formées autour de chaque produit.

Selon Bryan Liles, Kubernetes est voué a être déployé sur de plus en plus de plateformes (x86, ARM, embarqué, etc.) et il transforme l’expérience développeur.
Kubernetes devient aujourd’hui une vraie plateforme, permettant aux développeurs de s’abstraire du système sous-jacent.

Enfin, le speaker explique que le management des configurations progresse avec notamment la création de projets dédiés, et également avec des communautés qui s’organisent de mieux en mieux, créant toujours plus de synergie autour de nouveaux concepts comme les services Mesh par exemple.

 

Laura Rehorst, PO à ABN AMRO BANK et Mike Ryan, DevOps consultant à backtothelab.io opèrent la transformation pour passer un applicatif en COBOL à Kubernetes.

La banque comporte plus de 3000 applications en production avec une majorité de legacy. Passer aux conteneurs leur apporterait un gain de vitesse de développement et de livraison, plus de flexibilité, un environnement de déploiement unifié ainsi qu’une réduction des coûts.
Mais quelle distribution Kubernetes choisir ? Il faut procéder en fonction des besoins. Dans ce cas précis, un usage guidé, des fonctionnalités prêtes à l’emploi et une manière uniforme de travailler étaient requis.
De plus, la banque souhaite garder une cohérence entre les composants logiciels. Pour ce faire, des modèles et squelettes seront fournis, ainsi que des pipelines et des plateformes. Ces apports auront également pour effet d’accélérer les développements des différentes équipes.

En croisant tous ces besoins, la banque a réussi à créer un tableau représentatif de tous les logiciels et fonctionnalités cloud nécessaires pour atteindre leurs objectifs.
Quelques éléments de leur stack : Clouds AWS et Azure pour l’infra, Terraform pour le provisionning, Docker pour le runtime, Kubernetes pour l’orchestration ainsi que Helm, CloudBees et Jenkins pour l’applicatif. Niveau sécurité, Vault et Open Policy Agent seront utilisés.

 

Tom Wilkie, Grafana Labs et Frederic Brancyk RedHat ont présenté le futur de l’observabilité.

Pour ce talk, les deux speakers annoncent trois prédictions. Ils présentent ensuite les trois piliers : les métriques, les logs, et les traces.

1ère prédiction: davantage de corrélations entre les trois piliers.
Selon les speakers, surveiller les métriques (et leurs graphes) permet de se rendre compte d’une anomalie. La suite logique est d’aller lire les logs pour comprendre d’où vient l’erreur, et de remonter aux traces pour fixer le problème.
De plus, la lecture des traces aide à comprendre un affichage inattendu sur un graphe.

2ème prédiction : de nouveaux signaux et de nouvelles analyses.
Les speakers affichent à l’écran un graphe sur l’utilisation mémoire d’un node. Ils montrent un arrêt net de la consommation de la mémoire.
Les speakers expliquent qu’il s’agit ici d’un event OOM Killer qui s’est produit, tuant probablement le container runtime, ce qui a pour effet de tuer tous les conteneurs.
L’effet boule de neige arrive alors, une ou plusieurs applications consomment trop de mémoire, l’OOM Killer passe et rend tous les pods du node indisponibles. Kubernetes replace alors les pods sur d’autres machines et engendre une surconsommation de la mémoire.
Pour palier ce problème, un projet initié par Google est présenté : Google Wide Profiling. Cet outil permet d’obtenir, à l’échelle du datacenter, les performances des applications.
Grâce à ce produit, il est donc plus facile d’observer le comportement des applications quant à la consommation des ressources et ainsi d’anticiper les futurs problèmes en patchant l’applicatif ou en changeant les limites d’accès aux ressources pour chaque pod.

3ème prédiction:  l’avènement des outils d’agrégation de logs sans index.
Selon les speakers, des produits comme Grafana Loki prendront rapidement de l’ampleur pour ce genre d’infrastructure.
La présentation de Grafana Loki fera ensuite l’objet d’un talk à part – lire l’article ci-dessous !


Grafana Loki: Like Prometheus, but for logs.

Tom Wilkie, VP Product, Grafana Labs présente Grafana Loki.

Loki est un système d’agrégation de logs multi-tenants, scalable et en haute disponibilité.
Tom Wilkie est un des principaux développeurs du projet et également un des mainteneurs de Prometheus. C’est pourquoi le projet s’inspire tant de son architecture logicielle.

Le projet a été initié en 2018 et lancé en décembre dernier lors de la KubeCon US.

Selon Tom, Loki est :

  • Simple et peu coûteux à opérer et à mettre en place
  • S’intègre avec les outils d’observation existants
  • Est cloud-natif et offre un mode hors ligne à l’aide d’un cache.

L’un des éléments forts de l’architecture du produit est que Loki n’indexe pas le texte des logs mais crée des objets files indexés avec des labels, où sont placés les logs.

Les nouvelles fonctionnalités du projet sont nombreuses. Parmi elles :

  • La possibilité de chaîner les filtres du langage associé LogQL avec des pipes
  • L’extraction des labels des logs
  • Le suivi en direct des logs avec du contexte

Enfin, de futurs développements sont prévus tels que :

  • L’ajout d’alertes
  • La possibilité de retirer la dépendance vers une base NoSQL

La première version bêta sort maintenant !


Testing your K8s apps with KIND

Benjamin Elder, Software Engineer, Google & James Munnelly, Solutions Engineer, Jetstack.io nous explique comment tester des applications Kubernetes.

Pendant cette présentation Benjamin et James partent du constat qu’une des promesses de Docker était d’être capable de jouer ses tests applicatifs en mimant l’environnement de production, cela reste un challenge avec Kubernetes. Actuellement, pour tester ses applications, il existe plusieurs options :

  • Utiliser un serveur externe
  • Déployer un cluster pour chaque test (sur GKE par exemple)
  • Jouer les tests sans Kubernetes

Pour répondre à la problématique une 4ème solution est arrivée, KinD Kubernetes in Docker, qui répond aux critères suivants :

  • Rapide et léger,
  • Cross-Platform, les seuls prérequis sont Go et Docker

KinD permet donc de facilement déployer un cluster Kubernetes pour y tester son application. La logique de test proposée est la suivante :

  1. Démarrer un cluster via KinD
  2. Si nécessaire, compiler son application
  3. Construire une image contenant son application
  4. Démarrer l’application sur Kubernetes
  5. Jouer les tests
  6. Supprimer le cluster

Depuis nos derniers tests de KinD chez Objectif Libre, la solution a beaucoup évolué. KinD propose maintenant de démarrer un cluster complet avec plusieurs nœuds. Le cluster ainsi déployé peut être facilement personnalisé. KinD s’appuie sur une configuration Kubeadm standard.

Ensuite une démo est lancée, un simple script bash permet d’appliquer l’ensemble de la logique évoquée plus haut.

Une fois la démonstration déroulée avec succès, Benjamin & James chacun leur tour recommandent de ne pas utiliser bash pour les test. Transition toute trouvée pour introduire un lien pointant vers un projet github contenant des exemples d’utilisation de KinD avec Circle CI et Travis-CI.n

Pour finir, il a été mis en avant que KinD pouvait être utilisé comme une bibliothèque de développement et de redire une dernière fois « No more bash ».

La présentation s’est conclue sur la roadmap de KinD :

  • Meilleure gestion du réseau (CNI),
  • Support IPv6 (test inclus) qui a été fait,
  • Accès aux services de type NodePort sur MacOS & Windows,
  • Build d’images docker (node & worker) depuis la CI de Kubernetes ou depuis les .tar.gz,
  • Optimisations,
  • Passer le projet en phase Beta

Scaling Edge Operations at Onefootball with Ambassador: From 0 to 6000 rps

Rodrigo Del Monte, Ingénieur DevOps chez Onefootball, et Jonathan Juares Beber SRE chez Onefootball, présentent leur retour d’expérience pour la mise à l’échelle de leur plateforme.

Onefootball est une société de médias comptant plus de 10 millions d’utilisateurs actifs par mois et diffusant plus de 10 To de contenu quotidien.

Leur plateforme est basée sur les éléments suivants :

  • Un cluster Kubernetes sur EC2 d’Amazon (+ de 350 instances)
  • Plus de 50 microservices
  • Un environnement en mode cloud natif avec Helm, Prometheus et Grafana

Onefootball avait besoin d’une passerelle API et d’une solution d’Ingress pour Kubernetes, capable de gérer une forte charge de trafic de manière fiable et efficace.

Ils ont choisi Ambassador comme passerelle API couplée à la solution de service mesh Envoy.

Ambassador leur a permis :

  • d’avoir un seul point d’entrée et de configuration
  • de réaliser une réduction des coûts avec un passage de 100 à 4 load balancers basés sur le cloud
  • de bénéficier d’une meilleur surveillance, la combinaison d’Ambassador et Envoy permet à Prometheus de fournir un maximum de métriques (requêtes, erreurs et délais)
  • de faciliter la maintenance, ils ont découplé les paramètres de cluster et le processus de livraison des applications, permettant ainsi une plus grande rapidité lors de la livraison de nouvelles fonctionnalités.

You Might Just be a Functional Programmer Now

Cornelia Davis, Vice President, Technology, Pivotal s’interroge sur comment la programmation fonctionnelle a pris le pas sur la programmation impérative.

Voici un petit historique de cette évolution.
Il y a 30 ans, on utilisait des systèmes monolithiques : 1 machine = 1 CPU. Le langage de prédilection était l’assembleur. Sont apparus les multi processeurs, le langage C, vite suivis par les systèmes multi-threading et Java.
Maintenant on ne parle plus que principalement de microservices et de langages comme Scala ou Kotlin.

Avant de parler de la mise en œuvre des microservices, quelle différence entre la programmation impérative et la programmation fonctionnelle ?

Programmation impérative :
Déroulement séquentiel des opérations avec des possibilités de boucles, on contrôle chaque étape du processus. Une erreur interrompt la chaîne de traitement sans retour possible. Il faut relancer le processus pour obtenir le résultat.
Il est difficile de paralléliser les tâches d’un algorithme écrit en langage impératif.

Programmation fonctionnelle:
Les besoins sont décrits de manière déclaratives, les boucles sont remplacées par de la récursivité, avec des facilités à paralléliser les tâches. Le résultat du processus peut être démontré de manière mathématique (notion de preuve) grâce à l’immutabilité des tâches qui sont répétables à volonté.

Muni de ces définitions pour instancier les micro-services des infrastructures modernes, on distinguera ceux qui utilisent des solutions et mécanismes impératifs (ansible, chef, salt, puppet, script bash) et ceux qui utilisent des solutions fonctionnelles (cloud foundry, BOSH, Kubernetes).

On oppose alors les déploiements scriptés aux déploiements déclaratifs. Tout comme on opposera : l’utilisation de VM (long running processus) à l’utilisation de conteneurs éphémères, comme de middleware versus sidecars.

Avec un mécanisme fonctionnel, toute l’intelligence est rapportée dans la boucle de contrôle dont le but est de faire converger le résultat vers la demande déclarative du client et donc de son besoin.
C’est tout le paradigme de la programmation fonctionnelle.

https://kccnceu19.sched.com/event/MPXT/you-might-just-be-a-functional-programmer-now-cornelia-davis-pivotal


Helm 3: Navigating To Distant Shores

Bridget Kromhout, Principal Cloud Advocate, Microsoft & Jessica Deen, Senior Cloud Advocate Microsoft nous font naviguer vers des rivages lointains avec Helm, belle perspective en cette fin de Kubecon.

Ce duo présente la nouvelle version majeure 3-alpha1 de Helm. Elle est construite à partir du retour des utilisateurs et vise à améliorer et à enrichir l’outil en restant « Simpler to use, more secure to operate ».

L’histoire commence avec les conteneurs qui promettaient de résoudre les problèmes de « consistent installation and repeated deployment« . Mais certains problèmes persistent et d’autres apparaissent comme notamment la nécessité d’orchestrer ces conteneurs. Alors arrive Kubernetes suivi de Helm. Ce dernier permet de trouver, partager et utiliser les applications construites pour le premier.

Helm offre les fonctionnalités pour :

  • Gérer la complexité des applications avec les charts en devenant le seul point d’entrée
  • Faciliter les mises à jour via des hook personnalisés
  • Simplifier le rollback des applications

Cette nouvelle version prend en compte et s’inspire :

  • Des bonnes pratiques de la communauté
  • D’un besoin de simplifier l’utilisation
  • D’un changement architectural pour améliorer la sécurité

Ainsi la version 3 n’est pas compatible avec la version 2, le processus de migration entre versions est en cours d’écriture.

Les nouveautés intégrées ou en cours pour cette version sont :

  • La suppression de Tiller car présente une faiblesse dans la sécurité. C’est LA bonne nouvelle attendue par beaucoup
  • Le recours au contrôle de sécurité avec kubeconfig, Helm sera maintenant soumis au limite des RBAC
  • L’utilisation du namespace courant. Helm est maintenant ‘namespaced’ pour la gestion des déploiements. A chaque release un nouvel objet et un nouveau secret Kubernetes sont créés pour suivre les déploiements successifs et faciliter les rollbacks
  • La gestion des dépendances est désormais incluse dans le fichier Chart.yaml
  • Le support des OCI repository docker avec une commande dédiée
  • L’introduction de fonctions dans les charts pour définir des éléments réutilisables
  • Le refactoring des fichiers values.yaml en Lua

Helm3 : https://helm.sh/blog/helm-3-preview-pt1/

Helm3-demo: https://github.com/jldeen/helm3-demo