Suppose traffic suddenly surges and you need more copies of your application. Scaling is easier when any copy can handle the next request. In a stateless design, each replica can serve an incoming request without relying on data stored locally by another replica. section 1.0 section 6.4.1
Stateless does not mean the application uses no data. Keep data that must survive a request or be available to other replicas in an external store. SQL or NoSQL databases can hold structured data, object storage can hold files, and a memory database such as Redis can hold session state. Local ephemeral storage is still useful for temporary processing when its contents need not be shared or available to a later request. section 6.4.1
In Kubernetes, a stateless application can run as a Deployment: its Pod definition identifies the containers to run, and its replica count states how many instances you want. Kubernetes places those Pods in the cluster. Container disk data is ephemeral by default, so do not treat it as durable application state. section 1.2.1 section 6.4.1
Some workloads genuinely need persistent state. Kubernetes can support them with persistent volumes and StatefulSets, but that is a different choice from keeping easily replicated application instances stateless. A platform as a service may deploy stateless frontends simply; check whether it can also accommodate a required stateful backend before relying on that simplicity. section 6.4.1 section 1.2.3
