Le faire tourner était la partie facile. Le garder en marche, c'est le job.
Le day-two, c'est là où Kubernetes mange les équipes en silence : mises à niveau qui cassent quelque chose de non documenté, perte de nœud avec un runbook périmé, et config qu'une seule personne peut expliquer. Zeus rend les mises à niveau, le scale et le démantèlement opérables depuis la même console que le provisionnement.
Le savoir tribal n'est pas une stratégie DR.
La personne qui a monté le cluster le comprend. Tout le monde d'autre devine. La config dérive de ce qu'elle est censée être. Les mises à niveau sont reportées parce que plus personne n'est confiant de ne rien casser. Le node group qui fait tourner le service payments a un taint que plus personne ne se souvient d'avoir ajouté.
Zeus ne rend pas Kubernetes plus simple — il rend la complexité compréhensible et les opérations répétables. Provisionner, scaler, mettre à niveau et démanteler des clusters suit le même parcours guidé quel que soit qui le fait ou sur quel cloud ça tourne.
Les quatre opérations dont chaque cluster a besoin.
Provisionnement
Un assistant en cinq étapes — fournisseur, bases, network plan, add-ons, revue — fonctionne de la même façon pour EKS, GKE, k3s et Proxmox. Regardez-le se construire en live. Pas de modules Terraform à maintenir, pas de scripts spécifiques au fournisseur à debugger.
Scaling des node groups
Node groups managés façon EKS sur chaque type de cluster, y compris k3s sur bare metal. Ajoutez des nœuds, changez les types d'instance, activez le spot, fixez labels et taints, scalez en live — sans toucher le cluster directement.
Des mises à niveau qui ne parient pas avec la production
Une bannière EOL apparaît avant la fin du support. Les contrôles preflight font remonter les blockers — APIs dépréciées, add-ons incompatibles — avant que quoi que ce soit ne bouge. Un parcours par étapes (plan de contrôle → add-ons → node groups) avec rollback signifie qu'un bump de version n'est pas un week-end d'anxiété.
Démantèlement propre
Destroy balaye les ressources taguées avec une checklist conserver/supprimer : volumes EBS, clés KMS, security groups, load balancers. Rien ne traîne. Pas de ressources orphelines qui accumulent discrètement des charges des mois plus tard.
Un bump de version Kubernetes ne devrait pas être un pari.
La plupart des pannes dues aux mises à niveau arrivent pour les mêmes raisons : des APIs dépréciées non détectées, des add-ons qui ne supportent pas la nouvelle version, des node groups mis à jour avant que le plan de contrôle soit stable. Zeus vous guide à travers chaque étape dans l'ordre.
Alerte EOL
Zeus suit les fenêtres de support Kubernetes et affiche une bannière quand votre version approche de la fin de vie — avant d'être forcé de mettre à niveau dans l'urgence.
Contrôles preflight
Avant que quoi que ce soit ne bouge, Zeus vérifie l'usage d'APIs dépréciées, les add-ons incompatibles et les blockers connus spécifiques à votre saut de version.
Parcours par étapes
Le plan de contrôle d'abord, puis les add-ons, puis les node groups — dans l'ordre que Kubernetes attend. Chaque étape confirme avant de continuer.
Rollback
Si quelque chose tourne mal, le chemin de rollback est explicite et guidé — pas une procédure manuelle que vous inventez sous pression.
Ce que vous cessez d'avoir à deviner à la volée.
Pods, logs et métriques en live sur chaque cluster.
Explorer →Mêmes opérations sur chaque fournisseur.
Explorer →Équipes qui font tourner Kubernetes sans personne d'infra dédiée.
Explorer →Arrêtez de découvrir que votre runbook ne marche pas pendant une vraie panne.
Voyez comment Zeus gère le provisionnement, les mises à niveau et les opérations dans une démo live.