Home >> Blog >> KubeCon Paris 2024 – Intelligence Artificielle avec Kubernetes et l’Avenir Cloud Native

KubeCon Paris 2024 – Intelligence Artificielle avec Kubernetes et l’Avenir Cloud Native

07 avril 2024

By Yann Albou.

Une kubecon sous le thème de l’AI en fêtant les 10 ans de Kubernetes !

Quel événement cette année ! Le plus grand de toute l’histoire de la Cloud Native Computing Foundation (CNCF) ! avec plus de 12 000 personnes !
Même en 3 jours de conférence, il était difficile de faire le tour, énormément de conférences, sponsors, discussions, soirées sponsors, …
Déjà plus de 10 ans de Kubernetes !
A cette occasion la CNCF propose que vous soumettiez votre logo du 10ème anniversaire de Kubernetes!: https://www.linuxfoundation.org/kubernetes-10-year-logo-contest

Sans surprise, le thème majeur de la Kubecon était l’Intelligence Artificielle en mode Cloude Native avec Kubernetes, mais pas que !
Voici un résumé, non exhaustif, des conférences qui m’ont intéressé en regroupant par thématiques:

  • Intelligence Artificielle: « Kubernetes doit devenir le standard de l’IA »
  • Supply Chain: une plateforme unique !
  • WASM: La tendance WebAssembly
  • Sustainability: l’innovation responsable
  • Infrastructure-as-Code: L’Invisible Omniprésent !
  • Observabilité et OpenTelemetry
  • Platform Engineering: le retour d’expérience
  • Kubernetes: évidemment !
  • Securité: reste un sujet majeur

Intelligence Artificielle: « Kubernetes doit devenir le standard de l’IA »

La première keynote de Priyanka Sharma (Executive Director, Cloud Native Computing Foundation) s’est ouverte sur l’Intelligence Artificielle.
Le cloud Native n’échappera pas à cette tendance AI mais à clairement besoin de standards et d’outils.
Clairement, tout ça est en route et prendra une part importante dans cette accélération de l’IA avec le partage de modèles, de processus et de savoir-faire:

« Kubernetes doit devenir le standard de l’IA », Priyanka Sharma.

Training & Inference

L’entraînement est la première phase d’un modèle d’IA. Le « training » peut impliquer un processus d’essais et d’erreurs, ou un processus consistant à montrer au modèle des exemples d’input et d’output.
La phase d’inférence représente l’exécution d’un modèle une fois qu’il a déjà été entraîné. Ainsi, l’inférence intervient après les étapes d’apprentissage. On peut également parler de phase de déploiement sur le terrain du modèle d’IA. Et donc, à cette étape, le modèle d’intelligence artificielle est déjà pré-calculé et a déjà été modélisé à l’aide de jeux de données (data sets). Ainsi, à ce moment, les systèmes d’intelligence artificielle peuvent tirer des conclusions ou des prédictions à partir des données ou connaissances qu’ils ont apprises.

Kubernetes et la CNCF se positionnent maintenant sur l’ensemble et utilisent la plateforme d’orchestration aussi bien pour gérer le cycle de vie du Machine Learning (AI/ML/LLM Ops) que pour faire tourner les modèles et les applications.
Un nouveau groupe de travail de la CNCF, la Cloud Native AI a publié un livre blanc sur les aperçus des techniques récentes d’IA/ML.

Introduction à l’initiative Cloud Native Artificial Intelligence (CNAI):
Broken Chain

Cette tendance amène des évolutions de Kubernetes en particulier sur :

  • Le support des GPU : En particulier avec les drivers Nvidia
  • Nouvelles techniques de partage de GPU pour maximiser son utilisation
  • Dynamic Resource Allocation (DRA) : Nouvelle façon de demander des ressources disponibles dans k8s 1.26+
  • Apparition de nouveaux outils/opérateurs Kubernetes : exemple avec KAITO : Kubernetes AI tools operator qui simplifie l’expérience d’exécution de modèles OSS AI sur vos clusters AKS
  • Optimisation en utilisant des LLMs locaux : Ollama

Self-Hosted LLMs on Kubernetes: A Practical Guide – Hema Veeradhi & Aakanksha Duggal, Red Hat

Les modèles de langage de grande taille (LLMs) gagnent rapidement en popularité et l’idée de déployer et de gérer son propre LLM peut être très intéressant, surtout en matière de sécurité, confidentialité, et customisation. Ce talk nous guide à travers le processus vers une compréhension claire et pratique de l’auto-hébergement des LLMs sur Kubernetes.

Auto-hébergement : Avantages et Considérations

  • Pour ou contre l’auto-hébergement ? Cela dépend de cas d’usage spécifiques. Les modèles hébergés peuvent être nécessaires pour des raisons de confidentialité, de fiabilité ou de conformité.
  • Avantages de l’auto-hébergement :
    • Sécurité, confidentialité et conformité accrues.
    • Personnalisation avancée.
    • Évite le verrouillage par un fournisseur.
    • Réduction des coûts computationnels.
    • Facile pour les débutants ou ceux qui commencent tout juste dans le domaine.

Implémentation:

Hosted LLM

Voici la liste des LLMs Opensource
et un papier sur « tracking openness of instruction-tuned LLMs

