From ff086faef66d0317367cfe8519f57eeee6c1ccdb Mon Sep 17 00:00:00 2001 From: Guillaume Da Silva Date: Thu, 7 May 2026 12:14:10 +0200 Subject: [PATCH] docs: align cronjob nodepool docs with required affinity behavior Cron job pod affinity for the dedicated cronjob Karpenter nodepool was recently switched from preferred (soft) to required (hard) so cron pods actually land on that nodepool instead of silently scheduling on the default nodepool whenever it has spare capacity. The docs still described the previous soft behavior. Both the cronjob page and the EKS managed cluster resources page now: * describe a required (hard) node affinity instead of preferred * state that redeploying cron jobs is mandatory after enabling or disabling the cronjob nodepool, not just recommended * remove the false claim that jobs fall back to the default nodepool when the cronjob nodepool is removed; with hard affinity they stay in Pending until redeployed Pairs with the corresponding engine code change. --- docs/configuration/cronjob.mdx | 9 +++++++-- .../integrations/kubernetes/eks/managed.mdx | 2 +- 2 files changed, 8 insertions(+), 3 deletions(-) diff --git a/docs/configuration/cronjob.mdx b/docs/configuration/cronjob.mdx index 0766ccb..043eae3 100644 --- a/docs/configuration/cronjob.mdx +++ b/docs/configuration/cronjob.mdx @@ -18,11 +18,16 @@ Cron Jobs in Qovery are Kubernetes workloads that run on a regular schedule. The ## Dedicated Cronjob Node Pool -On AWS EKS clusters with Karpenter, you can enable a dedicated **cronjob node pool**. When enabled, a Karpenter NodePool named `cronjob` is created with a `nodepool/cronjob: NoSchedule` taint. Qovery cron jobs automatically receive the appropriate toleration and a preferred node affinity toward this node pool, so they are steered there when available. See [AWS EKS cluster resources](/configuration/integrations/kubernetes/eks/managed#resources) for details on enabling and configuring this nodepool. +On AWS EKS clusters with Karpenter, you can enable a dedicated **cronjob node pool**. When enabled, a Karpenter NodePool named `cronjob` is created with a `nodepool/cronjob: NoSchedule` taint. Qovery cron jobs automatically receive the appropriate toleration and a required node affinity toward this node pool, so they always run there. See [AWS EKS cluster resources](/configuration/integrations/kubernetes/eks/managed#resources) for details on enabling and configuring this nodepool. -After enabling or disabling the cronjob node pool, **we strongly recommend redeploying all your cron jobs** to ensure they pick up the updated scheduling configuration. If the nodepool is removed before jobs are redeployed, existing cron jobs can fall back to the default nodepool instead of staying in `Pending`, but redeploying ensures they run with the latest intended scheduling behavior. +Whenever you enable or disable the cronjob node pool, **you must redeploy every cron job** so they pick up the updated scheduling configuration. The node affinity is required (hard), so: + +- Cron jobs deployed **before** the nodepool was enabled will not run on it until they are redeployed. +- Cron jobs deployed **while** the nodepool was enabled will stay in `Pending` if the nodepool is later disabled and they are not redeployed. + +There is no automatic fallback to the default node pool. Always redeploy your cron jobs after touching this setting. ## Deployment Sources diff --git a/docs/configuration/integrations/kubernetes/eks/managed.mdx b/docs/configuration/integrations/kubernetes/eks/managed.mdx index 788de7a..ca5fd5e 100644 --- a/docs/configuration/integrations/kubernetes/eks/managed.mdx +++ b/docs/configuration/integrations/kubernetes/eks/managed.mdx @@ -255,7 +255,7 @@ Qovery deploys two node pools by default: Additional optional node pools can be enabled: - **GPU node pool**: Can be enabled if you want to run GPU workloads on your cluster. You can select the GPU instance types you want to use on this nodepool. -- **Cronjob node pool**: A dedicated node pool for Qovery cron jobs. When enabled, a Karpenter NodePool named `cronjob` is created with a `nodepool/cronjob: NoSchedule` taint. Qovery cron jobs automatically receive the appropriate toleration and a preferred node affinity toward this nodepool, so they are steered there when available. This helps isolate cronjob workloads from long-running services on shared nodes. The cronjob nodepool supports consolidation scheduling and resource limits (same as the stable nodepool). After enabling or disabling this nodepool, **we strongly recommend redeploying all your cron jobs** to ensure they run with the latest intended scheduling configuration. If the nodepool is removed before redeploy, existing jobs can fall back to the default nodepool instead of staying in `Pending`. +- **Cronjob node pool**: A dedicated node pool for Qovery cron jobs. When enabled, a Karpenter NodePool named `cronjob` is created with a `nodepool/cronjob: NoSchedule` taint. Qovery cron jobs automatically receive the appropriate toleration and a required node affinity toward this nodepool, so they always run there. This helps isolate cronjob workloads from long-running services on shared nodes. The cronjob nodepool supports consolidation scheduling and resource limits (same as the stable nodepool). The node affinity is required (hard): whenever you enable or disable this nodepool, **you must redeploy every cron job** so they pick up the updated scheduling configuration. There is no automatic fallback to the default node pool. Cron jobs deployed before the nodepool was enabled will not run on it until they are redeployed, and cron jobs deployed while the nodepool was enabled will stay in `Pending` if the nodepool is later disabled and they are not redeployed. #### Settings for nodepools: