Sidecar Container on Zwindler's Reflection

Kubernetes 1.34 - Pod-level resources - simplifier la gestion des ressources quand on a plein de containers

Thu, 13 Nov 2025 06:00:00 +0200

Introduction

Aujourd’hui, je vais vous parler d’une nouvelle fonctionnalité de Kubernetes 1.34 qui est passée en béta : les Pod-level resources.

Et pour illustrer cette nouvelle fonctionnalité, je vais prendre l’exemple d’un pod pour lequel je souhaite avoir la QoS Guaranteed.

Pendant un temps, j’étais persuadé (mais alors je sais pas pourquoi… parce que la doc est claire 🤔) que pour avoir la QoS Guaranteed, il fallait que tous les containers du pod aient limits=requests, mais les mêmes pour tous les containers (ce qui est faux). Et c’est super pénible parce que des fois on a une grosse app principale et un tout petit sidecar et ça n’a pas de sens de leur mettre les mêmes valeurs.

Si on relit la doc, ce qui compte pour la QoS Guaranteed (doc officielle), c’est que :

Chaque container doit avoir cpu.limit = cpu.request
Chaque container doit avoir memory.limit = memory.request

Mais les valeurs peuvent être différentes entre les containers !

Pour s’en convaincre, il suffit de tester ce manifest :

apiVersion: v1
kind: Pod
metadata:
 name: ctrlevel-demo1
 namespace: pod-resources-example
spec:
 containers:
 - name: ctrlevel-demo1-ctr-1
 image: nginx
 resources:
 limits:
 cpu: "0.8"
 memory: "100Mi"
 requests:
 cpu: "0.8"
 memory: "100Mi"
 - name: ctrlevel-demo1-ctr-2
 image: fedora
 resources:
 limits:
 cpu: "0.2"
 memory: "200Mi"
 requests:
 cpu: "0.2"
 memory: "200Mi"
 command:
 - sleep
 - inf

Et devinez quoi ? QoS Class: Guaranteed.

Le premier container a 0.8 CPU / 100Mi, le second a 0.2 CPU / 200Mi, et ça ne pose aucun problème tant que chaque container respecte individuellement limit=request pour cpu et ram.

Bon. Maintenant que j’ai admis mon erreur publiquement (shame shame shame), on va quand même parler de Pod-level resources, parce que cette fonctionnalité reste utile.

Alors, à quoi ça sert, les Pod-level resources ?

Dans certains cas, il arrive que les containers (init, sidecar, …) soient très peu consommateurs. Certains sont aussi injectés à la volée (service mesh, auto instrumentation) de manière généralisée. Spécifier explicitement des limits / requests pour ces “petits” containers annexes peut être pénible, chronophage, difficile à tuner s’il y en a beaucoup…

Exemple typique : on injecte un sidecar qui expose juste des métriques Prometheus. Il consomme 10m de CPU et 20Mi de RAM. Vous pourriez écrire :

containers:
- name: mon-app
 resources:
 limits:
 cpu: "1"
 memory: "100Mi"
 requests:
 cpu: "1"
 memory: "100Mi"
- name: metrics-exporter
 resources:
 limits:
 cpu: "10m"
 memory: "20Mi"
 requests:
 cpu: "10m"
 memory: "20Mi"

Mais franchement, c’est chi**t. Et si demain l’exporter a besoin d’un poil plus de mémoire dans certains cas mais pas tous, il faut modifier le manifest pour l’augmenter partout, ou alors gérer l’exception…

Avec Pod-level resources, vous pouvez faire :

#fichier podlevel-demo1.yaml
apiVersion: v1
kind: Pod
metadata:
 name: podlevel-demo1
 namespace: pod-resources-example
spec:
 resources:
 limits:
 cpu: "1"
 memory: 100Mi
 requests:
 cpu: "1"
 memory: 100Mi
 initContainers:
 - name: sidecar-test
 image: busybox:latest
 command: ["sh", "-c", "while true; do sleep 3600; done"]
 restartPolicy: Always
 containers:
 - name: podlevel-demo1-ctr
 image: vish/stress
 args:
 - -cpus
 - "2"

Ici :

Les resources sont déclarées au niveau du spec du Pod
Les containers eux-mêmes n’ont PAS de déclaration de ressources
Le sidecar (déclaré en tant qu’initContainer avec restartPolicy: Always, cf. mon article précédent sur les sidecars) se partage les ressources du Pod avec le container.

Dans cet exemple, c’est un container et un sidecar, mais ça aurait très bien pu être n’importe quel autre mix de containers, d’init containers classiques et de sidecars.

Testons ça !

kubectl create namespace pod-resources-example
kubectl apply -f podlevel-demo1.yaml

Maintenant, vérifions que nous avons bien obtenu la QoS Guaranteed avec ce oneliner des enfers 😈 :