Voir la vidéo de cette session

Future of Intelligent Cluster Ops: LLM-Azing Kubernetes Controllers – Rajas Kakodkar, VMware & Amine Hilaly, AWS

Une autre manière d’utiliser l’IA et les LLMs est l’utilisation des modèles de langage pour améliorer les opérations sur Kubernetes. Ils ont intégré les LLMs avec les CRD et controllers Kubernetes via un opérateur LLMnetes permettant de simplifier la gestion de cluster au travers une interface de langage naturel ressemblant à :

  • Scan images for pods and deployments
  • Break my cluster load balancers
  • Deploy a CronJob that will delete pod randomly in the cluster every 2 hours

Ce projet souhaite aller plus loin avec des questions du type « Can I upgrade my cluster in 1.29 ? » qui nécessitera d’analyser les journaux d’audit, les ressources du cluster et lire le changelog.md des versions de k8s.

Attention : les LLM ne sont pas déterministes ! ! !

Comme mentionné : Évitez d’interroger un modèle d’apprentissage automatique pour des tâches nécessitant des données précises.

Voir la vidéo de cette session

Supply Chain: une plateforme unique !

Le build et le delivery restent des tendances fortes de la KubeCon avec des évolutions pour tenir compte du MLOps mais aussi beaucoup de conférences sur les aspects de sécurisation de la Supply Chain.

La keynote de Solomon Hykes (CEO, Dagger.io) sur le « Future of Application Delivery in a Containerized World » a retracé les 10 ans d’évolution de Kubernetes avec un message fort sur l’amélioration continue de l’usine logicielle, qui doit servir vos besoins et être un lieu central pour amener votre entreprise à un niveau supérieur comme un élément clé différenciateur :

Every Factory is Unique

En considérant aussi l’usine comme une plate-forme (là encore, l’ingénierie des plates-formes joue un rôle essentiel – on en reparle plus bas).

SLSA: Supply-chain Levels for Software Artifacts

Plusieurs conférences très intéressantes autour des bonnes pratiques pour se prémunir au maximum des « Supply Chain Attacks ». Nous avions fait un blog sur cette thématique « Comment se protéger d’une “Supply Chain Attack” ? ».

En particulier le framework de sécurité SLSA a été mis en avant:

SALSA (en version 1.0) définit les lignes directrices pour la sécurité de la chaîne d’approvisionnement avec différents niveaux et contient plusieurs « Tracks » en particulier la « Build track » qui se focalise sur la provenance (du source à l’artefact):

Chain of Trust ?

Scanner nos artefacts à la recherche de vulnérabilités est une excellente chose mais pas suffisant, il faut aussi se prémunir des problèmes de falsification de l’ensemble des éléments.

Alors comment augmenter le niveau de confiance de nos chaînes d’approvisionnement logiciel ? Et sur quoi repose ces approches :

  • Attestation: Une déclaration authentifiée (via des métadonnées) sur un artefact logiciel ou une collection d’artefacts logiciels
  • Signature: garantit que les artefacts n’ont pas été modifiées ou compromises lors de leurs distributions.
  • SBOM (Software Bill of Materials): est essentiellement un inventaire détaillé de tous les composants logiciels dans un produit logiciel. Cela inclut les bibliothèques, modules, packages et autres dépendances.

Voici quelques outils utilisé

  • In-toto: Pour gérer et générer les attestions
  • Sigstore/cosign: Pour signer des logiciels, des attestations, des SBOM et d’autres métadonnées
  • SPIFFE/Spire: pour construire des « workload identities »
  • [TUF](The Update Framework): pour fournir un cadre qui peut être utilisé pour sécuriser les systèmes de mise à jour logicielles nouveaux et existants ainsi que de fournir les moyens de minimiser l’impact des compromissions de clés.
  • Vault: Pour la gestion des secrtes et de la PKI
  • Docker BuildKit: pour générerer les attestations (au format json in-toto) et la sbom
    docker buildx build --sbom=true --provenance=true ...

Il y a vraiment beaucoup d’outils pour sécuriser cette CI/CD:

SLSA Tooling

La CNCF travail sur un document pour mapper ces outils

N’oubliez pas non plus qu’il faut sécuriser votre code source ! En signant vos commits, protégeant vos branches, ayant une RBAC adaptée, une authentification via MFA, utilisation des clés SSH…

Pour démontrer l’ensemble la CI/CD Tekton avec les Tekton Pipeline a été souvent utilisée.

A noter aussi l’existence du projet FRSCA une « Factory for Repeatable Secure Creation of Artifacts: FRSCA » qui fournit des outils et une implementation du projet de la CNCF Secure Software Factory Reference Architecture et qui suit les recommandations SLSA.

Supply Chain: La maturité de construction et de déploiement des containers

Les pratiques de CI/CD autour des conteneurs se renforcent et gagnent en maturité. Trois conférences ont particulièrement attiré mon attention :

Building Container Images the Modern Way – Adrian Mouat, Chainguard

La conférence sur la construction des images docker de façon moderne a comparé plusieurs approches pour construire des images docker.
En partant de « l’ancienne manière » avec un Docker Build (qui produit des images qui ne sont pas reproductibles, trop volumineuses et avec beaucoup de CVEs)

