Kubernetes v1.36

Date de sortie : 22 avril 2026
Nom de code : ハル (Haru — « Printemps » en japonais)

Kubernetes v1.36 est sorti fin avril 2026 sous le nom de code Haru (printemps en japonais), et c’est une release dense.

Voici mon tour d’horizon des changements les plus significatifs.

🔐 Sécurité : des fondations qui arrivent enfin à maturité

User Namespaces : 🟢 Stable

Le problème :

Par défaut, un processus qui tourne en tant que root (UID 0) dans un conteneur est aussi root sur le nœud hôte. En cas de fuite de conteneur (container escape), l’attaquant dispose immédiatement de privilèges root sur la machine, ce qui compromet l’ensemble des workloads du nœud.

La solution :

Les User Namespaces (isolation des UID/GID entre le pod et le nœud) passent en GA (Stable). Kubernetes remape automatiquement les UID/GID du conteneur vers des UID/GID non privilégiés sur le nœud hôte. Un processus root dans le conteneur (UID 0) est vu comme un utilisateur sans privilège sur le nœud (ex : UID 65534).

Exemple :

apiVersion: v1
kind: Pod
metadata:
  name: app-with-userns
  labels:
    app: secure-app
spec:
  hostUsers: false  # Active les User Namespaces
  containers:
  - name: app
    image: myregistry/my-app:latest
    securityContext:
      runAsUser: 0         # root dans le conteneur...
      allowPrivilegeEscalation: false
      capabilities:
        drop: ["ALL"]
    resources:
      limits:
        memory: "256Mi"
        cpu: "500m"

Avec hostUsers: false, le UID 0 dans le conteneur est remappé vers un UID non privilégié sur le nœud (ex : 65536). Même en cas d’évasion, l’attaquant n’a aucun privilège sur l’hôte.

Fine-Grained Kubelet API Authorization : 🟢 Stable

Le problème :

Kubelet est l’agent qui tourne sur chaque machine de votre cluster et qui s’assure que vos applications fonctionnent. Jusqu’ici, les permissions pour accéder à cet agent étaient soit tout ou rien — un peu comme une serrure unique pour toute une maison.

La solution :

Il est maintenant possible de définir des permissions très précises : cet outil de monitoring peut seulement lire les logs, cet autre outil peut redémarrer des pods mais pas lire les données, etc.

Pourquoi c’est important :

Si un outil tiers est compromis, il ne peut pas profiter de ses accès pour faire n’importe quoi sur vos machines. C’est le principe du moindre privilège appliqué là où ça compte vraiment.

Exemple :

# Exemple de Role pour accéder uniquement aux logs des pods
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-log-reader
rules:
- apiGroups: [""]
  resources: ["pods/log"]
  verbs: ["get", "list"]

Admission Policies immuables : 🔴 Alpha

Le problème :

Un administrateur mal intentionné (ou simplement qui fait une erreur) peut supprimer des règles de sécurité critiques sur un cluster.

La solution :

Certaines politiques de sécurité peuvent maintenant être déclarées comme permanentes dans des fichiers de configuration. Personne ne peut les supprimer via l’API, il faudrait accès direct au cluster pour les retirer.

Exemple :

apiVersion: policy.k8s.io/v1
kind: PodSecurityPolicy
metadata:
  name: no-privileged
spec:
  privileged: false
immutable: true

Declarative Validation : 🟢 Stable

Le problème :

Quand on déploie une application sur Kubernetes, on peut définir des règles pour valider les configurations (ex : “tous les pods doivent avoir un label env”). Historiquement, ces validations passaient par des services externes appelés webhooks, qui rajoutaient de la complexité et pouvaient tomber en panne.

La solution :

Ces règles de validation peuvent maintenant être écrites directement dans la configuration Kubernetes, sans service intermédiaire. Kubernetes les vérifie lui-même, instantanément.

Pourquoi c’est important :

Moins de webhooks à maintenir, moins de latence, et une validation plus robuste au niveau de l’API Server.

⚙️ Gestion des ressources : vers plus de finesse

