Kubecon Europe 2021 on Zwindler's Reflection

Kubecon Europe 2021 – Récap’ du vendredi

Wed, 12 May 2021 07:00:00 +0000

Dernier jour de Kubecon !

C’est déjà la fin de la Kubecon :-(.

Bon, en vrai, faire une conférence en ligne sur 3 jours était hyper intense et je suis rincé et je suis aussi un peu content que la conférence ait une fin ;-p.

J’ai énormément appris de choses et je ne me suis pas trop trompé dans les talks que j’ai sélectionné. Visiblement, le board qui choisi les talks est bien rôdé maintenant et je pense que la très grande majorité des conférences étaient de grande qualité.

Si vous avez lu le résumé des jours précédents, vous aurez remarqué que j’ai fait un gros focus sur la partie réseau et sécurité de l’écosystème autour de Kubernetes. Et c’est bien normal puisque c’est une bonne partie du travail qui m’attend dans les prochains mois…

Keynotes

J’ai eu un peu de mal à suivre les keynotes ainsi que certaines conférences de cette journée pour une raison que je détaillerai dans un dernier article, avec mes conclusions. Voilà quand même ce que j’ai noté :

J’ai raté la keynote sur WASM, celle sur l’innovation dans l’open source (Success Through Failure), donnée par Thomas Di Giacomo, Chief Technology & Product Officer chez SUSE, ainsi que celle sur COVID Tracker.

La keynote suivante était une keynote sponsorisée par Vijoy Pandey, un VP chez Cisco, qui était assez basique sur l’intérêt des services mesh. Le talk aurait pu être résumé en une seule slide (la seule intéressante) qui disait que les services mesh servent à 4 choses : Discover, Consume, Connect, Observe.

Un keynote vraiment sympa (de mon point de vue) était la keynote de Daniel Mangum. Il a présenté l’architecture RISC-V (propriétaire) puis un projet open source pour l’Instruction Set Architecture, qui a permis le portage de nombreux projets open source sur RISC-V. A force de portages, d’abord go, puis des projets en go, puis docker et enfin Kubernetes ont été portés sur RISC-V (ce qui est aussi fun qu’inutile).

On a également eu un chouette talk sur la community culture pour le projet Kubernetes par Aeva Black (Microsoft) et Bob Killen (Google).

Globalement, j’en ai retenu que les communautés sur des projets si vastes (des milliers de contributeurs, dont des entreprises multinationales) étaient mouvantes et qu’il fallait mettre en place des processus parfois complexes de manière à garder de la cohérence mais surtout de la confiance dans le travail des uns et des autres.

J’ai aussi beaucoup aimé ce diagramme:

Gateway API: A New Set of Kubernetes APIs for Advanced Traffic Routing

Cette session avait vocation à présenter la Gateway API, une nouvelle API permettant d’étendre les capacités en termes de routage des requêtes HTTP par rapport à ce qu’on peut faire actuellement avec les Services (trop focus sur les Loadbalancers tiers) ou les Ingress (trop limités).

gateway-api.sigs.k8s.io/

Au delà de l’ajout indéniable de features comme le traffic splitting, les header matching, … out of the box, l’avantage de la Gateway API est qu’elle ajoute des couches d’abstractions, notamment au niveau implémentation.

Cela permet notamment (dans un contexte multi cloud par exemple) d’avoir des contrôleurs différents dans des clusters distincts, et ainsi fournir une expérience unifiée pour les développeurs d’un cluster à l’autre, ou alors de faciliter la migration d’un service mesh à un autre.

Aujourd’hui, les composants/logiciels suivants implémentent la Gateway API : Contour, kong, solo, gke, traefik, istio.

Kubernetes Advanced Networking Testing with KIND

Ce talk était plus une grande démo de KIND (Kubernetes in Docker) qu’autre chose.

Le speaker a montré qu’il était possible d’émuler sans trop de bidouilles plusieurs clusters Kubernetes sur un même laptop avec KIND.

Meh.

A Deep Dive on Supporting Multi-Instance GPUs in Containers and Kubernetes

Même si j’en ai effectivement « un peu » besoin puisque j’ai des workloads GPU à administrer, ce talk était plus un talk plaisir qu’autre chose ;)

Dans ce talk, ça a parlé de GROS GPU, notamment les A100, et des outils que NVidia met à disposition pour les splitter en plusieurs GPU virtuels. Ca a parlé de MIG (Multi Instance GPU), de GPU Instance, de compute instance et de memory slices.

