为何不建议为无状态应用使用Kubernetes StatefulSet？

很多人都知道有状态应用要用StatefulSet，但很少有人明确说无状态别用它——其实Deployment才是无状态应用的标准选择，原因主要在这几点：

Deployment对无状态应用的优势 #

• 编排逻辑更简洁高效：Deployment的Pod是完全平等的“临时实例”，扩缩容、更新都是批量操作，不用管顺序。比如扩容10个Pod，Deployment能同时启动多个，而StatefulSet必须按序号一个个来，等前一个就绪才搞下一个，纯纯浪费时间。
• 更新策略更灵活：Deployment的滚动更新可以通过maxSurge和maxUnavailable参数，灵活控制更新时的可用实例数，比如允许同时更新一半Pod，快速完成版本迭代。StatefulSet默认是逐个更新Pod，还会因为单个Pod更新失败暂停整个流程，对无状态应用来说，这种保守策略完全没必要——反正Pod坏了直接换就行，批量更新效率高多了。
• 调度和维护开销更低：StatefulSet要给每个Pod维护固定的DNS名称、序号，还要绑定专属PVC（如果用了volumeClaimTemplates），K8s控制器得额外盯这些状态。而Deployment的Pod是一次性的，不需要跟踪这些固定标识，控制器负载更低，调度更快。

StatefulSet跑无状态应用的坑 #

• 有序操作纯属多余开销：扩缩容、更新都要按顺序来，速度慢还没好处——无状态应用本来就不需要Pod有先后顺序，完全是做无用功。
• PVC资源冗余：就算你的无状态应用用PV存日志，日志也不需要和特定Pod绑定。但StatefulSet如果配了volumeClaimTemplates，每个Pod都会生成一个专属PVC，最后一堆没人管的PVC，增加存储管理的麻烦。要是用Deployment，直接挂载共享PV或者用临时存储就行，根本不用搞这么多PVC。
• 固定网络标识没用还可能添乱：StatefulSet的每个Pod有固定主机名和DNS记录，但无状态应用应该通过Service做负载均衡，谁会去记单个Pod的名字？这些固定标识不仅没用，还可能让人误以为要依赖它们访问，反而违背了无状态的设计原则。

总结 #

StatefulSet不是不能跑无状态应用，而是没必要——它的那些特性都是为有状态场景设计的，对无状态应用来说全是冗余。除非你的“无状态”应用其实有特殊需求（比如必须固定Pod标识，但这其实已经不算纯无状态了），否则老老实实用Deployment就对了。

内容的提问来源于stack exchange，提问作者Eddy Kim