kubernetes（k8s）StatefulSet 和 Deployment 区别及选择方式

访问方式：

Compare Deployment & StatefulSet

类型 特性	Deployment	StatefulSet
是否暴露到外网	可以	一般不
请求面向的对象	serviceName	指定pod的域名
灵活性	只能通过service/serviceIp访问到k8s自动转发的pod	可以访问任意一个自定义的pod
易用性	只需要关心Service的信息即可	需要知道要访问的pod启动的名称、headlessService名称
PV/PVC绑定关系的稳定性（多replicas）	（pod挂掉后重启）无法保证初始的绑定关系	可以保证
pod名称稳定性	不稳定，因为是通过template创建，每次为了避免重复都会后缀一个随机数	稳定，每次都一样
启动顺序（多replicas）	随机启动，如果pod宕掉重启，会自动分配一个node重新启动	pod按 app-0、app-1...app-（n-1），如果pod宕掉重启，还会在之前的node上重新启动
停止顺序（多replicas）	随机停止	倒序停止
集群内部服务发现	只能通过service访问到随机的pod	可以打通pod之间的通信（主要是被发现）
性能开销	无需维护pod与node、pod与PVC 等关系	比deployment类型需要维护额外的关系信息

综上所述：

1. 如果是不需额外数据依赖或者状态维护的部署，或者replicas是1，优先考虑使用Deployment；
2. 如果单纯的要做数据持久化，防止pod宕掉重启数据丢失，那么使用pv/pvc就可以了；
3. 如果要打通app之间的通信，而又不需要对外暴露，使用headlessService即可；
4. 如果需要使用service的负载均衡，不要使用StatefulSet，尽量使用clusterIP类型，用serviceName做转发；
5. 如果是有多replicas，且需要挂载多个pv且每个pv的数据是不同的，因为pod和pv之间是 一 一对应的，如果某个pod挂掉再重启，还需要连接之前的pv，不能连到别的pv上，考虑使用StatefulSet
6. 能不用StatefulSet，就不要用

只能用StatefulSet:

最近在微软的aks平台上部署服务，由于Deployment在scale的时候需要动态申请volume，采取使用volumeClaimTemplates属性的方式来申请，当前Deployment对象（1.15）不支持这一属性，只有StatefulSet才有，因此不得不使用后者。目前看来有点本末倒置，不过不排除以后k8s会支持这一属性。

注意：

如果使用StatefulSet，spec.serviceName需要指向headlessServiceName，且不能省略指定步骤，官方文档要求headlessService必须在创建StatefulSet之前创建完成，经过测试，如果没有也不会影响pod运行（pod还是running状态），只是不能拥有一个stable-network-id 集群内部不能访问到这个服务（如果这个服务不需要被发现，只需要去发现其他服务，则serviceName随便写一个也行），官方要求要在创建StatefulSet之前创建好headlessService，是为了让pod启动时能自动对应到service上。

之所以要指定一个headlessService，是因为admin可以给StatefulSet创建多个、多种类型的service，k8s不知道要用哪个service的名称当作集群内域名的一部分。

Deployment类型则不能有此参数，否则报错。