KubeconEU CNCF

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

Jour 1

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
  • Kubernetes Failure Stories
  • CoreDNS
  • Back to basics : Hands-On Deployment of Stateful Workloads on Kubernetes
  • Kubernetes + encrypted memory
  • Tutorial: Building Security into Kubernetes Deployment Pipelines
  • Building Images Efficiently and Securely on Kubernetes with BuildKit

Bonne lecture !


Keynotes

 

Keynote d’ouverture – matin

Après une journée de WorkShop et la session de Lightening talks, la KubeCon/CloudNativeCon EU 2019 est lancée. C’est parti !

Dan Kohn, Executive Director de la Cloud Native Computing Foundation, introduit cette keynote en commençant par nous parler de la version 1 de la Cloud Native Definition.

Il fait une amusante comparaison avec le jeu Civilization V, avant de rappeler différentes inventions marquantes de l’histoire pour enfin aborder l’état de Kubernetes aujourd’hui et le programme des trois prochains jours.

Cheryl Hung met ensuite en avant quelques chiffres :

  • Le nombre d’entreprises membres de la CNCF progresse de manière exponentielle : +400 membres
  • 88 communautés d’utilisateurs
  • 2,66 millions de contributions
  • 56 214 contributeurs

Différents intervenants se succèdent sur l’immense scène pour parler des projets de la CNCF :

  • OpenEBS
  • Linkerd
  • Helm
  • Harbor
  • Rook
  • CRI-O
  • OpenCensus & OpenTracing
  • Fluentd

Nous retiendrons de cette partie la fusion des projets OpenCensus & OpenTracing en un seul et même projet OpenTelemetry.

Pour terminer la session de keynotes du matin, Vijoy Pandey VP/CTO Cloud de Cisco, évoque l’évolution du réseau vers plus de simplicité en introduisant la notion de Network Service Mesh. Puis Lucas Käldström et Nikhita Raghunath clôturent sur la communauté CNCF et les valeurs qui la composent.

 

Keynote de clôture – Soir

Après une première journée riche en sessions et en échanges, une session de keynotes dédiée aux annonces de nouveautés achève la journée.

La création de SMI (Service Mesh Interface) vise à simplifier l’utilisation des services mesh pour traiter les policy, les métriques et les logs. Le modèle est celui utilisé avec Ingress.

Cheryl Hung déroule le parcours de Kubernetes, depuis les débuts avec le projet Borg en 2003 jusqu’à sa reconnaissance comme standard des orchestrateurs. Elle termine par la présentation des objectifs, selon trois axes :

  • l’extensibilité
  • la fiabilité
  • la scalabilité

Ensuite Joe Beda présente l‘approche récursive de Kubernetes : comment gérer un cluster Kubernetes grâce aux nouvelles ressources mises à disposition : Cluster, Machine, MachineSet et MachineDeploy.

Toujours au chapitre des nouveautés, Rob Szumski dresse un portrait des opérateurs et des fonctionnalités associées. Le dépôt operatorhub.io met à disposition les outils déjà créés par la communauté.

Pour souffler, un exemple d’utilisation est donné par le CNES qui présente l’infrastructure mise en place pour traiter les données permettant de valider l’existence du bozon de Higgs et, au final, l’obtention d’un prix Nobel de physique. Une infrastructure devant stocker 70 To de données générées dans un court laps de temps, traitées par quelques 25 000 jobs Kubernetes. Comme tout bon scientifique, une démo est effectuée en live pour reproduire les résultats : impressionnant et très motivant !

 


Kubernetes Failure Stories

