kubernetes controller源码解读之StatefulSet-阿里云开发者社区

1. StatefulSet应用场景说明

Deployment部署的无状态应用，应用的各个实例是相互独立的。但是在实际应用中存在如下需求:

应用的各个实例之间有一定依赖关系。如多个实例组成一个集群(比如ETCD集群)，实例之间需要通过通信选出leader。这就要求各个实例的网络地址必须固定(不管是实例重启，还是热迁移到别的节点等实例的网络地址都必须保持不变)，否则就无法组成稳定集群。
应用的实例和存储数据需要绑定。比如部署mysql集群(主备模式)，两个实例通过 sharding来保存数据，所以访问这两个实例是分库之后不同的数据。而用户会要求访问两个实例返回数据是稳定的，也就是要求实例和存储数据必须要绑定(不管是实例是重启，或者迁移到其他节点)，实例对应的 storage必须固定。
应用的各实例启动需要遵循一定的顺序。比如首先启动的实例必须为 Master实例，其他 Slave实例才能后续启动。

针对上面的需求，如果用户不通过 kubernetes来实现的话，就需要为每个实例提供 static ip和固定的 volume，并且要定制化来保证一定的启动顺序。这样对应用的部署会产生很大的约束。而在kubernetes中可以通过 Statefulset来满足上述的场景。

解决方案是通过 StatefulSet部署的Pod会有一个固定身份和身份相关的其他固定信息。不管Pod是原地重启还是迁移到其他节点，这些固定信息都会跟着他，同时启动顺序也有充分保证。从而对应用的部署约束大大降低。

除了上述功能外, Stateful|Set也具备方便的实例升级和实例扩缩容能力。这也是用户通过自身运维很难简单实现的。下面通过分析StatefulSet的源码，深入看一下各功能实现。

2. StatefulSet资源定义

具体分析源码前，我们需要先了解StatefulSet资源定义。单个 StatefulSet资源的定义结构( tatefulSet的yam定义需要遵守该结构)如下

type StatefulSet struct {
  metal.TypeMeta
  metal.ObjectMeta
  Spec StatefulSetspec
  Status StatefulSetStatus
}

kube-controller-manager组件中的StatefulSet Controller模块会根据 StatefulSetSpec的定义来驱动控制逻辑，并刷新StatefulSetStatus来反馈StatefulSet实时状态。 StatefulSetspec和 StatefulSetStatus的定义如下:

StatefulSetspec的定义如下:

type StatefulSetspec struct {
  Replicas *int32
  Selector *metav1.LabelSelector
  Template v1.PodTemplateSpec
  VolumeClaimTemplates []v1.PersistentVolumeClaim
  ServiceName string
  PodManagementPolicy PodManagementPolicyType
  UpdateStrategy StatefulSetUpdateStrategy
  RevisionHistoryLimit *int32
}

按用途可以把 StatefulSetSpec中的字段分成下面3类:

Pod创建或者删除; Selector, Template, VolumeClaimTemplates, ServiceName,
PodManagementPolicy
Pod副本数控制: Replicas
Pod升级和回滚: UpdateStrategy，RevisionHistoryLimit

Statefulset中的 StatefulSetStatus的定义如下:

type StatefulSetStatus struct {
  ObservedGeneration *int64
  Replicas int32
  ReadyReplicas int32
  CurrentReplicas int32
  UpdatedReplicas int32
  CurrentRevision string
  UpdateRevision string
  CollisionCount *int32
  Conditions []StatefulSetCondition
}

StatefulSet的yam1具体实例,可以参照:
https://raw.githubusercontent.com/kubernetes/website/master/content/en/docs/tutorials/stateful-application/web.yaml

注意: 部署StatefulSet时，需要先部署一个headless的service。其中service的Name用于填充StatefulSetSpec中的ServiceName字段。
了解完StatefulSet资源定义后，基于资源定义我们分析StatefulSet的具体实现，打开看看她是怎么满足各场景需求的。

3. StatefulSet Controller详细说明

刚开始有提到 Statefulset部署的Pod带有固定身份标识，那首先我们就先看一下Pod的身份标识:

3.1 Pod固定身份标识

主要给Pod绑定固定名称，固定网络地址(DNS记录)，固定存储信息这3个维度的信息。具体如下:

名称维度

PodName由 Statefulse的Name+应用实例索引号来决定。索引号={0~ StatefulSetSpec.Replicas - 1}。StatefulSet Controller保证在每个索引号创建一个Pod，所以每个索引位置的Pod名称是固定的。PodName代码处理如下:

