Mutations automatiques et politiques

Kontainers applique automatiquement certaines modifications (mutations) et certains contrôles (politiques) sur vos workloads au moment de leur création. Si vous avez l’habitude d’un cluster Kubernetes « vanilla », cette page est celle à lire en premier : elle recense tout ce qui se passe sans que vous l’ayez demandé.

Vue d’ensemble

Comportement	Effet
`imagePullPolicy` forcé à `Always`	L’image est re-vérifiée auprès du registre à chaque démarrage de pod
Requests injectées si absentes	`cpu: 100m`, `memory: 200Mi`, `ephemeral-storage: 1Gi`
`limits.memory` alignée sur `requests.memory`	Toujours, même si vous déclarez une valeur différente
Limite de stockage éphémère	2 Gi par conteneur si non déclarée
Aucune limite CPU	Jamais injectée, jamais imposée
Pod Security `baseline`	Pods privilégiés, hostPath, hostNetwork… rejetés
Tolerations control-plane	Pods rejetés à l’admission

Avant / après : un exemple réel

Voici ce que devient un Deployment déclaré sans aucune section resources :

# Ce que vous soumettez
containers:
  - name: web
    image: nginx:alpine

# Ce qui tourne réellement (observé sur le cluster)
containers:
  - name: web
    image: nginx:alpine
    imagePullPolicy: Always
    resources:
      requests:
        cpu: 100m
        memory: 200Mi
        ephemeral-storage: 1Gi
      limits:
        memory: 200Mi
        ephemeral-storage: 2Gi

Et si vous déclarez une limite mémoire différente de la request, elle est ramenée à la valeur de la request :

# Vous déclarez :          requests.memory: 300Mi / limits.memory: 500Mi
# La plateforme applique : requests.memory: 300Mi / limits.memory: 300Mi

Conséquences opérationnelles

`imagePullPolicy: Always`

Un tag mutable (latest, main…) est re-téléchargé à chaque redémarrage : vos pods suivent le registre, ce qui peut être voulu… ou pas.
Si votre registre est indisponible ou votre token de pull expiré, vos pods ne peuvent plus redémarrer — même si l’image est déjà présente sur le nœud. Pensez-y avant une opération de maintenance sur votre registre, et surveillez l’expiration de vos pull secrets.

`limits.memory = requests.memory`

Il n’y a pas d’overcommit mémoire : ce que vous réservez est ce que vous pouvez consommer. Dès que votre conteneur dépasse sa request, il est OOMKilled.
Le réflexe vanilla « j’augmente la limit » ne fonctionne pas ici : il faut augmenter la request (et c’est elle qui est facturée).
Dimensionnez la request mémoire sur votre pic réel de consommation, observable dans le monitoring.

Requests injectées

Même un pod déclaré « sans ressources » réserve 0,1 vCPU et 200 Mi — et cette réservation est facturée. Déclarer vos resources explicitement, c’est piloter votre facture.

CPU sans limite

Vos conteneurs peuvent burster au-delà de leur request CPU sans throttling.
En cas de contention sur un nœud, le partage se fait au prorata des requests : une request CPU réaliste vous garantit votre part.

Politiques de rejet

Certaines créations sont refusées à l’admission. Les messages d’erreur ci-dessous sont ceux que vous verrez réellement.

Pods privilégiés (Pod Security `baseline`)

privileged: true, hostPath, hostNetwork, hostPID, hostIPC sont rejetés. Si un chart Helm public échoue au déploiement, c’est une cause fréquente.

Tolerations control-plane

admission webhook "validate.kyverno.svc-fail" denied the request:
restrict-controlplane-scheduling: 'validation error: Pods may not
use tolerations which schedule on control plane nodes.'

Retirez la toleration node-role.kubernetes.io/control-plane de votre manifest.