FROM golang
WORKDIR /work
COPY . /work
RUN go build -o hello ./cmd/server
ENTRYPOINT ["/work/hello"]

Pour aller vers une approche « Distroless Multistage Docker Build » de façon à n’avoir que le strict minimum dans l’image sans package manager ni shell…

Les images distroless sont construites avec

  • Ko build: Spécifique aux images Go
  • Bazel: Par Google, et permet de produire des bonnes images distroless mais reste complexe à appréhender.
  • Chiselled Containers; par Canonical basé sur Ubuntu pour Java et .Net
  • Buildpacks: CNCF projet utilisant un language toml pour produire les images (moins légères que les autres)
  • Dagger avec Buildkit: Projet CI/CD bien plus large que la construction d’images
  • Nix: permet de produire des bonnes images distroless mais difficile de s’y retrouver: trop de manières de faire les choses.
  • Apko & wolfi: par Chainguard permet aussi de produire des bonnes images distroless mais de manière plus simple:
    contents:
    repositories:
    - https://dl-cdn.alpinelinux.org/alpine/edge/main
    packages:
    - alpine-base
    entrypoint:
    command: /bin/sh -l
    environment:
    PATH: /usr/sbin:/sbin:/usr/bin:/bin

Misconfigurations in Helm Charts: How Far Are We from Automated Detection and Mitigation? – Francesco Minna, Vrije Universiteit Amsterdam & Agathe Blaise, Thales SIX

Dans cette session, ils ont présenté plusieurs outils permettant de vérifier la conformité des charts Helm, dont Checkov, Datree, KICS, Kubelinter, Kubeaudit, Kubescape et Terrascan.
Ces outils testent et examinent si les charts Helm respectent les bonnes pratiques en particulier en matièrer de sécurité.

Helm Chart tools

Le référentiel suivant contient une liste de Chart Helm public et a été utilisé pour tester les outils: https://github.com/fminna/mycharts

Plusieurs points intéressants ont été soulevés :

  • La plupart des projets nécessitent des autorisations ou des capacités Linux supplémentaires
  • Les erreurs de configuration les plus courantes sont ClusterRoles, limite de mémoire, NS par défaut

Misconfigurations in Helm Charts

Par rapport aux outils les feedbacks sont:

  • Les analyseurs de Chart Helm nécessitent toujours une intervention manuelle importante
  • La même atténuation peut satisfaire un outil mais pas un autre (règles qui se contredisent)
  • Résultats faussement négatifs/positifs

Voir la vidéo de cette session

GitOps Continuous Delivery at Scale with Flux – Stefan Prodan

Suite à l’annonce sur Weavework annonçant que la société stoppait son activité, ont pouvait sérieusement s’inquiéter de la suite du produit GitOps Flux.

Cette présentation était rassurante sur l’avenir de ce produit:

  • De nombreuses fonctionnalités passent en GA prochainnement
  • Nouvelles fonctionnalités planifiées : Notary Project integrations, CDEvents integrations, Helm OCI improvements, …
  • Beaucoup de travail sur l’optimisation: “Mean Time To Production” benchmark, Horizontal scaling, Flux sharding for multi-cluster delivery, …

Si a cela on rajoute le fait que Flux est un projet de la CNCF et qui est passé au niveau de maturité « Graduated » le 30 novembre 2022 cela nous permet de garantir une certaine pérénité de la solution !

Voir la vidéo de cette session

WASM : La tendance WebAssembly

Ce n’est pas une technologie nouvelle mais elle était fortement présente durant la KubeCon et en particulier lors de la première keynotes.

WebAssembly est un format standard d’instruction binaire conçu pour remplacer JavaScript avec des performances supérieures. Le standard consiste en un bytecode, sa représentation textuelle et un environnement d’exécution dans un bac à sable compatible avec JavaScript. Il peut être exécuté dans un navigateur Web et en dehors
De nombreux langages de programmation possèdent aujourd’hui un compilateur WebAssembly, parmi lesquels : Rust, C, C++, C#, Go, Java, Lua, Python, Ruby, …

WebAssembly est très efficace, rapide et sécurisé ce qui le rend compatible avec le monde Cloud Native.

Leveling up Wasm Support in Kubernetes – Matt Butcher, Fermyon

cette conférence, explore l’utilisation de WebAssembly dans Kubernetes au travers d’un outil SpinKubepin

Les forces de WebAssembly:

  • Security sandbox
  • Cross-platform, cross Architecture
  • Démarrage et exécution très rapide
  • Peut supporter n’importe quelle language

Fermyon, positionne WASM comme une évolution des containers pour des usecase adaptés:
WASM

En particulier, pour le pattern Serverless: Les conteneurs sont excellents pour exécuter des processus de longue durée, mais avoir une techno type WASM pour du Serverless qui peut démarrer à froid instantanément, s’exécuter jusqu’à la fin et s’arrêter.

Comment cela fonctionne:

  • Spin est un projet open source pour construire des applications WebAssembly Serverless
  • SpinKubepin: exécute des applications Spin dans Kubernetes

Spinkube contient tous les éléments nécessaires pour faire tourner les applications WASM Spin dans k8s en se reposant sur les projets runwasi (pour la partie shim de containerd) et Kwasm pour la partie opérateur.