@kubernetes/pkg/controller/statefulset/stateful_set_utils.go
func getPodName(set *apps.StatefulSet, ordinal int) string {
    return fmt.Sprintf("%s-%d", set.Name, ordinal)  // ordinal为索引号
}

网络地址维度:

根据kubernetes dns spc的约定，headless service对应pod的网络地址(完整域名)为: <hostname>.<subdomain>.<ns>.svc.cluster.local，而StatefulSet pod的 hostname和 subdomain生成代码如下:

@kubernetes/pkg/controller/statefulset/stateful_set_utils.go
func initIdentity(set *apps.StatefulSet, pod *v1.Pod) {
    updateIdentity(set, pod)
    // Set these immutable fields only on initial Pod creation, not updates.
    pod.Spec.Hostname = pod.Name  // hostname设置为 podName
    pod.Spec.Subdomain = set.Spec.ServiceName // subdomain设置为 Headless Service的名称
}

因为从名称维度可知，podName是固定的，所以pod的网络地址也是固定的。

存储维度

Pod的各个 volume是通过PVC来管理的，所以只要 Volume对应的PVC能保持不变，那就可以保证存储不变。那么顺其自然一定会想到，只要PVC的名称也和Pod的索引位置绑定，那问题就解决了。代码中处理如下:

@kubernetes/pkg/controller/statefulset/stateful_set_utils.go
func getPersistentVolumeClaimName(set *apps.StatefulSet, claim *v1.PersistentVolumeClaim, ordinal int) string {
    // NOTE: This name format is used by the heuristics for zone spreading in ChooseZoneForVolume
    // ordinal为pod的索引号
    return fmt.Sprintf("%s-%s-%d", claim.Name, set.Name, ordinal)
}

所以综上说明，可以看到3个维度的固定，本质都是依赖Pod的索引位置来固定的。

理解完Pod的身份标识,接下来分析一下Pod的创建。

3.2 StatefulSet Pod创建

根据StatefulSetSpec.PodManagementPolicy的设置，Pod创建分为OrderedReady和 Parallel两种模式。

OrderedReady模式: 按索引号0 ~ replicas-1的顺序，前序Pod创建成功后，才会接下来创建下一个Pod。
Parallel模式:并发创建各个Pod。

代码中处理如下

monotonic := !allowsBurst(set) //获取创建模式, monotonic=true:顺序创建, false:并发创建

// 按0~replicas-1遍历每个索引号,保证前序Pod创建成功后再创建后续Pod
for i := range replicas {
    // 索引位置Pod存在但是为fai1ed状态，则重建该Pod,并更新StatefulSet.Status
    if isFailed(replicas[i]) {
        if err := ssc.podControl.DeleteStatefulPod(set, replicas[i]); err != nil {
            return &status, err
        }
        if getPodRevision(replicas[i]) == currentRevision.Name {
            status.CurrentReplicas--
        } else if getPodRevision(replicas[i]) == updateRevision.Name {
            status.UpdatedReplicas--
        }
        status.Replicas--
        replicas[i] = newVersionedStatefulSetPod(
            currentSet,
            updateSet,
            currentRevision.Name,
            updateRevision.Name,
            i)
    }
    // 索引位置的pod还没有创建,那么就创建它,并更新StatefulSet.Status
    if !isCreated(replicas[i]) {
        if err := ssc.podControl.CreateStatefulPod(set, replicas[i]); err != nil {
            return &status, err
        }
        status.Replicas++
        if getPodRevision(replicas[i]) == currentRevision.Name {
            status.CurrentReplicas++
        } else if getPodRevision(replicas[i]) == updateRevision.Name {
            status.UpdatedReplicas++
        }

        // 顺序创建模式时，后续索引位置Pod需要等该Pod运行正常后才能创建
        if monotonic {
            return &status, nil
        }
        // pod created, no more work possible for this round
        continue
    }
    // 索引位置pod为删除状态且为顺序创建模式,那就等该pod删除后再创建后续Pod。
    if isTerminating(replicas[i]) && monotonic {
        return &status, nil
    }

    // 索引位置pod还未ready且为顺序创建模式,那就等该pod状态ready后再创建后续Pod。
    if !isRunningAndReady(replicas[i]) && monotonic {
        return &status, nil
    }
    // 检查pod的身份标识是否变化,没有变化说明Pod正常可以继续创建后续Pod
    if identityMatches(set, replicas[i]) && storageMatches(set, replicas[i]) {
        continue
    }
    // 否则Pod身份变化就刷新该Pod
    replica := replicas[i].DeepCopy()
    if err := ssc.podControl.UpdateStatefulPod(updateSet, replica); err != nil {
        return &status, err
    }
}

