KubeCon Europe 2018 à Copenhague : jour 1

Publié le 02/05/2018

par Pierre Freund, Kevin Lefevre, Léo Georgel, Kévin Messy, Romain Guichard, Adrien Cunin, Youenn Piolet, Lionel Daubichon, Alexandre Kervadec, Igor Aiestaran, Aurélien Joga

dans Kubernetes

⭠ Retour à la liste des articles

En ce début de mois de mai au Danemark, le soleil brille, les oiseaux chantent... mais les experts, eux, continuent de bosser ! Depuis ce matin, un peu plus de 4200 personnes se sont retrouvées au Bella Center de Copenhague pour la conférence phare de la Cloud Native Computing Foundation : la KubeCon + CloudNativeCon.

Sommaire de ce dossier complet KubeCon + CloudNativeCon 2018 à Copenhague par Osones :

#Kubecon2018 #DevOps #Kubernetes #kubecon #cloudcomputing

Une publication partagée par Osones (@livinthecloud) le 2 Mai 2018 à 6 :21 PDT

Le centre de conférence qui sera notre nid durant ces trois jours est à l'image du pays - moderne et éco-friendly, entre espaces verts et grandes verrières. N'ayez crainte si vous n'avez pas pu faire le déplacement : voici un retour de la KubeCon par les experts Osones !

Keynotes

Une fois n'est pas coutume, c'est après un café à l'eau comme on les aimes qu'a lieu la première des deux Keynotes aujourd'hui - la seconde cloturant la journée vers 17h. Les MC sont Dan Kohn, Executive Director de la CNCF, et Kelsey Hightower, Staff Developer Advocate chez Google.

Dan a commencé par dresser un état de lieu de la CNCF et son évolution depuis 1 an :

Le nombre de projets intégrés à la CNCF est passé de 3 à 20
Le nombre de participants aux événements a considérablement augmenté (plus de 4000 personnes ici à Copenhague contre moins de 1000 il y a un an) .

Le graduation program de la CNCF était détaillé et faisait ressortir trois "niveaux" :

graduated projects ; comme Kubernetes
incubated projects ; comme Prometheus
sandbox projects ; comme Rook

Pour plus d'informations,le plus simple reste d'aller étudier les critères de classification des projets sur le site de la CNCF.

Toujours lors de la Keynote du matin (et après une présentation rapide de Cisco), Alexis Richardson - chairman du Technical Committee de la CNCF - a donné sa vision pour 2020. On y a par exemple entendu parler de GitOps, un neologisme poussé par Alexis via la société dont il est le co-fondateur : Weaveworks. Trivialement, le GitOps consiste à diriger les opérations avec des outils "Cloud Native" et utilisable par les développeurs, dont notamment Git - vous l'aurez compris. Marketing ou révolution, nous vous laisserons vous faire une idée ! Plus d'infos sur ce blogpost (EN).

La Keynote de 17H apporte son lot de bonnes interventions, dont nous posterons ici même les vidéos dès que possible.

Parmi celles que nous avons particulièrement appréciées, Kelsey Hightower - de Google, toujours lui - met le doigt sur une question sensible : quid de l'inter-ops entre différents providers de services "serverless ? Comment faire parler une Lambda avec une fonction serverless sur GCP ?
Hop, il n'en fallait pas plus pour enchainer sur la présentation de https://serverless.com, dont une des missions est de faire s'entendre les acteurs principaux proposants des services Serverless sur des standards (par exemple des Endpoints en HTTP).

Demo à l'appui, Kelsey nous fait part de ses derniers projets (cad pas encore disponibles sur son github) rendant cela possible : un fichier texte "Hello World" dropé dans un bucket Amazon S3 ira triggered un event SNS, qui va ensuite envoyer un message aux instances sur Google Cloud Plateform pour traduction, avant de renvoyer le "Hello world" en dannois sur le bucket S3 d'origine. Répondant ainsi aux inquiétudes de certains clients autour du tant redouté "lock-in" des services de Serverless.

Enfin, nous retiendrons dans les liens utiles le site officiel https://landscape.cncf.io vous permettra d'explorer le paysage des projets de la CNCF en fonction de leur classification, de leur cas d'usage ou grâce à d'autres critères.

Place maintenant au retour de quelques conférences auxquelles nous avons eu la chance d'assister !

Retours de quelques unes des conférences