WASM Spin Architecture

Il y a eu clairement un fort intérêt pour WASM et SpinKube de part les performances et son intégration dans le monde Cloud Native:
Performance WASM Spin

Voir la vidéo de cette session

Sustainability: l’innovation responsable

On parle d’Intelligence Artificiel mais avons nous oublié le thème de l’année dernière sur la durabilité et l’éco-responsabilité ?

Le discours d’ouverture a appelé à « l’innovation responsable » : continuez à innover, mais faites-le en utilisant l’open source et en gardant à l’esprit les économies de coûts et d’énergie.

Les projets comme WASM vont dans ce sens, et les modèles de LLM rentrent dans un cycle d’optimisation de leur modèle, est-ce suffisant pour autant ?

Building IT Green: A Journey of Platforms, Data, and Developer Empowerment at Deutsche Bahn

Cette session montre des cas d’utilisation réel en entreprise sur la durabilité chez Deutsche Bahn.

Ils ont d’abord procédé à une optimisation entre l’utilisation moyenne du CPU machine et le CPU réel utilisé par l’application en forçant l’utilisation de la définition des requests et limits ainsi que l’utilisation des VPA (VerticalPodAutoscaler).
Puis ils ont utilisé des scheduleurs pour réduire ou arrêter les workloads qui ne servent pas pendant les heures non travaillées ou de moindre activitées…
En plus d’économiser beaucoup d’énergie cela permet aussi d’économiser de l’argent.

La mesure des coûts énergétiques est faite avec le projet Kepler:
Kepler

Cela permet de mesurer les impacts par projet ou même mesurer l’impact d’un changement à l’autre, et ainsi avoir un empreinte carbone globale et cibler.
Ces dashboards font maintenant partis de la vie des projets et constituent des informations pouvant influencer certaines décissions…

Voir la vidéo de cette session

Cloud Native Sustainability Efforts in the Community – TAG Environmental Sustainability – Antonio Di Turi, Data Reply Gmbh & Kristina Devochko, Independent

Le TAG Environmental Sustainability soutient des projets et des initiatives liés à la fourniture d’applications cloud natives, notamment leur création, leur packaging, leur déploiement, leur gestion et leur exploitation.

alt text

Les objectifs de ce groupe sont:

  • Fournir des ressources grâce à un processus et une méthodologie d’examen pour aider les projets du CNCF à évaluer leur empreinte de durabilité et à intégrer des pratiques de durabilité environnementale.
  • Collaborer avec les responsables du projet CNCF pour produire des analyses significatives de l’empreinte durable.
  • Communiquer les résultats des évaluations de durabilité cloud native des projets.

Le score SCI aidera à calculer l’intensité carbone des logiciels:
score SCI

Et le but étant de produire ces métrics:
Sustainability metrics

Le projet Falco a demandé sa première revue « Green » et d’autres projets de la CNCF vont suivres.

Voir la vidéo de cette session

Observabilité et OpenTelemetry

Beaucoup de tracks sur l’observabilité avec en particulier un focus sur Opentelemetry mais aussi sur l’IA.

OpenTelemetry: Project Updates, Next Steps, and AMA – Severin Neumann, Cisco; Austin Parker, Honeycomb; Trask Stalnaker, Microsoft; Daniel Gomez Blanco, Skyscanner; Alolita Sharma, Apple

Le projet OpenTelemetry est partout et largement utilisé

OpenTelemetry

Juste sur le mois précédent cette KubeCon il y a eu 25 000 contributions !!!
Bref sa popularité n’est plus à démontrer.

News côté logging:

  • Stable logging SDK: C++, .Net, Java et PHP
  • Experimental logging SDK: Go, JS, Python, Rust, Erlang/Elixir

OpenTelemetry définit des « Semantic Conventions » qui spécifient des noms communs pour différents types d’opérations et de données ce qui permet d’amener des standards sur le codebase, les librairies et les plateformes.
Les Semantic Conventions sont disponibles pour les traces, metrics, logs et ressources le tout en version stable pour la partie HTTP.
Et travail en cours sur les parties Databases, Messaging, RPC, System et le nouveau petit dernier AI/LLM !!!

Extension des signaux OpenTelemetry sur la partie « Client-side » et pas seulement au niveau applicatif et infrastructure.

Définition d’un nouveau concept « Entity » pour mieux représenter le producteur de la télémétrie.

Le projet OpenTelemetry a postulé pour être un projet « Graduated » de la CNCF et ainsi démontrer sa stabilité et sa maturité.

Voir la vidéo de cette session

Observability TAG: A Review and the Rise of Gen-AI Observability – Alolita Sharma & Matt Young, Apple; Vijay Samuel, eBay; Bartłomiej Płotka, Google

Le groupe de travail « Observability TAG » vise à enrichir l’écosystème des projets liés à l’observabilité dans les technologies natives du cloud, en identifiant les lacunes, en partageant les meilleures pratiques, en éduquant les utilisateurs et les projets CNCF, tout en offrant un espace neutre pour la discussion et l’implication communautaire.