Pendant cette présentation, Henning Jacobs (Head of Developer Productivity) fait un retour d’expérience sur les problèmes que Zalando rencontrés en production avec Kubernetes.
La présentation commence par une touche d’humour : « Nous vendons des chaussettes, mais pas que ». Pour rappel, Zalando est un site e-commerce qui commercialise des articles de prêt-à-porter et des chaussures et qui compte plus de 250 millions de visiteurs par mois.
Les serveurs Kubernetes sont hébergés sur des VMs EC2 chez AWS, avec 380 comptes AWS et 118 clusters Kubernetes déployés.
Le retour d’expérience porte sur 8 incidents rencontrés en production :
  1. Un incident qui impacte tous les utilisateurs. Le problème identifié par les équipes montre un nombre important d’erreurs de type 500 au niveau des Ingress. L’analyse a permis d’identifier que skipper (service utilisé chez Zalando comme reverse-proxy/ingress) en était la cause. Skipper consommait une quantité trop importante de mémoire. Le service OOMkiller a fait son travail et a tué le processus skipper.
  2. La perte de l’API serveur a engendré une indisponibilité de l’ensemble des IngressAfin de ne plus reproduire ce problème, Zalando a conclu que l’Ingress devait rester en état de marche même pendant un problème au niveau de l’API-Server. Ils ont mis en place une configuration pour maintenir en mémoire les dernières « routes » vers les services.
  3. Un nouveau problème sur la partie Ingress, lié à la perte du service CoreDNS. C’est un composant qui assure la résolution de nom interne au cluster K8S (notamment pour le service discovery).
  4. Un problème sur la perte du cluster K8s au complet. La cause est une mauvaise manipulation lors de suppression de clé récursive dans le service etcd. Pour pallier à cette problématique, ils ont mis en place un PRA, une sauvegarde de l’etcd dans S3 d’Amazon (stockage objet) et un monitoring des différents snapshots d’etcd.
  5. Les masters et les workers Kubernetes qui n’arrivent pas à contacter etcd. Cette fois-ci, le problème venait d’AWS qui a rencontré un problème de réseau durant une maintenance concernant un certain type d’instance. Ici, la conclusion donnée est la suivante « Ce n’est jamais la faute de l’infrastructure d’AWS… jusqu’au jour où ça l’est ».
  6. Un problème au niveau des Ingress durant un upgrade du cluster. Afin de corriger cela, Zalando a mis à jour sa partie testing en incluant la section upgrade du cluster K8s.
  7. En version 1.12.5, une fuite mémoire a engendré l’effondrement d’une partie des nœuds du cluster.
  8. Pour libérer de la ressource, ils ont réalisé un « scale down » du composant IAM provider. En conséquence, la création de nouveaux objets « Deployment » est devenue indisponible. Ce problème a été corrigé en désactivant la fonction CPU-cfs-quota=false et en repassant le composant IAM provider à l’état initial.

 


CoreDNS

Daniel Garcia (Contributeur: CoreDNS Architecte SaaS: Infoblox) et Michael Grosser (mainteneur: CoreDNS et Contributeur: K8s) ont présenté les nouveautés de CoreDNS.
CoreDNS est une solution qui permet de fournir un service DNS et DNS over TLS.
CoreDNS peut être utilisé avec de multiples environnements, et offre les fonctionnalités de service discovery pour Kubernetes et Etcd.
Le projet est parrainé par la CNCF et est distribué sous Licence Apache V2.
La dernière release date d’avril 2019. Le projet est soutenu par une communauté de 150 contributeurs, 15 mainteneurs et compte plus de 4000 étoiles sur GitHub.
Le plugin K8s/CoreDNS est disponible depuis la version 1.11 de K8s et nativement aujourd’hui en 1.13.
CoreDNS propose des nouveaux plugins comme : 
  • Response Rate Limiting (rrl) pour limiter le taux de réponse afin de diminuer les attaques de type déni de service DNS
  • Block ANY queries (any) pour une réponse minimale à toutes les requêtes
Sur la partie roadmap, les nouveautés sont également riches:
  • La partie cœur : Amélioration des performances et de la stabilité
  • La partie plugin : 
    • GRPC avec itération de transport client et serveur
    • DNS over HTTPS
    • Plugin resolver en tant que plugin externe