Git-Push workflow for deploying applications on Kubernetes

Tanmai Gopal, Co-Fondateur Hasura
Vamshi Surabhi Rao, CTO Hasura

Hasura est une entreprise proposant entre autres un service de CI/CD permettant de builder, tester, migrer et deployer des applications sur Kubernetes.

L'idée de base est d'avoir une CI/CD qui permet de déployer du code suite à un git push. On pourrait alors penser qu'un script Bash suffit, or, lorsque l'on a déjà eu à faire à ce genre de problématique, on se rend compte qu'il existe des circonstances dans lesquels un script Bash fonctionnerait mais ce n'est ni optimisé, ni flexible/agile.

Le speaker résume les besoins d'un pipeline de CI/CD avec le tableau suivant:

Need	Action
Build + run tests	Dockerfile
Production build (artifacts)	Multi-stage Dockerfile
Deploy configuration	Update Kubernetes Manifests
Run statefull tasks (database migrations)	Update CRs
Run integration tests	Run jobs with init-containers to check if microservices are ready

La solution Gitkube permet de répondre à ces besoins de manière déclarative. Le speaker ne rentre pas trop dans les détails du fonctionnement, et passe directement à une demo à base de simple Pod nginx avec une page statique. Il fait une modification de code qu'il git commit && git push, ce qui va trigger le workflow.

On voit le job s'effectuer, un Dockerfile de builder, puis le kubectl apply -f qui va déployer le nouveau code.

Afin de rajouter un peu de complexité, afin de venir un peu plus proche de la réalité des choses, il ajoute une étape stateful : une modification de base de données. En l'occurrence, c'est juste un peuplement de données factices.

La démonstration s'arrête ici. On passe à une dernière partie, dans laquelle on va expliciter les points sensible de la CI/CD :

Secrets : ils doivent être appliqué en dehors du repo Git
Templating : Helm ou Kubernetes native templating
Releases, canary deployments : on ne voudrait pas déployer du code qui ne fonctionne pas :)

En bref, durant cette courte conférence, on nous a introduit le nouveau terme/job de GitOps.

Continuous Delivery Meets Custom Kubernetes Controller: A declarative configuration approach to CI/CD

Simon Cochrane, Director of Engineering API (Nearmap)
Suneeta Mall, Software Engineer (Nearmap)

Au cours de cette présentation, Nearmap, une entreprise d'imagerie aérienne australienne nous a présentés son approche de la CI/CD avec un contrôleur Kubernetes maison dédié à la gestion des versions de containers.

Dans un contexte où les outils CI sont de plus en plus externalisés via des plateformes managées type SaaS (CircleCI, Travis, etc.), le déploiement d'artefacts sur un cluster privé peut poser problème, en particulier au niveau de la gestion des identifiants. Un workflow où la CI pousse les déploiements sur un cluster privé est envisageable (avec une bonne gestion des secrets), mais un modèle plus simple et pérenne consiste aujourd'hui à faire en sorte que ça soit le cluster qui tire ses propres mises à jour : dernières version des containers à déployer, dernière configuration applicatives... mais comment informer le cluster de l'existence de nouveaux artefacts ?

Après avoir testé des outils comme notamment Spinnaker ou Weave Flux, Nearmaps a préféré revenir vers une gestion du besoin initial la plus simple possible, en se concentrant sur les prérequis suivants:

Respect des principes d'intégration continue
Pas de plateforme supplémentaire dédiée au déploiement
Réutilisation des concepts de Kubernetes
Automatisation de bout en bout

Respect des bonnes pratiques :

