TDC上StatefulSet下线pod

2024-03-29 其他常见问题

内容纲要

概要描述

TDC页面上不支持单独停止某个pod的操作，本文描述如何对statefulset控制器调度的pod，进行单独的下线操作

详细描述

当前解决方案

改变statefulset控制器行为，在statefulset的metadata.annotations["offline-pod.transwarp.io/ordinal-list"] 中添加待下线pod序号。statefulset将待下线pod的序号看作占位符，不再监控对应的pod，对下线pod的删除/更新等操作不会再被statefulset感知，statefulset在更新/扩容时也会跳过这些pod.

案例操作

pod 下线操作

本文以es-data-k8vf7这个statefulset为例，进行操作
可以看到es-data-k8vf7 这个sts的replicas=3
file
下线之前pod的详细信息为
file
pod下线 —以下线es-data-k8vf7-1 为例
操作

kubectl -n w5qsyon patch sts es-data-k8vf7 -p'{"metadata":{"annotations":{"offline-pod.transwarp.io/ordinal-list":"[1]"}}}'

其中[1] 为要下线的sts的序号
查看sts的yaml内容

 kubectl get sts es-data-k8vf7 -n w5qsyon -oyaml

可以看到
file

此时查看sts
file
可以看到DESIRED replicas=3不会改变，因为：

考虑到后续重新上线的可能，上线只需要把序号从annotations移除。
statefulset对序号有严格的要求，每次同步都是根据.spec.replicas（就是DESIRED值）依次对pod更新，所以这里下线pod序号1被当成一个占位符，ESIRED显示的是在线pod和下线pod数量的总和。

2/3 中2就表示current，即当前在线pod数量，所以 DESIRED-CURRENT 就能得到下线pod数量。
此时pod的状态为：
file

需要注意的是。在tos 版本 <1.9.3 这种古早版本里面，pod可能需要手动删除，比如

kubectl delete pod es-data-k8vf7-0 -n w5qsyon

可以观察到的是，这个pod将不会自动创建

tos 版本 >=1.9.3， >=1.10，>=2.0, < 3.0
和低版本相比，多了一个杀pod的行为，下线的pod会被自动杀掉，本例的测试环境，pod就被自动杀死了。
除此之外，还允许用户通过offline-pod.transwarp.io/all-ordinals anntations key 控制所有pod 下线。

kubectl -n w5qsyon patch sts es-data-k8vf7 -p'{"metadata":{"annotations":{"offline-pod.transwarp.io/all-ordinals":""}}}'

file

tos 版本 >= 3.0
tos 3.0 以后，wsts 代替了原来的 sts。由于 wsts 是一个自定义资源，所以需要在 patch 时，显示的指定 type=merge

kubectl patch wsts es-data-k8vf7 -p '{"metadata":{"annotations":{"offline-pod.transwarp.io/ordinal-list":"[1]"}}}' --type merge

pod上线操作

把下线pod序号从annotations移除实现pod重新上线

kubectl -n w5qsyon patch sts es-data-k8vf7 -p'{"metadata":{"annotations":{"offline-pod.transwarp.io/ordinal-list":"[]"}}}'

file

statefulset更新

更新会跳过被下线的pod，即被下线的pod不会被更新

statefulset缩容

缩容后，如果下线pod序号还在[0, .spec.replicas)内，pod被当成一个下线pod对待。
如果不在[0, .spec.replicas)内，pod会被杀掉。这样做的考虑是

如果pod序号不在[0, .spec.replicas)内，那就是一个非法序号，自然也不是一个下线pod序号了。所以应该按照正常statefulset 管理pod逻辑删除。
假设跳过非法pod的话不处理的话，就会出现 OFFLINED > DESIRED 的情形。比如缩容至.spec.replicas=0，如果还保留下线pod，就会有OFFLINED > DESIRED，这是非常不合理的，因为任何情况下下线pod数量属于从 DESIRED 的pod中衍生出的。

statefulset扩容

扩容后，如果下线pod序号还在[0, .spec.replicas)内，pod被当成一个下线pod对待。

如果不在[0, .spec.replicas)内，则不认为是一个下线pod序号。

pvc/pv

下线的pod创建的pv/pvc不会被删除，pod重新上线还能访问到旧的pv/pvc数据，即便下线pod被删除，重新上线还能访问到pv数据。
因为pv name是按照"pvc claim name – pod name" 拼接而成的，"pvc claim name"来自statefulset不会变，同一个pod序号不变，那么"pod name"也不会变。所以对同一个pod而言，上线后下线前"pvc name" 不会变，而下线不会删除pvc/pv，pod重新上线后同一个pvc绑定到之前的pv. 从而访问到原来的数据。