Kubernetes 1.33 sort les conteneurs sidecar du bac à sable et muscle le contrôle d’admission

Nom de code Octarine, la version 1.33 de Kubernetes a été livrée le 23 avril 2025. Soixante-quatre enhancements au compteur : 18 passages en stable, 20 en beta, 24 nouvelles alpha. Derrière le volume, trois changements redessinent le quotidien des opérateurs : les conteneurs sidecar natifs passent en disponibilité générale, les Pods peuvent être redimensionnés sans redémarrage, et la configuration structurée des chaînes d’autorisation devient le standard.

Pour les clusters qui s’appuient encore sur des webhooks d’admission maison, 1.33 est le signal : les ValidatingAdmissionPolicy (VAP) en CEL sont maintenant une alternative de production. Voici ce qu’il faut retenir, et ce qu’il faut migrer.

Sidecars natifs : fin du bricolage

Le pattern sidecar — un conteneur auxiliaire qui tourne aux côtés du conteneur applicatif pour le réseau, la journalisation ou la télémétrie — était implémenté de facto depuis des années par les service meshes et les collecteurs OpenTelemetry. Mais Kubernetes n’avait aucun moyen natif de garantir que le sidecar démarre avant l’application principale.

La 1.33 règle définitivement le problème. Le mécanisme, introduit en alpha dans la 1.28 et beta dans la 1.29, est maintenant stable. Le principe : un initContainer avec restartPolicy: Always devient un conteneur sidecar. Il démarre avant les conteneurs réguliers, persiste pendant tout le cycle de vie du Pod, et s’arrête automatiquement après la fin des conteneurs principaux.

spec:
  initContainers:
    - name: envoy-proxy
      image: envoyproxy/envoy:v1.30
      restartPolicy: Always   # ← Ce flag le transforme en sidecar
      startupProbe:
        httpGet:
          path: /ready
          port: 9901
        failureThreshold: 30
  containers:
    - name: app
      image: myapp:latest
      # Garanti : Envoy est prêt avant le démarrage de l'app

Pour Istio, Linkerd et les déploiements OpenTelemetry, c’est une clarification bienvenue. L’ordonnancement du cycle de vie devient prédictible, sans scripts wrapper ni initContainers détournés. Les sidecars peuvent désormais utiliser des sondes (startup, readiness, liveness) et leur score OOM est aligné sur celui des conteneurs principaux.

Redimensionnement à chaud des Pods

Avant 1.33, modifier les ressources CPU ou mémoire d’un Pod imposait de le tuer et de le recréer. La fonctionnalité In-Place Pod Vertical Scaling, en beta dans cette version, change radicalement la donne.

kubectl patch pod my-pod --subresource=resize \
  -p '{"spec":{"containers":[{"name":"app","resources":{"requests":{"cpu":"500m","memory":"512Mi"}}}]}}'

Aucun redémarrage. Le Pod reçoit ses nouvelles limites directement.

La spécification s’enrichit d’un champ resizePolicy par conteneur, avec deux politiques : RestartNotRequired (par défaut pour le CPU) et RestartContainer (pour la mémoire sur certains runtimes). Le statut du Pod distingue désormais allocatedResources (ce que le nœud a effectivement alloué) de resources (la cible souhaitée).

Couplé au HPA, le redimensionnement vertical devient un choix d’architecture à part entière : pour les charges stateful, mieux vaut parfois un seul Pod plus gros que dix Pods plus petits.

Admission : VAP sort de l’ombre

Le changement le plus structurant est la montée en maturité des ValidatingAdmissionPolicy (VAP). Introduites en alpha dans la 1.26, elles offrent une alternative déclarative aux webhooks d’admission validants : les règles sont écrites en Common Expression Language (CEL) et évaluées dans l’API server lui-même — sans appel réseau externe.

La 1.33 apporte des améliorations d’expressivité CEL et une meilleure gestion des messages d’erreur. Le VAP est désormais viable en production pour les politiques exprimables en CEL.

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: require-app-label
spec:
  failurePolicy: Fail
  matchConstraints:
    resourceRules:
      - apiGroups: ["apps"]
        apiVersions: ["v1"]
        operations: ["CREATE", "UPDATE"]
        resources: ["deployments"]
  validations:
    - expression: "has(object.metadata.labels) && has(object.metadata.labels.app)"
      message: "Le label 'app' est obligatoire sur tous les Deployments"

Ce que le VAP fait bien. Pas de contrôleur supplémentaire à opérer, latence minimale (traitement interne à l’API server), idéal pour les règles simples : « tout Deployment doit porter le label app », « interdire le registre docker.io/noname ».

Ce que le VAP ne fait pas. CEL reste moins expressif que le Rego de Gatekeeper ou le YAML de Kyverno. Le VAP ne couvre que la validation — pas de mutation. Pas de workflows d’exceptions avancés.

