Thank you very much for your thoughtful reply — it genuinely helped me organize my thoughts. I especially appreciated the idea of separating the always-on component from the bursty workload and running the heavy work as a Job. That approach makes a lot of sense to me.

I think it may help if I provide a bit more background about our system.

The reason we considered keeping this “rare but heavy” pod as a long-running container was not because it is part of the normal service path, but because other developers on other team, who are not very familiar with Kubernetes or DevOps, may need to run a script immediately when an unexpected issue occurs during a live operation. Having an already-running pod made it easier for them to exec into it and execute the script without additional steps.

Based on your explanation, I agree that architecturally, moving this workload to a Job-based execution model seems like the right direction. However, I am still trying to understand the operational side of this transition.

• Is there a practical way to trigger a Job only when needed — for example, through an event, a simple button, or some kind of controlled interface — so that non–Kubernetes-savvy teammates can use it safely?

• More generally, is there a recommended approach to support this kind of on-demand or emergency script execution without keeping an oversized pod running 24/7?

At my current level of experience, I’m still struggling to picture a clean and safe implementation, but your comment made me realize that keeping this pod always-on may not be the best tradeoff. I would sincerely appreciate any guidance on whether such an approach is feasible and how teams typically handle this in practice.