kubectl get pod podlevel-demo1 -n pod-resources-example -o jsonpath=$'Pod-level resources:\n Requests: {.spec.resources.requests}\n Limits: {.spec.resources.limits}\n\nContainer podlevel-demo1-ctr:\n Requests: {.spec.containers[0].resources.requests}\n Limits: {.spec.containers[0].resources.limits}\n\nSidecar sidecar-test:\n Requests: {.spec.initContainers[0].resources.requests}\n Limits: {.spec.initContainers[0].resources.limits}\n\nQoS Class: {.status.qosClass}\n'

Résultat :

Pod-level resources:
Requests: {"cpu":"1","memory":"100Mi"}
Limits: {"cpu":"1","memory":"100Mi"}
Container podlevel-demo1-ctr:
Requests:
Limits:
Sidecar sidecar-test:
Requests:
Limits:
QoS Class: Guaranteed

Les containers individuels n’ont PAS de ressources déclarées, mais le Pod dans son ensemble a des ressources. Et on obtient quand même la QoS Guaranteed !

Tout fonctionne comme prévu.

On peut aussi mixer pod level et container level

Au-delà de cet exemple, sachez qu’il est possible de mixer du container level (classique) avec du pod level.

Voici un exemple inspiré par la doc officielle :

#fichier podlevel-demo2.yaml
apiVersion: v1
kind: Pod
metadata:
 name: podlevel-demo2
 namespace: pod-resources-example
spec:
 resources:
 limits:
 cpu: "1"
 memory: "200Mi"
 requests:
 cpu: "1"
 memory: "200Mi"
 containers:
 - name: podlevel-demo2-ctr-1
 image: nginx
 resources:
 limits:
 cpu: "0.5"
 memory: "100Mi"
 requests:
 cpu: "0.5"
 memory: "100Mi"
 - name: podlevel-demo2-ctr-2
 image: fedora
 command:
 - sleep
 - inf

Ici, le container podlevel-demo2-ctr-1 spécifie ses ressources, mais on spécifie aussi des ressources pour tout le pod, et pas du tout dans podlevel-demo2-ctr-2.

Pour info, l’exemple de ce pod est aussi Guaranteed, malgré l’absence de limits/requests sur podlevel-demo2-ctr-2

kubectl get pod podlevel-demo2 -n pod-resources-example -o jsonpath=$'Pod-level resources:\n Requests: {.spec.resources.requests}\n Limits: {.spec.resources.limits}\n\nContainer podlevel-demo2-ctr-1:\n Requests: {.spec.containers[0].resources.requests}\n Limits: {.spec.containers[0].resources.limits}\n\nContainer podlevel-demo2-ctr-2:\n Requests: {.spec.containers[1].resources.requests}\n Limits: {.spec.containers[1].resources.limits}\n\nQoS Class: {.status.qosClass}\n'

Résultat :

Pod-level resources:
Requests: {"cpu":"1","memory":"200Mi"}
Limits: {"cpu":"1","memory":"200Mi"}
Container podlevel-demo2-ctr-1:
Requests: {"cpu":"500m","memory":"100Mi"}
Limits: {"cpu":"500m","memory":"100Mi"}
Container podlevel-demo2-ctr-2:
Requests:
Limits:
QoS Class: Guaranteed

Conclusion

Les Pod-level resources sont une fonctionnalité qui simplifie la vie dans certains cas d’usage, notamment quand on utilise des sidecars légers ou des containers injectés à la volée.

Est-ce révolutionnaire ? Non. Est-ce que ça va changer votre vie ? Probablement pas. Mais ça peut toujours servir.

On en apprend tous les jours. Même (surtout ?) quand on se plante. 😌

Références

Kubernetes 1.29 - sidecar container - à quoi ça peut bien servir ?

Fri, 19 Jul 2024 12:00:00 +0200

Introduction

J’ai un copain qui doit lancer un traitement périodique. Ce traitement est réalisé par un bout de code qui tourne dans un container (sur un cluster GKE), et qui a besoin de requêter une base de donnée Cloud SQL.

Pour ce genre de choses, Google Cloud fourni une image à mettre à côté de son application (sidecar pattern) qui sert de passe plat (proxy) pour que l’application se connecte à l’instance Cloud SQL chez Google cloud.

cloud.google.com/sql/docs/mysql/connect-kubernetes-engine?hl=fr

Pas de bol, il se trouve que cette image met parfois un peu de temps à démarrer, et son absence fait crasher l’application de mon ami. On se retrouve avec une race condition et il m’a demandé si j’avais des idées de solutions pour régler ce problème.

Parmis d’autres propositions (que je détaille dans le tout dernier paragraphe), je lui propose d’essayer une toute nouvelle fonctionnalité qui est en béta dans Kubernetes 1.29 que je n’avais pas encore testé moi même : les sidecar containers !

kubernetes.io/docs/concepts/workloads/pods/sidecar-containers/

Fun fact: en cherchant de la documentation sur cloud sql sidecar, je suis tombé sur cet article d’une personne qui a exactement le même problème que mon ami.

hwchiu.medium.com/exploring-kubernetes-1-28-sidecar-container-support-ed1a39ac7fe0

Une fois n’est pas coutume, pour que vous puissiez bien comprendre le problème et sa résolution, je vous propose de faire cette découverte de feature avec une démo.

La totalité du code et les instructions pour le refaire en anglais sont disponibles sur le dépôt github github.com/zwindler/sidecar-container-example.

L’idée est la suivante : on va simuler le problème de mon poto avec deux images Docker créées pour l’occasion :

zwindler/slow-sidecar un helloworld basique en V lang (vhelloworld) qui fait un sleep de 5 secondes avant d’écouter le port 8081.
zwindler/sidecar-user un script bash qui curl et exit 1 si le curl échoue.

Prérequis

Comme dit précédemment, la fonctionnalité a été introduite dans Kubernetes 1.28 en tant que fonctionnalité alpha. Si vous utilisez cette version et souhaitez la tester, vous devez activer spécifiquement le flag de fonctionnalité.

À partir de Kubernetes 1.29, cette fonctionnalité est passée en bêta et devrait être activée par défaut sur votre cluster.

Sans conteneurs sidecar

D’abord, on va essayer de déployer le CronJob de manière naïve sur un cluster :

$ cat 1-cronjob-without-sidecar-container.yaml
apiVersion: batch/v1
kind: CronJob
metadata:
 name: sidecar-cronjob
spec:
 schedule: "* * * * *"
 jobTemplate:
 spec:
 template:
 spec:
 containers:
 - name: sidecar-user
 image: zwindler/sidecar-user
 - name: slow-sidecar
 image: zwindler/slow-sidecar
 ports:
 - containerPort: 8081
 restartPolicy: Never

$ kubectl apply -f 1-cronjob-without-sidecar-container.yaml

Cela devrait échouer car le conteneur “slow sidecar” ne sera pas prêt lorsque le conteneur “sidecar user” essaiera de faire un curl.

$ kubectl get pods
NAME READY STATUS RESTARTS AGE
sidecar-cronjob-28689938-5n5x9 1/2 Error 0 9s

$ kubectl describe pods sidecar-cronjob-28689938-5n5x9
[...]
Containers:
 slow-sidecar:
[...]
 State: Running
 Started: Fri, 19 Jul 2024 15:38:03 +0200
 Ready: True
[...]
 sidecar-user:
[...]
 State: Terminated
 Reason: Error
 Exit Code: 1
 Started: Fri, 19 Jul 2024 15:38:05 +0200
 Finished: Fri, 19 Jul 2024 15:38:05 +0200
 Ready: False
 Restart Count: 0
[...]

slow-sidecar fonctionne bien mais notre requête sidecar-user a échoué car le sidecar était trop lent à démarrer.

Petit nettoyage avant de recommencer :

kubectl delete cronjob sidecar-cronjob

Utiliser un conteneur init n’est pas une option non plus car le conteneur init ne se terminera jamais (ce n’est pas son but) et le conteneur “sidecar user” attendra éternellement son tour. Si vous voulez essayer, convertissez simplement slow-sidecar en initContainer.

apiVersion: batch/v1
kind: CronJob
metadata:
 name: sidecar-cronjob
spec:
 schedule: "* * * * *"
 jobTemplate:
 spec:
 template:
 spec:
 containers:
 - name: sidecar-user
 image: zwindler/sidecar-user
+ initContainers:
 - name: slow-sidecar
 image: zwindler/slow-sidecar
 ports:
 - containerPort: 8081
 restartPolicy: Never

Et lancez-le

$ kubectl apply -f 2-cronjob-with-init-container.yaml

$ kubectl get pods
NAME READY STATUS RESTARTS AGE
sidecar-cronjob-28689955-lzbnf 0/1 Init:0/1 0 27s

Et on reste boqué à cette étape jusqu’à la fin de teeeeeeemps.

Avec des conteneurs sidecar

Pour éviter ce type de race condition, mettons à jour le manifest en convertissant slow-sidecar en initContainer MAIS EN AJOUTANT également restartPolicy: Always dans la déclaration du container slow-sidecar.

Cette bidouille est la manière de dire à Kubernetes de lancer ce conteneur en tant qu’initContainer mais de ne PAS attendre qu’il se termine (ce qu’il ne fera jamais puisqu’il s’agit d’un serveur web écoutant sur 8081 jusqu’à la fin des temps) pour démarrer l’application principale.

apiVersion: batch/v1
kind: CronJob
metadata:
 name: sidecar-cronjob