L’observabilité Whitepaper est disponible.
Il se concentre sur l’amélioration de l’observabilité dans les systèmes cloud-natifs, offrant une vue d’ensemble des signaux d’observabilité, tels que les métriques, les logs et les traces, et discute des meilleures pratiques, des défis et des solutions potentielles. Il vise à clarifier le concept d’observabilité, fournissant des informations précieuses pour les ingénieurs et les organisations cherchant à améliorer la fiabilité, la sécurité et la transparence de leurs applications et infrastructures cloud-natives.

Le TAG observability a co-sponsorisé le Cloud Native AI workgroup (voir le chapitre AI plus haut) et a revu plusieurs projets autour de l’AI:

  • OpenLLMetry: ensemble d’extensions construites sur OpenTelemetry qui vous offrent une observabilité complète sur votre application LLM.
  • K8sGPT: outil pour analyser vos clusters Kubernetes, diagnostiquer et trier les problèmes dans un anglais simple
  • Logging Operator: Il résout les problèmes liés au logging dans les environnements Kubernetes en automatisant le déploiement et la configuration d’un pipeline de logging Kubernetes.

Il y a clairement une tendance « Observability + Gen AI » afin de :

  • Détecter d’une anomalie
  • Analyser des tendances
  • Compréhension du Distributed Tracing
  • Qualité des données
  • Analyse de la cause originelle
  • Suggestions pour les prochaines étapes

Observability + Gen AI

Voir la vidéo de cette session

Infrastructure-as-Code: L’Invisible Omniprésent !

L’IaC n’était pas une tendance de la conférence, il n’y avait pas de session dédiée par exemple à Terraform ou Ansible.
Par contre dans la plupart des conférences ces outils d’Infra-as-Code étaient utilisés comme socle de base !

De plus il y a quand même 2 points notables sur ce domaine:

Le premier concerne les multiples échanges et discussions informelles autour de Terraform suite au changement de licence par HashiCorp (Business Source Licence: BSL v1) qui a amené à un fork de la release 1.5 de Terraform pour créer le projet OpenTofu !

  • Quelle va être le posittionnement d’Hashicorp ?
  • Faut-il migrer nos projets Terraform vers OpenTofu ?
  • Les versions vont-elle diverger ?
  • Y aura t il une compatibilité Terraform <-> OpenTofu ?
  • Quid du Support ?
  • Le modèle OpenSource peut-il vivre en gagnat de l’argent ?

Terraform est fortement implanté dans les entreprises et projets et selon l’évolution de ces 2 projets, cela pourra amener beaucoup de changement… A suivre

Le second point concerne la forte présence de Crossplane qui gagne sérieusement en popularité et qui est, sans aucun doute, un projet très intéressant.

Crossplane Intro and Deep Dive – the Cloud Native Control Plane Framework – Jared Watts & Philippe Scorsolini, Upbound

Crossplane est un outil d’IaC qui se définit comme un « Cloud Native control plane » pour provisionner et gérer toutes vos ressources en se basant sur Kubernetes !

C’est un projet très implanté dans l’éco-système de la CNCF et surtout production ready:
Crossplane IaC

Toutes les ressources sont gérées depuis kubernetes au travers de CRD et Crossplane gère la communication vers des ressources externes comme AWS, Azure ou Google Cloud.

Crossplane architecture

Il existe un Marketplace communautaire avec une liste de providers dont certains sont donnés par Upbound (La société derrière Crossplane))

Crossplane permet également la création d’API Kubernetes personnalisées. Les équipes de plateforme peuvent combiner des ressources externes et simplifier ou personnaliser les API présentées aux consommateurs de la plateforme.
Et donc vous pouvez créer votre propre platform API: par exemple composer un GKE en mode Platform Engineering.

Voir la vidéo de cette session

The IaC Evolution – on Open Source & Everything Else – Sharone Zitzman, RTFM Please; Mandi Walls, PagerDuty; Roni Frantchi, env0; Solomon Hykes, Dagger.io; Eran Bibi, Firefly

Cette session n’était pas une présentation mais une discussion avec un panel de personnes qui ont partagé leurs avis et leur vision sur l’évolution de l’Infra-as-Code.
Plusieurs points intéressants :

  • Quelles sont les tendances entre fragmentation et consolidation des acteurs ? le Débat Terraform, OpenTofu revient encore !
  • Finalement il semble que, pour des raisons de simplificité, le plus gros écosystème sera probablement le gagnant
  • Le State management reste quelque chose de difficile
  • On rentre vite dans un monde « Teaching yet another tool », pour quelle plus-value ?
  • L’abstraction du cloud est nécessaire pour amener moins de complexité
  • L’approche Multi-lamguagage devient de plus en plus nécessaire pour laisser les organisation choisir en fonction de leur connaissances et besoins.
  • Besoin d’avoir une approche sans vendor locking

Mais à la fin, la migration entre les outils IaC est toujours un effort important.

Voir la vidéo de cette session

Platform Engineering: le retour d’expérience

Lors de la KubeCon EU en 2022 la tendance était au Plateform Engineering, cette année le platform engineering n’est plus une tendance mais une réalité.
Les outils et frameworks d’infrastructure, tels que Kubernetes, les service Meshs, les gateways, la CI/CD, etc…, ont bien évolué et sont largement considérés comme des « technologies classiques » (du moins pour ce public spécialisé). Le grand défi consiste désormais à assembler les pièces du puzzle pour apporter de la valeur aux clients internes.
Voir notre article sur ce qu’est le Platform Engineering et les liens avec le DevOps

