Kubernetes 1.30 : Sidecar Containers natifs et nouvelles fonctionnalités production (Novembre 2025)

Kubernetes 1.30 "Uwubernetes" : La révolution des Sidecar Containers

Le 17 avril 2024, la Cloud Native Computing Foundation (CNCF) a publié Kubernetes 1.30, nom de code "Uwubernetes", une version qui marque un tournant décisif dans l'histoire de l'orchestration de conteneurs. Avec 45 améliorations dont 12 nouvelles fonctionnalités promues en stable et 19 en beta, cette release se positionne comme la version la plus attendue de 2024-2025 pour les environnements de production.

En novembre 2025, après plus d'un an de déploiements massifs en production, Kubernetes 1.30 s'est imposé comme le standard incontournable avec une adoption de 67% dans les entreprises utilisant Kubernetes, selon le dernier rapport CNCF. Cette adoption massive s'explique par trois innovations majeures qui répondent aux défis critiques des architectures cloud-native modernes.

Les trois piliers de Kubernetes 1.30 :

1. Sidecar Containers natifs (Beta) : Enfin une solution élégante au problème des init containers persistants
2. Sécurité renforcée : Pod Security Standards, secrets encryption, admission webhooks
3. Production-readiness : Observabilité, performance, et stabilité accrues

Cette version représente 4 ans de développement sur les sidecars, avec plus de 250 contributions de développeurs du monde entier, et des tests intensifs sur des clusters gérant jusqu'à 15,000 nœuds et 1 million de pods.

Sidecar Containers natifs : Une révolution architecturale

Le problème historique des sidecars

Depuis les débuts de Kubernetes, les sidecar containers sont au cœur des architectures cloud-native modernes. Un sidecar est un conteneur auxiliaire qui s'exécute aux côtés du conteneur principal dans un Pod pour fournir des fonctionnalités transverses :

• Service mesh : Envoy (Istio, Linkerd), proxies de routage intelligent
• Logging centralisé : Fluentd, Fluent Bit, collecte de logs applicatifs
• Monitoring : Prometheus exporters, métriques applicatives
• Sécurité : Vault agents pour injection de secrets, authentification mTLS
• Caching : Redis sidecars, accélération de requêtes

Le problème majeur : Avant Kubernetes 1.30, il n'existait aucun mécanisme natif pour garantir qu'un sidecar démarre avant le conteneur principal et reste actif pendant toute la durée de vie du Pod.

Conséquence concrète :

# Architecture problématique (avant K8s 1.30)
apiVersion: v1
kind: Pod
metadata:
  name: webapp-with-logging
spec:
  containers:
  - name: webapp
    image: nginx:1.25
    # Application démarre immédiatement
    # Problème : Fluentd peut ne pas être prêt !

  - name: fluentd-sidecar
    image: fluent/fluentd:v1.16
    # Démarre EN PARALLÈLE de nginx
    # Race condition : qui démarre en premier ?

Conséquences en production :

• Perte de logs : Les logs générés pendant les premières secondes sont perdus
• Erreurs de connexion : L'application ne peut pas se connecter au sidecar (timeouts)
• Redémarrages en cascade : Le conteneur principal crash en attendant le sidecar
• Complexité accrue : Scripts bash dans command: pour attendre le sidecar (workarounds fragiles)

Une étude de Datadog (2024) révèle que 43% des incidents en production sur Kubernetes sont liés à des race conditions entre conteneurs, dont 62% impliquent des sidecars.

La solution native : restartPolicy dans initContainers

Kubernetes 1.30 introduit une fonctionnalité révolutionnaire : le champ restartPolicy dans les initContainers, permettant de créer des sidecars natifs qui démarrent avant les conteneurs principaux et persistent pendant toute la vie du Pod.

Architecture corrigée avec Kubernetes 1.30 :

apiVersion: v1
kind: Pod
metadata:
  name: webapp-with-logging-correct
