在之前，我们知道应用程序分为两类，一种是有状态，一种无状态。无状态的有nginx等。有状态的居多。
如：redis,mysql,zook集群等，其中一些不单单有主从状态，更有启动顺序等的区分。这时候可使用statefulse，但是statefulse在完成一些配置的时候仍然是非常麻烦的，很多时候需要手动编写脚本，或者依赖于地第三方的一些工具来做。statefulse在处理，特别是在一些运维逻辑非常复杂的时候，仍然是非常麻烦的。coreos提供了一种组件operator，可以将复杂的逻辑封装在这个组件当中。但是我们会使用kubernetes官网的statefulset-->有状态副本集。
无状态关注的更多的是群体，任何一个轻易的就会被其他所取代。没有 本地的数据，也没有独特的依赖状态。但是对于有状态的应用来讲，就需要有个体的：cattle,pet。在之前称为petset，现在称为SatefulSet。
SatefulSet
在kubernetes上的SatefulSet主要用于管理一下应用1，具备稳定的环境，唯一的网络标识符2，具备稳定持久的存储设备3，有序，优雅平滑的部署和扩展，以及有序终止和删除，有序的滚动更新（如：启动顺序等，关闭顺序等）。
一般来讲SatefulSet将会由三个组件组成：headless service，SatefulSet控制器，VolumeClaimTemplate存储卷申请模板
- headless service
我们知道创建没每个pod的名称是无序的，但是在有状态的应用中节点的名称是不能变的，pod的名称是识别pod唯一性的标识符。这个标识符必须稳定持久有效，这时候就需要headless service（无头服务），解析的名称直达后端pod地址，并确保名称唯一。
- VolumeClaimTemplate
大多数有状态的pod都会用到持久存储，以redis cluster为例，假设有6台redis，每台redis的槽位是不一样的，数据也是不一样的(数据有可能，或者重名)，也就意味着至少需要6个单独的存储卷用来专用存储，不能够共享。因为数据名称是一样的，数据不一样。
此时基于pod模板定义则只能访问同一个存储卷，因此使用VolumeClaimTemplate(卷申请模板)在创建pod的时候会自动生成一个专有的pvc，请求绑定一个专有pv,从而有单独的存储
在SatefulSet中的pod不能够使用同一个存储卷，因此通过pod模板来创建pod是不适用的，这也就是为什么要用定义VolumeClaimTemplate的原因。