CoreDNS propose des plugins pour la partie données :
  • file : lire des données à partir d’un fichier maître unique 
  • auto : lire des données à partir de fichiers maîtres
  • forward : lire les données des résolveurs en amont
  • hosts : lire des données de zone à partir d’un fichier /etc/hosts
  • proxy : déprécié et remplacé par forward
CoreDNS fournit également des plugins pour la partie exploitation :
  • reload : recharge automatiquement les Corefile
  • errors : enregistre tous les messages d’erreur 
  • log : enregistre les requêtes et les données de réponse sur la sortie 
  • prometheus : expose les métriques pour une intégration avec Prometheus
  • cache: met en cache de la réponse DNS
Enfin, les plugins pour K8S ont été présentés :
  • kubernetes : lit les données de zone à partir de l’API de cluster Kubernetes
  • etcd : lit les données de zone à partir de l’etcd en version 3 
  • health : active les « health check »
  • ready : active les « readiness check HTTP »
Pour plus d’informations sur le projet : https://github.com/cncf/soc#coredns

 


Back to basics : Hands-On Deployment of Stateful Workloads on Kubernetes

Par David Zhu, Google & Jan Šafránek, Red Hat.
Cette session a pour but d’expliquer les différences entre les objets de type workload de Kubernetes pour mieux maîtriser les déploiements d’applications. Elle se découpe en deux parties, l’une théorique suivie d’une autre pratique avec un tutoriel.

 

Les volumes

Un objet de type Pod a besoin de volumes pour rendre ses données persistantes. Deux modèles existent alors pour fournir du stockage aux opérateurs de Kubernetes : 
  • Le plus simple est le modèle statique.
    Les administrateurs créent à l’avance les objets de type PersistentVolume (PV). 
    Ces objets représentent des espaces disques distincts et disponibles pour le cluster Kubernetes. Ils seront récupérés et attachés aux pods grâce aux objets de type PersistentVolumeClaim (PVC). Ce type d’objet représente le lien entre un pod et un PersistentVolume.
  • Le second est le modèle dynamique.
    Les administrateurs créent un objet de type StorageClass, qui sera capable de cré
    er des objets de type PersistentVolume à la volée et à la création d’un PersistentVolumeClaim. Le second modèle permet de s’affranchir de la création manuelle de PV, et fait donc gagner du temps aux équipes d’administrateurs. Ce modèle permet également de regrouper facilement les volumes en fonction de critères techniques.
L’exemple utilisé par les speakers consiste en la création de deux objets StorageClass, un premier dit « lent » et un second dit « rapide ». Ceux-ci se basent respectivement sur des disques durs et des SSD. À leur création, les volumes d’un même type seront donc regroupés ensemble.

 

Les workloads

Le workload, dans un contexte Kubernetes, regroupe tous les objets Kubernetes permettant de créer des Pods. Les speakers s’attardent sur deux d’entre eux en particulier : les objets Deployment et StatefulSet.
Ces derniers comportent des similitudes, ils permettent tous deux de créér N réplicats de Pods et de les recréér automatiquement en cas de destruction. Enfin, le nombre de réplicats peut évoluer au cours de la vie de l’objet.
Cependant, ils comportent également des caractéristiques qui leur sont propres : dans le cadre d’un objet Deployment, tous les réplicats d’un Pod partagent le même PVC, contrairement au StatefulSet, où chaque Pod se voit attribuer un PVC.
De plus, chaque Pod d’un objet StatefulSet obtient une identité stable : les noms de pods sont les mêmes, se différenciant seulement grâce à un numéro ajouté en suffixe. Ces noms sont adressables et résolvables grâce au DNS interne de Kubernetes.

 

Tutoriel