而对于Pod删除，用户直接删除StatefulSet的Pod是无法凑效的，因为 StatefulSet马上就会重建。如果要删除Pod,必须通过调整 StatefulSet的 Spec.Replicas来达到删除目的。即为Pod扩缩容处理。

3.3Pod扩缩容

扩容处理: Replicas增大的情况，则直接是Pod创建的逻辑(参考3.2章节)。因为 StatefulSet会在每一个索引位置创建一个Pod，所以扩容就是多创建几个后续Pod。
缩容处理: 因为需要减少Pod，为了不和Pod创建过程冲突，缩容是从最大索引号开始删除Pod。

代码中处理如下(下面代码中顺序还是并发删除说明省略)

if ord := getOrdinal(pods[i]); 0 <= ord && ord < replicaCount {
    replicas[ord] = pods[i]
} else if ord >= replicaCount {
    //pod索引号大于最新的Spec.Replicas,说明Replicas减小了，这些Pod需要被缩容掉
    condemned = append(condemned, pods[i])
}

// 从最大索引号开始缩容
for target := len(condemned) - 1; target >= 0; target-- {
    // 如果该Pod正在被删除,则等待被删除完成即可
    if isTerminating(condemned[target]) {
        if monotonic {
            return &status, nil
        }
        continue
    }

    // 如果被删除pod的前序pod中有不健康的,那么需要等待前序pod恢复为正常状态后才能继续缩容
    if !isRunningAndReady(condemned[target]) && monotonic && condemned[target] != firstUnhealthyPod {
        return &status, nil
    }

    // 到这里可以执行pod缩容删除了
    if err := ssc.podControl.DeleteStatefulPod(set, condemned[target]); err != nil {
        return &status, err
    }
    // 更新StatefulSet.Status
    if getPodRevision(condemned[target]) == currentRevision.Name {
        status.CurrentReplicas--
    } else if getPodRevision(condemned[target]) == updateRevision.Name {
        status.UpdatedReplicas--
    }
    if monotonic {
        return &status, nil
    }
}

当分析完Pod的创建和扩缩容后，接下来需要看看pod的升级。

3.4 Pod的升级

Pod升级动作主要指更新Spec.Template中的内容(一般主要更新镜像)，从而触发新旧Pod的替换。
Pod升级策略由Spec.Update.Strategy字段指定，目前支持OnDelete和RollingUpdate两种模式。
Spec.UpdateStrategy.Type=OnDelete: Spec.Template更新后，需要用户手动删除旧Pod，然后StatefulSet Controller会利用新的Spec.Template创建新Pod(新Pod创建细节可以参照3.2章节)。代码中处理如下:

if set.Spec.UpdateStrategy.Type == apps.OnDeleteStatefulSetStrategyType {
    return &status, nil
}

当升级策略为OnDelete时，执行直接返回，等待用户手动删除pod。

Spec.UpdateStrategy.Type=RollingUpdate: Spec.Template更新后，StatefulSet Controller会从最大索引号开始逐个升级Pod。即先删除pod，然后等到删除的pod被创建好后再进行下一个索引号的Pod升级。
RollingUpdate模式的Pod升级，可以只升级部分Pod。新旧Pod分水岭的索引号由Spec.UpdateStrategy.RollingUpdate.Partition指定。其中[0 ~ partition-1]索引号的Pod为旧版本，而[partition ~ replicas-1]索引号的Pod为新版本。当然如果 partition > Spec.Replicas，则不会升级任何Pod。

RollingUpdate模式的代码如下(下面主要为删除旧Pod，而新Pd创建请参照3.2章节)

updateMin := 0
if set.Spec.UpdateStrategy.RollingUpdate != nil {
    updateMin = int(*set.Spec.UpdateStrategy.RollingUpdate.Partition)
}

// 从最大索引号开始执行Pod升级处理(此处为旧Pod删除)
for target := len(replicas) - 1; target >= updateMin; target-- {
    // 如果pod为旧版本并且不在被删除状态，则执行Pod删除
    if getPodRevision(replicas[target]) != updateRevision.Name && !isTerminating(replicas[target]) {
        err := ssc.podControl.DeleteStatefulPod(set, replicas[target])
        status.CurrentReplicas--
        return &status, err // 直接退出,等待被删除Pod被创建
    }

    // 等待到被删除pod创建且ready，才进行下一个pod的升级。否则就退出for循环
    if !isHealthy(replicas[target]) {
        return &status, nil
    }
}