Le « sponsor showcase » été plein de mentions sur les plateformes, l’ingénierie des plateformes et l’expérience des développeurs, avec en particulier:
Humanitec, Backstage, Port, Cortex, Kratix, Massdriver, Mia-Platform, Qovery, …

On voit même apparaître des langages de spécification de workload comme Score et Radius pour amener une couche d’abstraction entre la demande du développeur et la réalisation technique par le Platform Engineer.

The State of Backstage in 2024 – Ben Lambert & Patrik Oldsberg, Spotify

L’incontournable Backstage pour l’IDP (Internal Developpeur Platform) est le projet auquel les utilisateurs de la CNCF ont le plus contribué !
Après 4 ans d’existance il y a plus de 2,4k adoptants et 1,4K contributeurs !!!

Le projet continue de travailler sa maturité sur la gouvernance en proposant un processus d’amélioration: Backstage Enhancement Proposals qui est largement inspiré par le Kubernetes Enhancement Proposals (KEPs)

Voici les nouveaux domaines de ce projet :

  • plugins dans Backstage :
    • besoin d’un repository de plugins de référence pour la communauté
    • réduire la barrière pour publier un plugin open source
    • Déplacer les plugins du repository backstage vers un nouveau dépôt ‘backstage-community’
  • OpenAPI
    • Routeurs typés pour les premières applications de schéma
    • Clients typés pour l’interaction avec les spécifications OpenAPI
  • Scaffolders
    • Scaffolders SIG every bi-weekly
    • Retries & Rollbacks en cas de problème : travail en cours
    • Test Helper pour les actions
    • Prise en charge améliorée des secrets : extension de champ « ui:field : Secret »
  • Microsite et document
    • Audit documentaire de la CNCF: En cours
  • Notifications et signaux
    • Notifications : notification riche dans l’application et prise en charge des notifications externes
    • Signaux : Abstraction pour pousser des events du backend au client
  • Core Framework
    • Améliorations de l’authentification : sécurisée par défaut, authentification de service à service simplifiée
    • Evolution en cours
  • New Frontend System
    • En cours pour amener de la simplification
    • Deuxième phase plus tard en 2024 : compatibilité, plugins avec support transparent pour les deux systèmes
  • New Backend system
    • Prêt pour la production !
    • La majorité des plugins et modules ont été migrés
    • Maintenant la valeur par défaut
  • Dynamic Features :
    • installation des plugins sans devoir refaire un build
    • Dépent des nouveaux Backend et Frontend Système
    • Travail en cours

L’évolution de Backstage se poursuit avec un axe de simplification qui sera, sans aucun doute, très apprécié !

Voir la vidéo de cette session

Boosting Developer Platform Teams with Product Thinking – Samantha Coffman, Spotify

Cette session faisait le focus sur l’approche produit pour développer la plateforme en décrivant qu’est-ce qu’une « Platform Product » chez Spotify.
Et avant tout c’est un changement d’état d’esprit en mode « Platform as a Product Mindset » qui change la manière de faire un IDP et la gestion des produits internes.

Avoir un portal n’est pas suffisant, l’orientation produit consiste à orienter les résultats souhaités et à créer une valeur continue et itérative pour atteindre ces résultats:

IDP solution)

Cette approche permet aussi d’optimiser les opérations, réduire les coûts et s’aligner sur les tendances du marché.
Le but étant de se focaliser sur les résultats en analysant la valeur (quelle problème on cherche à résoudre) et la viabilité (Qui sont les clients et pourquoi ils utilisent la plateforme).
Et sortir du mode « cool on adopte une nouvelle techno à la mode », « il y a un seul besoin, faisons une nouvelle solution », …
Il est nécessaire de comprendre le besoin business et de développer une « Customer Empathy » en discutant régulièrement avec son client et pas seulement un membre de l’équipe.

Mais aussi de comprendre les motivations des différents users et managers jusqu’au CTO, c’est l’idée de « l’empathie de déploiement » et ainsi avoir la vision globale pour délivrer une solution aussi adaptée aux décissionnaires.

Platform Engineering

Voir la vidéo de cette session

Kubernetes: évidemment !

Evidemment, Kubernetes, le coeur de la KubeCon, était fortement présent !
Après plus de 10 ans d’existant, il continue d’évoluer, de s’enrichier et de s’adapter aux besoins et aux nouveautés du marché.

10 Years of Kubernetes Patterns Evolution – Bilgin Ibryam, Diagrid & Roland Huss, Red Hat

