访问方式：

Compare Deployment & StatefulSet

综上所述：

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类型则不能有此参数，否则报错。