Le but du tutoriel est de créer un cluster Cassandra (base de données orientée colonnes par Apache) en utilisant l’objet StatefulSet.
L’idée est que chaque Pod a son volume, mais que le cluster s’occupe lui-même de la synchronisation des données entre chaque membre. Les volumes contiendront au final les mêmes données.
Enfin, un peu de scaling à chaud et de debugging seront effectués.
Nous vous invitons à tester le tutoriel : https://github.com/jsafrane/caas
NB : Il est tout à fait possible de jouer ce tutoriel sur un environnement Minikube et non pas sur un environnement cloud, fourni par Google dans le cadre de cette session.

 


Kubernetes + encrypted memory

Le but de cette conférence est de présenter les bénéfices d’utiliser Katacontainer pour protéger les données dans un cluster kubernetes.
Sil est facile de chiffrer les données stockées sur un disque ou en transit grâce à l‘utilisation de protocoles chiffrés, comment faire pour chiffrer les données en cours dutilisation : cache, CPU, in memory, … ?
Les possibilités de hack pourraient facilement venir :
  • d’un autre logiciel
  • d’un administrateur malicieux
  • d’un hôte corrompu
La solution passe par lutilisation de secure virtual machine (svm) pour exécuter les conteneurs dans un environnement contraint.
Ces secureVm sont instanciées grâce à Katacontainer au travers des couches crio et containerd. Chaque pod est alors un svm dans lequel les initcontainers et containers sont exécutés. Les containers peuvent se partager un espace mémoire sécurisé au travers des volumes emptydir et du médium memory.
Reste le problème du registry : les images sont extraites sur la machine hôte non sécurisée. Cependant, pour résoudre cette problématique, il manque des fonctionnalités à la couche OCI pour permettre que l’image soit chargée directement dans le svm. À suivre donc…

 


Tutorial: Building Security into Kubernetes Deployment Pipelines

Par Michael Hough, IBM & Sam Irvine, ControlPlane (Limited Availability; First-Come, First-Served Basis)

Devsecops k8s pipeline workshop
Les conférenciers présentent les contraintes minimum viables pour obtenir un environnement à base de conteneurs secure:
  1.     Construire limage depuis une source de base fiable
  2.     S’assurer que le contenu de limage nest pas vulnérable
  3.     Signer limage une fois quelle a été analysée
  4.     Interdire lutilisation des images non signées en production
Ces étapes sont réalisées au travers dun pipeline, en utilisant des outils tels que Harbor, Notary et Portieris. Portieris est un admission controller permettant à k8s de communiquer avec Notary ; il sassure que seules les images signées seront utilisées par le cluster.
Si on parle ici danalyser le contenu dune image, on ne parle pas des failles de configuration ; ce rôle sera laissé aux podpolicies et networkpolicies pour contraindre et limiter le comportement de lapplication exécutée.
Parmi les autre outils évoqués pendant cette présentation, kubesec.io permet danalyser les fichiers yaml dun déploiement k8s et d’obtenir un score de risques, ainsi que des best practices décriture d’un fichier de déploiement.

 


Building Images Efficiently and Securely on Kubernetes with BuildKit

Par Akihiro Suda, NTT Corporation

Buildkit est un outil conçu pour sécuriser et accélérer le build des images docker. Il est disponible depuis la version 18.06 de Docker. Des tests de performance ont permis de démontrer une division par deux du temps de build d’images grâce à la parallélisation, et un gain encore plus important (x7 à x9) avec un cache local ou à distance.
Buildkit offre des solutions de montage pour utiliser des connexions SSH et réaliser un git clone par exemple, mais aussi pour utiliser des secrets. Il supporte les formats Dockerfile mais aussi de nouveaux formats tels que buildpacks, Mockerfile ou Gokerfile.
De nouveaux outils sont développés pour utiliser buildkit comme une commande docker `docker buildx build …` ou avec docker-compose *bake*.
Cette session, très riche, a permis de présenter les interactions possibles avec un cluster Kubernetes. Il offre la possibilité de construire des images Docker dans kubernetes de manière sécurisée. En effet, buildkit fonctionne en mode rootless, mais c’est encore en mode expérimental.
En savoir plus :