Cette session explique les patterns principaux de K8S, comprendre ces modèles est crucial pour saisir l’état d’esprit de Kubernetes, et renforcer notre capacité à concevoir des applications dîtes Cloud Native pour quelles s’incrivent au mieux dans cette démarche.
Les patterns par catégorie:

  • Foundational Patterns
    • Health Probe: Répond à la question « comment communiquer l’état de santé d’une application à Kubernetes ? » Via les Startup, Readiness et Liveness health checks
    • Structural Patterns: « Comment améliorer les fonctionnalités d’une application sans la modifier ? » Via les SideCar containers (Separation Of Concerns)
    • Behavioral Pattern: « Comment s’assurer qu’une seule instance d’application est active ? » Vai StatefullSet avec 1 seul replica (Notion de Singleton), sinon posiibilité de faire du « In-Application Locking »:
      In-Application Locking Pattern
    • Configuration Pattern: « Comment configurer votre application avec des images de conteneurs immuables ? » Via Volumes
    • Security Patterns: « Comment protéger la plateforme contre le code déployé ? » Via l’isolation et les SecurityContext (RunAsNonRoot, allowPrivilegeEscalation, readOnlyRootFilesystem, capabilities, …)
  • Avanced Patterns
    • Controller Pattern: « Comment passer de l’état actuel à un état cible déclaré ? » Via le State Reconciliation : Observe – Analyze – Act
    • Operator Pattern: « Comment encapsuler les connaissances opérationnelles dans un logiciel exécutable ? » : Via les operateurs (CRD + Controller)

Il y a plein d’autres patterns, voir le livre « Kubernetes Patterns »

Voir la vidéo de cette session

Planning for Maturity: SIG Release’s Revamp for a More Stable Kubernetes – Adolfo García Veytia, Stacklok; Kat Cosgrove, Dell Technologies; Carlos Panato, Chainguard; Joseph Sandoval, Adobe

Je trouve extrêmement intéressant de regarder le processus de Release de Kubernetes par le Kubernetes SIG Release Group.
Kubernetes est un produit complexe composé de multiples composants avec des équipes multiples de sociétés différentes et distribuées dans le monde entier le tout avec un cycle de release exigeant. Et ça marche !!!

De part cette complexité, c’est toujours compliqué en entreprise de faire partie de l’équipe de Release et les attentes ne sont pas toujours au rendez-vous !
Kubernetes - SIG Release

La documentation est un point crucial et un prérequis pour les améliorations faisant parties des releases Kubernetes.
Avoir une phase de « Docs Freeze » est importante tout comme les phases de « Code Freeze » pour amener des phases de stabilisation.

Kubernetes v1.30 « Uwubernets » est en cours:
Kubernetes - v1.30 Release

La roadmap 2024 pour le SIG Release est d’avoir un Release Pipeline plus robuste, plus rapide et plus flexible.

  • Robuste : le processus de création de metadata doit être cohérent entre les exécutions consécutives et résistant aux pannes d’infrastructure.
  • Rapide : le temps de création des releases de Kubernetes doit être minimisé.
  • Flexible : les améliorations futures du processus seront prises en compte dès le début, par exemple lors de la réflexion sur l’extension des métadonnées de publication.

Le build de package k8s se fait avec OpenBuildService de Suse qui permet de travailler avec toutes les principales distributions Linux. Les packages sont ensuites publiés sur pkgs.k8s.io
Les actions de releases sont faites avec GitHub Actions, en utilisant des steps de création de Provenance, de SBOMS, Check Dependencies et de publication de release et de release notes.
Tout le procesus de release est décrit dans le repository kubernetes

Le futur est de créer une Supply Chain véritablement sécurisée: SBOMS, Provenance, Signature fait déjà partie du processus mais peu les utilise ou s’appuie dessus.
Il va y avoir un nouveau flux de sécurité Kubernetes avec un Security Response Committee (SRC)

Il y clairement beaucoup de choses à en tirer pour l’appliquer sur nos propres Release même sur des projets non Opensource mais en mode « InnerSource »

Voir la vidéo de cette session

Network Policy: The Future of Network Policy with AdminNetworkPolicy – Surya Seetharaman & Andrew Stoycos, Red Hat; Hunter Gregory, Microsoft

Les NetworkPolicy sont une importante fonctionnalité de kubernetes gérées par le SIG Network et permettent de sécuriser les flux de communications entre les pods.
Elles ont été pensées pour les dev avec un design d’API implicit (refus implicite, liste d’autorisation explicite des règles).

NetworkPolicy

Apparition de 2 nouveaux objets: AdminNetworkPolicy et BaselineAdminNetworkPolicy en v1alpha pensés, cette fois, pour les Admins avec un mode explicit.
Les usecases:

  • En tant qu’administrateur de cluster, je souhaite appliquer des politiques réseau d’administration non modifiables qui doivent être respectées par tous les utilisateurs du cluster.
  • En tant qu’administrateur de cluster, je souhaite appliquer le modèle d’isolation des tenants et déléguer la responsabilité d’autoriser explicitement le trafic des autres tenant au propriétaire du tenant à l’aide de NetworkPolicies.

L’API AdminNetworkPolicy a la priorité sur l’API NetworkPolicy.
L’API BaselineAdminNetworkPolicy correspond à une posture de sécurité par défaut du cluster en l’absence de NetworkPolicies

Plusieurs propositions d’amélioration: Network Policy Enhancement Proposals (NPEP):

  • Cluster egress CIDR traffic controls
  • Egress CIDRGroup peer
  • Cluster egress FQDN traffic controls
  • Cluster ingress traffic controls
  • Better tenancy expressions
  • Conformance profiles

Future Plans: Network Policy V2?

  • DeveloperNetworkPolicy:
    • Réinventez de A à Z la politique de mise en réseau axée sur les développeurs.
    • AdminNetworkPolicy + DeveloperNetworkPolicy = “NetworkPolicy v2”
    • Pour l’instant juste une idée
  • Policy Assistant
    • CLI qui résume les interactions des Policy.
    • Moteur d’analyse, simulant le comportement des Policy théorique.
    • Etend le projet Cyclonus
    • excellent pour faire de la Pre-Validation, de l’expérimentation et du troubleshooting !

NetworkPolicy Assistant

Voir la vidéo de cette session

Comparing Sidecar-Less Service Mesh from Cilium and Istio – Christian Posta, Solo.io

Les services Mesh deviennent incontournables lorsque l’on fait des micro-services dans kubernetes, les avantages sont multiples:
Service Mesh

Les services Mesh ont largement adoptés l’approche des Sidecar containers afin d’amener le réseau au plus près de l’application sans être intrusif mais viennent aussi avec des incovénients (Difficulté de sizer, Security, upgrade challenging, …)

L’utilisation d’eBPF pour les Services Mesh permet de résoudre certains de ces problèmes ce qui n’exclus pas le besoin d’avoir un proxy:

Service Mesh Proxy

La comparaison entre Cilium et Istio en mode « Sidecarless » ou en mode mixte (Séparation des layer 4 et 7) explique clairement les differentes architectures et le fonctionnement de ces 2 Services Mesh.

Voir la vidéo de cette session

We Tested and Compared 6 Database Operators. The Results are In! – Jérôme Petazzoni, Tiny Shell Script LLC & Alexandre Buisine, Enix

La question de la base de données dans Kubernetes est récurrente. Est-ce production ready si on utilise des opérateurs ?
Ce comparatif a choisi quelques opérateurs de Base de donnée (PostgresQL, MySql, MariaDB) par rapport aux fonctionnalités de setup, d’Observabilité, de backup restore, d’upgrade, …

Service Mesh Proxy

Retour d’expérience intéressant basé sur leur expérience réelle de production, et noté à l’aide d’icônes Banane (bon), Tête de mort (moins bon) ou un mélange des deux (amélioration par rapport aux versions précédentes).

Voir la vidéo de cette session

Cloud Native Storage: The CNCF Storage TAG Projects, Technology & Landscape – Raffaele Spazzoli, Red Hat; Alex Chircop, Akamai

Pour aller plus loin par rapport à la session précédente sur les opérateur de base de données, cette présentation explique les avancées sur le storage kubernetes: Plus de workload Statefull vers K8S : automatisation, évolutivité, performances, basculement !!!

Il existe un livre blanc pour clarifier la terminologie, expliquer comment ces éléments sont actuellement utilisés en production dans des environnements de cloud public ou privé et comparer les différents domaines technologiques.
Storage Attributes

Un focus sur les database avec aussi un livre blanc « Data on Kubernetes Whitepaper – Database Patterns » qui explique bien les modes de fonctionnement :
Storage Databases

Il est intéressant de voir que l’Operatorhub contient 349 operators dont 47 db operators avec 9 PostgreSQL opérateurs.

Un point essentiel lorsque l’on gère des données dans Kubernetes est l’aspect Disater Recovery
Il existe plusieurs approches décrites dans ce document

Les prochains focus seront sur les données et workload AI/ML…
Ainsi qu’un livre blanc sur les performances.

Voir la vidéo de cette session

Sécurité: reste un sujet majeur !

La sécurité était partout, sur l’ensemble des thématiques avec des approches zero-trust.
En particulier, les chaînes d’approvisionnement sécurisées ont été largement mentionnées dans les outils de construction de conteneurs (aux côtés du SBOMS et de SLSA): voir le chapitre Supply Chain plus haut.
La sécurité des réseaux était aussi bien présente, avec des mentions intéressantes de Cilium (et eBPF dans ce contexte), Linkerd et Istio.

Choose Your Own Adventure: The Struggle for Security – Whitney Lee, VMware & Viktor Farcic, Upbound

Je retiens cette présentation où le public a pu choisir les outils de sécurité pour protéger une application dans kubernetes:

Security tools

Outre les démonstrations sucessives des outils, ce qui était très intéressant c’était de voir le choix des outils par l’audience:

Voir la vidéo de cette session

Conclusion

La KubeCon 2024 a marqué un tournant décisif dans l’évolution de Kubernetes et de l’écosystème Cloud Native, en mettant particulièrement l’accent sur l’intégration de l’intelligence artificielley, tout en soulignant l’importance de la sécurité, de la Supply Chain, de la durabilité, de l’infrastructure-as-code et de WebAssembly.
Ces thématiques montrent une maturité et une vision à long terme, préparant le terrain pour des innovations futures.
Le large spectre de sujets abordés, allant de la supply chain sécurisée aux meilleures pratiques en matière d’observabilité et d’opérations, confirme l’engagement de la communauté envers une amélioration continue. Kubernetes, au cœur de ces discussions, prouve une fois de plus qu’il reste à l’avant-garde de la technologie, prêt à relever les défis futurs du Cloud Native.

Laisser un commentaire

  Edit this page