首页 > 云计算 > Docker/K8 > 如何在 K8s 中实现 Pod 原地更新?
正如在 “指定实例下线”特性介绍里所述,早期的版本中,KubeBlocks 最终生成的 Workload 是 StatefulSet,这导致 KubeBlocks 继承了 StatefulSet 的局限性。
另一个局限性是,StatefulSet 通过 PodTemplate 渲染最终的 Pod,当 PodTemplate 中有任何字段发生了改变,都会导致所有 Pod 被更新,而 StatefulSet 采用的更新方式是 Recreate,即首先删除现有的 Pod,然后再新建一个 Pod。对于数据库等对可用性要求很高的系统,这样的方式显然不是最佳选择。
为了解决这个问题,KubeBlocks 从 0.9 版本开始,使用 InstanceSet 替代了 StatefulSet,新增了 实例原地更新特性,在实例模板中部分字段更新时,InstanceSet 会采用 原地更新 Pod 或扩容 PVC 的方式,实现实例更新, 降低实例更新时对系统可用性的影响。
从原理上来讲,KubeBlocks 实例原地更新复用了 Kubernetes Pod API 原地更新能力。所以具体支持的字段如下:
annotationslabelsspec.activeDeadlineSecondsspec.initContainers[*].imagespec.containers[*].imagespec.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 版本了。
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 |
|
Resources 的原地更新一直以来有比较强的需求,在低于 1.27 版本的 Kubernetes 中,我们可以看到很多 Kubernetes 的发行版中支持了 Resources 的原地更新能力,不同的发行版可能采用了不同的方案去实现这一特性。
为了兼容这些 Kubernetes 发行版,KubeBlocks 中增加了
IgnorePodVerticalScaling 特性开关。当该特性打开后,KubeBlocks 在做实例更新时,会忽略 Resources 中 CPU 和 Memory 的更新,从而使得最终渲染的 Pod 的 Resources 跟当前在运行 Pod 的 Resources 配置保持一致。
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,也欢迎您成为产品的使用者和项目的贡献者。跟我们一起构建云原生数据基础设施吧!
💻 官网:
🌟 GitHub: https://github.com/apecloud/kubeblocks
🚀 Get started: https://cn.kubeblocks.io/docs/preview/user-docs/try-out-on-playground/try-kubeblocks-on-local-host
☁️ Cloud 试用:https://console.apecloud.cn/
关注小猿姐,一起学习更多云原生技术干货。
来自 “ ITPUB博客 ” ,链接:https://blog.itpub.net/70035809/viewspace-3024500/ ,如需转载,请注明出处,否则将追究法律责任。