CR KubeCon EU 2019

Cette année la KubeCon Europe avait lieu à Barcelone !
En cette occasion OCTO a envoyé deux mercenaires pour aller prendre quelques informations fraîches sur l'écosystème Cloud Native !
Cette année encore il y avait trop de talks pour que l’on puisse tout voir, il a donc fallu faire des choix. Cet article (bien que très en retard) recense ce qui nous aura le plus marqué.

Du côté de la CNCF

Dès le premier jour nous avons été mis dans le bain avec une première keynote retraçant les principales updates des différents projets présents dans l’organisation. On vous fait le récap !

Pour chacun des projets présentés leur niveau de maturité est décrit entre parenthèses :

• Sandbox: point d’entrée dans la CNCF, ils concernent les projets très récent ayant au moins 2 sponsors de la CNCF
• Incubating: Projets ayant un nombre stable de contributeur et étant utilisé en production avec succès par 3 utilisateurs finaux
• graduated: Sont les projets qui disposent d’une core team venant d’au moins 2 organisations et qui sont soumis à des audits sécurités et de qualités

OpenEBS (sandbox)

On commence avec les nouveaux venus dans la fondation et c’est une solution de stockage native Kubernetes qui fait son entrée, OpenEBS ! 
Cet outil permet de fournir du stockage pour les workloads stateful de Kubernetes en utilisant Kubernetes lui-même pour la gestion du stockage. OpenEBS peut par exemple utiliser le stockage disponible sur les nœuds du cluster pour créer des volumes répliqués ! L’architecture de cette solution est vraiment intéressante car on y retrouve la philosophie des micro-services appliquée à du stockage !
Avec ces 5000 étoiles sur Github, le projet dispose déjà d’une bonne communauté et vient proposer une alternative à Rook pour du stockage dans Kubernetes !

Pour plus d’informations, le site d’openEBS : https://openebs.io/

Linkerd (incubating)

On enchaine ensuite avec les projets incubés et c’est linkerd qui ouvre le bal !
Linkerd est un service mesh léger qui permet d’améliorer l’observabilité, la sécurité et la fiabilité des applications dans Kubernetes sans toucher au code source. Il se différencie d’Istio par le fait qu’il reste limité en périmètre mais aussi beaucoup plus facile à mettre en place.

Durant cette présentation, on verra une démo d’une nouvelle fonctionnalité introduit par Linkerd 2.3 récemment sortie, le zéro config pour le mutual TLS. Elle permet de chiffrer la communication entre 2 applications présentes dans le cluster sans les modifier. Cela passe par l’injection d’un proxy sidecar dans les pods de chaque application.

Helm 3 (incubating)

La première grosse annonce de cette KubeCon est l’arrivé de Helm 3 ! 
Pour rappel Helm est un package manager qui permet de packager/déployer les applications à destination d’une plateforme Kubernetes ! Pour plus d’informations jetez un coup d’oeil par ici: https://helm.sh/

Le premier gros changement dans Helm 3 est une refonte de l’architecture ! À l’origine helm était découpé en 2 composants, un client (helm) servant d’interface pour l’utilisateur et une partie serveur (tiller, installé dans le cluster Kubernetes) s’occupant du déploiement.
Dans sa troisième version, Helm passe en mode client only et supprime tiller ! Toute la mécanique se passe maintenant dans le client. Cela permet de gérer plus finement les droits des déploiements car ce dernier utilisera exclusivement les droits de l’utilisateur qui lance la commande et non plus les droits de tiller.

Cette nouvelle architecture va permettre d’introduire d’autres changements ! Notamment que l’état des déploiements ne sera plus géré par tiller mais au travers de CRDs déployées par Helm. Cette modification introduit également l’isolation des déploiements à l’échelle du namespace.
Helm devient également compatible avec les registry OCI qui hébergent tous les artefacts Cloud Natives.

Pour le moment, Helm 3 est disponible en alpha ! Toutes les fonctionnalités annoncées ne sont pas encore implémentées dans ces premières releases !

Pour plus de détails sur Helm 3, un talk dédié est disponible ici: https://www.youtube.com/watch?v=lYzrhzLAxUI

