Une semaine de fonctionnement, adaptée à votre équipe
Prenez un environnement de recette utilisé du lundi au vendredi, de 8 h à 19 h, dans le fuseau Europe/Paris. Définissez ces plages comme heures d’activité : en dehors, la règle prévoit l’arrêt des cibles compatibles, week-end compris. Cet exemple illustre un calendrier, pas un résultat financier garanti.
Une livraison jeudi soir ? Ajoutez une exception qui maintient l’environnement allumé. Un test imprévu samedi ? Demandez un réveil temporaire. À son échéance, le calendrier reprend. Une reprise peut prendre du temps selon le fournisseur et la ressource : prévoyez vos plages en tenant compte du démarrage de l’application.
Vérifiez ce qui se passerait avant d’autoriser les actions
Une nouvelle règle commence en simulation. Onicost affiche les ressources retenues, celles qui sont exclues et pourquoi, les prochaines actions et le potentiel mensuel estimé lorsqu’il est chiffrable. Les ressources restent dans leur état actuel pendant cette simulation.
Vérifiez le périmètre, les plages d’activité et le fuseau horaire avec les responsables du service. Activez ensuite la règle explicitement. Le journal permet de consulter les actions et leurs résultats, y compris un refus de permissions ou une erreur du fournisseur.
Des permissions dédiées pour agir, distinctes de la collecte
La collecte utilise la lecture seule par défaut. Le Scheduler nécessite des droits dédiés, une activation explicite et un journal. Pour Kubernetes, activez le mode actions de l’agent avec ses permissions propres. Pour le cloud, configurez une identité d’écriture séparée des identifiants servant à lire les coûts et l’inventaire.
Les propriétaires et administrateurs créent, modifient et activent les règles. Les membres, y compris les viewers, peuvent demander un réveil temporaire dans les limites prévues ; sa durée maximale est de 72 heures. Un réveil permet de travailler hors horaires sans modifier durablement la semaine de fonctionnement.
Kubernetes : des workloads ciblés, avec leurs contraintes
Une règle Kubernetes sélectionne des namespaces et des labels pour cibler des Deployments, StatefulSets et CronJobs. Les namespaces exclus et les ressources marquées pour être ignorées restent hors périmètre. Vérifiez les cibles en simulation avant de couvrir tout un environnement.
Les contrôleurs d’autoscaling et GitOps peuvent modifier l’état attendu. Un HPA peut imposer une réplique minimale ; une réconciliation Argo CD peut remettre un workload en service. Examinez les avertissements et le journal, puis testez les dépendances de l’application, en particulier les composants avec état.
Arrêter ces workloads ne signifie pas arrêter les nœuds. Pour diminuer la capacité cloud facturée, une action adaptée sur un pool compatible peut aussi être nécessaire. Les volumes et certaines charges restent présents pendant l’arrêt.
Cloud : vérifiez le service et le type de ressource
La prise en charge d’un fournisseur ne rend pas tous ses services arrêtables. Le Scheduler agit sur des cibles compatibles de l’inventaire, avec les permissions requises. Les nœuds Kubernetes connus se pilotent par leur pool, pas comme des VM indépendantes.
- AWS : instances EC2 compatibles, node groups EKS gérés, instances RDS et clusters Aurora compatibles. AWS peut relancer une base après sept jours d’arrêt ; le Scheduler peut la réarrêter si le calendrier demande encore l’arrêt. Les instances RDS ayant une réplique de lecture ou servant de réplique ne peuvent pas être arrêtées ; des restrictions supplémentaires s’appliquent selon le moteur et le déploiement.
- Azure : VM, pools AKS et serveurs flexibles PostgreSQL/MySQL compatibles. Un pool système AKS garde au moins un nœud. Azure SQL ne fait pas partie des bases arrêtables.
- Google Cloud : instances Compute Engine, pools GKE et instances Cloud SQL compatibles. Les limites du service et de son autoscaling restent applicables.
- Scaleway : Instances et pools Kapsule compatibles. Les bases managées Scaleway ne sont pas arrêtées par le Scheduler.
Lisez le potentiel estimé sans le confondre avec la facture
Une estimation de planification rapproche le coût disponible des heures prévues à l’arrêt. Elle aide à comparer les règles avant activation. Elle ne garantit pas un montant économisé et ne remplace pas vos factures. Une estimation absente ne signifie pas qu’une ressource est gratuite.
Disques, adresses IP, stockage, frais fixes ou engagements peuvent continuer pendant l’arrêt du calcul. Des pods arrêtés sur un nœud encore facturé ne font pas disparaître son coût. Regardez les lignes concernées et la capacité effectivement retirée.
Après activation, comparez les coûts observés et le contexte : activité, prix et infrastructure peuvent avoir changé en même temps. Une différence avant/après ne prouve pas qu’Onicost en est l’unique cause.
Team, 100 règles et un déploiement progressif
Le Scheduler Bêta est inclus dans Team. Chaque organisation peut avoir 100 règles au total, en comptant les règles en simulation et en pause. Commencez avec un environnement non critique et vérifiez le cycle arrêt/reprise avant d’élargir le périmètre.
La Bêta ne comporte ni remise ni SLA spécifique et ne garantit pas de reprise instantanée ou de disponibilité. Prévoyez les dépendances et les délais du fournisseur. L’essai Team dure 14 jours sans carte bancaire, avec ses propres plafonds : 50 clusters, 10 membres, 5 000 cœurs et 5 comptes cloud.
Questions fréquentes
Le Scheduler applique-t-il les recommandations de dimensionnement ?
Non. Les recommandations donnent des pistes que votre équipe choisit et applique. Le Scheduler exécute les arrêts et reprises prévus par les règles que vous simulez puis activez.
Un viewer peut-il rallumer un environnement ?
Oui, les membres, y compris les viewers, peuvent demander un réveil temporaire dans les limites prévues. Les propriétaires et administrateurs gèrent les règles. Un réveil est limité à 72 heures.
L’arrêt coupe-t-il toutes les dépenses ?
Non. Des disques, IP, charges de stockage ou engagements peuvent rester facturés. L’arrêt de pods ne retire pas nécessairement les nœuds. Le potentiel affiché est une estimation, pas un résultat acquis.
Puis-je tester une règle sans arrêter les ressources ?
Oui. Une nouvelle règle est en simulation : vous vérifiez son périmètre et son calendrier avant de l’activer explicitement.