KubeCon CloudNativeCon

Pause Cloud & DevOps – édition spéciale KubeCon Europe

KubeCon Europe – jour 3 (et dernier jour)

Et voici la fin de 3 jours de conférence riches et passionnants. Si vous aviez un doute, nous pouvons maintenant vous l’assurer : c’est bien ici que ça se passe !

Suivez  le dernier jour de la KubeCon & CNCF Europe 2018 comme si vous y étiez grâce au résumé des consultants d’Objectif Libre présents sur place.

Au menu :

  • Keynotes d’ouverture
  • Stockage
  • Opérations
  • et du LOL pour terminer !

Bonne lecture, et rendez-vous à Barcelone l’année prochaine !

  • Voir le résumé du jour 1 ici
  • Voir le résumé du jour 2 ici
  • Voir les vidéos en replay sur la chaîne Youtube CNCF ici

Keynotes

Kubeflow Machine Learning on k8s

Par David Aronchick, Cloud AI & co-founder of Kubeflow, & Vishnu Kannan, Sr Software Engineer, Google.

La présentation commence par un exemple d’utilisation de Machine learning (ML) pour contrôler la consommation électrique des Datacenter de Google. Et cela permet effectivement de faire des économies.

Comment est-ce que ça marche ?

Au début de kubernetes, beaucoup de choses devaient être faites à la main. Le Machine Learning est à peu près au même niveau aujourd’hui, notamment lorsqu’il s’agit de le faire dans le cloud.

Le Cloud Native Machine Learning doit permettre d’engager la même révolution que k8s … pour atteindre le niveau « boring Machine learning infra » :

  • solution composable
  • solution portable
  • solution scalable: GPU, cpu, skillets, experiences, etc

Faut-il adopter les conteneurs et k8s comme solution ? Ce n’est pas si simple. Kubeflow est une piste intéressante.

Des annonces sont faites sur kubeflow 0.1:

  • Intégration notebook Jupyter
  • Prise en charge l’apprentissage distribué et multi-architecture
  • Prise en charge de plusieurs bibliothèques de ML pour l’utilisation des modèles créés lors de la phase d’apprentissage
  • Utilisation de ksonnet pour la configuration des workflows et des déploiements

Le Machine Learning aura un impact fort sur le monde. Il faut permettre aux data-scientistes de se concentrer sur les expériences, et non sur les problèmes de mise en œuvre d’infrastructures.

Voir la vidéo

 

Running with Scissors

Par Liz Rice, Technology Evangelist, Aqua Security, fait un focus sur la sécurité.

Lancer des conteneurs privilégiés (ce que nous faisons tous les jours) serait aussi risqué que de courir avec des ciseaux – ce qu’on nous apprend à ne pas faire lorsqu’on est enfant.

Un rappel, suivi d’une démonstration, retrace les bonnes pratiques de sécurité dans les environnements conteneurisés :

  • Vous n’êtes pas privilégiés seulement dans le conteneur mais sur l’hôte aussi
  • Attention à ne pas ajouter de capacités inutiles à vos conteneurs
  • Et finalement : ne pas lancer de pod en mode privilégié !

Kubernetes permet d’interdire au processus de se lancer de manière privilégiée. Le problème c’est que 86% des images sur le hub se lancent en tant que root. Il est donc nécessaire de faire de nouvelles images.

NDR: retrouvez ces bonnes pratiques dans notre webinaire sur la sécurité de kubernetes, disponible en replay ici

Voir la vidéo

 

Scaling Deep Learning Models in Production using k8s

Par Sahil Dua, Software Developer, Booking.com

Cette conférence porte sur l’utilisation des modèles de Machine Learning avec k8s par Booking.com

Commençons par quelques chiffres assez impressionnants concernant Booking.com : +1,5 millions de réservations de chambres toutes les 24h, dans +220 pays. Cela donne une idée de l’immense masse de données à traiter.

Quelques exemples de champs d’application du Machine Learning pour Booking.com :

  • La reconnaissance / le tag d’images, avec la problématique de remonter des informations pertinentes sur l’image en prenant correctement en compte le contexte de l’image, ce afin de fournir les descriptifs les plus pertinents pour les clients
  • Les traductions, avec un bon niveau de prise en compte des spécificités du métier
  • L’achat de publicité et de mots clés

Les enjeux et difficultés à traiter sont les suivants : énormément de calculs impliquant énormément de données, et pouvant être difficiles à paralléliser.

Les raisons du choix de k8s résident dans les capacités d’isolation, d’élasticité et de flexibilité de la technologie.

Vient ensuite le détail de l’utilisation de k8s dans le processus de Machine Learning :

  1. Entraînement des modèles. Pour cela, ils utilisent des images de base qui intègrent un framework de machine learning. Le code d’entraînement est installé dès  le départ. L’accès aux données se fait via Hadoop. Ils ont ensuite un pod qui récupère le code depuis Git, récupère les données et démarre l’entraînement. Les progrès sont surveillés à partir des logs. Le modèle est ensuite exporté et ré-injecté dans Hadoop.
  2. Utilisation du modèle pour les prédictions en production. Les différents modèles issus de l’entraînement sont exécutés en parallèle par les clients. Le système s’auto-adapte à la demande et aux requêtes des utilisateurs de booking.com ; le passage des modèles en production se fait via une application stateless avec un code basique, conteneurisée. Aucun modèle n’est dans une image, ce sont les APIs REST exposées qui sont utilisées pour faire les prédictions.

Voir la vidéo

 

Crossing the River by Feeling the Stones

Par Simon Wardley, researcher, Leading Edge Forum

La Keynote se clôt sur une intervention passionnante de Simon Wardley, intervention drôle, riche et dense qu’il nous semble impossible de résumer sans trahir.

Le replay est disponible ! Voir la vidéo

Cas d’usage

End-2-end testing using kubectl

Cette conférence a présenté les outils et les réflexions autour d’un environnement de tests de bout-en-bout pour une application. Le titre était un peu trompeur mais le contenu intéressant 🙂

MayaData est la société qui développe le projet openEBS, système de stockage logiciel. Ce logiciel doit être testé, avec d’autres, afin de bien valider leur fonctionnement.

Deux points de vues différents sur ce que doivent être les tests ont été présentés, points de vues de 2 personnes internes à la société :

  1. Le point de vue d’un développeur :
    • besoin d’écrire les tests eux-mêmes
    • utilisation de minikube en local, avec kubectl et helm pour aider au déploiement de l’environnement
    • upload des fichiers specs/yamls sur github
  2. Le point de vue d’un ingénieur qualité :
    • les tests peuvent être déclenchés automatiquement depuis un pipeline CI/CD
    • ansible et jenkins sont les outils de prédilection
    • les tests sont exécutés régulièrement et les résultats partagés avec personnes concernées
  3. Les autres besoins glanés au fil des discussions :
    • les tests doivent pouvoir fonctionner sur n’importe quel type de plateforme (cloud et bare metal)
    • besoin de collecter des métriques et de les visualiser
    • besoin de valider que les fonctionnalités des sprints sont correctement implémentées

Mais est-ce que ces contraintes techniques sont suffisantes pour définir ce que doivent contenir les tests ? Non, car les cas d’usage utilisateurs ne sont pas toujours représentés.

Une idée pour implémenter ces tests est donc d’inclure les utilisateurs, à partir de « user stories ».

Plusieurs outils ont alors été utilisés pour inclure les déroulés utilisateurs :

  • godog : outil Open Source développé par Datadog permettant d’exprimer une série d’actions / tests en anglais, et de les traduire en actions Kubernetes : https://github.com/DATA-DOG/godog
  • kubectl : utilisé pour déployer sur k8s, peu importe la cible : minikube, déploiement on-prem ou dans le cloud
  • litmus : un outil « maison » pour orchestrer le tout : https://github.com/openebs/litmus

L’idée d’inclure les utilisateurs dans les procédures de test, et leur donner les moyens d’écrire des scénario validant leurs cas d’usagesa via un outil simple, est particulièrement attirante.

Stockage

Container Storage Interface (CSI): present et future – Jie Yu (Mesosphere Inc)

Aujourd’hui, chaque orchestrateur de conteneurs (Docker, k8s, mesos, etc) utilise ses propres techniques d’intégration des solutions de stockage.
Cela présente plusieurs inconvénients :
  • interfaces évoluant avec les différents systèmes, impossible de découpler le cycle de release.
  • les vendeurs doivent implémenter plusieurs interfaces (on se retrouve avec le même problème que les différents formats de prises de courant dans le monde !)
  • les interfaces sont généralement fortement couplées à leurs implémentations respectives
L’objectif de CSI est donc de proposer :
  • une interface standard permettant l’interopérabilité des solutions de stockages avec les orchestrateurs
  • une spécification indépendante de tout vendeur
  • une définition uniquement du plan de contre
  • tout ça de manière simple, simple et simple !!
Le speaker est ensuite revenu sur différents choix de conception (non détaillés dans cet article) :
  • développement « out-of-tree », c’est à dire indépendant du code source des orchestrateurs
  • utilisation en mode service (en opposition du choix fait par CNI pour le réseaux)
  • 2 types d’api: contrôleur et nœud. Les services de type nœud devront être déployés sur chaque nœud pour réaliser les actions bas-niveau comme le montage, formatage, etc.
  • implémentation idempotant : c’est le contrôleur qui insère l’identifiant du volume à la demande. Cela permet de ne pas avoir de volumes fantômes si la réponse du service nœud se perd et que le contrôleur redemande la création du volume.
  • utilisation de grpc pour l’implémentation des APIs
  • APIs synchrones
Plusieurs implémentations sont déjà disponibles sur github, et suffisamment avancées pour être testées :
Il reste encore de nombreux sujets à traiter :
  • gestion de la topologie
  • support des snapshots
  • redimensionnement des volumes
  • enregistrement des plugins
  • fourniture d’une suite de smoke tests.

Voir la vidéo

 

Kubernetes Local persistent volumes in production – Michelle Au (Google) & Ian Chakeres (Salesforce)

Le succès de Salesforce en tant que plateforme SaaS a engendré une explosion dans leurs besoins de stockage. Ayant déjà adopté Kubernetes pour leur déploiement, Salesforce a voulu voir les
possibilités d’exploiter le stockage local de leur infrastructure.

Pourquoi le stockage local plutôt que le stockage réseau classique ? parce que dans certains cas d’usage, le stockage offre de bien meilleures performances à moindre coût. Cela est notamment le cas pour le déploiement de solution de stockage DANS kubernetes, comme ceph ou cassandra, ou pour des applications fortement contraintes par les I/O.

Dans kubernetes, il est bien entendu possible d’utiliser les volumes Hostpath mais cela amène de nombreuses contraintes :

  • peu sécurisé (puisque les utilisateurs peuvent indiquer n’importe quel chemin dans leur pod)
  • non portable
  • pas de maîtrise de la gestion du stockage sous-jacent (c’est juste un chemin)
  • non scalable (inutilisable avec les statefulsets)

La solution est donc d’utiliser les volumes locaux disponible en béta dans k8s v1.10:

  • permet de voir des disques locaux comme des volumes persistants (mais ils doivent être formatés et montés a priori)
  • Utilisable comme tout volume persistant via les PVC
  • Intégré au modèle de scheduling pour positionner les pods sur les bons nœuds, notamment dans le cas d’utilisation de plusieurs volumes dans le même pod.
  • Utilisation d’un provisionneur local pour découvrir automatiquement les disques montés dans un répertoire dédié

L’utilisation des volumes locaux s’appuie sur deux cycles de vie :

  • préparation des nœuds (formatage et montage des disques, installation du provisionneur local)
  • utilisation des volumes locaux via PVC

Salesforce a ensuite montré comment ils avaient utilisé les deamonsets pour réaliser la partie préparation des nœuds:

  • Un premier dameonset avec une affinité pour s’exécuter sur des nœuds ne contenant pas le label « nodeprep »: il a la charge de formater et monter les disques en utilisant une description poussée
    dans un configmap
  • Un deuxième daemonset avec une affinité pour s’exécuter sur des nœuds avec le label « nodeprep » pour déployer le provisionneur local. Ainsi, le déploiement se trouve scalable (configuration automatique à l’ajout d’un nouveau nœud) sans utiliser un autre système de provisionning comme Puppet ou Ansible.

Pour finir, les évolutions futures sont:

  • possibilité de créer des volumes locaux en mode block
  • provisionneur local dynamique avec LVM
  • gestion du formatage et montage dans kubernetes.

Voir la vidéo

 

Kubernetes runs anywhere, but does your data ? Jared Watts – Maintainer for Rook

C’est un acquis, Kubernetes peut être déployé partout :
  • c’est l’orchestrateur de conteneurs, un standard de fait
  • il tourne sur la majorité des plateformes de cloud et sur des machines physiques
  • et le plus important : il permet d’exécuter des applications n’importe où
Les applications sont portables, il est facile de profiter du meilleur environnement pour un job donné (coût, qualité de service, fonctionnalités, résilience, …).
Comment est-ce possible ? Grâce aux abstractions de Kubernetes (pods, deployments, services, …).
Qu’en est-il pour le stockage ? Des abstractions existent également : PV, PVC, CSI, StorageClass. Mais :
  • focus sur la consommation côté utilisateur, et non sur le côté fournisseur
  • besoin de s’appuyer sur des solutions de stockage externes à Kubernetes
  • quelqu’un (une personne) doit donc s’occuper de ces solutions (automatisation possible, mais pas via Kubernetes)
  • les abstractions de stockage sont basées sur le concept de volume, qui n’est pas adapté à toutes les applications (database, object store, clé/valeur, …)
Quelle pourrait alors être une solution portable ? Voici quelques contraintes à respecter :
  • besoin de rendre les applications stateful plus portables
  • pourquoi ne pas gérer le stockage dans k8s ?
  • et pourquoi pas d’autres abstractions, par exemple un objet de type database/sql ?
