2026¶

Homelab

For 2 years, I started building myself a homelab, to be able to host applications for myself and to have infra at hand to try new technologies and concepts before using them at work. It has become a mix of "Home prod", Devops lab, with heavy "Prepper" vibes.

My approach is to get as close to the experience I have deploying applications to a cloud provider, and ensure that I can have some redundancy, data backups and high availability, in the limit of the hardware I have at my disposal. I don't want a fully air gapped setup, but I want to rely only on external resources for artifacts (code deps, images, helm charts), as I don't currently want to mirror everything in a private registry.

I like to work with kubernetes, but I don't want my whole stack to rely on it. I need some devops tools to store my code, bootstrap and manage the kubernetes environment. So I went with the following abstraction layers.

physical nodes --> proxmox cluster --> kubernetes cluster

This allows me to have some VMs and LXCs next to kubernetes, to manage the whole thing.

Hardware - aka cable mess

Here is a physical view of my setup.

flowchart TD
ISP[ISP box]
subgraph home
    UDR7
    NAS@{ shape: disk, label: "Synology NAS" }
    subgraph lan-default[LAN default]
       dev@{ shape: processes, label: "personal devices"}
    end
    subgraph lan-proxmox[LAN proxmox]
        direction TB
        node1[gmktek n97] 
        node2[gmktek n97]
        node3[mllse n150]
        node4[hp g3 400]
        ceph1@{ shape: disk, label: "1TB"}
        ceph2@{ shape: disk, label: "ceph2"}
        ceph3@{ shape: disk, label: "ceph3"}
    end
    subgraph lan-iot[LAN IoT]
        iot@{ shape: processes, label: "IoT devices"}
    end


end
ISP <-->|2.5Gb| UDR7
UDR7 <-->|1Gb| lan-default
UDR7 <-->|1Gb| lan-proxmox
UDR7 <-->|1Gb| lan-iot   
NAS <-->|1Gb| lan-proxmox
NAS <--> |2.5Gb| UDR7
NAS <-.->|1Gb vlan| lan-default
node1 <-->|usb| ceph1 
node2 <-->|usb| ceph2
node3 <-->|usb| ceph3

My initial goal was to get completely rid of my ISP's box. But I gave up on the idea as I had issues finding the right ONT SFP plug (optic fiber), proprietary VLAN, PPPoE config. And frequent internet loss were not an option in my household...

The NAS is a Synology DS220+, with 2x4TB storage in raid1.

One day I plan to switch to a homemade machine with TrueNAS, but I will wait for the Synology to be full before switching.

Hosts list

Networking

Topology

All my networking is handled by the Ubiquiti UDR7, it handles:

• LAN management
• sees my ISP's box as a WAN
• DNS resolution
• DHCP
• firewall policies

All that done through the UniFi portal, hosted on the thing.

My lan topology is as following

DNS

I use home.com as local domain. All physical nodes have a static ip and an associated DNS record frieren.home.com, stark.home.com or nas.home.com

Proxmox vms also have static ips and DNS forgejo.home.com or docker.home.com

And finally, I attach a wildcard record for the kubernetes Gateway API IP *.k8s.home.com, so that I don't have to manage records for all my k8s hosted apps.

Firewall & Security

I have a few basic rules, - Geoblocking every inbound that is not from France on all traffic. - Blocking IoT network outbound to anywhere. - DNS ad blocking, stock from the dream router (this replaces a PyHole/AD-GUARD) - Protocol blocking of Peer-to-peer, so I don't accidentally torrent linux ISOs without a VPN.

I have only 2 ports opened to the internet - The UDR7 OpenVPN port, so I can connect remotely to my LAN. - Homeassistant, through NAT and port mirroring, to be able to access it from home assistant's android app from anywhere.

I know that my networking is not too open source oriented, as i am vendor locked to ubiquiti devices and features. But the price per feature is great. Maybe i will go a more open route some day.

Virtualisation & Storage - Proxmox

All 4 physical nodes join the same PVE cluster.

3 of the nodes have an additional 1TB drive attached to them, that are used with PVE integrated ceph.

Ceph is a great distributed storage solution, and having it separated over 3 nodes means that I can safely lose a physical node and disk and be able to rebuild the data.

This Ceph pool is accessible from all 4 PVE nodes, and used for VM disk provisioning.

All PVE nodes also have an NFS volumes mounted from the NAS. These are used either on RW volumes to store backups, or on read only volumes to access media that is on the NAS.

On my first iteration of the lab, I was using the NAS as SAN to mount iscsi luns for the VM disks and even for kubernetes pvcs, but it was a pain to manage, and slow because of the HDDs on the NAS.

For important VM backups, I added a Proxmox Backup Server (PBS) instance, to handle the snapshotting of VMs with minimal storage footprint, on an NFS volume on the NAS. The PBS runs as an LXC on proxmox itself. That LXC is not backed up, but I don't plan on it to fail.

Devops stack - Forgejo

Once we have virtualisation and storage, we are good to go. For devops purpose, I wanted to be able to store code, run pipelines and store custom container images. The simplest solution I found was Forgejo. As I prefer github action style pipelines to gitlab components. I have a Forgejo LXC, and next to it, a docker VM that hosts the Forgejo runner for the pipelines. This docker VM also hosts a minio, that I used for s3 style terraform states storage.

flowchart LR
subgraph Forgejo
repos
registries
actions
end
subgraph docker
  runner
end
actions -->|runs on| runner

From Forgejo, I am able to run open tofu in pipelines, to provision infrastructure to proxmox.

Kubernetes - Talos

Now that I can manage some infra, I was able to start building my main platform, the kubernetes cluster. I chose to go with Talos, as it is easy to setup and maintain.

In the first version of the lab, I was running a baremetal k3s cluster, but this meant having all 3 control plane physical nodes running at all times, and left me no spare compute for other use.

To have high availability, I deploy 3 control plane Talos nodes (you either have 1 or 3+, because of quorum), that are each on different proxmox nodes.