Comme c’est littéralement une des premières choses que j’ai essayé de faire lorsque j’ai commencé à travailler il y a 12 ans (même si c’était pas pour Kubernetes à l’époque, bien sûr), j’ai vraiment adoré ce talk même si je n’ai pas appris grand chose.

Ce qu’il faut retenir, c’est que « oui », c’est possible de splitter des GPU dans Kubernetes, mais que ce n’est pas trivial et qu’il y a plein de limitations (en tout cas pour l’instant) qui rende le splitting pas flexible pour un sou.

Si ça vous intéresse, je vous invite à lire les slides qui décrivent pas mal les problématiques que vous pourriez rencontrer.

Discontiguous CIDRs for Dynamic Cluster Scaling

Comme j’avais déjà eu par le passé des problématiques de CIDR trop petit dans un cluster Kubernetes, j’ai voulu voir ce talk donné par deux ingénieurs de chez Google cloud, par curiosité.

Même si j’ai appris quelques trucs sur les raisons de pourquoi on doit trasher un cluster si le clusterCIDR qu’on a choisi est trop petit, je n’ai pas été super emballé par la façon dont c’était présenté (« on vous montre ce qu’on veut proposer comme solution à ce problème pour le projet Kubernetes ») qui faisait plus promo de leur implémentation de solution qu’un réel talk pour expliquer.

C’était quand même intéressant, en faisant abstraction de l’aspect « campagne électorale », puisqu’on a deep dive sur la façon dont les CIDR sont affectés et les composants qui utilisent le cluster CIDR (nodeIPAM controller & kube-proxy).

Les talks que j’aurai aimé voir

Après m’être un peu cassé les dents sur un problème de liveness probe pétée avec Rook, j’aurais bien aimé pouvoir voir le talk Rook: Intro and Ceph Deep Dive de Satoru Takeuchi et Blaine Gardner, deux mainteneurs de Rook, en particulier sur la partie Ceph.

Les slides sont disponibles ici.

J’aurais aimé aussi voir Multi-tenancy vs. Multi-cluster: When Should you Use What? mais un collègue est allé le voir alors je suis sûr qu’il me fera un retour ;)

Conclusion

Malgré quelques points négatifs (j’y reviendrais dans un dernier article la semaine prochaine), faire une Kubecon en ligne n’était pas un exercice vain.

Je repars avec beaucoup d’idées, beaucoup de motivation. C’était donc compliqué car intense, mais utile.

Les intervenants et leurs talks (je mets de côté les keynotes) étaient de grande qualité et il n’y a pas eu de créneaux « creux » où je n’avais rien envie d’aller voir (c’était même plutôt le contraire).

J’ai hâte de refaire des conférences IRL (voire en tant que speaker qui sait ?).

En attendant, have fun ;-)

Kubecon Europe 2021 – Récap’ du jeudi

Thu, 06 May 2021 17:00:00 +0000

Deuxième jour de Kubecon

Hier, je vous faisais un petit résumé de la première journée de Kubecon !

Si vous ne l’avez pas lu, je vous conseille de commencer par là, car je ne vais pas refaire la petite intro avec le contexte.

Aujourd’hui, les talks ont été très condensés et j’ai fait un gros focus réseau / sécu, comme vous pourrez le voir dans la suite de l’article :)

Keynotes

Aujourd’hui, c’était moins dense en termes de nombre de keynotes.

La première keynote a été réalisée par Stephen Augustus, Co-Chair & Head of Open Source chez Cisco. Il a donné quelques nouvelles sur le projet Kubernetes. Le plus gros morceau est le fait qu’il ait été acté que la release cycle allait passer à 15 semaines, ce qui fait 3 releases par an maintenant au lieu de 4. Il a également parlé du fait que les SIGs doivent opt-in les modifications qu’ils veulent inclure dans chaque release et a aussi acté le retour des community meetings.

Les deux talks qui ont suivi étaient sans intérêt, avec un talk sponsorisé de Veeam très très basique sur la sécurité et un talk sur Linkerd qui sauve le monde du COVID-19, que j’ai trouvé plus que déplacé. Je ne me suis pas privé pour le dire sur Twitter d’ailleurs (lol).

Le talk suivant (sponsorisé aussi) rattrapait un peu le niveau, avec un focus sur Knative réalisé par Brenda Chan de chez VMware. Je n’ai pas encore regardé en détail ce qu’on pouvait faire avec knative et ce talk m’a donné envie de creuser le sujet.