Harbor (incubating)

La présentation fait un rapide passage sur Harbor, une registry Docker qui s’occupe de stocker, analyser les vulnérabilités et signer des images de nos chers conteneurs. Elle offre également la possibilité d’héberger les charts Helm associés à ses applications.

Harbor 1.8 vient de sortir est permet d’introduire 2 grandes nouvelles fonctionnalités :

• L’intégration d’OpenIDconnect pour gérer la partie authentification/autorisation des utilisateurs
• La réplication entre différentes registries

Si vous avez besoin d’une registry privée, Harbor est une solution assez complète.

Rook (incubating)

L’attention arrive maintenant sur Rook qui vient de passer en version 1.0. Pour rappel Rook est une solution d’orchestration de stockage cloud native. Il s’occupe de déployer, manager, configurer,  monitorer... Des plateformes de stockage comme Ceph, EdgeFS, Minio, ...

Dans sa première release majeure, on retrouve des changements sur :

• Le support de la dernière version majeure de Ceph du doux nom de Nautilus
• L’upgrade automatique des clusters Ceph gérés par son opérateur
• Le passage en bêta de l'opérateur EdgeFS

Rook supporte également d’autres solutions de stockage comme Minio, CockroachDB et Cassandra, ce qui élargit très fortement les ambitions initiale de Rook...

La volonté de faire tourner des workloads stateful dans Kubernetes est de plus en plus demandée. Chez les cloud providers des solutions de stockage entièrement managées sont disponibles mais lorsqu’on arrive sur du on-premise ou du multi-cloud.: il faut revoir sa stratégie. Ce genre de solutions peut être une réponse.

Open Telemetry (incubating)

Cette session de la KubeCon était l’occasion pour les projets Open-Census et Open-Tracing d'annoncer leur fusion qui donnera naissance à Open-Telemetry.
Les deux projets fournissent des librairies et API permettant la collecte de métriques/traces et la propagation de contexte, le but est de permettre de tracer les échanges dans un système distribué.
La fusion est une initiative à saluer, les deux projets voyant un recouvrement dans leur fonctionnalités, la décision a été prise de regrouper leurs efforts plutôt que de tenter de rester dans un modèle de concurrence. Bravo !

Les Ops soucieux de la problématique d’observabilité devront suivre l’évolution de ce projet !

Fluentd (graduated)

La dernière annonce de cette keynote est le passage de Fluentd de projet incubé à projet gradué !  C’est le sixième projet à atteindre ce statut.
On retrouve Fluentd autour des problématiques de logging pour garantir la distribution des logs dans services de stockage tiers comme ElasticSearch, Stackdrivers (GCP), log analytics (Azure)…

Dans la dernière version (1.5), on retrouve un focus autour de la stabilité du produit, notamment avec une amélioration :

• des performances, grâce au forward protocol et à l’utilisation du keep alive pour réduire la consommation en bande passante
• de la sécurité, avec le support du TLS pour du http et du syslog
• de la scalabilité, sur la gestion de plusieurs workers

Du côtés des talks

Voici le résumé de quelques talks que nous avons vraiment bien appréciés ! L’intégralité des talks est disponible sur Youtube.

Chaos toolkit

Si le Chaos Engineering vous intéresse, nous vous recommandons la présentation de Sylvain Hellegouarch (CTO, ChaosIQ) sur chaos toolkit. Le framework ouvre la possibilité d’écrire des expérimentations en JSON et d’y inclure des assertions sur le comportement de votre application.
Pendant la présentation, l'expérimentation présentée visait à effectuer le rollback d’une API dans sa version N-1 et de vérifier que l’opération ne génère pas d’erreur 500 en interrogeant une métrique Prometheus, la vérification de l’assertion est permise à l’aide d’un driver pour Prometheus (d’autres drivers existent cependant).
Le tout est exécuté avec un CLI qui permet l'intégration dans une chaîne d'Intégration Continue et l’automatisation !

Le lien vers l’enregistrement du talk: https://youtu.be/Qus15C5vT5Y

Canary & BlueGreen avec Kubernetes

L’un des talks ayant reçu un bel accueil des participants était le talk d’Intuit sur leur stratégie de déploiement.

Le talk était l’occasion pour Intuit de présenter leur produit orientés GitOps mais également leur controller Kubernetes maison (OpenSource) permettant les stratégies de déploiement de type Canary ou BlueGreen (La stratégie de déploiement par défaut de Kubernetes étant le rolling update).

Une bonne partie des participants était restée pour poser des questions aux représentants d’Intuit, même après la session de questions du talk.

Intuit a été récompensé du CNCF End User Award pour leur contribution à l'écosystème Cloud Native.

Le lien vers l’enregistrement du talk: https://youtu.be/yeVkTTO9nOA
A voir !

Kapp

Au détour d’une balade dans les stands des sponsors, nous sommes tombés sur une session de TGI K8s (un rendez-vous hebdomadaire sous forme d’une vidéo dans laquelle Heptio/VMware présente l’actualité de la semaine et présente la démo d’un outil) animée par Joe Beda (lui-même). Pendant cette session nous avons vu Joe utiliser Kapp, un outil qui permet d’effectuer les déploiements dans Kubernetes. Mais ce qui nous aura marqué, c’est la capacité de l’outil à afficher les changements avant le déploiement. 
Un peu comme le ferait Terraform avec la commande `terraform plan`.

Faites un petit tour sur la page de l’outil pour avoir un bon aperçu des possibilités: https://get-kapp.io/

Un jouet de plus à essayer pour nos équipes !

KubeHunter

Si vous êtes administrateur de clusters Kubernetes, le talk de Liz Rice (Aqua Security) vous intéressera assurément !

Le talk aborde la mise à disposition de Kube-Hunter, un outil open source permettant de reproduire les attaques que pourrait effectuer un hacker sur votre cluster.

Ce framework propose d’effectuer des attaques dites passives (simple audit) mais également des attaques actives qui tenteront d’effectuer des opérations sur votre cluster !

L’outil (en Python) permet d’écrire des modules permettant d’enrichir la liste de tests déjà disponibles !

Le lien vers l’enregistrement du talk: https://youtu.be/fVqCAUJiIn0

Un outil de plus à tester pour nos équipes !

Test with OPA

Pour ceux qui ont touché les limites du système RBAC de Kubernetes, vous avez surement déjà joué avec OPA (Open Policy Agent), qui permet d’appliquer des policies sur les objets créés dans le cluster.
Si vous en avez jamais entendu parler, il y a un super article disponible ici sur le blog : https://blog.octo.com/durcissez-votre-kube-avec-openpolicyagent/

Durant ce talk, un nouvel outil a été présenté, Conftest, qui permet de tester nos policies avant de les déployer ! Il peut être utilisé sur son poste de développement pour faire du TDD avant d’écrire ses policies mais s'intègre très bien dans une CI applicative, par exemple avec des charts Helm pour valider que ces derniers respectent certaines normes de labellisation.

Gatekeeper, l’implémentation d’OPA pour Kubernetes fonctionne à base de webhook pour valider la création/mise à jour d’un objet sur le cluster. Cela veut dire que lorsque vous déployez une nouvelle policy, elle n’affecte pas les objets existants ! Afin d’éviter les surprises lors d’un rescheduling, Conftest dispose d’un plugin kubectl afin de vérifier sur le cluster si certains objets déjà présents ne respectent pas les policies déployées.

Conftest apporte en outre un système de partage de policies ! Beaucoup de policies vont être assez standard à tous les types de clusters, par exemple interdire les images latest. Une base commune des policies, va permettre de gagner beaucoup de temps lors de leur mise en place !

OPA n’étant pas limité à Kubernetes, Conftest va encore plus loin et s'intègre avec d’autres langages que le YAML de Kubernetes, comme Terraform !
Conftest ne va pas bloquer au niveau IAM la création des ressources, mais il peut très bien être installé dans un pipeline CI pour faire des tests de conformité en amont (à partir des terrraform plan par exemple) !

A tester de toute urgence ! https://youtu.be/AfTuzonH93U

Secrets Store CSI

