如何在 K8s 中实现 Pod 原地更新？

背景

正如在“指定实例下线”特性介绍里所述，早期的版本中，KubeBlocks 最终生成的 Workload 是 StatefulSet，这导致 KubeBlocks 继承了 StatefulSet 的局限性。

另一个局限性是，StatefulSet 通过 PodTemplate 渲染最终的 Pod，当 PodTemplate 中有任何字段发生了改变，都会导致所有 Pod 被更新，而 StatefulSet 采用的更新方式是 Recreate，即首先删除现有的 Pod，然后再新建一个 Pod。对于数据库等对可用性要求很高的系统，这样的方式显然不是最佳选择。

为了解决这个问题，KubeBlocks 从 0.9 版本开始，使用 InstanceSet 替代了 StatefulSet，新增了实例原地更新特性，在实例模板中部分字段更新时，InstanceSet 会采用原地更新 Pod 或扩容 PVC 的方式，实现实例更新，降低实例更新时对系统可用性的影响。

实例（Instance）哪些字段支持原地更新

从原理上来讲，KubeBlocks 实例原地更新复用了 Kubernetes Pod API 原地更新能力。所以具体支持的字段如下：

• annotations
• labels
• spec.activeDeadlineSeconds
• spec.initContainers[*].image
• spec.containers[*].image
• spec.tolerations (只支持新增 Toleration)

Kubernetes 从 1.27 版本开始，通过 InPlacePodVerticalScaling 特性开关可进一步开启对 CPU 和 Memory 的原地更新支持。KubeBlocks 同样增加了 InPlacePodVerticalScaling 特性开关，以便进一步支持如下能力：

对于大于或等于 1.27 且 InPlacePodVerticalScaling 已开启的 Kubernetes，支持如下字段的原地更新：

• spec.containers[*].resources.requests["cpu"]
• spec.containers[*].resources.requests["memory"]
• spec.containers[*].resources.limits["cpu"]
• spec.containers[*].resources.limits["memory"]

需要注意的是，当 resource resize 成功后，有的应用可能需要重启才能感知到新的资源配置，此时需要在 ClusterDefinition 或 ComponentDefinition 中进一步配置 container restartPolicy。

对于 PVC，KubeBlocks 同样复用 PVC API 的能力，仅支持 Volume 的扩容，当因为某些原因扩容失败时，支持缩容回原来的容量值。而 StatefulSet 中的 VolumeClaimTemplate 一经声明，便不能修改，目前官方正在开发相关能力，但至少需要等到 K8s 1.32 版本了。

从上层 API 视角，哪些字段更新后使用的是原地更新

KubeBlocks 跟实例相关的上层 API 包括 Cluster、ClusterDefinition、ClusterVersion、ComponentDefinition 和 ComponentVersion。这些 API 中有若干字段最终会直接或间接用来渲染实例对象，从而可能会触发实例原地更新。

这些字段非常多，这里对这些字段进行罗列和简单描述（注：API 中标记为 deprecated 的字段不在列表内，immutable 的字段不在列表内）。

所属 API	字段名称	说明
Cluster	annotations, labels, spec.tolerations, spec.componentSpecs[*].serviceVersion, spec.componentSpecs[*].tolerations, spec.componentSpecs[*].resources, spec.componentSpecs[*].volumeClaimTemplates, spec.componentSpecs[*].instances[*].annotations, spec.componentSpecs[*].instances[*].labels, spec.componentSpecs[*].instances[*].image, spec.componentSpecs[*].instances[*].tolerations, spec.componentSpecs[*].instances[*].resources, spec.componentSpecs[*].instances[*].volumeClaimTemplates, spec.shardingSpecs[*].template.serviceVersion, spec.shardingSpecs[*].template.tolerations, spec.shardingSpecs[*].template.resources, spec.shardingSpecs[*].template.volumeClaimTemplates	Resources 相关字段都指的是: requests["cpu"], requests["memory"], limits["cpu"], limits["memory"]
ComponentVersion	spec.releases[*].images	可能会触发实例原地更新，或不触发。取决于最终匹配的 Image 是否有变化。
KubeBlocks 内置	annotations, labels

IgnorePodVerticalScaling 特性开关

Resources 的原地更新一直以来有比较强的需求，在低于 1.27 版本的 Kubernetes 中，我们可以看到很多 Kubernetes 的发行版中支持了 Resources 的原地更新能力，不同的发行版可能采用了不同的方案去实现这一特性。

为了兼容这些 Kubernetes 发行版，KubeBlocks 中增加了 IgnorePodVerticalScaling 特性开关。当该特性打开后，KubeBlocks 在做实例更新时，会忽略 Resources 中 CPU 和 Memory 的更新，从而使得最终渲染的 Pod 的 Resources 跟当前在运行 Pod 的 Resources 配置保持一致。

End

KubeBlocks 已发布 v0.9.0！KubeBlocks v0.9.0 全面升级了 API，构建一个 Cluster 更像是在用 Component “搭积木”！新增 topologies 字段，支持多种部署形态。InstanceSet 代替了 StatefulSet 来管理 Pods，支持将指定的 Pod 下线、Pod 原地更新，同时也支持数据库主从架构里主库和从库采用不同的 Pod spec。v0.9.0 还新增了 Reids 集群模式（分片模式），系统的容量、性能以及可用性显著提升！还支持了 MySQL 主备，资源的要求更少，数据复制的开销也更小！快来试试看！

小猿姐诚邀各位体验 KubeBlocks，也欢迎您成为产品的使用者和项目的贡献者。跟我们一起构建云原生数据基础设施吧！

💻 官网: www.kubeblocks.io

🌟 GitHub: https://github.com/apecloud/kubeblocks

🚀 Get started: https://cn.kubeblocks.io/docs/preview/user-docs/try-out-on-pl...

☁️ Cloud 试用：https://console.apecloud.cn/

关注小猿姐，一起学习更多云原生技术干货。