And then I deploy 3 worker talos nodes, on the same PVE node, the one with the most RAM. If this one fails, the worker VMs will be able to move to other PVE nodes. Using proxmox HA.

All these are deployed using terraform, for the init. And on a day to day basis, i use talosctl to manage the day 2 actions, updating nodes / api.

# Terraform module for the cluster
module "cluster1" {
  # source = "github.com/bbtechsys/terraform-proxmox-talos"
  source = "./modules/talos"

  talos_cluster_name = "talos-k8s-cluster"

  talos_version = "1.11.2"
  control_nodes = {
    "node-control-1" = "fern"
    "node-control-2" = "frieren"
    "node-control-3" = "stark"
  }
  control_machine_config_patches = [
    <<-EOT
    - op: add
      path: /cluster/network
      value:
        cni:
          name: none
    EOT
  ]
  worker_nodes = {
    "node-worker-1" = "eisen"
    "node-worker-2" = "eisen"
    "node-worker-3" = "eisen"
  }
  worker_machine_config_patches = [
    <<-EOT
    - op: add
      path: /cluster/network
      value:
        cni:
          name: none
    EOT
  ]
  proxmox_iso_datastore     = "vm-pv"
  proxmox_image_datastore   = "ceph-vm-storage"
  proxmox_control_vm_cores  = 2
  proxmox_worker_vm_cores   = 2
  proxmox_worker_vm_memory  = 4096
  proxmox_control_vm_memory = 4096
}

This runs on Forgejo Actions

Here is a view of a talos node from talosctl dashboard

If I had to do it again, I would have looked at setting up the cluster through Cluster API from a k0s or something, instead of terraform. But I didn't have the knowledge at the time.

The clusters use Cilium as CNI.

When installing Talos make sure to build an image with the Qemu addon, otherwise they cannot run on Proxmox virtualisation.

Here is the node view from k9s

Deployment

To manage deployments to the cluster, I use FluxCD for gitops. It reconciles all the configuration that I put in a Forgejo repository. It is organised so that each folder holds an app.

Everything that is not an app is deployed in the infra folder.

To avoid race condition errors, there are 2 separate flux reconciliations - first the infra - then the apps

Storage

I have 2 main CSIs a Read only to the NFS drives on my NAS, to access media, and RWX to Ceph fs for all other PVCs.

This allows to have resilient storage, and most important, to not rely on any local node storage, so that all pods can move to any node and have access to their persistant volumes.

I don't yet have databases on the cluster, I plan to add CNPG for PostgreSQL dbs, but I would have to make some room on the cluster.

Ingress

To expose applications, I use kubernetes Gateway API. I use a fixed IP, and add the wildcard dns entry *.k8s.home.com to it.

flowchart TD
subgraph UDR7
 wild[A *.k8s.home.com 10.0.0.80]
end
subgraph Kubernetes Cluster
  metallb
  Gateway
  http1[HttpRoute glance.k8s.home.com]
  http2[HttpRoute jellyfin.k8s.home.com]
end
metallb --> |allocate ip & load balance| Gateway
wild --> |resolves to| Gateway
Gateway --> |redirects| http1
Gateway --> |redirects| http2

# Gateway definition
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: cluster-gateway
  namespace: default
  annotations:
    io.cilium/lb-ip-address: "10.0.0.80"
spec:
  gatewayClassName: cilium
  listeners:
    - name: https
      protocol: HTTPS
      port: 443
      tls:
        mode: Terminate
        certificateRefs:
          - kind: Secret
            name: cluster-gateway-tls
      allowedRoutes:
        namespaces:
          from: Same

The load balancing and Gateway IP allocation is handled by metallb.

#MetalLb config
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: primary-pool
  namespace: kube-system
spec:
  addresses:
    - 10.0.0.80-10.0.0.90
---
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: main-advertisement
  namespace: kube-system
spec:
  ipAddressPools:
    - primary-pool

HTTP routes are signed by a self signed certificate provided by cert-manager, this root ca is added to all my personal devices. This certificate signs all *.k8s.home.com endpoints.

Even though I have several Route53 DNS zones, I didn't want to rely on external DNS challenge and LetsEncrypt for the kubernetes hosted apps.

The cert-manager deployment

apiVersion: source.toolkit.fluxcd.io/v1beta2
kind: HelmRepository
metadata:
  name: cert-manager
  namespace: flux-system
spec:
  interval: 1h
  url: https://charts.jetstack.io
---
apiVersion: helm.toolkit.fluxcd.io/v2
kind: HelmRelease
metadata:
  name: cert-manager
  namespace: flux-system
spec:
  interval: 5m
  releaseName: cert-manager
  targetNamespace: cert-manager
  install:
    createNamespace: true

Applications

Let's start by the apps hosted on kubernetes.

The main app I run is Glance, that serves as a homepage to access my other applications. And has news on the public stuff I follow (steam sales, twitch, youtube,...)

as well as proxmox nodes statuses

I then have different media apps, they all point to a NFS volume depending on the media type.

• Jellyfin : movies and tv shows
• Navidrome : music
• Booklore : eBooks

I don't have anything dedicated to podcasts as I don't follow any.

I then have two apps that run as VM on the synology nas directly, as this is where I started and never moved them to proxmox. - Home Assistant - Kiwix (local copy of wikipedia and other wikis)

The last app I run, that is not yet in kubernetes but only on the docker host is a Vaultwarden, to serve my secrets locally, I use Bitwarden as my main secret manager, the Vaultwarden hosts a copy of Bitwarden, that I sync manually once in a while.

Glance centralizes those apps as well as giving me a health status.

Monitoring - Grafana

My current monitoring stack is a bit resource-hungry for the size of my infra. This is why I monitor only metrics at the moment and no logs.

flowchart
subgraph Proxmox
subgraph Docker
 influxdb
end
subgraph Kubernetes
prometheus
Grafana
end
PVEmetrics
end
PVEmetrics --> |send metrics| influxdb
Grafana --> |reads| prometheus
Grafana --> |reads| influxdb 

Within the kubernetes cluster, I host a Grafana, and have a prometheus node exporter that fetches metrics from all the nodes.

To monitor proxmox, and retain long time metrics, I set up an InfluxDB on the docker vm, and configured standard proxmox ve metrics export to it.

Grafana then has dashboards using the 2 sources, Prometheus and InfluxDB.

This is not an ideal setup, because if I lose Grafana or kubernetes I lose access to the underlying proxmox monitoring, but I had to make compromises, as my homelab resources are finite.

PS

Wile writing this, i had the great idea to switch my proxmox network size from /10 to /24, to make some space.

Issue is, that meant my talos nodes had to get ips in the new range. And i didnt think to do it prior to the subnet size change.

The 3 control plane nodes lost track of their etcd, and i got a split brained cluster, i spent 4 hours putting every thing back together with an etcd snapshot.

This explains why some uptime are so fresh in the screenshots ^^

TLDR : backup your stuff.

Cloud Native Days France 2026

https://www.cloudnativedays.fr/programme

Agenda

Glossaire, au cas où

• k8s : kubernetes
• KaaS : kubernetes as à service
• OSS : Open Source Software
• GPU : Graphical Processing Unit, aka carte graphique
• FPGA : Field Programmable Gate Array, un genre de processeur re-programmable pour un usage unique.
• SRE : Site Reliability Engineer/ing métier qui consiste à s'assurer que la prod tourne bien, dans des contextes DevOps pour assurer évolutivité et fiabilité.
• OPS : diminutif pour décrire les personnes travaillant à l'installation et au maintien opérationnel des serveurs, comme dev pour développeurs.
• CLI : Command Line Interface, une interface terminale qui permet d'utiliser un outil donné.
• airgaped : qui n'a pas du tout accès à internet, genre il y à de l'air entre le serveur et internet.
• SBOM : Software Bill Of Material, comme une BOM en industrie, mais pour des briques logicielles, la liste des composants de fabrication/dépendances, utilisée surtout dans les analyses SecOps
• PKI : Public key infrastructure, rôles/policies/logiciels de gestion des certificats / Certificate Authority.
• LZ : Landing Zone, zone d'atterrissage, jargon Cloud pour décrire la zone souscription/account... dédiée à un cas d'usage où un domaine.
• SPOF : single point of failure
• CRD : Custom Ressource Definition, ce sont des extensions de l'API kubernetes.
• Bare Metal : Un serveur physique sans couche de virtualisation.

Keynote d'ouverture

Contribuer aux projets OSS !

Exemple de pourquoi : La fin de Nginx ingress controller --> gateway api, car les maintainers du projet on stoppe

Demo sur le traitement des data issues des accélérateurs de particules

Cluster de 500 nœuds. 30k applications. 300gb/s actuellement et dans 1 an 5Tb/s de data d'event pendant les experiences. Stockage des data au sein du cluster sur Longhorn

graph TD
subgraph K8S
    Kubeflow
    LongHorn
end
LHC[Large Hadron Collider] --> |5Tb/s| FPGA[ML sur FPGAs]
FPGA --> |3Gb/s| LongHorn
Kubeflow --> |Analyze| LongHorn

Données de mesure issue de accélérateur de particule du CERN, LHC/Atlas

Construction de mini modèles AI (~100k paramètres), pour tourner rapidement sur des FPGA, le but faire le pre-processing des événement de mesure pour conserver cote Applicatifs standard un nombre d’événements plus minime. Via HLS4ML

Pour le traitement des data une fois récoltes utilisation principalement de Kubeflow et ses sous briques MLflow Kserve pour le training et serving, et JupyterLabs ,VScode et acces directement en ssh sur les pods pour les end users. Data sur Longhorn et Prometheus. GPU h100 intégré aux noeuds Kubeflow., séparés en partitions par MIG (NVidia Multi Instance GPU). Qui permet la reservation d'une portion de GPU lors de la creation d'une instance de compute Kubeflow Les user des personnes sont utilises au seins des pods, les end users ont sudo dans leur pods de travail, pour une meilleur acceptance des data-scientists. Les end users on access à l api k8s via leur user également, sur leur scope. ils peuvent également ssh sur leur pods, via credentials Kerberos. Access via l'extension k8s dans VSCode, pour remote access sur les pods directement dans l'IDE.

Sur les couche bas niveau, rattachement entre servers avec SLURM

Utilisation d'inifinity band pour le networking des GPU. CPU pinning, pour s'assurer que les CPU assignés par k8s à un projets sont bien sur le meme NUMA node qui porte les GPU.

GPU --> consommation de watt meme en idle. Utilisation de DRA, Dynamic resource allocation. Composable dis aggregated infrastructure, les GPU sont physiquement unplugged si non utilisées pour ne pas consommer d’énergie en mode idle.

DINUM et DGFIP : DSI de l’état français, stratégie numérique de l état

DINUM : Direction Interministérielle du NUMérique, la DSI de l’état DGFIP : Direction Générale des Finances Publiques

Contexte cloud prive de l’état

graph TD
subgraph OpenStack
    subgraph kubo [Cluster Kubo 1]
        ns[namespace n]
    end
    c1[Cluster Kubo2 ]
    c3[Cluster de management]
end
DINUM --> |utilise| c3
DINUM --> |gere| OpenStack
c3 --> |provisionne| kubo
c3 --> |provisionne| c1
DGFIP ----> |instancie des applications| ns

2 OpenStack internes à l’état, avec cluster k8s, usage de CAPI(Cluster API) pour le provisionnent de clusters sur OpenStack - ministère de l'intérieur - DGFIP --> Calcul des imports Plateforme certifiée Label SecNumCloud. Les applications principales hébergées sont
- France connect - Démarche simplifiée (les impôts) - App ministère - Tchap : messagerie instantanée du secteur publique - Viso interne, docs interne, ... La DINUM fournis un KaaS pour une 40 aine d’applications fournis par l’État.