Kubernetes fournit les outils pour l’implémentation de cette abstraction : les opérateurs et les CRD (custom resource definitions) sont la clé. Ces outils aident au déploiement, mais aussi et surtout au run des services (sauvegardes, mises à jour, scalabilité, …).
Pour illustrer ces concepts, Jared a créé en direct 3 types de stockages différents grâce à Rook :
   * cockroachDB
   * Ceph
   * Minio
Le projet Rook (https://rook.io) apporte une réponse au besoin d’abstraction de plus haut niveau du stockage dans Kubernetes.

Opérations

Conquering a Kubeflow Kubernetes Cluster with ksonnet, Ark, and Sonobuoy – Kris Nova, Heptio & David Aronchick, Google

Déployer des applications dans un cluster kubernetes peut être compliqué ; déployer en multi-cluster est encore plus compliqué.

Il faut s’occuper de tâches supplémentaires potentiellement assez complexes :

  • gestion des backups
  • uniformité des déploiements entre les clusters
  • synchronisation des données

Heptio présente leur boîte à outils développée pour répondre en partie à ces problèmes.

  • Sonobuoy : outils de scan de conformité
    Sonobuoy scanne vos configurations kubernetes à la recherche d’éléments non conformes aux bonnes pratiques.
    L’application avertit notamment en cas de configuration d’éléments qui ne sont pas portables entre différents fournisseurs kubernetes.
  • Ksonnet : outil de packaging d’application k8s
    Cet outil est similaire à Ansible pour k8s : vos ressources sont templatisées et peuvent être déployées sur différents environnements. Sa syntaxe sera facile à prendre en main pour les habitués de Kubernetes.
    La démonstration utilise ksonnet pour déployer kubeflow sur un cluster Amazon.
  • Ark : outil de gestion de sauvegarde/restauration de vos ressources k8s
    Ark lit vos ressources k8s, les sauvegarde sous forme d’archive (par exemple dans du stockage objet S3) et peut ensuite redéployer les ressources.
    La démonstration sauvegarde les ressources du cluster sur Amazon, les sauve sur S3 et les rejoue sur Google Cloud.

On se retrouve ainsi avec deux déploiements uniformes sur deux fournisseurs Cloud différents (objectif multi-cloud atteint).

 

LOL

Why Running kubelet on Your Vacuum Robot Is (Not) a Good Idea – Christian Simon, Jetstack (Any Skill Level)

L’auteur de la session commence par nous expliquer ce qui l’a motivé à proposer cette conférence assez atypique. En effet, il décrit comment il a modifié un robot aspirateur Xiaomi pour l’interfacer avec Kubernetes. Ce robot possède un Linux embarqué et suffisamment de RAM et de mémoire flash pour pouvoir être hacké. Cet aspirateur a toutefois besoin de se connecter au cloud de Xiaomi pour pouvoir être opéré via un smartphone. Le robot dispose donc de logiciels propriétaires permettant la connexion au cloud de Xiaomi et piloter le matériel.
La première étape pour notre hacker était de se séparer de cette couche logicielle pour « libérer » l’aspirateur du Cloud. Cette libération permet à l’utilisateur de reprendre le contrôle de ses données et de ne plus dépendre d’un service externe pour gérer les cycles d’aspiration.
Le conférencier explique qu’il a utilisé Kubernetes et notamment son apiserver pour démarrer des cycles d’aspiration ainsi que pour récupérer des données en provenance de l’aspirateur. Le hacker a créé un logiciel nommé rocklet qui émule le comportement d’un kubelet. L’aspirateur ne lance pas de pods ; à la place, il exécute des cycles d’aspiration. L’aspirateur peut être piloté grâce à la commande kubectl, comme une ressource habituelle de Kubernetes. La commande « exec » permet de piloter le robot. On peut ainsi lui donner l’ordre de bouger dans une certaine direction ou de retourner sur sa base de chargement.
Le robot remonte son état via un Custom Resource Definition (CRD) nommé « vacuum ». Ce dernier contient la durée de la session d’aspiration, un éventuel code d’erreur, le statut mais également une carte du trajet effectué par le robot au moment du cycle d’aspiration. Ces informations sont affichées sur une page web. Enfin, le robot renvoie des métriques prometheus et peut donc se connecter sur une chaîne de métriquse traditionnelle.
Bien qu’on puisse douter de l’intérêt d’un tel hack, il est intéressant de voir à quel point Kubernetes est flexible et peut s’adapter à de très nombreux cas d’utilisation.
Une conférence « out of the box », idéale pour clôre cette semaine stimulante !