用于有状态应用程序但不需要永久磁盘的 Kubernetes 工作负载
Kubernetes workload for stateful application but no need of persistent disk
我有一个有状态的应用程序 - 我将数据保存在用户会话中（基本上是 HttpSession 对象中的数据） - 但我不需要将任何内容写入永久磁盘。
据我目前所读 - StatefulSet 工作负载适用于有状态应用程序，但到目前为止我的理解是，即使我的应用程序是有状态应用程序，但部署工作负载也可以满足我的要求，因为我不想将任何内容写入永久磁盘。
但是，有一点我不确定，假设我使用部署工作负载并且我的 HttpSession 对象中存在大量用户数据，现在由于某种原因 Kubernetes 会重启我的 Pod，当然所有用户会话数据都将丢失。所以，我的问题如下：
- StatefulSet 是否比 Deployment 工作负载更好地处理这种情况？
- 那么，Deployment 工作负载和 StatefulSet 工作负载之间的唯一区别在于 absence/presence 永久磁盘，或者在 StatefulSet 的情况下也与应用程序会话管理有关？
Does StatefulSet handles this situation any better than Deployment workload?
没有。 Deployment 和 StatefulSet 都不会保留内存内容。要保留会话信息，您需要将其存储在某个地方。一种常见的方法是使用 Redis.
So, only difference between Deployment workload and StatefulSet workload is about absence/presence of persistent disk or there is something to do with application session management as well in case of StatefulSet?
不是，还有其他区别：
- StatefulSets 创建（和重新创建）确定性的、一致的 pod 名称（标识符）。
- StatefulSets，以确定的、一致的顺序一个接一个部署、扩展和更新。只有在前一个 pod 达到
Running 状态后才会创建下一个 pod。
此外，值得一提的是，永久磁盘可以附加到不属于 StatefulSet 的 pods。只是让磁盘始终附加到具有一致 id 的 pod 很方便。例如，如果您有 pods 运行 一个复制数据库，您可以使用 StatefulSets 来确保主副本的磁盘始终附加到 pod #1。
编辑：
Link to official documentation about StatefulSets
来自文档：
Like a Deployment, a StatefulSet manages Pods that are based on an
identical container spec. Unlike a Deployment, a StatefulSet maintains
a sticky identity for each of their Pods. These pods are created from
the same spec, but are not interchangeable: each has a persistent
identifier that it maintains across any rescheduling.
...
StatefulSets are valuable for applications that require one or more of
the following.
- Stable, unique network identifiers.
- Stable, persistent storage.
- Ordered, graceful deployment and scaling.
- Ordered, automated rolling updates.
In the above, stable is synonymous with persistence across Pod
(re)scheduling. If an application doesn't require any stable
identifiers or ordered deployment, deletion, or scaling, you should
deploy your application using a workload object that provides a set of
stateless replicas. Deployment or ReplicaSet may be better suited to
your stateless needs.
我有一个有状态的应用程序 - 我将数据保存在用户会话中（基本上是 HttpSession 对象中的数据） - 但我不需要将任何内容写入永久磁盘。
据我目前所读 - StatefulSet 工作负载适用于有状态应用程序，但到目前为止我的理解是，即使我的应用程序是有状态应用程序，但部署工作负载也可以满足我的要求，因为我不想将任何内容写入永久磁盘。
但是，有一点我不确定，假设我使用部署工作负载并且我的 HttpSession 对象中存在大量用户数据，现在由于某种原因 Kubernetes 会重启我的 Pod，当然所有用户会话数据都将丢失。所以，我的问题如下：
- StatefulSet 是否比 Deployment 工作负载更好地处理这种情况？
- 那么，Deployment 工作负载和 StatefulSet 工作负载之间的唯一区别在于 absence/presence 永久磁盘，或者在 StatefulSet 的情况下也与应用程序会话管理有关？
Does StatefulSet handles this situation any better than Deployment workload?
没有。 Deployment 和 StatefulSet 都不会保留内存内容。要保留会话信息，您需要将其存储在某个地方。一种常见的方法是使用 Redis.
So, only difference between Deployment workload and StatefulSet workload is about absence/presence of persistent disk or there is something to do with application session management as well in case of StatefulSet?
不是，还有其他区别：
- StatefulSets 创建（和重新创建）确定性的、一致的 pod 名称（标识符）。
- StatefulSets，以确定的、一致的顺序一个接一个部署、扩展和更新。只有在前一个 pod 达到
Running状态后才会创建下一个 pod。
此外，值得一提的是，永久磁盘可以附加到不属于 StatefulSet 的 pods。只是让磁盘始终附加到具有一致 id 的 pod 很方便。例如，如果您有 pods 运行 一个复制数据库，您可以使用 StatefulSets 来确保主副本的磁盘始终附加到 pod #1。
编辑：
Link to official documentation about StatefulSets
来自文档：
Like a Deployment, a StatefulSet manages Pods that are based on an identical container spec. Unlike a Deployment, a StatefulSet maintains a sticky identity for each of their Pods. These pods are created from the same spec, but are not interchangeable: each has a persistent identifier that it maintains across any rescheduling.
...
StatefulSets are valuable for applications that require one or more of the following.
- Stable, unique network identifiers.
- Stable, persistent storage.
- Ordered, graceful deployment and scaling.
- Ordered, automated rolling updates.
In the above, stable is synonymous with persistence across Pod (re)scheduling. If an application doesn't require any stable identifiers or ordered deployment, deletion, or scaling, you should deploy your application using a workload object that provides a set of stateless replicas. Deployment or ReplicaSet may be better suited to your stateless needs.