Distribution k8s Kubo, la DINUM s'est fait sa propre distribution k8s hardened à ses besoins.

• Hybride
• Namespace as à service
• la DINUM gère tout pour les end users
• base sur CAPI, donc compatible tout hosting
• postes d admin sur NixOS, os immuable
• Autres briques de la stack intra k8s:
  • Capsule pour le framework de multi tenancy et les policies associées
  • Sveltos pour le déploiement d'addons depuis le management sur les clusters metiers
  • Kyerno pour l'application des policies

Scaleway

Tech lead, Jean baptiste kempf

(Advertisement)

Vrai souveraineté : Compile everything Kernel linus, propre stack de conteneur,...

Mise à dispo de SKD, provider TF, console on top of GO api.

Fait parti de Iliad.

Table ronde

• qu'est ce qu on doit regarder sur les CV?
  • moins de tech pure, plus de skills de prod, le monitoring, les archi haute disponibilité
  • diverse, avoir une équipe avec skills diverses, data, dev, secu, infra,...
• Comment on-boarder des gens
  • donner des outils pour aller taper directement sur lecosysteme, sans forcement qu ils aient à comprendre toute la stack.
  • rencontrer les autres equipes
• Estce que le dev vas etre responsable de tout où il faut splitter le roles, dev , devops, ...
  • peu importe les roles, il faut des RACI, sinon personne prend l'ownership, mais il faut le definir des le debut, et accepter d'etre contacter sur son scope
  • you build it you run it marche bien, sur la partie applicative.
  • one ne peu pas demander au dev d'etre responsable de ce quils livrent si ils ne comprenent pas la stack total, il faut former les devs à l'ops.
  • ideal vers lequel il faut tendre checker 'team topologies'
• est-ce que une bonne doc ca ne ferais pas l'affaire
  • la doc c est dur car il faut la faire vivre, mettre la doc dans le code ? en plus de la doc, mettre des guardrail dans la ci, pour s assurer que ce qui ship est compliant avec les plans initiaux.
  • pour ce qui peut etre fait en auto, faire en auto, pour la liste des ressources par exemple.
  • trop de doc pas naviguable est pas bon non plus. il faut delete les docs outdated.
• k8s c'est trop dur, vrai où pas, metter en place un portail qui gere toute la stack pour les devs c'est une solution ?
  • il ne faut pas sur outiller via un IDP, ne pas en faire la premiere etape de mise en place d'une plateforme
  • la fourniture de framework appicatif est bienvenue par les devs, car ils n'aiment pas faire de helm charts.
    • Si trop restrictif, cafait du shadow it
    • il faut laisser un peu de mou
  • il faut que tous le monde soit capable de debug, siil y à des 100aine d'applis il faut mieux etre assez uniforme.
• les astreintes, le you build it you run it
  • ce qui marche, les devs sont en binome d un sre/ops, pour qu ils aient l'impact de leur build sur le run. meme sans etre on call
  • on à jamais juste une personne on call
• les pro tips, voeux
  • que les équipes se parlent sans silot, entre les devs et les sre. lol comme les devs et les ops avant
  • aller voir les Communautés de pratiques
  • stay curious, experiment
  • Eviter que les devs gèrent les Helm charts, sinon ça explose, centraliser ca.

Numspot La plateforme de Service cloud Data et AI

(Advertisement)

GA depuis quelques mois. Socle 100% open source

Écosystème à date - ecosystem k8s, PostgreSQL, container registry, secret manager, GPU , VM, stockage, réseau - Souverain France SecNumCloud - Polyvalence, provider Terraform disponible

TOSIT The open source i trust

Tosit, association française autour de l'usage de l'open source entre les entreprise françaises et les ministères qui le souhaitent. Devenir acteurs de l'Open Source entant que consommateurs via des ateliers.

Openstack, k8s, PKI, AI, Data, ...

Le but de l'initiative ? Faire des REX entre entreprise, travailler sur des outils communs

Stop the Fight : doper et unifier HPA, VPA et KEDA avec des métriques avancées

Les problèmes entre
- HPA : horizontal pod scaling --> pod replicas - VPA : vertical pod scaling --> pod sizing - KEDA : event based scaling --> events

HPA se base sur un metric server de base, il faut mieux passer par des metric Prometheus, car plus rapide à remonter des metrics.

VPA collecte 1 sample par minute, avec de l'historique de sampling par jour, et des halflife des journées précédentes, dans le but de définir des patterns d'usage quotidiens, réagis pas trop bien au pics, et il doit redémarrer les pods.

Keda crée un objet HPA under the hood. Suis des Scale Objects genre des queues Kafka, comme pour HPA, il faut mieux utiliser des metrics de Prometheus pour Keda aussi.

Il ne faut pas qu'une metric soit utilisée par plusieurs scalers, sinon: conflits, oscillations, restarts.

Exemple si on met HPA et Keda sur la meme metric de CPU, Keda vas voir des requets arriver et faire popper des pods, mais la règle HPA aussi sur le CPU, vas kill les pods car pour lui il n'y à pas de besoins immédiat, ca oscille.

Ca peut être pareil avec du VPA+HPA, HPA scale, les usages par pods baissent, VPA recommande moins de CPU, les pods restart pour scaller, ont à du throteling, qui fait scaller HPA et ca boucle.

Plutôt utiliser des metrigs Leading vs Lagging

Reco: pas de scaling sur la mémoire,il faut la right sizer sizer comme pour l'usage maximum d'un pod.

Utiliser Prometheus adapter si pour HPA, et le connecteur prom natif pour Keda.

voir https://github.com/google/cadvisor

REX SNCF - Smells like Cloud Kubernetes : Notre Kube managé on-premise

Yann Rotilio, Matthieu Strohl, Etienne Germain

Contexte

