More debugging. It appears to be a race condition in the KubernetesTaskRunner. Some process in druid is submitting tasks in rapid fashion to this class, which ignores most of it because it keeps its own internal task list in a synchronized map. When the task completes, everything is fine, it gets success, it cleans it all up, it gets removed from all task lists, but then within a second the same job gets resubmitted to this process, since it is no longer in it's task list, it gets put back in, then spawned again. At some point the taskQueueManager notices a process running that shouldn't be and kills it, but KubernetesTaskRunner never gets that memo I guess, it leaves the task in it's internal list. At some point (guessing here), the size of this list exceeds the number of threads it has allocated to run more processes(number of threads == maxTasks) and so it won't spawn new tasks beyond the number it has in its list.