最后再统一说明一下StatefulSet.Status的各个字段，方便用户理解 StatefulSet的Pod创建和升级进度。

3.5 StatefulSet.Status的各字段说明:

Replicas: 所有属于该 StatefulSet的Pod数量
ReadyReplicas: 所有属于该 Statefulset的Pod且状态为ready的数量
CurrentReplicas:所有属于该 StatefulSet当前版本的Pod数量(升级完成时会等于UpdatedReplicas)
UpdatedReplicas:所有属于该 StatefulSet升级版本的Pod数量
CurrentRevision: Statefulset当前版本的 set.Name+hash
UpdateRevision: Stateful|Set升级版本的 set.Name+hash

4. Statefulset的控制流程

经过上面代码级别的细节说明，下面大致梳理一下 StatefulSet Controller的控制流程。具体如下:

获取 StatefulSet: 由key从set.Lister(本地缓存)中获取到需要处理的 StatefulSet实例
获取 Statefulset所有Pod: 由StatefulSet.Spec.Selector从 pod.Lister(本地缓存)中过滤所有符合条件的Pod(且podName和 set.Name匹配)
获取当前版本和升级版本的 Controller Revision: 如果升级版本的 Controller Revision不存在，就新创建一个。(StatefulSet创建时，当前版本和升级版本相同。当前升级完成后,他们也相同)
从0 ~ Spec.Replicas-1逐个索引，创建StatefulSet Pod(3.2章节)
所有pod创建完成后，进入扩缩容逻辑处理(如果需要扩缩容操作的话)(3.3章节)
扩缩容操作完成后，进入Pod升级逻辑(如果需要Pod升级操作的话)(3.4章节)
更新 StatefulSet的 Status(3.5章节)

5. StatefulSet的几点思考

StatefulSet使用时有几点要求,1:需要创建 headless service用于pod的DNS A记录创建。2:最好采用分布式存储做数据存储。如果采用本地存储的话,就需要保证Pod重启必须调度到同一台机器，就需要用户再设置亲和性等参数。
StatefulSet的Pod升级实现方式和 Daemonset类似,都利用 Controller revision对版本进行管理。因为Controllerrevision中保存了 Pod.Spec信息,所以用户来可以利用 Controller Revison来做Pod回滚。
当 Statefulset部署Pod失败时，用户同样也可以采用 kubectl工具进行问题定位。具体命令可以看[参考链接1]
因为 StatefulSet部署Pod可以严格按照索引号[0~replicas-1]的顺序启动，所以对启动顺序有要求的应用(比如说主备模式部署)可以充分利用这点。同时在Pod(容器)中，也可以通过获取 hostname信息(带有索引号)，从而知道自己启动顺次，方便做各自独立的配置。比如说0索引号和其他索引号的应用配置文件不同等。
StatefulSet的Pod因为顺次启动，一个Pod启动并且ready后，才能启动后续的Pod。所以当Pod出现错误,或者健康检查fail时, kubelet必须可以重启pod,否则就会影响后续Pod的启动。因此
spec.Template.Spec.RestartPolicy一定要设置要为Always(这个和 Deamonset是一样的)。
.从第5点延伸出来，如果容器中是从脚本启动的业务进程，脚本应该要保证: 如果子进程(业务进程)退出后，脚本也能自行退出，从而引起容器退出。否则在无健康检查的情况下,业务不可用时kubelet也无法重启该容器。
从章节4可以看出, StatefulSet的Pod处理优先级为: Pod创建 > Pod扩缩容 > Pod升级,即必须 spec.Replicas指定的Pod数创建完成后，才会执行缩容处理(删除多余的Pod)。最后才会轮到Pod升级。也就是说如果某个索引位置Pod没有创建成功会阻塞Pod缩容和升级。

kubernetes controller源码解读之StatefulSet

1. StatefulSet应用场景说明

2. StatefulSet资源定义

3. StatefulSet Controller详细说明

3.1 Pod固定身份标识

3.2 StatefulSet Pod创建

3.3Pod扩缩容

3.4 Pod的升级

3.5 StatefulSet.Status的各字段说明:

4. Statefulset的控制流程

5. StatefulSet的几点思考

6.参考链接

热门文章

最新文章

相关课程

相关电子书

相关实验场景

推荐镜像