15k train daily eSNCF Solution - 2000 apps - 3 Cloud providers - 4 datacenters Service conteneurisation - depuis 2018 - 14 inge - 200 apps - 7 clusters à la base, maintenant 25 clusters - 60k containers - Stack on prem l’idée et de proposer sur le on prem un service ISO à celui des cloud providers.

Step 1 : RKE2

Premiere iteration de k8s on prem VM generiques, Ansible et Terraform, zone airgaped et DMZ. 1 an de dev, 1 mois pour avoir un cluster, 7 clusters en 4 ans. ExcelOps et TicketOps, car provisionnent et ops à l'ancienne en zone très fermé, tout à la mano.

Step 2 : OpenStack

A permis de consommer facilement l'infra de base de d'y déployer des RKE2 plus simplement.

Step 3 : Talos

en 2024, switch sur Talos OS car - rapide à setup - hardened - scalable

Les cluster Talos on une machine outils pour setup les clusters sur Ubuntu avec Talosctl, et après un control plane avec 3 nœuds, et 2 node pools de 2 nœuds chacun, via OpenStack. Problèmes de gestion du Day2 en mode script Talos depuis la machine outil

graph TD
subgraph OpenStack
    Terraform
    ubuntu[Ubuntu with talosctl]
    subgraph Cluster [Cluster Talos]
        direction TB
        subgraph cp [Control plane]
        t1[Talos 1, 2, 3]
        end
        subgraph wn [worker nodes]
        t4[Talos 4, 5]
        end
    end
end
Terraform --> |Creates| ubuntu
Terraform --> |Creates| Cluster
ubuntu --> |Manages| t1
ubuntu --> |Manages| t4
cp --> |controls| wn

Step 4 : ArgoCD

Passage sur un cluster de management central qui gère tout le parc - cluster autogéré - app of apps pattern - Le cluster central gère pour les autre clusters toutes les ressources de bases - CNI/CSI - monitoring - security/external secrets

Step 5 : CAPI Cluster API

Ajout de Cluster API pour initier les cluster Talos sur OpenStack - node autoscaling - auto healing - déclaratif - via des opérateur sur le cluster de management

Le pet est mort, vive le cattle

Les problématiques

Mette en oeuvre un provider pour cluster api il faut - components.yaml - metadata.yaml Utilisation de ORAS pour stocker les configs de providers en OCI. Centralisation des config cluster API dans Harbor pour configurer ses providers depuis le cluster de management.

Il y à un seul fichier yaml qui définit un cluster applicatifs du point de vue du cluster de management. Il est converti en Helm chart, pour que Argo CD le gère comme une ressource normal.

Pour la gestion des secrets, problemo Le provider contrôle plane de Talos génère des secrets au moment de la creation via CAPI Cluster API, qui sont nécessaire ensuite dans les namespace ArgoCD Leur brique maison Capix, qui est un controller, consomme les events de creation de cluster par CAPI pour les récupérer les secrets et les ajouter dans le namespace ArgoCD. Capix est bientôt open source.

Le fichier de description des cluster est ingéré par Terraform et pousse sur ArgoCD.

A part Terraform qui gère l'initialisation, tout le reste et sur le cluster de management.

Cluster IA Air-Gapped : Concevoir, Sécuriser et Déployer une Plateforme Souveraine

Dassault Systèmes Outscale Stephane Robert, Christophe Morvan

Pourquoi airgapped - protéger les données - respect des règles de diffusion C3 (classification des données confidentielles si je comprends) - la sécurisation de la supply chain et des deploiements

Pas d'internet, pas de cloud service , pas d'images non signées Une zone autorisée pour l'ingestion dans le SI, le bridge, un genre de DMZ

stack base sur Talos linux, mais il faut prévoir d'apporter les drivers et les images Talos au sein du SI.

Packer et Ansible pour construire des images d os Talos et y ajouter les drivers Nvidia, nvlink nvidia, device plugin, gpu operator, csi/ccm

On à ensuite une conf Talos GPU ready.

Pour la partie SecOps, utilisation de SBOM pour toutes les briques. Et d'une registry interne.

pour la PKI, creation d'une PKI OpenBao, qui fait un root CA, et fait un intermediate platform pour le registry, un pour le cluster, et un intermediate application pour les workloads applicatifs.

Point d'attention: Il faut être très strict sur les versioning et mettre à dispo des bundles fonctionnels en l’état.

K0s distribution k8s

• k0s: lightweight k8s distro, single binary
• k0sctl : la cli associée, pour gérer les cluster de façon declarative, via du yaml
• k0smotron : on à un cluster de management, et on fait popper des control planes dans des pods du cluster de management, on vas rajouter des workers sur d'autres machine, c'est une CAPI provider, donc il peu s'appuyer sur plusieurs infra provider pour faire popper des noeuds kub via cluster API.
  • cluster
  • control plane
  • infrastrcuture provider
  • machinedeployment
  • bootstrap
• kordent : permet de gérer des application sur une flotte k0s, et de template des deployment kub sur des k0s

REX Air France-KLM - Des chaînes applicatives aux chaînes OPS : Voyage vers le Cloud à bord d'Air France-KLM

Caroline de Vasson

2500 appli metier, 540 appli techniques nécessaire aux vols 3 data centres 1 cloud prive : pas trop utilise pour le moment, c'est pour les application old school qui nécessite des hardware particuliers 2 cloud public GCP et Azure 1000 employés qui font de l'ops

la forge historique ci/cd : git, #sonar , #bamboo, #nexus Cette chaine fonctionne bien et pousse du code en production, mais problemo, pas de provisioning d'infra automatique, c'est du ExcelOps via demande excel traitées par les ops

L'ere du cloud

Le but était - de faire monter en competences toutes les équipes, cart out le monde n’était pas au niveau - limiter l adherence aux cloud providers, pour ne pas se vendor lock - accélérer le time to market

Automation 1.0

• Postula "you build it you run it"
• offrir un catalogue de service infra
• les dev demande un service IT, via ticket, qui lance du Ansible, qui lance du GitHub Actions, qui provisionne en Terraform
• Problemo car encore beaucoup d'actions manuels, et de gestion de fails de pipelines, à gérer à la main par les Ops

