Remplacement du CronJob Scheduler Kubernetes

Si vous utilisez le CronJob Scheduler pour gérer les taches et jobs dans vos conteneurs Docker ou d’autres applications conteneurisées, vous comprendrez facilement que cela reste complexe, limité et peu flexible. Gestion des codes erreurs, des logs, time zones, récurrence, etc. sont quelques-unes des limites connues.

Problématiques récurrentes

Kubernetes reconnaît que "les CronJobs peuvent présenter des limitations et des incertitudes". Plus précisément, comme l’ont expérimenté les informaticiens de Lyft qui utilisent CronJobs pour remplacer le Cron Unix, les jobs peuvent connaitre des retards de démarrages importants, car les tâches nécessitent que plusieurs événements se produisent avant que toute application ne commence à s’exécuter. Ces événements combinés aux attentes et besoins d’un CronJob Scheduler peuvent entrainer des retards importants et imprévisibles avec pour conséquences que les CronJobs ne sont pas exécutés.

Par exemple, au départ, CronJobcontroller traite et décide de lancer le Cronjob. Dans un événement qui suit, CronJobcontroller crée un job à partir des spécifications du job du CronJob. Ensuite, jobcontroller notifie le nouveau job et crée un Pod. Les contrôleurs d’admission Kubernetes injectent des spécifications du Container Sidecar dans les spécifications du POD. Le Kube-scheduler planifie le Pod sur un kubelet. Le Kubelet exécute le Pod (en ayant extrait toutes les images des containers), démarre tous les containers Sidecar et le container de l’application.

Dès qu’un certain nombre de Cronjobs sont lancés, la latence à tendance à croître. Dans Kubernetes 1.18, le Cronjobcontroller se contente de contrôler les cronjobs toutes les 10 secondes et de manière synchrone en appelant l’API de multiples fois par cronjob. Lorsque le nombre de Cronjobs atteint un certain niveau, ces appels API commencent à être limités en termes de débit, selon Kevin Yang, auteur du rapport de Lyft.

Les pics d’activités peuvent se produire à des moments de forte demande pour les tâches de l’ordonnanceur Kubernetes – à chaque demande en minutes, au début de chaque heure lorsque de nombreux crons doivent être invoqués simultanément. Pourquoi ces problèmes sont importants ? Parce qu’ils sont susceptibles de provoquer l’échec de l’appel des Cronjobs et au final leur non-exécution.

Les administrateurs ont également identifié un certain nombre de problèmes liés au suivi des tâches et des conteneurs en erreur, notamment des « problèmes techniques de longue date dans Kubernetes » qui nécessitent une intervention manuelle pour y remédier.

Mon cron fonctionne-t-il ?

Des actions et commandes manuelles sont possibles pour obtenir des informations sur le status des programmes Cron. La documentation Kubernetes donne des indications sur la manière de savoir si un Cron est en cours d’exécution. Cependant, Jack Wallen, chroniqueur pour Tech Republic, donne une explication plus précise dans un article sur l’utilisation des CronJobs pour la planification dans Kubernetes.

Il explique comment, après avoir déployé un cluster Kubernetes et crée un fichier YAML pour la tâche, vous pouvez utiliser une série de commandes pour déployer la commande qui inclut la tâche planifiée, vous assurer que la tâche est en cours d’exécution, et la surveiller en obtenant une liste de chaque tâche déployée.

Mon cron s'est-il bien exécuté ?

Certains utilisateurs réorganisent leur implémentation en prenant un certain nombre de mesures, notemment en corrigeant les bugs sous-jacents de Kubernetes et en outillant sa plateforme avec des métriques et des alertes intégrées.

Ces outils comprennent une série de compteurs qui renvoient les éléments suivants :

• L’application s’est-elle bien exécutée
• Le Cron s’est-il exécuté avec succès
• Pourquoi mon Cron ne fonctionne pas

Vous pouvez créé vos propres compteurs pour mesurer le délai de démarrage et le temps nécessaire à l’exécution du code

Mais voulez-vous vraiment développer et maintenir tous ces programmes spécifiques ?

Il existe des solutions pour exploiter Kubernetes sans avoir à créer sa propre automatisation. Quelle est l’alternative à Cronjobscheduler ?

Les ordonnanceurs restent très performants y compris pour se substituer au planificateur natif de Kubernetes, sachant qu’ils ont évolué vers des plateformes d’automatisation très complètes comme OpCon. La plateforme OpCon permet de gérer les événements, planifier tous les processus avec un niveau de granularité très fin. La gestion de ressources est très utile pour éviter les problèmes de surcharge lié à la parallélisation des jobs tels que constaté avec Cronjobcontroller.

En tant que manager IT, vous vous demandez si il est vraiment possible de gérer tout type d’automatisation depuis une unique plateforme, disponible 24/7 et sécurisée pour l’ensemble de vos processus d’infrastructure et applications. La plateforme OpCon le permet car elle a été architecturée pour cela. Planifier, ordonnancer, automatiser, orchestrer, industrialiser, superviser, alerter et bien plus encore à partir d’une seule interface graphique est possible avec la solution OpCon, qui est maintenant aussi disponible sur Docker.

Les problèmes d’ordonnancement de Kubernetes CronJob semblent être une nouveauté, mais c’est en fait une problématique récurrente sur toute nouvelle infrastructure. SMA Technologies avec OpCon aide votre organisation à contourner les limites des outils d’ordonnancement natifs de Kubernetes et économiser beaucoup de temps et de ressources.