In-Place Vertical Scaling au niveau Pod : 🟡 Beta

Le problème :

Imaginez une application qui tourne en production et qui commence à manquer de mémoire. Jusqu’ici, la seule solution était de l’arrêter, changer sa configuration, et la redémarrer soit manuellement, soit via le Vertical Pod Autoscaler (VPA).

La solution :

Il est maintenant possible d’augmenter (ou réduire) la mémoire et le CPU alloués à une application en direct, sans interruption. Kubernetes ajuste les ressources à chaud.

J’aime énormément cette feature pour les applications qui ont des besoins variables ou qui sont difficiles à dimensionner à l’avance. C’est un vrai gain de flexibilité et cette feature sera un atout pour réduire encore un peu plus notre facture cloud.

Tiered Memory Protection with Memory QoS : 🟡 Beta

Kubernetes v1.36 affine le modèle d’allocation mémoire : les pods critiques peuvent désormais bénéficier de garanties mémoire plus fortes, tandis que les pods best-effort sont soumis à une pression mémoire plus agressive. Une feature qui change la vie en production sur des nœuds fortement chargés.

Mutable Pod Resources for Suspended Jobs : 🟡 Beta

Le problème :

Kubernetes permet de mettre en pause les ressources de type Job mais si on veut modifier les ressources allouées avant de reprendre le job, ce n’était pas possible.

La solution : Pendant qu’un job est en pause, on peut maintenant modifier ses ressources (plus de mémoire, moins de CPU…) avant de le relancer.

📊 Observabilité et scalabilité de l’API

PSI Metrics : 🟢 Stable

Les métriques PSI (Pressure Stall Information) qui mesurent la pression réelle subie par les workloads sur le CPU, la mémoire et l’I/O passent en GA. Ces métriques Linux sont bien plus précises que les métriques CPU classiques pour détecter une saturation réelle. Si vous utilisez Prometheus, commencez à les intégrer dès maintenant.

# Exemple : pression mémoire sur les nœuds
container_memory_psi_full_total

Cf. PSI Metrics Documentation pour plus de détails.

💾 Stockage

Volume Group Snapshots : 🟢 Stable

Les snapshots groupés de volumes (capturer atomiquement plusieurs PVCs en une seule opération) atteignent la GA. Indispensable pour les bases de données distribuées où la cohérence des snapshots entre plusieurs volumes est critique.

🌐 Réseau : Gateway API v1.5

En parallèle de la release Kubernetes, Gateway API v1.5 est sorti avec plusieurs features passant en stable. Le projet continue de s’imposer comme le successeur d’Ingress, et l’outil Ingress2Gateway 1.0 facilite désormais la migration automatisée de vos ressources Ingress existantes.

Je prévois de faire un article dédié sur Gateway API dans les prochaines semaines, c’est une évolution majeure pour la gestion du trafic dans Kubernetes et il y a beaucoup à dire sur les nouvelles possibilités offertes par cette API.

🗑️ Dépréciations et suppressions à surveiller

Service ExternalIPs

Dépréciés, suppression imminente en v1.37. Si vous utilisez des ExternalIPs pour exposer vos services, il est temps de migrer vers des solutions plus modernes comme les LoadBalancers ou la Gateway API.

Comment vérifier si vous êtes concernés ?

Rien de plus simple avec JQ et kubectl :

kubectl get svc --all-namespaces -o json | jq '.items[] | select(.spec.externalIPs != null) | {namespace: .metadata.namespace, name: .metadata.name, externalIPs: .spec.externalIPs}'

🔄 Ce que ça change pour vos clusters

Conclusion

Kubernetes v1.36 Haru est une release accès sur une gestion plus fine des ressources et sur la sécurité. Plusieurs features clés passent en GA(Stable) et peuvent désormais être utilisées en production.

Le gros point d’attention concerne le décommissionnement à venir des ExternalIPs, qui peut impacter les clusters qui les utilisent pour exposer des services.

Sources : Kubernetes v1.36 Release Notes · Kubernetes Blog, PSI Metrics Documentation, PSI Overview