Automation 2.0

• simplifier le cycle de vie
• encore en you build it you run it
• abstraire la complexité
• unifier l'experience developeur
• nouveau process
  • mise à dispo d un repo de management aux dev par lz/spoke
    • routage , dns, certificats
    • gouvernance
    • modules Terraform standardises
    • workspace shared services Terraform pour les service simples
  • certain service on leur pipeline Terraform dédiées, comme les AKS (Azure Kubernetes Service) our les app gateway qui on des cycle de vie plus complexes
  • PAS D UPGRADE IN PLACE DES AKS, que des blue green de clusters.
  • decoupage de la lz en workspaces terraform
  • mise à dispo d une documentation sur comment utiliser les services et modules
  • les devs ne voient que GitHub et des workflows, en full autonomie sur l'usage
  • Contrôle de coherence entre les service demandés dans le Terraform et les service Valides par la CMDB / CCoE, directement au sein des pipelines GitHub.
• des qu'on propose un service il faut prévoir qu il vas évoluer, donc l'équipé DevOps doit maintenir la doc et les modules. Ils informe et accompagnent ensuite les projet metiers sur la mise à jour de leurs service / modules.

Resenti des Ops vs Dev

final où pas ? non un chaine est un produit, avec amelioration continue, nouveaux services mise à dispo régulièrement.

Sécuriser vos déploiements : quand kube-image-keeper sauve la prod !

paul laffitte , enix

KUIK Kube Image Keeper Outil de gestion des images au sein des clusters kub Les registries sont des SPOF - pas de fallback - images deleted - quotas

Les images doivent être - redondantes - observables

Concept clés - avec un kind ClusterReplicatedImageSet, avec une definition d image qui peut venir de plusieurs registries à la fois - mirroring d'images, vis ClusterImageSetMirror, les images pulled d un cote peuvent être pushed ailleur Utilisation de mutating webhooks pour remplacer les images demandes, au moment de la demande de creation des pods

les CRDS - ImageSetMirror pour les namespaces - ClusterImageSetMirror pour le cluster - ReplicatedImageSet pour les namespaces - ClusterReplicatedImageSet pour le cluster

Pour le moment, pas de garbage collect / cleanup, pas de prio entre les registries.

Kagent sur Kubernetes : comment l'IA agentique vous rend 10 fois plus efficaces

Amine AIT AAZIZI, SRE et cloud archi Les agents ai sur k8s

Pourquoi des agents sur k8s : bcp d'outils, bcp d'intervention

Kagent : projet en cncf sandbox

Framework : dashboard, cli, controller, backend base sur google ADK

Definition d'agents AI, au sein du cluster via une crd/kind Agent, en yaml - ajout des MCP tools

Core concepts - Agents , via la CRD - LLM providers diverse via ModelConfig

Dans lidee on definie un agent auquel on donne les bon outils pour monitorer le cluster, et par exemple ouvrir des PR de fix sur les repo de definition de ressources kub.

Il y à un subproject #khook, qui fait pareil mais sans humain dans la boucle.

Inside Cilium: Deep Dive sur DSR (Direct Server Return)

Alexis la goutte, kubernetworker

Cilium : - CNI principale à date, - securisation des ys, l4 à l7 - remplace ment de kube-proxy via ebpf - hubble pour l observabilite reseau DSR : - un client parle au load ball, qui renvoir au serveur, et le serveur parle direct au client - la où de base, cest l ip du load bal - via cilium dsr, meme si on plusieurs noeuds, on peut s assurer de renvoyer le l ip du pod serveur source au client - le but est que dans le trafic backend vers client, on n ai pas les IP des pods cilium en source IP, du point de vue du client. Cilium à plusieurs mode de tunelling - Protocole GENEVE --> tldr il faut mieux utiliser ce mode la. - Protocole IP

Cf la documentation DSR

CA-GIP - Construire la Plus Grande Plateforme Grafana On-Premise d'Europe

Maxime Calves, Credit Agricole

La problématique, plein de plateformes Grafana dans des versions differentes.

En 2023 10 users, en 2025 6500 users

La plateforme - plusieurs projets GitLab avec des images docker, des helm, des projets ArgoCD - un cluster qui sur lequel on deploy les Grafana - des DB PostgreSQL pour la persistante sur une stack HCI à part.

A la base, pas d'uniformisation, il y avais de l’observabilité, mais pas d'uniformisation. Car absence de produit / plateforme maintenue par une équipe.

Le but, faire de Grafana un Produit interne au meme titre que les autres solution internes.

Le end user fait un formulaire , qui lance via un script dans GitLab ci, qui fait des calls API à Grafana pour créer des teams, folder, ...

Travail avec les équipe ops qui travaillais dejas via ces outils, pour y intégrer les source de données utiliees à tout le monde. Mettre à dispo les bonnes sources pour avoir une bonne adoption de la plateforme.

Différents types de users, qui peuvent interagir différemment avec la plateforme en fonction de leurs attentes. des possibilité de faire à la mano, où de passer via des yaml de déploiement et des repos. Il faut qu elle soit accessible.

Chaque équipe à la main sur ses source de data et fait ses tableau de bord par besoins. Les users sont owner de leur viz, full self service.

Mise en place de beaucoup de com, des articles, des release notes, des webinars, un channel teams, ...

Car la plateforme vie par ses end users, pas par la tech. Une plateforme sans users et une voiture sans volant.

L'adoption se fait d elle meme. Un outil ne se scale pas, un produit si.

Sous le capot de Cluster API: concevoir et implémenter un provider d'infrastructure

La base de cluster api CAPI. - des CRD et des controllers pour gérer des cluster kubernetes dans kubernetes. - un provider cluster API est un opérateur kub, qui vas pouvoir traiter les CRD demande par les ressources CAPI, - le provider d'infra : parle avec les stack d infra , aws,gcp,nuta,vmware,... - le providers bootstrap : mettent place les distro k8s, talos, k3s, ... - le provider control plane : qui instancie le controle plane k8s : talos, k3s ,...

Il faut donc pour apporter ses providers, il faut ramener en plus de CRD Core de CAPI, il faut étendre ces CRD pour la stack sur laquel on veut provisionner, ainsi que le controller pour ces extended CRD.

Pour faciliter la creation, s'appuyer sur Kubebuilder qui facilite la creation d'un opérateur kub, en go. Et importer le SDK go de notre infra provider, si elle existe.

On peut ajouter ses propres champs qu'on veut permettre à l'utilisateur d'utiliser lors de la creation de ses clusters. comme, le vnet, la zone dns, ...

Les kind à implementer - cluster - machine - machine template Les controller à implementer - Cluster Reconciler - creation d un scope avec les contextes api de l'infra et de la CRD cluster - ajout de finalizer sur les secret aligne avec le cycle de vie de la CRD cluster - renvoie des address controle plane sur la crd cluster - Cluster service, on définie des reconcilers pour tous les service sous jacent pre requis pour le setup du cluster. - vpc - gateway - load bal - domain - Machine, meme méthode de reconciling pour le provisionnement des machines.

Pour l'operator, il faut builder une image dédie, avec les binaire capable de parler avec notre stack d infra.

REX Mistral AI - Construire un fournisseur cloud de zero: ClusterAPI dans le datacenter

Leonard Suslian, Antoine Roy

KaaS en bare metal Mistral Compute: initiative d'avoir un cloud europeen, avec du materiel GPU Nvidia à date, fournir une offre complete de bare metal à du SaaS mistral studio et entre les deux du KaaS.

Passage via le provider infra Metal3.

Comment on crée le cluster de management? utilisation de la fonction Pivot, pour cloner le cluster avec CAPI local vers une cible.

Le premier cluster CORE à toutes les CRDs CAPI. Et on rajoute le provider - Infra Metal3 - Kubeadm pour bootstrap - Kamaji pour le control plane

Le cycle de vie des cluster de CAPI est comme une app normal.

Metal3 pour le bare metal - CAPI provider Metal3 - Metal3 operator :gère les ressource de Metal3, mais ne les provisionne pas, il les définies. - Ironic, gère quels machines physiques on apporte à Metal3, le provisioning physique des machines est fait par ce service

Le cycle de déploiement est le suivant : CAPI core -> Metal3 -> baremetal host -> Ironic -> pxe -> os=> node kube

Kamaji - gestion de control plane dans un cluster qui vas porter les control planes de tous les clusters crée par la stack CAPI. - Les control plane sont isolés comme celas, uniquement via l'api server. - permet d avoir de la haute disponibilité, sans ajouter 3 nœuds bare metal par clusters.

Il on fait un opérateur on top de tout ca, pour avoir une CRD pour faire leur propre ComputeOperator, via Kubebuilder encore une fois.

Leur CRD : managedCluster. avec des reasons pour toutes les étapes du cycle de vie d'un cluster k8s, la CRD une fois definie en yaml fait 30 lignes à peu prêt.

En frontal de l'operator, une api customer facing avec un IDP.

Le Monitoring - Fulls stack Grafana Alloy - La kub monitoring stack - Si on fait du KaaS, il faut du monitoring - Cluster de management, qui trigger via Sveltos un déploiement des Alloy avec kub state metricset node exporter - Le Grafana , Loki, Mimir sont sur le cluster de management central ! pour ne pas être aveugle en cas de pb. ils sont instanciés pour chaque tenant/client qui posede un managedCluster, donc si un client à 10 cluster il à une instance de monitoring unique pour tous ses clusters.

Pour la gestion des workload, utilisation de SLURM . Slurm + kub = Slinky Il y à des ressources dédies à SLURM , le controler les nodeset, loginNodes Pour ca aussi, il on fait une sur couche qui encapsule SLURM .

Les problemo

Cluster hybride x86_64 et arm64, sur les serveurs Nvidia, Grace fournis par nvidia, il y à de base des cpu arm64, dont pour toute la partie Metal3, il faut gérer les builds arm, pas de support Ironic dans Metal3 pour arm de base.

Mise à l’échelle, ETCD est le maillon faible. Avec bcp de nodes, les leases et events explosent et pète le ETCD, sur des cluster à 4600 nodes. Solution -etcd-servers-overrides permet de passer certaines ressources sur d'aures clusters ETCD. Ils ont donc multiplie le nombre de serveur ETCD, genre 5 cluster ETCD différents, mais il faut partager les CA mtls. Ils ont fait une contrib sur Kamaji, de dataStoreOverrides, pour pouvoir dériver des events sur des ETCD secondiry. Avoir que les ressources kubernetes dans les ETCD primary.

Hardware Shenanigans RedFish, BMC, PDU, DPU, DHCP, iPXE, VXLAN, OOB, DDN,....

Q&A

Pourquoi il n ont pas remplace ETCD ? ils y on pense, et veulent tester du PostgreSQL et Kine, mais le sharding marche.

Pourquoi bare metal? parce que dans le cas de l AI, en tout cas en training, on consomme toujours 100% du host, donc pas davantage à etre en VM. Et les perfs bas niveau sont la.

Qu est ce qui se passe si on perd le secondary ETCD ? ça casse pas tout askip

Le delete d'un managed cluster ? il y à plein de cleanup, decom des nodes pools cluster API, ils utilisent des petits host de cleanup des Machine bare metal. Puis tear down du control plane kamaji.

Pas de PB de nombre de pods par hosts? Ca arrive pas sur les workload ai, que sur la ci/cd on atteint les 110 pods par nodes. Mais pour les GPU on est à 10 pods par noaueds. Et come il y à SLURN un cluster slurn est dans un POD, donc ok.

CNI ? Cilium, mais sans encapsulation vxlan, usage auto-direct-node-route, le pod cilium peut prendre chere. 30go/ram