Dans un précédent article sur le blog, nous vous parlions de l’intégration d’HashiCorp Vault pour la gestion des secrets d’une application dans Kubernetes( cf : https://blog.octo.com/deployer-ses-application-dans-Kubernetes-avec-des-secrets-vault/)
La technique présentée, non native Kubernetes, était assez complexe et nécessitait d’utiliser des init-containers ce qui n’était pas évident pour les équipes n’ayant pas de solide base sur Kubernetes

Une nouvelle méthode, plus simple et plus scalable, nous a été présentée à base d’un nouveau CSI drivers gérant le stockage des secrets. Ce drivers s’occupe de récupérer le secrets depuis un coffre-fort externe et monte les données dans un volume pour le conteneur.

Si vous faites de la multi-tenancy, une question reste en suspend : comment restreindre l’accès à certain pods au coffre-fort ou une partie du coffre-fort.
Pour cela, le driver va se baser sur l'identité du pod à travers son service account. L’intégration avec certains cloud providers est déjà disponible comme Azure avec Active Directory Pod Identity ou GKE avec Workload Identity.

Ce driver est pour le moment en alpha et supporte uniquement Azure Key Vault et HashiCorp Vault. Il faut également être sur la dernière version de Kubernetes (1.15) avec l’option InlineVolume d’activée !

On attend avec impatience que cette solution devienne mature pour améliorer la sécurité des secrets des applications dans Kubernetes

https://youtu.be/bIC4kLnrKN0

Loki

Loki est un projet très intéressant poussé par Grafana labs qui vient traiter autour des problématiques des logs ! 
Lorsqu'on ne l’utilise pas une solution managée pour gérer ses logs, l’implémentation que l’on retrouve le plus souvent est la stack EFK (Elasticsearch, fluentd, Kibana). Toute la complexité derrière cette solution est située au niveau d’Elasticsearch, sur la gestion du stockage et de ses index. L’approche derrière Loki est d’avoir une solution plus simple à déployer/gérer. Pour cela ils sont inspirés de ce qui est fait avec Prometheus !

La présentation commence par une phrase qui résume bien le produit : “Loki is like prometheus but for logs”. En fait Loki utilise le moteur de Prometheus pour à la fois stocker les logs dans sa base TSDB et faire la décoration de ces derniers avec les labels des pods. Ce système est découpé en 2 parties, un agent sur les nodes qui remonte les logs et le serveur principal qui les stocke. Étant basé sur Prometheus, il dispose des mêmes capacités (et limitations) pour le stockage long terme.

Loki ne faisant pas d’indexation se pose du coup la question de comment faire des recherches !
Comme le disait Tom Wilkie lors de la présentation “The research is a UI problem now”
Les logs étant décorés avec les labels des pods et de leur timestamps, il suffit juste de bien positionner les selectors pour réduire au maximum la fenêtre de recherche !

Hâte de tester cet outil plus en détail.
https://youtu.be/CQiawXlgabQ

Rex incident

Cette année encore, il y avait encore de très beaux talks sur des REX d’incidents avec des clusters k8s. 
Les rex d’incidents sont très intéressants car ils permettent d’éviter les erreurs commises par d’autres sociétés et de les anticiper dès le design de la solution.

Nous avons pu assister à  3 présentations sur ce sujet particulièrement intéressantes !

La première, présentée lors des keynotes, par Spotify retrace l’histoire de comment ils ont supprimé plusieurs fois leur cluster de production sans le moindre impact utilisateur !
https://youtu.be/ix0Tw8uinWs

Pour la deuxième, c’est Datadog qui est venu nous montrer 10 façons de se tirer une balle dans le pied avec Kubernetes  !
https://youtu.be/QKI-JRs2RIE

Et pour finir Zalando nous a raconté 8 façons de crasher son cluster !
https://youtu.be/QKI-JRs2RIE

Si les REX d’incidents sur Kubernetes vous intéresse, il y a un site regroupant toutes les perles ! https://k8s.af/

Conclusion

Cette KubeCon était très riche en annonce et en nouveautés. Nous sommes repartis avec une belle liste d’outils à tester (et quelques coups de soleil) 
La prochaine KubeCon EU aura lieu à Amsterdam du 30 mars au 2 avril !