Change Details

Previously most workloads on the Kubernetes cluster have been web services and other continuous jobs where a restart on another node would not have mattered. This assumption changes when the jobs framework introduces cron jobs. This task is to: * check if running jobs will not misbehave when they are restarted ** TODO: should jobs reschedule or not if they don't complete? especially relevant for one-off jobs * consider adding some delay to let running jobs complete when nodes are being evicted

Previously most workloads on the Kubernetes cluster have been web services and other continuous jobs where a restart on another node would not have mattered. This assumption changes when the jobs framework introduces cron jobs. This task is to: * check if running jobs will not misbehave when they are restarted ** TODO: should jobs reschedule or not if they don't complete? especially relevant for one-off jobs * consider adding some delay to let running jobs complete when nodes are being drained

Previously most workloads on the Kubernetes cluster have been web services and other continuous jobs where a restart on another node would not have mattered. This assumption changes when the jobs framework introduces cron jobs. This task is to: * check if running jobs will not misbehave when they are restarted ** TODO: should jobs reschedule or not if they don't complete? especially relevant for one-off jobs * consider adding some delay to let running jobs complete when nodes are being evicteddrained