OS immage des noeuds ? pas immutable, car Nvidia drivers certifies pour Ubuntu 24.04 par ex, pour le support Nvidia. Mais si il pouvais Kros où Talos.

Technos à checker

• K0s : Distribution k8s single binay pour du cloud, bare metal où edge/iot
• Capsule : framework de multitenancy et policy
• Nats : queing
• cAdvisor : suivi de metrics de containers
• UI pour voir les workspaces terraforms
• kuik : gestion des images via kub
• kagent : agent ai au sein des cluster k8s, pour acter comme un gestionnaire de cluster, SRE
• CAPI : Cluster API, provisioning de cluster k8s depuis un cluster k8s
• HLS4ML : Portage de modèles d inference sur des FPGA pour usage real time
• SLURM : SLURM Workload Manager, un scheduler de workloads sur cluster linux.
• ORAS : Manage any artifact as an OCI container.
• Metal3 : Bare metal host management for k8s, base sur Ironic
• Ironic : Bare metal as à Service
• Kine : Permet de remplacer ETCD par un rdms autre.

Deploiement LLM IA - Etat de l'art

Table des matières

• La représentation physique des LLMs
  • Quantification (quantization)
  • Distillation
• La construction des LLMs
• L'utilisation des LLMs
• La personnalisation des LLMs
• Le hosting des LLMs
• La construction d'agents
• Multi Agents Systems

Lexique - Générale

La représentation physique des LLMs

Les réseaux de neurones actuels dont les LLMs sont des successions de niveau de transformer qui portent les "couches d'intelligence", qui s'appuient sur des tensors (collections multidimensionnels, ex: un tensor 2D = matrice). Ces tensors sont représentées par des paramètres correspondant principalement a des Poids ou des Biais.

Si on prend des exemples de modèles open sources, sur hugging-face

On voit par exemple pour Deepseek R1 : https://huggingface.co/deepseek-ai/DeepSeek-R1/tree/main

• Model size 658 Milliards de paramètres
• Tensort types : BF16 donc un floating point 16 bits , …

Cela représente dans le repository hugging-face, un modèle au format safetensors, 163 partitions de 4,3Gb, soit un modèle de ~700Gb a monter en mémoire GPU dans sa version non quantifiée.

Quantification (quantization)

Si on effectue une Quantification par exemple en Q_4, qui transforme les floating point 16 bit en int 4 bit, on peut descendre a ~360Gb a monter en memoire GPU

On peut aller jusqu'à 1 bit!

Distillation

Un autre axe de réduction des pré-requis memoire GPU est de passer sur une version du modèle "distillé" c'est a dire avec moins de paramètres, exemple

On conserve des paramètres de 16bits, mais on passe a 32 milliard de paramètres contre les 685 du modèle "complet".

On a ainsi un modèle de "seulement" 70Gb a monter en mémoire GPU

La combinaison de ces deux techniques, quantization/distillation permet de servir des modèles puissant a différent niveaux d'efficacité sur des infra de tailles variables.

On se rend compte que quand si on dit je fait tourner Deepseek R1 sur mon Raspberry pi, ça ne veut pas dire grand choses, si on ne sais pas quelle distillation et potentielle quantification est utilisée.

La construction des LLMs

Toutes les applications AI, de haut niveau sont codées en python. La couche basse CUDA est codée dans un langage propriétaire proche du C, maintenue par Nvidia.

Les frameworks de manipulation et entrainement de réseaux de neurones sont développes par des Tiers, PyTorch par Facebook et TensofFlow par Google par exemple. Ces Frameworks s'appuient sur les drivers et librairies de parallélisation CUDA.

Les développeurs de LLMs utilisent un couche d'abstraction supplémentaire comme par exemple Keras, qui offre une API de gestion/expérimentations/entrainement de modèles deep learning. Cet plateforme est agnostique du backend et peut s'appuyer sur TensorFlow, PyTorch, JAX.

Lorsqu'on évoque un modèle "open source" (llama, deepseek,…), cela n'implique pas toujours que les jeux de données (data sets) et le code source d'entraînement soient intégralement ouverts. Souvent, ce sont principalement les poids finaux du modèle qui sont publiés, par exemple sous forme de fichiers .safetensors. Certains projets open source vont plus loin en partageant également le code d'entraînement voire les données.

Pour les modèles propriétaires, comme ceux d'OpenAI, la confidentialité de ces poids est cruciale et leur divulgation est généralement évitée.

L'utilisation des LLMs

On voit bien ici qu'une fois qu'on abstrait le serving du LLM, en passant par un endpoint centralise ou externe, les besoins applicatifs sont beaucoup plus simples.

La personnalisation des LLMs

Le hosting des LLMs

Bien que des acteurs et projet concurrent commencent a émerger (Intel Arc, AMD Rocm), on voit sur le marché l'omni presense des solution Nvidia, sur la plupart des couches structurantes de l'écosysteme IA. Du bare metal, au librairies Python, en passant par les environnements conteneurisés, cela est principalement du a la stack CUDA, qui fait office de kernel entre les librairies/framework, et les couples de CPU + GPU Nvidia. (d'où les stonks📈💸)

Le management des couches On prem et IaaS est assez similaire, a partir de la couche VM, l'important est de gérer la continuité de driver Nvidia, de bas en haut.

Pour du serving en conteneur Simple ou directement en Python, on utilise des librairies tel que Vllm, qui apportent de la simplicité.

Une fois qu'on est dans le spectre Kubernetes, on privilégie des solution plus adaptées et Cloud Native, tels que Kserve.

Les Solution PaaS et SaaS, même si on ne le voie pas, se basent sur des couches inferieurs très similaire, et les optimisent grâce a la multitenancy native de leurs déploiements. Ce qui leur apporte un avantage financier, car il est difficile d'utiliser « au taquet » des infra GPU on prem ou dédiées de taille suffisants au hosting de modèles modernes. (200GB VRAM+)

La construction d'agents

Multi Agents Systems