La dernière keynote était assez intéressante, avec un REX sur l’intégration des projets cloud native par les équipes de Deutsche Telekom. Après avoir présenté les problèmes auxquels ses équipes ont du faire face, Vuk Gojnic a présenté Das schiff, la solution qu’ils ont implémenté pour déployer des clusters Kubernetes distribués (as a service).

What Do You Mean K8s Doesn’t Have Users? How Do I Manage User Access Then?

La journée a commencé plutôt soft avec un talk assez généraliste sur l’AuthN/AuthZ pr Jussi Nummelin de chez Mirantis. Il a pointé du doigt un vrai problème dans Kubernetes : il n’y a pas de gestion des utilisateurs humains a proprement parlé.

C’est d’ailleurs écrit noir sur blanc dans la documentation officielle de Kubernetes !

It is assumed that a cluster-independent service manages normal users –kubernetes.io/docs/reference/access-authn-authz/authentication/

Tout ce qui est authentification dans Kubernetes passe soit par certificat x509, soit par des tokens de service account soit par des webhook. Tout ceci est donc plutôt réservé aux pods, comptes de services et pas du tout adapté pour des personnes en chair et en os.

Je ne parlerai même pas de l’authentification ‘static token file’ qui est un réel scandale qui ne devrait même pas être utilisée en lab.

La seule option viable est donc bien l’implémentation d’une authentification tierce via un connecter OIDC comme Dex, par exemple.

github.com/dexidp/dex

FalcOMG That’s AWESOME - New Things, Fixed Things, and YOU Panel

Page de la session
[Slides](https://static.sched.com/hosted_files/kccnceu2021/a1/FalcOMG That)

Cette session avait pour but de présenter tout un tas de choses à propos du projet Falco. Pour rappel, Falco est un cloud-native security runtime, initié par Sysdig en 2016. Il utilise eBPF (encore lui) pour détecter voire empêcher les workloads suspects sur vos machines Linux (pas que Kubernetes donc). Les dernières parties qui manquaient ont été données par sysdig en février 2021 (kernel modules + ebpf probe + runtime security).

Après une longue introduction du projet (donné à la CNCF en 2018, accepté en tant qu’Incubating en 2020), deux mainteneurs (Leonardo Grasso et Leonardo Di Donato) ont présentés le processus de release ainsi que la façon dont les artefacts (cf falco open infra) sont générés automatiquement (plus de 3500).

L’équipe de falco est également très impliquée dans l’accès à cette technologie pour tous et recherche activement des traducteurs pour traduire le site et la documentation de falco dans le plus de langues possible. Le processus d’internationalisation a été présenté par Radhika Puthiyetath, technical writer chez sysdig. C’était assez intéressant de voir que le processus mis en place était assez simple et donc accessible au plus grand nombre.

Enfin, l’outil falco sidekick a été présenté par Thomas Labarussias, SRE chez Qonto. Il s’agit d’un démon permettant de collecter l’ensemble des événements transmis par falco (présent sur tous vos nodes kube par exemple) et de les forwarder à une 30aines d’outputs différents en fonction de certaines règles.

On peut ainsi mettre en place de l’alerting ou loguer les événements dans des SIEM ou des moteurs de recherche (Elasticsearch) pour traitements ultérieurs par exemple.

Uncovering a Sophisticated Kubernetes Attack in Real-Time

Troisième talk de la journée sur la sécurité !!! Natália Réka Ivánkó (Security Engineer chez Isovalent) et Jed Salazar (Manager, Platform Security chez Tesla) nous on présenté un panel assez large de risques de sécurité et de vecteurs d’attaques accessibles depuis un cluster Kubernetes.

Après avoir balayé très rapidement les solutions classiques pour réduire les risques (Distroless base images, OPA, pas de shells pour réduire la surface d’attaques, analyse statique des images et analyse au runtime), ils ont cherché à comprendre ce qu’on pouvait faire de plus.

On peut aussi appliquer à la sécurité le mindset « devops » (on parle parfois de devsecops) en considérant que ce qu’on a mis en place en termes de sécurité doit être (1) testé et (2) observé.

Et selon eux, le meilleur outil pour le faire, c’est eBPF. Ils nous ont donc ensuite présenté plusieurs scenarii d’attaques dans lesquels Cilium (eBPF-based Networking, Observability, and Security) était utilisé pour connecter, surveiller et sécuriser les événements sur le réseau de kubernetes.

Le talk était riche et dense et il est extrêmement dur pour moi de le résumer ici. Je serais probablement amené à en reparler sur le blog tant le sujet est pléthorique.

How to Break your Kubernetes Cluster with Networking

J’ai vraiment adoré le talk précédent mais alors celui là c’est le meilleur que j’ai vu depuis le début de cet Kubecon. Thomas Graf, en plus d’être un excellent pédagogue est un excellent speaker. C’est le CTO d’Isovalent (tiens tiens tiens, encore eux !) et il est core member du projet Cilium (encore lui !).

Là aussi, le talk était extrêmement dense et Thomas Graf s’est employé à brosser toutes les façons de casser son cluster Kubernetes avec le réseau. Cela va de bête erreurs DNS à l’utilisation de kube-proxy + iptables en passant par des CRD watchers qui DDoS votre API server et en finissant par des histoires d’horreur de changement de CNI (ou double run) qui cassent tout le réseau du cluster (kids, don’t do this at home).

Une fois de plus, le talk était tellement dense qu’il est difficile de le résumer. Ce qu’on peut en retenir simplement, c’est que le mieux est encore de rester le plus simple possible dans la limite de vos besoins et de ne pas ajouter trop de couches juste parce qu’elles sont « shiny ». (Et je suis évidemment à 100% d’accord).

Oooooooh! Shiny ones!

Les talks que j’aurai voulu voir

Je l’ai déjà dit hier, choisir c’est renoncer.

Si j’avais pu, je serai également allé voir BuildKit CLI for kubectl: A New Way to Build Container Images par curiosité pour l’outil, que je ne connais pas. Mais les dieux du scheduling en ont voulu autrement (c’était pendant la présentation sur Falco).

Fin de la journée

Si on peut appeler ça la fin de la journée puisque le dernier talk a fini vers 15h ;-) mais en vrai c’était tellement intense il y avait pas mal à débriefer.

