18 points par xguru 2025-11-13 | 4 commentaires | Partager sur WhatsApp
  • Outil d’exécution développé pour réduire le gaspillage de ressources des conteneurs inactifs dans un environnement Kubernetes
  • S’il n’y a aucune connexion TCP pendant une durée donnée, le conteneur est automatiquement checkpointé sur disque
  • Fonctionne sous la forme d’un containerd shim : il enregistre l’état mémoire du conteneur avant de l’arrêter, puis le restaure en quelques millisecondes lors de la première connexion suivante
  • Lors de la restauration, tout l’état de l’application est récupéré à l’identique, avec une latence presque imperceptible côté utilisateur
  • Utilise une redirection basée sur eBPF pour transmettre les paquets TCP à un proxy, puis repasse en connexion directe une fois la restauration terminée
  • Effectue les opérations de checkpoint et de restauration avec CRIU - Checkpoint and Restore in Userspace
  • Fournit, via une séquence d’activation (activation sequence), un flux de restauration automatique dès la première requête
  • Inclut une logique d’attente intelligente qui surveille l’activité TCP récente afin d’éviter des arrêts et restaurations trop fréquents
  • Sur Kubernetes, le conteneur est perçu comme s’il continuait à s’exécuter, ce qui évite les redémarrages du runtime
  • La commande kubectl exec déclenche une restauration automatique, permettant d’y accéder comme à un conteneur classique
  • Chaque processus shim collecte des métriques, et le zeropod-manager au niveau du nœud les agrège puis les expose via un endpoint HTTP
  • Propose une fonctionnalité d’in-place scaling qui ajuste dynamiquement les demandes de ressources si le cluster le prend en charge
  • Lors du drainage d’un nœud, il est possible de migrer vers un autre nœud des Pods déjà scaled down
  • Prend également en charge, à titre expérimental, la migration à chaud
  • Convient bien aux services à faible trafic, aux environnements de développement et de staging, aux offres low cost de type Heroku, ainsi qu’aux backends de sites statiques
  • La plupart des programmes fonctionnent sans modification particulière, et les logs de containerd permettent d’analyser les erreurs CRIU

4 commentaires

 
kayws426 2025-11-14

Une réinvention d'inetd ? (plaisanterie)

 
dongho42 2025-11-13

L’année dernière, j’avais vu l’Elastic Machine Pool de Platform 9 à l’AWS re:Invent, mais à l’époque c’était un peu lourd à tester rapidement puisqu’il était réservé au B2B. Celui-ci, en revanche, est simple à installer et son fonctionnement est intuitif, ce qui est appréciable. Je voulais allouer les ressources de façon agressive dans l’environnement de développement sans dégrader l’expérience utilisateur ; si le PoC est concluant, cela semble valoir le coup de l’adopter.

 
laeyoung 2025-11-13

Je me demandais en quoi cela différait de KNative, et il semble que les deux phrases ci-dessous en soient l’essentiel.

  • fonctionne sous la forme d’un shim containerd, enregistre l’état mémoire du conteneur puis l’arrête, avant de le restaurer en quelques millisecondes lors de la première connexion suivante
  • lors de la restauration, tout l’état de l’application est récupéré tel quel, si bien que du point de vue de l’utilisateur il n’y a presque aucune latence
 
vb6ko 2025-11-13

lambda. . .. ?