访问方式:

Compare Deployment & StatefulSet

                  类型
特性
DeploymentStatefulSet
是否暴露到外网可以一般不
请求面向的对象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类型则不能有此参数,否则报错。

Logo

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