Le pattern émergent en 2025-2026 : VAP pour les garde-fous simples et universels ; Kyverno ou Gatekeeper pour les politiques supply chain complexes. Les deux coexistent sans conflit sur le même cluster.

Autorisation structurée : le YAML remplace les flags CLI

Autre graduation majeure : la configuration structurée des chaînes d’autorisation passe en GA. Avant 1.30, exprimer une chaîne d’authorizers (Node → RBAC → Webhook) passait par des flags de ligne de commande — ordonnés, fragiles, impossibles à versionner proprement.

La 1.33 rend un fichier YAML déclaratif obligatoire :

apiVersion: apiserver.config.k8s.io/v1
kind: AuthorizationConfiguration
authorizers:
  - type: Node
    name: node
  - type: RBAC
    name: rbac
  - type: Webhook
    name: opa-webhook
    webhook:
      timeout: 3s
      failurePolicy: Deny
      matchConditions:
        - name: only-non-system
          expression: "!request.userInfo.username.startsWith('system:')"

Les matchConditions en CEL permettent de n’appeler le webhook d’autorisation que pour les requêtes pertinentes — un gain de performance significatif. Le chemin par flags est en cours de dépréciation : migrez avant 1.34.

Ce qui va casser

Fournisseurs cloud in-tree. Les contrôleurs natifs AWS, GCP et Azure sont supprimés. Les clusters doivent impérativement utiliser le cloud-controller-manager externe. Si votre cluster tournait encore sur du in-tree, la migration n’est plus optionnelle.

cgroup v1. Les signaux de dépréciation se resserrent. Les runtimes liés à cgroup v1 doivent planifier leur migration — la suppression n’est pas pour 1.33, mais l’écriture est sur le mur.

PSP fantômes. La PSP est morte depuis la 1.25, mais des clusters vieillissants traînent encore des contrôleurs d’admission PSP résiduels. La 1.33 est le bon moment pour les purger.

# Vérifier l'utilisation d'API dépréciées
kubectl get --raw /metrics | grep apiserver_requested_deprecated_apis

# Auditer le Pod Security Admission par namespace
kubectl get namespaces -o json | jq '.items[] | {name: .metadata.name, pss: .metadata.labels["pod-security.kubernetes.io/enforce"]}'

Jobs : plus de granularité

Les charges batch gagnent deux améliorations en GA. La Success Policy permet de définir « terminé » au-delà de « tous les pods ont réussi » — exiger les N premiers index, un nombre minimal, ou une combinaison. Les Backoff Limits Per Index autorisent des seuils d’échec par index : un seul pod défaillant ne fait plus échouer le Job entier.

La check-list de montée de version

1. Vérifier la compatibilité des contrôleurs d’admission tiers — Kyverno, Gatekeeper, contrôleurs commerciaux
2. Migrer la configuration d’autorisation des flags CLI vers le fichier structuré YAML
3. Vérifier l’utilisation d’API dépréciées — kubectl get --raw /metrics | grep apiserver_requested_deprecated_apis
4. Déployer le CCM externe si votre cluster utilisait un fournisseur cloud in-tree
5. Auditer les namespaces pour le Pod Security Admission avant de passer en mode enforce

La règle de cadence : opérez en version N ou N-1 en production. Kubernetes publie trois versions par an avec un support de 14 mois. Être à plus d’une version de retard compresse dangereusement la fenêtre de décision sur les correctifs de sécurité.

Le verdict

Kubernetes 1.33 est un cycle de maturation, pas une révolution. Mais c’est une maturation qui change la pratique quotidienne.

Les sidecars natifs règlent un problème d’ordonnancement que les service meshes contournaient depuis des années — sans script, sans détournement d’initContainer. Le redimensionnement à chaud supprime une friction opérationnelle majeure : ne plus avoir à tuer un Pod pour lui donner plus de CPU change la façon dont on dimensionne les charges stateful. Et les VAP deviennent une alternative réelle aux webhooks pour les politiques simples — sans le coût d’opérer un contrôleur supplémentaire.

Si vous gérez des clusters en production, le moment de solder la dette technique est venu : migrez la configuration d’autorisation, vérifiez vos contrôleurs d’admission, et commencez à déplacer vos règles de validation simples vers le VAP. La 1.34 n’attendra pas.

Références

• Kubernetes v1.33: Octarine, Kubernetes Blog, 23 avril 2025.
• Kubernetes 1.33 Security Deep Dive, Safeguard, 20 juin 2025.
• Kubernetes 1.31 to 1.33: Every Feature You Need to Know Right Now, Dev Note, 30 juin 2026.
• Validating Admission Policy, documentation Kubernetes.
• Sidecar Containers, documentation Kubernetes.
• KEP-753: Sidecar Containers.
• KEP-1287: In-Place Update of Pod Resources.
• KEP-3850: Backoff Limit Per Index For Indexed Jobs.
• KEP-3998: Job success/completion policy.