Sécurité
Gestion des blue-green deployments
Historisation et gestion de version (avec possibilité d'effectuer des rollbacks)
Instrumentalisation et outils de visualisation

Pour répondre aux besoins, Nearmaps a trouvé une solution simple : étendre le contrôleur Kubernetes (CustomResourceDefinition) pour la gestion d'un nouveau type de déploiement. Appelé CVM pour Container Version Management, l'extension permet de créer au sein de Kubernetes un nouveau déploiement avec la directive kind: ContainerVersion, qui s'assurera périodiquement du raffraichissement des images à tirer d'une registry docker. Le tracking se fait sur la base d'un docker tag. On part du principe que la CI place pour chaque image construite un certain nombre de tags au niveau de la registry. Par exemple : branche git, hash du commit, et environnement de déploiement cible. Ce dernier tag est pertinent pour un tracking depuis le cluster Kubernetes associé.

CVM se découpe en trois parties :

CV controller: controlleur Kubernetes qui réagit à un changement de version au niveau de la ressource
CR syncer: assure que l'état du container dans le pod correspond à la version que le CV controller annonce. Le syncer peut aussi exécuter les tests de non régression, de qualité, des scans de vulnérabilité ou même de la signature d'image. Il gère également le retour arrière si nécessaire, en tirant profit des blue-green ou canary deployments
CI tools

Schéma de l'architecture CVM

Les avantages du workflow et de CVM sont les suivants :

Pas besoin de donner au cluster un accès aux git repositories
Pas de repository de configuration supplémentaire au niveau du cluster. La configuration légère peut être embarquée dans les artefacts
Séparation forte avec la CI
OpenSource
Peu de maintenance
Pas d'API de cluster à exposer sur l'Internet
Autogéré, natif et simple

Nearmaps termine sa présentation en partageant une liste de bonnes pratiques :

Encourager le roll-forward
Initier les déploiement via un merge sur la branche master des projets
Utiliser le git hash comme identifiant de version lorsqu'il n'y pas besoin de le communiquer avec une tierse partie
mettre en place un dashboard pour suivre les déploiements
automatiser tous les tests

Pour plus d'information sur CVM :

Container Runtime Interface (CRI) et Frakti

Kubelet est le composant de Kubernetes qui pilote ce que l'on appelle la container runtime. Au debut une seule runtime était supportée : Docker. Ce fut ensuite au tour de rkt et d'autres runtimes ont également souhaité s'intégrer au Kubelet. Supporter les differentes runtimes et leurs evolutions allaient vite devenir complexes.

Pour pallier à ce problème, la communauté Kubernetes a mis au point une specification : CRI pour Container Runtime Interface, une interface gRPC qui permet d'abstraire les runtimes de containers.

Dockershim était la première implementation afin de rendre Docker compatible avec CRI et Frakti la première implementation non Docker.

CRI spécifie ce que le Kubelet attend d'une runtime de container (par exemple les différents appels tels que list, create, start, exec, etc). Ces specifications doivent être implementées par la runtime.

Aujourd'hui, plusieurs projets deviennent compatible CRI :

Frakti est un peu particulier : c'est une implementation de CRI qui supporte des containers basés sur des VMs, pour cela Frakti utilise les Kata containers. Les Kata containers sont le resultat de la fusion entre Intel Clear Container et Hyper.sh.

Les Kata containers sont de petites VMs et supportent de multiples architectures telles que x86 ou ARM, ces VMs se comportent comme des PODs avec la securité des VMs en plus (pas de Kernel partagé).

La compatibilité avec CRI des differentes runtimes permettra de changer plus facilement de runtime mais également d'avoir différents niveaux d'isolation : certains conteneurs pourront utiliser une runtime "classique" tandis que d'autres conteneurs plus sensible pourront utiliser des runtimes "VM", tout cela au sein d'un même cluster Kubernetes.

SIG OpenStack

Petit état des lieux du SIG (Special Interest Group) OpenStack. L'objectif du groupe ? Développer les liens entre les deux communautés et Fondations (OpenStack et Cloud Native Computing Foundation / Kubernetes), et travailler ensemble pour assurer la complémentarité des outils.

Parmi les évolutions récentes, le provider OpenStack pour Kubernetes, qui est évidemment un point d'intérêt majeur pour le SIG, a été découpé et sorti dans son propre dépôt de code. Ceci permet à ce composant de suivre un cycle de release indépendant du reste de Kubernetes. C'est la direction prise par l'ensemble des providers, pour plus de modularité.

D'autres sujets sont bien sûr suivis par le SIG, notamment :

Déployer OpenStack sur Kubernetes avec OpenStack-Helm
Faire tourner des infrastructures Kubernetes sur OpenStack avec Magnum
Gérer des conteneurs directement au-dessus d'OpenStack avec Zun
Exposer aux conteneurs fonctionnant au-dessous d'OpenStack les réseaux Neutron également exposés aux autres ressources OpenStack (telles que les instances)

À noter que ce SIG qui existe au sein de Kubernetes est depuis peu également reconnu comme un SIG dans la communauté OpenStack.

Build Docker images without Docker

Matt Rickard, Software Engineer @ Google

La problématique de build des images Docker existent depuis... que Docker existe. L'objectif est de construire des images les plus petites possibles qui ne contiennent que ce dont l'application a besoin : cela permet entre autre un gain de place ainsi qu'une surface d'attaque réduite. Ces images se doivent d'être reproductibles et indépendantes de l'outil de run. Actuellement le daemon Docker est l'outil le plus utilisé pour builder des images. L'utilisation d'un daemon pour ce genre d'action ne devrait pas être nécessaire, il ne devrait pas être nécessaire de disposer de Docker pour builder des images ; celles-ci ne tourneront peut être pas avec le runtime Docker en production. Dans un monde idéal, l'outil de build d'image devrait uniquement builder des images, rien de plus, rien de moins.

Plusieurs projets ayant ce but en tête sont présentés, tous assez différents les uns des autres.

projectatomic/buildah Pas de daemon, buildah peut prendre en entrée un Dockerfile mais possède sa propre syntaxe, extrêmement proche de celle de Docker
genuinetools/img Un des plus "anciens", il est compatible OCI et permet de fonctionner en mode non-privilégié, ce qui est important dans le cas où vous ne faîtes pas confiance à votre runtime d'un point de vue sécurité. Ce dernier point permet surtout de builder vos containers sans utilisateur privilégié. La syntaxe est la même que celle des Dockerfile, ce qui permet un portage rapide.
runtime-less Le meilleur choix possible, pas de dépendances au Linux namespaces ni aux cgroups, cela permet une très grande portabilité et permet, dans le cas d'une CI, de s'intégrer parfaitement avec des environnements conteneurisés.
googlecontainertools/distroless L'idempotence est mise en avant, les timestamps sont stripés, les dépendances sont connues au moment du build et les layers indépendantes, ce qui permet de rebase une image lorsqu'une layer doit être changée sans rebuilder entièrement l'image.

SIG Contributor Experience intro - Get involved !

Session animée par Paris Pittman (Google) et Elsie Philipps (CoreOS).

Nous avons participé à plusieurs sessions sur la gestion de la communauté Kubernetes, animées par le groupe de travail "SIG Contributor Experience" (SIG pour Special Interest Group).

L'objectif principal de ce groupe est de s'assurer que les contributeurs soient "heureux et productifs".

Plusieurs sous-projets sont traités en parallèle :

Outils de documentation & communication

Comme dans la grande majorité des projets Open-source, la gestion de la documentation est un point critique. Les tâches de rédaction de documentation ne sont clairement pas les plus appréciées des développeurs. Le groupe s'assure donc que si une tâche n'est pas automatisée, c'est qu'elle est bien documentée. Le groupe s'assure que les problématiques liées à l'adoption ou à l'utilisation des outils de documentation soient traités, et assure la pérennité des outils, notamment au niveau des "Human Single Point of Failure".

Mentoring

Le groupe de travail réfléchit à la création d'un programme de mentorat entre contributeurs. L'objectif serait d'organiser des sessions d'une heure entre un mentor et un mentoré au cours de laquelle

Un problème récurrent remonté par Paris Pittman (Google) dans une session consacrée au mentoring, est la gestion du temps pour le mentor. Cette activité en consomme beaucoup. Dans le programme de mentorat, si le mentor n'a plus de temps à consacrer au mentoré, ce dernier se retrouve dans un état de frustration, et peut parfois le prendre personnellement.

Ces programmes peuvent se révéler toxiques. Cette toxicité est très largement décrite dans des retours d'expérience que l'on retrouve facilement sur le web avec les termes "Mentorat toxicity". De plus, l'humain ne se multipliant pas facilement, des situations de goulet d'étranglement peuvent rapidement se créer et ainsi bloquer le système de mentoring, jusqu'à génerer des burnouts chez les mentos.

Enfin, il est important de fixer en amont les objectifs du mentorat, ce qui se révèle parfois difficile pour les mentorés qui ne connaissent pas encore tous les rouages de Kubernetes. Le mentor doit pratiquer à la fois des tâches de guide, d'entremetteur, de coach et de sponsor.

Ce sujet semble à la fois innovant et dangereux pour un projet de l'ampleur de Kubernetes.

DevStats

Pour les utilisateurs d'OpenStack, vous connaissez sûrement le site Stackalytics qui compile toutes les statistiques de contribution du projet OpenStack. Ce groupe travaille sur ce type d'outils mais pour tous les projets de la CNCF. Vous pouvez retrovuer les dashboards à l'adresse k8s.devstats.cncf.io.

et tous les autres

Lors de cette session, de nombreux autres projets ont été cités, comme la création de guides de développement pour les contributeurs, un guide plus spécifiques pour les développeurs, la gestion des repository, la gestion des évenements de type "Weekly community Meetins", des roadshows, ou encore des summits pour contributeurs.

Continuously Deliver your Kubernetes Infrastructure - Mikkel Larsen, Zalando SE

Zalando est un site de e-commerce majeur :

4,5 milliards d'euros de CA 2017
300 000 produits
23 millions de clients
2000 employés dans le domaine technique
200 équipes de developpement

De part leur taille, ils exploitent 84 clusters Kubernetes (un par produit) sur 366 comptes AWS.

Mikkel Larsen nous a présenté leur processus de gestion et de mise à jour de leurs déploiements Kubernetes. Les objectifs de son équipe sont les suivants :

Fournir un Kubernetes toujours dans la dernière version stable
Mettre à jour les clusters sans interruption de service
Ne pas maintenir de configuration spécifique à un cluster
Se baser sur un workflow git (pull request)

Pour ce faire, les déploiements Kubernetes sont orchestrés par un "Cluster Lifecycle Manager", un développement Zalando disponible sur Github, et réalisés via des templates CloudFormation. Ce "Cluster Lifecycle Manager" interagit avec un "cluster registry", et se charge de maintenir le cluster dans l'état souhaité.

Cluster Lifecycle Manager

Les instructions de déploiement et les templates CloudFormation sont versionnées dans git. Lorsqu'un changement doit être opéré, leur workflow de travail est basé sur les feature branch.

Un pipeline Jenkins est utilisé pour déployer le cluster et y lancer des tests :

144 tests de conformité de Kubernetes
Stateful tests (montage/démontage de volumes...)
Tests customs (déploiement d'applications)

Mikkel Larsen a pris le temps de détailler un scénario, dont nous avons déjà parlé, dans lequel il met à jour toutes les instances d'un auto-scaling group sans downtime.

Panel Discussion: Containers in Enterprise Cloud Strategy: Pitfalls, Best Practices, and Predictions - Moderated by Anni Lai, Huawei

Anni Lai, Open Source Strategy & Business Dev, Cloud BU, Huawei
Nils Magnus, Cloud Architect for the Open Telekom Cloud, T-Systems International GmbH
Brandon Philips, CTO of CoreOS, Red Hat
Brad Topol, IBM Distinguished Engineer, IBM
Ying Xiong, Chief Architect, Cloud Platform, Huawei

En format panel, cette session parle de la situation actuelle des conteneurs dans la strategie cloud des entreprises, les améliorations apportées, les problématiques, ainsi que les prévisions d'avenir.

Nils Magnus de T-Systems mentionne que sa société a beaucoup de clients qui sont des start-ups avec des applications 'greenfield' en microservices pour qui les conteneurs et Kubernetes ont tout leurs sens dès le début. Il souligne l'importance du facteur humain lors des migrations. La loi de Pareto qui dit que 80% des utilisateurs vont se servir de 20% des projets CNCF marque, selon lui, les grandes lignes des projets les plus matures comparés à ceux où il reste plus de travail à faire.

Brandon Philips de coreos donne plusieurs exemples de ses clients. Il dit notamment qu'une réduction de coût très importante est possible dans certains projets, mais qu'il faut faire attention quand on vente ces avantages auprès du management, car chaque projet est unique et personne ne veut se tirer une balle dans le pied.

Brad Topol de chez IBM considère que les parties réseau et stockage sont aujourd'hui moins matures et évoque le Service Catalog qui peut faire le pont entre les conteneurs et les projets legacy. L'inter-opérabilité est importante pour lui, et il souligne le fait qu'on peut migrer son cluster Kubernetes vers un cloud différent de façon relativement simple.

Ying Xiong de chez Huawei met l'accent sur l'automatisation et sur le fait qu'il faut, parfois, s'ajuster aux prérequis technologiques du client qui peuvent énormement varier de l'un à l'autre.

Tous sont confiants quand il s'agit de l'avenir : les conteneurs seront présents absolument partour dans 5 ans et la possibilité qu'une autre technologie les remplace avant cette date paraît peu probable.