A teammate wants to cache a per-user session on the pod's local disk "since the pod usually stays around for a while." What's wrong with that plan, and what does "usually" actually mean here?

A pod is the smallest thing Kubernetes schedules, and it is disposable by design: a pod that dies is not restarted, it is replaced, with a new name and a new IP, and its local disk goes with it. "Usually stays around for a while" is exactly the trap — a pod can be rescheduled for reasons that have nothing to do with a bug in the application: a node drains for an upgrade, the scheduler evicts it under memory pressure, a rolling update replaces it on purpose. Any design that assumes a specific pod keeps existing — a sticky session, a local cache that matters, a file written to the pod's own disk — breaks the moment that assumption is wrong, and it will be wrong in production even if it never was in a quiet staging environment. The fix is external state: a shared cache (Redis) for the session, object storage or a database for anything that has to survive a pod being replaced.