spec:
 schedule: "* * * * *"
 jobTemplate:
 spec:
 template:
 spec:
 containers:
 - name: sidecar-user
 image: zwindler/sidecar-user
+ initContainers:
 - name: slow-sidecar
 image: zwindler/slow-sidecar
+ restartPolicy: Always
 ports:
 - containerPort: 8081
 restartPolicy: Never

Note: C’est la manière officielle de déclarer un conteneur sidecar dans Kubernetes. Je n’ai pas encore lu le KEP donc je ne peux pas dire pourquoi l’équipe de développement n’a pas introduit un nouveau mot-clé sidecarContainers dans le schéma de spécification du Pod et a réutilisé les initContainers déjà existants.

$ kubectl apply -f 3-cronjob-with-sidecar-container.yaml

Cette fois, le conteneur init devrait se lancer et ENSUITE seulement, l’application :

$ kubectl get pods -w
NAME READY STATUS RESTARTS AGE
sidecar-cronjob-28689958-zrmhh 0/2 Pending 0 0s
sidecar-cronjob-28689958-zrmhh 0/2 Pending 0 0s
sidecar-cronjob-28689958-zrmhh 0/2 Init:0/1 0 0s
sidecar-cronjob-28689958-zrmhh 1/2 PodInitializing 0 2s
sidecar-cronjob-28689958-zrmhh 1/2 Error 0 3s

On voit que c’est mieux (sidecar-user démarre dans un second temps) mais dans cet exemple particulier, ça échoue encore…

Avec des conteneurs sidecar ET une startupProbe

Par défaut, le kubelet considère que le conteneur sidecar est up dès que le processus dans le conteneur est en cours d’exécution, puis si les autres initContainers ont tous terminé (ou s’il n’y en a pas), passe à la phase principale de démarrage des containers.

Malheureusement, dans notre cas, le conteneur sidecar est très lent (sleep 5), donc le fait que le processus soit en cours d’exécution n’est pas une indication de l’état du sidecar…

Nous devons ajouter une startupProbe pour que Kubernetes sache QUAND passer la phase d’init et démarrer la phase principale.

After a sidecar-style init container is running (the kubelet has set the started status for that init container to true), the kubelet then starts the next init container from the ordered .spec.initContainers list. That status either becomes true because there is a process running in the container and no startup probe defined, or as a result of its startupProbe succeeding.

apiVersion: batch/v1
kind: CronJob
metadata:
 name: sidecar-cronjob
spec:
 schedule: "* * * * *"
 jobTemplate:
 spec:
 template:
 spec:
 containers:
 - name: sidecar-user
 image: zwindler/sidecar-user
 initContainers:
 - name: slow-sidecar
 image: zwindler/slow-sidecar
 restartPolicy: Always
 ports:
 - containerPort: 8081
+ startupProbe:
+ httpGet:
+ path: /
+ port: 8081
+ initialDelaySeconds: 5
+ periodSeconds: 1
+ failureThreshold: 5
 restartPolicy: Never

Une dernière fois :

$ kubectl apply -f 4-cronjob-with-sidecar-container-and-startup-probe.yaml && kubectl get pods -w
cronjob.batch/sidecar-cronjob created
NAME READY STATUS RESTARTS AGE
sidecar-cronjob-28689977-lt77c 0/2 Pending 0 0s
sidecar-cronjob-28689977-lt77c 0/2 Pending 0 0s
sidecar-cronjob-28689977-lt77c 0/2 Init:0/1 0 0s
sidecar-cronjob-28689977-lt77c 0/2 Init:0/1 0 1s
sidecar-cronjob-28689977-lt77c 0/2 PodInitializing 0 6s
sidecar-cronjob-28689977-lt77c 1/2 PodInitializing 0 6s
sidecar-cronjob-28689977-lt77c 1/2 Completed 0 7s

Hooray!

Bonus : si vous n’avez pas sidecarContainers activé

Si vous êtes toujours en Kubernetes 1.28 (ou pire) et que vous n’avez pas la possibilité d’activer les alpha featureFlags, il va falloir trouver une autre méthode.

Malheureusement, il est probable que la solution soit de modifier le code de votre application principale ou son image Docker. Vous pouvez :

ajouter une politique de retry dans l’application sidecar-user
ajouter un script dans l’application sidecar-user qui attend un peu (sleep) avant d’essayer de contacter le sidecar

La première est une bonne pratique lorsqu’on traite avec des microservices et vous devriez l’envisager de toute façon pour gérer les problèmes temporaires de connexion à la base de données.

La deuxième est une rustine sur une jambe de bois. Je le déconseille fortement car la vitesse de démarrage peut varier dans le sidecar et ajouter trop de délai dans l’application est également mauvais lorsqu’on doit gérer des incidents et des bugs en prod (induisant potentiellement d’autres problèmes).