spec:
  # Nouveau : initContainers avec restartPolicy
  initContainers:
  - name: fluentd-sidecar
    image: fluent/fluentd:v1.16
    restartPolicy: Always  # 🎯 NOUVELLE FEATURE K8S 1.30 !
    # Ce conteneur :
    # 1. Démarre AVANT 'webapp'
    # 2. Reste actif pendant toute la vie du Pod
    # 3. Redémarre automatiquement en cas de crash
    # 4. S'arrête APRÈS 'webapp' lors du shutdown

    volumeMounts:
    - name: varlog
      mountPath: /var/log
    - name: fluentd-config
      mountPath: /fluentd/etc

  containers:
  - name: webapp
    image: nginx:1.25
    # Démarre SEULEMENT quand fluentd-sidecar est ready
    # Aucun log perdu !

    volumeMounts:
    - name: varlog
      mountPath: /var/log/nginx

  volumes:
  - name: varlog
    emptyDir: {}
  - name: fluentd-config
    configMap:
      name: fluentd-config

Comportement détaillé du cycle de vie :

Création du Pod :
└── Phase 1 : Init Containers avec restartPolicy: Always
    ├── fluentd-sidecar démarre
    ├── Health checks réussis (readinessProbe)
    └── ✅ fluentd-sidecar : READY

└── Phase 2 : Containers principaux
    ├── webapp démarre (fluentd déjà actif !)
    └── ✅ Pod : RUNNING

Pendant l'exécution :
├── Si fluentd-sidecar crash → Redémarrage automatique
└── Si webapp crash → Redémarrage normal (fluentd reste actif)

Shutdown du Pod :
└── Phase 1 : Arrêt containers principaux
    ├── webapp reçoit SIGTERM
    ├── Grace period (30s par défaut)
    └── webapp arrêté

└── Phase 2 : Arrêt init containers (sidecars)
    ├── fluentd-sidecar flush les derniers logs
    └── fluentd-sidecar arrêté proprement

Cas d'usage production : Service Mesh avec Istio

L'un des cas d'usage les plus critiques des sidecars natifs est l'intégration avec les service mesh comme Istio. Avant Kubernetes 1.30, l'injection du proxy Envoy causait de nombreux problèmes de démarrage.

Configuration Istio avec sidecars natifs :

apiVersion: v1
kind: Pod
metadata:
  name: payment-service
  labels:
    app: payment
    version: v2
  annotations:
    sidecar.istio.io/inject: "true"
    # Istio 1.20+ détecte K8s 1.30 et utilise restartPolicy automatiquement
spec:
  initContainers:
  # Istio injecte automatiquement ceci dans K8s 1.30+
  - name: istio-proxy
    image: istio/proxyv2:1.20.0
    restartPolicy: Always
    # Le proxy Envoy démarre AVANT l'application
    # Intercepte tout le trafic réseau dès le démarrage

    env:
    - name: ISTIO_META_POD_NAME
      valueFrom:
        fieldRef:
          fieldPath: metadata.name
    - name: ISTIO_META_MESH_ID
      value: "cluster.local"

    ports:
    - containerPort: 15090  # Prometheus metrics
      protocol: TCP
      name: http-envoy-prom

  containers:
  - name: payment-service
    image: mycompany/payment:2.3.1
    # Toutes les requêtes HTTP/gRPC passent par istio-proxy
    # Fonctionnalités :
    # - mTLS automatique
    # - Circuit breaking
    # - Retry policies
    # - Load balancing
    # - Telemetry (traces, métriques)

    ports:
    - containerPort: 8080
      name: http

    env:
    - name: DATABASE_URL
      valueFrom:
        secretKeyRef:
          name: payment-db-secret
          key: url

Bénéfices mesurables en production :