Maintenant qu’on est au 2/3 de la Kubecon, je vois 2 sujets prioritaires qu’il va falloir que j’investigue sérieusement :

la partie eBPF, avec un vrai choix technique côté CNI (test de Cilium à faire absolument) et évaluation des outils de sécus basés sur des programmes BPF
la partie CI/CD avec flux, flagger, litmus (mais plutôt réservée pour mes copains ingés CI/CD, je ne ferai que suivre le mouvement)

On verra si la journée de demain changera un peu ces priorité ou pas (probablement que non).

Et en attendant, have fun :)

KubeCon Europe 2021 – Récap’ du mercredi

Wed, 05 May 2021 18:24:05 +0000

(Mon) Premier jour de Kubecon

C’est la deuxième fois que je participe directement à une Kubecon (j’avais fais un récapitulatif quotidien de la Kubecon 2018 à Copenhague).

Cette année, comme l’an dernier, c’est en ligne ue ça se passe, bien entendu (COVID-19 oblige). Elle se déroule toute la semaine du 03 au 07 mai.

Le 03 était dédié aux « co-located conferences » (notamment la PromCon que j’ai faillis faire aussi mais finalement c’était trop intense). La journée de Mardi (hier) était dédiée majoritairement à des événements sponsorisés (j’ai juste vu un deep dive sur le Networking dans Kubernetes).

Ce mercredi (le 05) est donc le premier vrai jour de la Kubecon, avec une série de keynotes en début de journée, suivi d’un condensé de talks en simultanés (minimum 10 pour chaque créneau horaire).

Il a donc fallu faire des choix (et choisir, c’est renoncer) T_T.

Keynotes

Comme dans toutes les conférences, la journée commence donc par des keynotes. Là, ce n’est pas moins de 8 keynotes (!!!) qui se sont enchaînées de 10h à 12h.

La Kubecon a commencée par un talk (un peu surjoué) de Priyanka Sharma, General Manager de la CNCF. Elle nous a vanté les bienfaits des projets de la CNCF dans la lutte contre la crise sanitaire mondiale et l’accélération apportée par les logiciels la composant pour les startups et les grandes entreprises de la tech (mouais). Elle a également, avec Zain Asgar de New Relic le don de Pixie (observabilité) à la CNCF.

Cheryl Hung a ensuite interviewé 6 entreprises qui contribuent en tant qu’End Users à la CNCF et a décerné le prix du End User de l’année à Spotify, notamment pour sa contribution de Backstage, une plateforme de portail de développement assez intéressante.

