There's nothing intrinsic about crons in the same container that prevent you from rescheduling containers on other nodes, fearlessly restarting, or whacking ran

There's nothing intrinsic about crons in the same container that prevent you from rescheduling containers on other nodes, fearlessly restarting, or whacking random containers. What they're doing, how they're handling state, and their lifecycles might. Study your requirements. Whether you run your crons in the same container or a separate container depends on your system's behavior and failure/recovery scenarios. There are complexity tradeoffs--moving the cron scheduling outside of the container suddenly means you have moving parts outside of your container to test, instrument, monitor, and maintain. If you're already doing that, it's not too big of a deal, but if you aren't then I would think twice before adding all this complexity to your architecture, and make sure it's really worth it. (I can't tell from the article which approach works for their specific use cases...I'm pushing back against the general advice to "avoid cron in containers". I would default to using cron, and only move those processes to separate containers if you have a concrete reason to.)