• 99.9% de réussite au démarrage des pods (vs 87% avant K8s 1.30)
• Réduction de 73% des erreurs "connection refused" au démarrage
• Temps de démarrage réduit de 45% (pas de retry loops)
• Zéro perte de requêtes pendant le startup (proxy prêt avant l'app)

Pattern avancé : Multi-sidecars avec dépendances

Kubernetes 1.30 permet de définir plusieurs sidecars avec des dépendances ordonnées grâce à l'ordre de déclaration dans initContainers.

Architecture avec 3 sidecars :

apiVersion: v1
kind: Pod
metadata:
  name: complex-app
spec:
  initContainers:
  # Sidecar 1 : Configuration watcher (démarre en PREMIER)
  - name: config-watcher
    image: mycompany/config-watcher:1.2
    restartPolicy: Always
    # Surveille ConfigMap/Secrets et notifie l'app
    command:
    - /bin/config-watcher
    - --watch-path=/etc/config
    - --reload-endpoint=http://localhost:8080/reload

    volumeMounts:
    - name: config
      mountPath: /etc/config

  # Sidecar 2 : Vault agent (démarre APRÈS config-watcher)
  - name: vault-agent
    image: hashicorp/vault:1.15
    restartPolicy: Always
    # Injecte dynamiquement les secrets
    env:
    - name: VAULT_ADDR
      value: "https://vault.internal.company.com"
    - name: VAULT_ROLE
      value: "payment-service"

    volumeMounts:
    - name: secrets
      mountPath: /vault/secrets

  # Sidecar 3 : Envoy proxy (démarre en DERNIER)
  - name: envoy-proxy
    image: envoyproxy/envoy:v1.28
    restartPolicy: Always
    # Proxy L7 avec circuit breaking et retry
    command:
    - envoy
    - -c
    - /etc/envoy/envoy.yaml

    volumeMounts:
    - name: envoy-config
      mountPath: /etc/envoy

  containers:
  - name: payment-api
    image: mycompany/payment-api:3.1.0
    # Démarre quand LES TROIS sidecars sont ready
    # Bénéficie de :
    # 1. Configuration dynamique (config-watcher)
    # 2. Secrets injectés (vault-agent)
    # 3. Trafic sécurisé (envoy-proxy)

    ports:
    - containerPort: 8080

  volumes:
  - name: config
    configMap:
      name: payment-config
  - name: secrets
    emptyDir:
      medium: Memory  # tmpfs pour les secrets
  - name: envoy-config
    configMap:
      name: envoy-config

Ordre de démarrage garanti :

Temps    Action
------   ----------------------------------------------------------------
t=0s     config-watcher démarre
t=2s     config-watcher READY → vault-agent démarre
t=5s     vault-agent READY → envoy-proxy démarre
t=8s     envoy-proxy READY → payment-api démarre
t=10s    payment-api READY → Pod RUNNING

Améliorations de sécurité critiques pour la production

1. Pod Security Standards (PSS) en GA

Kubernetes 1.30 marque la disponibilité générale des Pod Security Standards, remplaçant définitivement les PodSecurityPolicies (supprimées dans K8s 1.25).

Les trois niveaux de sécurité :

• Privileged : Pas de restrictions (développement uniquement)
• Baseline : Restrictions minimales (évite les escalations de privilèges)
• Restricted : Restrictions maximales (production hautement sécurisée)

Application au niveau namespace :

apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    # Mode enforce : Bloque les pods non conformes
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/enforce-version: v1.30

    # Mode audit : Log les violations sans bloquer
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/audit-version: v1.30

    # Mode warn : Avertit l'utilisateur dans kubectl
    pod-security.kubernetes.io/warn: restricted
    pod-security.kubernetes.io/warn-version: v1.30

Pod conforme au niveau "Restricted" :

apiVersion: v1
kind: Pod
metadata:
  name: secure-app
  namespace: production
spec:
  # Exigences du niveau "Restricted"
  securityContext:
    # 1. Pas d'exécution en root
    runAsNonRoot: true
    runAsUser: 10001
    runAsGroup: 10001
    fsGroup: 10001

    # 2. Filesystem en lecture seule
    readOnlyRootFilesystem: true

    # 3. Capabilities minimales
    seccompProfile:
      type: RuntimeDefault

  containers:
  - name: app
    image: myapp:1.2.3
    securityContext:
      # Pas d'escalade de privilèges
      allowPrivilegeEscalation: false

      # Capabilities supprimées
      capabilities:
        drop:
        - ALL
        # Ajouter seulement les capabilities nécessaires
        add:
        - NET_BIND_SERVICE  # Bind ports < 1024

    # Filesystem en lecture seule → utiliser volumes pour écriture
    volumeMounts:
    - name: tmp
      mountPath: /tmp
    - name: cache
      mountPath: /app/cache

  volumes:
  - name: tmp
    emptyDir: {}
  - name: cache
    emptyDir: {}

Validation automatique :

# Tenter de créer un pod non conforme
kubectl apply -f insecure-pod.yaml
# Erreur : pods "insecure-pod" is forbidden: violates PodSecurity "restricted:v1.30":
# - allowPrivilegeEscalation != false
# - runAsNonRoot != true
# - seccompProfile is not set

# Vérifier conformité d'un pod
kubectl label --dry-run=server --overwrite ns production \
  pod-security.kubernetes.io/enforce=restricted

Impact en production : Depuis l'adoption de PSS en mode "restricted" chez Spotify, le nombre d'incidents de sécurité liés aux conteneurs a chuté de 89% (rapport DevSecOps 2025).

2. Secrets Encryption at Rest : Activation simplifiée

Kubernetes 1.30 simplifie drastiquement le chiffrement des Secrets dans etcd, rendant cette sécurité critique accessible à tous.

Configuration automatisée :

# /etc/kubernetes/encryption-config.yaml
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
- resources:
  - secrets
  - configmaps  # Nouveau dans 1.30 : support ConfigMaps
  providers:
  # Provider 1 : AES-GCM (recommandé, plus rapide que AES-CBC)
  - aescbc:
      keys:
      - name: key1
        # Clé de 32 bytes générée cryptographiquement
        secret: $(head -c 32 /dev/urandom | base64)

  # Provider 2 : KMS (Key Management Service)
  - kms:
      name: aws-kms-plugin
      endpoint: unix:///var/run/kmsplugin/socket.sock
      cachesize: 1000
      timeout: 3s

  # Fallback : identity (pas de chiffrement, pour migration)
  - identity: {}

Activation dans kube-apiserver :

# Modifier /etc/kubernetes/manifests/kube-apiserver.yaml
spec:
  containers:
  - command:
    - kube-apiserver
    - --encryption-provider-config=/etc/kubernetes/encryption-config.yaml
    # Nouveau flag K8s 1.30 : rotation automatique
    - --encryption-provider-config-automatic-reload=true

    volumeMounts:
    - name: encryption-config
      mountPath: /etc/kubernetes
      readOnly: true

  volumes:
  - name: encryption-config
    hostPath:
      path: /etc/kubernetes
      type: DirectoryOrCreate

Vérification du chiffrement :

# Créer un secret
kubectl create secret generic test-secret --from-literal=password=super-secret

# Vérifier dans etcd (AVANT chiffrement)
ETCDCTL_API=3 etcdctl get /registry/secrets/default/test-secret \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt
# Résultat : password=super-secret (visible en clair !)

# APRÈS activation du chiffrement et rechiffrement
ETCDCTL_API=3 etcdctl get /registry/secrets/default/test-secret \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt
# Résultat : données binaires chiffrées (incompréhensibles)

Rechiffrement des secrets existants :

# Rechiffrer TOUS les secrets du cluster
kubectl get secrets --all-namespaces -o json | \
  kubectl replace -f -

# Vérifier progression
kubectl get secrets --all-namespaces --field-selector metadata.managedFields[*].manager=kubectl-replace

3. ValidatingAdmissionPolicy : Contrôle avancé sans webhooks

Kubernetes 1.30 promeut ValidatingAdmissionPolicy en beta stable, offrant une alternative performante aux webhooks d'admission externes.

Policy de sécurité pour la production :

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: production-security-policy
spec:
  # S'applique aux pods
  matchConstraints:
    resourceRules:
    - apiGroups: [""]
      apiVersions: ["v1"]
      operations: ["CREATE", "UPDATE"]
      resources: ["pods"]

  # Validations avec CEL (Common Expression Language)
  validations:
  # Règle 1 : Pas d'exécution en root
  - expression: "object.spec.securityContext.runAsNonRoot == true"
    message: "Les pods doivent s'exécuter en tant que non-root (runAsNonRoot: true)"
    reason: Forbidden

  # Règle 2 : Images provenant uniquement de registries approuvés
  - expression: |
      object.spec.containers.all(c,
        c.image.startsWith('registry.company.com/') ||
        c.image.startsWith('ghcr.io/mycompany/')
      )
    message: "Images autorisées : registry.company.com/* ou ghcr.io/mycompany/*"
    reason: Forbidden

  # Règle 3 : Resources limits obligatoires
  - expression: |
      object.spec.containers.all(c,
        has(c.resources.limits.cpu) && has(c.resources.limits.memory)
      )
    message: "Tous les conteneurs doivent définir des CPU et memory limits"
    reason: Forbidden

  # Règle 4 : Pas de privilèges élevés
  - expression: |
      object.spec.containers.all(c,
        !has(c.securityContext.privileged) || c.securityContext.privileged == false
      )
    message: "Les conteneurs privileged sont interdits en production"
    reason: Forbidden

  # Règle 5 : Filesystem en lecture seule
  - expression: |
      object.spec.containers.all(c,
        has(c.securityContext.readOnlyRootFilesystem) &&
        c.securityContext.readOnlyRootFilesystem == true
      )
    message: "Le filesystem root doit être en lecture seule (readOnlyRootFilesystem: true)"
    reason: Forbidden

  # Règle 6 : Tags d'images obligatoires (pas de 'latest')
  - expression: |
      object.spec.containers.all(c,
        !c.image.endsWith(':latest') && !c.image.endsWith('@latest')
      )
    message: "Le tag ':latest' est interdit, utilisez des versions explicites"
    reason: Forbidden

Binding de la policy aux namespaces production :

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicyBinding
metadata:
  name: production-security-binding
spec:
  policyName: production-security-policy
  validationActions: ["Deny"]  # Bloque les créations non conformes

  # S'applique uniquement aux namespaces production
  matchResources:
    namespaceSelector:
      matchLabels:
        environment: production

Test de la policy :

# Pod non conforme (utilise :latest)
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: bad-pod
  namespace: production
spec:
  containers:
  - name: app
    image: nginx:latest  # ❌ Tag interdit
EOF

# Erreur attendue :
# Error from server (Forbidden): admission webhook "production-security-policy" denied the request:
# Le tag ':latest' est interdit, utilisez des versions explicites

Performances comparées :

Validation de 1000 pods :
├── Webhook externe : 850ms (appels réseau)
└── ValidatingAdmissionPolicy : 120ms (évaluation native)

Économie : 85% de latence en moins

Nouvelles fonctionnalités pour la production

1. Job Success/Completion Policy (Beta)

Kubernetes 1.30 introduit une gestion avancée des Jobs avec des politiques de succès granulaires.

Cas d'usage : Batch processing avec tolérance aux erreurs :

apiVersion: batch/v1
kind: Job
metadata:
  name: data-processing-batch
spec:
  # Nouveau dans K8s 1.30
  successPolicy:
    rules:
    # Règle 1 : Succès si 80% des pods réussissent
    - succeededIndexes: "0-79"  # 80 pods sur 100
      succeededCount: 80

  # Complétion basée sur index (pas de duplication)
  completionMode: Indexed
  completions: 100
  parallelism: 20

  template:
    spec:
      restartPolicy: Never
      containers:
      - name: processor
        image: mycompany/data-processor:2.1
        env:
        - name: JOB_INDEX
          valueFrom:
            fieldRef:
              fieldPath: metadata.annotations['batch.kubernetes.io/job-completion-index']
        command:
        - /bin/process-data
        - --index=$(JOB_INDEX)
        - --total=100

Résultat : Le Job est marqué comme succeeded même si 20% des pods échouent, évitant les retraitements inutiles pour les données déjà traitées.

2. ReadWriteOncePod Access Mode (GA)

Kubernetes 1.30 promeut en GA le mode d'accès ReadWriteOncePod pour les PersistentVolumeClaims, garantissant qu'un volume n'est monté que par un seul pod à la fois.

Cas d'usage : Bases de données stateful :

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: postgres-pvc
spec:
  # Nouveau : ReadWriteOncePod (GA dans K8s 1.30)
  accessModes:
  - ReadWriteOncePod  # Un seul pod peut monter ce volume
  resources:
    requests:
      storage: 100Gi
  storageClassName: fast-ssd
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: postgres
spec:
  serviceName: postgres
  replicas: 1
  selector:
    matchLabels:
      app: postgres
  template:
    metadata:
      labels:
        app: postgres
    spec:
      containers:
      - name: postgres
        image: postgres:16.1
        volumeMounts:
        - name: data
          mountPath: /var/lib/postgresql/data

  volumeClaimTemplates:
  - metadata:
      name: data
    spec:
      accessModes:
      - ReadWriteOncePod  # Protection contre multi-attach
      resources:
        requests:
          storage: 100Gi

Bénéfice : Prévient les corruptions de données causées par plusieurs pods écrivant simultanément sur le même volume.

3. CEL (Common Expression Language) généralisé

Kubernetes 1.30 étend l'utilisation de CEL à de nombreuses ressources, permettant des validations et transformations complexes sans code custom.

Validation de CRD avec CEL :

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: applications.company.com
spec:
  group: company.com
  names:
    kind: Application
    plural: applications
  scope: Namespaced
  versions:
  - name: v1
    schema:
      openAPIV3Schema:
        type: object
        properties:
          spec:
            type: object
            properties:
              replicas:
                type: integer
              environment:
                type: string
                enum: ["dev", "staging", "production"]
              resources:
                type: object
                properties:
                  cpu:
                    type: string
                  memory:
                    type: string

    # Validations CEL (nouveau K8s 1.30)
    validation:
      rules:
      # Règle 1 : En production, minimum 2 replicas
      - rule: "self.spec.environment != 'production' || self.spec.replicas >= 2"
        message: "Production applications must have at least 2 replicas for HA"

      # Règle 2 : CPU et memory obligatoires en production
      - rule: |
          self.spec.environment != 'production' ||
          (has(self.spec.resources.cpu) && has(self.spec.resources.memory))
        message: "Production applications must define CPU and memory resources"

      # Règle 3 : Validation du format CPU/memory
      - rule: |
          !has(self.spec.resources.cpu) ||
          self.spec.resources.cpu.matches('^[0-9]+m?$')
        message: "CPU format must be: 100m, 1, 2, etc."

Migration et upgrade vers Kubernetes 1.30

Stratégie d'upgrade sécurisée

Pré-requis critiques :

# 1. Vérifier version actuelle (doit être 1.29.x)
kubectl version --short
# Client: v1.29.3
# Server: v1.29.3

# 2. Vérifier composants dépréciés
kubectl get --raw /metrics | grep apiserver_requested_deprecated_apis
# Identifier les APIs dépréciées utilisées

# 3. Backup complet etcd
ETCDCTL_API=3 etcdctl snapshot save /backups/etcd-snapshot-$(date +%Y%m%d-%H%M%S).db \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key

# Vérifier le backup
ETCDCTL_API=3 etcdctl snapshot status /backups/etcd-snapshot-*.db --write-out=table

Plan d'upgrade production :

# Phase 1 : Upgrade control plane (nœud par nœud)
# Sur control-plane-1 :
sudo apt-mark unhold kubeadm
sudo apt-get update && sudo apt-get install -y kubeadm=1.30.0-00
sudo apt-mark hold kubeadm

# Vérifier plan d'upgrade
sudo kubeadm upgrade plan
# [upgrade/versions] Cluster version: v1.29.3
# [upgrade/versions] kubeadm version: v1.30.0
# ...

# Appliquer upgrade
sudo kubeadm upgrade apply v1.30.0 --yes

# Upgrade kubelet et kubectl
sudo apt-mark unhold kubelet kubectl
sudo apt-get install -y kubelet=1.30.0-00 kubectl=1.30.0-00
sudo apt-mark hold kubelet kubectl

sudo systemctl daemon-reload
sudo systemctl restart kubelet

# Phase 2 : Upgrade autres control plane nodes
# Sur control-plane-2, control-plane-3 :
sudo kubeadm upgrade node

# Phase 3 : Upgrade worker nodes (rolling upgrade)
kubectl drain worker-1 \
  --ignore-daemonsets \
  --delete-emptydir-data \
  --force \
  --grace-period=300

# Sur worker-1 :
sudo apt-get update && sudo apt-get install -y \
  kubeadm=1.30.0-00 kubelet=1.30.0-00 kubectl=1.30.0-00
sudo kubeadm upgrade node
sudo systemctl daemon-reload && sudo systemctl restart kubelet

# Retour en production
kubectl uncordon worker-1

# Répéter pour tous les workers

Temps estimés :

• Cluster 10 nœuds : 2-3 heures
• Cluster 50 nœuds : 6-8 heures
• Cluster 200+ nœuds : 12-24 heures (avec automation)

Conclusion : Kubernetes 1.30, la version production-ready de 2025

Kubernetes 1.30 "Uwubernetes" représente une étape décisive dans la maturation de l'écosystème Kubernetes, avec des fonctionnalités qui répondent aux besoins critiques des entreprises en production.

Les apports majeurs :

1. Sidecar Containers natifs : Solution élégante à un problème vieux de 4 ans, adoption massive dans les service mesh
2. Sécurité renforcée : Pod Security Standards en GA, chiffrement simplifié, admission policies sans webhooks
3. Production-readiness : Jobs avancés, volumes exclusifs, validations CEL

Adoption massive en 2025 : Avec 67% des entreprises déjà migrées vers Kubernetes 1.30 en novembre 2025, cette version s'impose comme le nouveau standard pour les infrastructures cloud-native.

Prochaines étapes recommandées :

1. Planifier l'upgrade vers 1.30 (Q4 2025 ou Q1 2026)
2. Adopter les sidecars natifs pour les service mesh (Istio, Linkerd)
3. Implémenter les Pod Security Standards en mode "restricted"
4. Activer le chiffrement des Secrets at rest
5. Former les équipes DevOps aux nouvelles fonctionnalités

Ressources essentielles :

• Documentation officielle : https://kubernetes.io/docs/
• Release notes K8s 1.30 : https://kubernetes.io/blog/2024/04/kubernetes-v1-30-release
• CNCF Slack : kubernetes.slack.com (#sig-release)
• Guide migration : https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/

Sources et références

• Kubernetes 1.30 Release Announcement - CNCF
• Native Sidecars in Kubernetes: A Deep Dive - Kubernetes Blog
• Kubernetes 1.30 : What DevOps Engineers Need to Know - Ippon Technologies
• Production-Ready Kubernetes: Security Best Practices 2025 - Blog du Modérateur
• Kubernetes Security Survey 2025 - CNCF