Jim Haughwout, VP chez Peloton a parlé de la manière dont les outils de la CNCF, en particulier Kubernetes, leur ont permis de soutenir leur croissance à 3 chiffres de cette année. Il indique notamment que Peloton a switché la totalité de son trafic externe en juste 1 an (de 0% à 100% sur Kubernetes).

Stefan Prodan, Developer Experience Engineer chez Weaveworks a fait un rapide talk sur Flux et ce qu’il apporte aux développeurs. Ça m’a beaucoup intéressé et j’ai d’ailleurs participé à une AUTRE conférence animée là aussi par Weaveworks sur Flux plus tard dans la journée.

Rapidement, je cite aussi 2 keynotes sponsorisées (IBM et Redhat… donc… IBM !) qui ne m’ont pas laissé un souvenir impérissable (meh).

La keynote de la Kubecon s’est terminée sur un talk de Liz Rice (Isovalent) et Lei Zhang (Alibaba) sur les « prédictions » du Technical Oversight Committee. Globalement, encore beaucoup de projets arrivent très fort sur des sujets comme les services Mesh, la sécurité mais aussi la dev experience / ops experience.

Ce dernier point m’a vraiment fait tiquer… Qu’est-ce que ça dit sur l’écosystème CNCF quand 11 projets arrivent dans l’écosystème pour faciliter l’adoption des autres ?

Sandbox

Je ne l’ai pas listé dans la section précédente, mais une des Keynotes était animée par Justin Cormack, (CTO Docker).

Il a égrainé tous les projets en Sandbox, plusieurs dizaines ! Il y aurait moyen de faire un article rien que sur cette liste, je vais me contenter de juste lister les projets qui ont le plus retenu mon attention :

Tremor pour l’event processing, permet de remplacer logstash :trollface:
Backstage portail de développement, véritable boite à outils avec plein de features comme un catalogue de logiciels internes, des outils pour faciliter le templating de projets, les docs, …
k3s comme distribution de kube IoT/edge (j’adore)
crossplane, qui facilite l’extension de l’API de Kubernetes
Dex, un portail OpenID Connect pour faciliter l’ajout d’authentification tierce dans Kubernetes
Metal3.io et tinkerbell pour le provisionning de Kubernetes sur du baremetal
Trickster, qui sert entre autre à mettre en cache des TSDB

Un extrait des projets en sandbox

Introduction and Deep Dive into Containerd

Les keynotes passées, j’ai juste eu le temps de me faire des pâtes (moins de 20 minutes de pause, la Kubecon c’est hardcore), pour enchaîner sur un deep dive sur containerd !

Kohei Tokunaga et Akihiro Suda, deux ingénieurs chez NTT, nous ont dans un premier temps présenté l’architecture de containerd.

Containerd est donc un container runtime de la CNCF au status Gratuated depuis 2019. Il est disponible sur Linux et sur Windows, et peut être utilisé par Docker, Kubernetes ainsi que des applications tierces via des clients. Il est utilisé par la plupart des gros cloud providers pour leurs Kubernetes managés.

Point intéressant, on peut interagir avec containerd de deux manières : soit avec la containerd API (utilisé par Docker), soit au travers de la CRI (container runtime interface) pour Kubernetes.

Containerd disposent de composants permettant de réaliser les tâches nécessaire à la containerisation (content store pour les images, snapshotter pour gérer les layers et les FS sous-jacents, runtime pour communiquer avec les runtimes supportés).

source : containerd.io

Une fois l’architecture du projet présentée, les deux présentateurs ont fait un focus plus poussé sur l’implémentation de clients (la plupart du temps en Go) pour réaliser des applications tierces qui interagissent avec containerd.

Je vous laisse lire les slides plus en détails si cette partie vous intéresse.

Helm Users! What Flux 2 Can Do For You

Cette session dédiée à ce que Flux 2 peut apporter aux utilisateurs de Helm était très prometteuse. Je ne me suis pas beaucoup penché sur les aspects CI/CD dans Kubernetes et j’ai beaucoup râlé sur Helm (dont un article il y a peu sur Helm 2).

La phrase à retenir du talk est je pense :

Helm is imperative, Flux is declarative

L’aspect sur lequel les deux ingénieurs de chez Weaveworks ont bien insisté c’est donc cette reconciliation loop qui fait toute la différence. On bascule de l’Ops au GitOps. Du manuel à l’automatisation et à l’idempotency.

La plus grosse partie de la présentation était une démo live de ce qu’on peut faire avec Flux et ce que cela apporte par rapport à du Kustomize ou du Helm. Et en 30 minutes, c’est vrai que c’était assez bluffant. La réconciliation peut s’appliquer régulièrement ou via l’utilisation de webhooks programmable.

Il existe également un composant (flagger) chargé de communiquer avec les IngressController ou service mesh de notre Kubernetes pour automatiser toute la partie le canary / A/B testing, …

Vraiment très hypé par cet outil, à tester d’urgence.

Multi-Tenancy in Kubernetes: How We Avoided Clusters Sprawl With Capsule

Page de la session
Slides (1 et (2)

J’étais un peu sceptique sur le fait que cette session soit découpée en 2 présentations distinctes mais finalement c’était très fluide / agréable.

La première partie de la présentation présentée par Dario Tranchitella de CLASTIX.io (société qui a créé Capsule), se concentrait sur la présentation de l’outil en lui même. Capsule est un operator permettant d’introduire une notion de multi-tenancy dans Kubernetes (absente par défaut).

Si Dario a d’abord insisté sur le fait que beaucoup de ce qui est implémenté dans Capsule peut être fait soit-même, à la main, il faut reconnaître que c’est beaucoup de travail. Et surtout que Capsule permet s’abstraire toutes les règles d’isolation que l’on souhaite, très simplement dans une CRD très claire.

La deuxième partie était un case study de la mise en place de l’outil chez Wargaming (éditeur de World of Tanks) qui dispose d’équipes de développement internes vues comme des clients par l’infra. L’utilisation de Capsule leur a permis de fournir à leurs clients (internes) des clusters en apparence distincts tout en ayant à gérer qu’un seul gros cluster par région (et une réduction du toil).

L’outil semble très prometteur et même si je ne suis pas bien sûr d’en avoir l’utilité, mérite d’être regardé avec attention.

eBPF on the Rise

Je ne m’étais pas encore intéressé à eBPF mais comme de plus en plus d’outils tirent parti d’eBPF (avec des fonctionnalités quasi magiques pour le profane), il était plus que temps de s’y intéresser. Je n’ai pas été déçu car l’intervenant, Quentin Monnet (ingénieur logiciel chez Isovalent) était excellent.

eBPF (pour extended Berkeley Packet Filter) est un moteur permettant de passer des appels systèmes bpf depuis l’userspace vers le kernel space, de manière efficace et sécurisée.

Cela permet d’avoir une vision très poussée de ce qui se passe sur la machine et c’est notamment ce qui permet aux outils de tracing/profiling d’obtenir des informations si précises sur ce qui se passe sur un host Kubernetes (ce que fait falco par exemple).

Un autre usage d’eBPF se situe sur l’aspect réseau. On peut faire beaucoup de chose comme du traffic control, de l’anti-DDOS et même optimiser le chemin réseau utilisé par les pods d’un cluster Kubernetes pour communiquer entre eux (Cilium Datapath)

La comparaison pod-to-pod via iptables versus eBPF pique… Quel sac de nouilles !

Bref, visiblement les possibilités sont folles et je vais devoir dig encore un peu pour bien comprendre ce qu’on peut faire avec ;-p.

Les sessions que j’ai loupé

Je l’ai dit en début d’article, choisir, c’est renoncer. Malheureusement, je ne suis pas capable de suivre 2 (ou 3) streams de Kubecon à la fois… J’ai donc « loupé » deux conférences qui m’auraient intéressé :

Get In Containerds, We’re Going Securing: Kubernetes SIG Security is Here!
Animée entre autre par Ian Coldwater, cette table ronde avait pour but de présenter le SIG dédié à la sécurité. A priori la session présentation était assez légère (genre vraiment niveau débutant) mais la partie Q+A était hyper intéressante… too bad.

Du beau monde

CSI Volume Attacks – The SRE Strikes Back
Une présentation des « failles » facilement exploitables au niveau du stockage dans Kubernetes. C’était probablement un peu léger là aussi, mais ça fait du bien de revoir les bases parfois. Dommage.

Demain, c’est loin !

Passer la journée sur son laptop devant des confs en anglais (avec l’accent de tous les pays du monde) et finir la journée par un récap’, c’est assez ambitieux ;-)

Mais je commence à connaître maintenant donc je vais essayer de tenir le rythme et de refaire un article sur la Kubecon demain et un autre lundi (car vendredi soir, c’est Koh lanta, faut pas déconner).

Alors en attendant, have fun !