📦 Dépôt GitHub Officiel & Documentation CNCF :

• GitHub : github.com/k3s-io/k3s (Créé le 31 mai 2018 par Darren Shepherd / Rancher Labs, publié officiellement le 26 février 2019, donné à la CNCF en août 2020)
• Documentation Officielle : docs.k3s.io

Déployer un cluster Kubernetes Vanilla complet (kubeadm) pour un environnement Edge, une PME, un cluster CI/CD ou un Homelab revient souvent à mobiliser 2 à 4 Go de RAM uniquement pour faire tourner le plan de contrôle (kube-apiserver, etcd, kube-controller-manager, kube-scheduler) avant même d’avoir lancé le moindre conteneur applicatif.

C’est précisément pour éliminer cette surcharge opérationnelle que Rancher Labs a publié K3s le 26 février 2019 (un jeu de mots sur « K8s divisé par deux », soit un Kubernetes 5 lettres plus léger en mémoire).

1. Architecture d’un binaire unique (< 70 Mo)

Contrairement à une distribution édulcorée ou non standard, K3s est une distribution Kubernetes 100 % certifiée CNCF (Cloud Native Computing Foundation). Toutes les API standard (Deployment, StatefulSet, Ingress, Gateway API, NetworkPolicy, RBAC) y fonctionnent à l’identique.

Pour tenir dans un binaire unique de moins de 70 Mo et consommer environ 512 Mo de RAM au repos, K3s regroupe tous les processus du Control Plane et du Node Agent dans un seul exécutable Go (k3s server / k3s agent) et supprime du code source amont :

• Les anciens In-Tree Cloud Providers (AWS, GCP, Azure historiques remplacés par les Cloud Controller Managers externes) ;
• Les anciens drivers de stockage In-Tree au profit de CSI (Container Storage Interface) ;
• Le démon Docker lourd au profit de containerd directement intégré.

L’astuce architecturale : Kine (Kine is not etcd)

Le composant le plus gourmand en IOPS disque et en mémoire d’un cluster Kubernetes classique est etcd. Sur un nœud unique ou une carte SD / NVMe Edge, etcd use prématurément le stockage par ses écritures d’élection Raft permanentes.

K3s introduit Kine, un traducteur léger qui expose l’API gRPC d’etcd à kube-apiserver, mais stocke les états en base relationnelle :

1. Par défaut sur nœud unique : une base SQLite locale (/var/lib/rancher/k3s/server/db/state.db), réduisant l’empreinte disque et RAM de 70 % ;
2. En production externe : PostgreSQL ou MySQL / MariaDB managé ;
3. En Haute Disponibilité (HA 3 nœuds) : etcd embarqué (--cluster-init), activable en une seule option CLI sans installer de cluster etcd séparé.

2. Comparatif 2026 : K3s vs kubeadm vs Talos Linux vs MicroShift

3. Déploiement Production durci (Haute Disponibilité & Cilium / Traefik)

Par défaut, curl -sfL https://get.k3s.io | sh - démarre un cluster fonctionnel en 30 secondes. En production ou sur un homelab exigeant, on personnalise toutefois l’installation via /etc/rancher/k3s/config.yaml (plutôt qu’une longue ligne d’arguments systemd) :

# /etc/rancher/k3s/config.yaml (Premier nœud Control Plane HA)
cluster-init: true
write-kubeconfig-mode: "0600"
tls-san:
  - "k8s.mon-domaine.interne"
  - "10.0.10.100"

# Sécurité : Chiffrement des Secrets Kubernetes au repos (AES-CBC)
secrets-encryption: true

# Optionnel : Désactiver Traefik v2 embarqué ou ServiceLB si l'on déploie MetalLB + Traefik v3 / Cilium
disable:
  - servicelb

# Durcissement Kubelet
kubelet-arg:
  - "max-pods=110"
  - "protect-kernel-defaults=true"

Gestion déclarative des Add-ons avec le HelmController natif

L’une des meilleures fonctionnalités méconnues de K3s est son Helm Controller intégré. Il suffit de déposer un manifeste YAML HelmChart dans /var/lib/rancher/k3s/server/manifests/ pour que K3s installe et maintienne automatiquement n’importe quel chart Helm au démarrage du nœud (idéal pour MetalLB, Cert-Manager, Longhorn ou Prometheus) sans aucun pipeline externe :

apiVersion: helm.cattle.io/v1
kind: HelmChart
metadata:
  name: cert-manager
  namespace: kube-system
spec:
  repo: https://charts.jetstack.io
  chart: cert-manager
  targetNamespace: cert-manager
  createNamespace: true
  version: v1.17.1
  set:
    crds.enabled: "true"

4. Quand choisir K3s (et quand s’en abstenir) ?

✅ Choisissez K3s si :

• Vous opérez entre 1 et 30 nœuds Bare-Metal, Mini-PC, ARM64 (Raspberry Pi 5 / Rockchip) ou VPS où chaque gigaoctet de RAM compte pour vos charges utiles ;
• Vous voulez un cluster GitOps prêt à l’emploi en moins d’une minute avec local-path-provisioner et HelmChart natifs ;
• Vous déployez sur des sites distants (Edge / Retail / IoT industriel) avec une bande passante limitée et des mises à jour automatisées via le system-upgrade-controller.

⚠️ Préférez Kubernetes standard ou managé (EKS/AKS/GKE) si :

• Vous gérez des clusters multi-équipes dépassant 50 à 100 nœuds à très forte densité d’objets API (où un cluster etcd dédié sur disques NVMe séparés du plan de travail reste indispensable) ;
• Votre entreprise impose un OS immuable piloté à 100 % par API gRPC sans accès shell ni systemd (auquel cas Talos Linux est plus adapté).

Références & Sources Officielles

1. Dépôt GitHub Officiel K3s (k3s-io/k3s) : Historique du projet (création mai 2018, annonce publique v0.1.0 le 26 février 2019) : https://github.com/k3s-io/k3s
2. Documentation Officielle K3s (Architecture & Options de Haute Disponibilité) : https://docs.k3s.io/architecture
3. CNCF K3s Project Page : Sandbox / Incubation Cloud Native Computing Foundation : https://www.cncf.io/projects/k3s/
4. Dépôt GitHub k3s-io/kine (Kine is not etcd) : Traducteur gRPC etcd vers SQLite/Postgres/MySQL : https://github.com/k3s-io/kine

Si vous voulez plus d’information sur l’infrastructure vous pouvez voir mon repo à ce sujet : https://github.com/ravindrajob/InfraAtHome