![]()
KusionStack 团队很高兴地宣布 Operating v0.5.0 版本发布啦！本次版本主要更新了以下几个功能：- CollaSet byPartition 更新策略中 partition 字段含义变更；
- CollaSet 支持同时推进副本变更与应用发布；
- CollaSet 新增 OperationDelaySeconds 字段支持 Pod 变更前等待；
您可以从 Github 查看本次发布信息，或者按照 KusionStack 官方网站指引完成安装来体验这个版本：
- https://github.com/KusionStack/operating/releases/tag/v0.5.0
- https://www.kusionstack.io/operating/started/install
CollaSet byPartition 更新策略中 partition 字段含义变更
Operating v0.4.0 版本及以前 CollaSet byPartition 更新策略中 partition 代表发布时新版本数量。为了与社区主流 workload 中的 partition 语义保持一致，自 operating v0.5.0 版本起这个字段含义变更为表示保留的老版本数量。更新后，partition 默认值是 0，即更新全部副本，不保留老版本。用户可以通过将 partition 的值从全量的副本数逐渐缩减至 0 控制老版本数量，进而控制发布进度。但注意在发布的过程中，暂不支持使用该字段进行回滚，即增大 partition 不会改变已发布的副本状态。在如下所示的发布示例中，会保留 2 个副本的 pod 停留在 1.24 版本，将 1 个副本的 pod 升级到 1.25 版本。apiVersion: apps.kusionstack.io/v1alpha1kind: CollaSetmetadata: name: collaset-samplespec: replicas: 3 template: ... spec: containers: - image: nginx:1.25 # changed from nginx:1.24 ... updateStrategy: rollingUpdate: byPartition: partition: 2
Operating v0.4.0 版本及以前，若用户使用 CollaSet 同时发起副本变更和应用发布，则发布需等待 Pod 副本数拉齐后才会执行，这在一定程度上限制了 CollaSet 管理 Pod 的灵活性。另外在副本保持失败的情况下，会阻塞应用的发布。例如由于 Quota 资源不足会导致 Pod 副本数迟迟无法拉齐，进而阻塞后续的Pod 发布流程。在 v0.5.0 版本后，用户使用 CollaSet 同时发起 Pod 扩缩容与发布时，两个变更动作可同步推进。举个例子：v1 版本中 CollaSet 副本数为 2。在升级到 v2 的过程中，用户希望将 CollaSet 的副本数扩容到 3，同时保留 1 个副本的 v1 版本 Pod。在 v0.4.0 及以前的版本中，调和逻辑会优先执行扩容的动作，在扩容全部完成后再对已存在的 pod 执行原地升级操作。这样的处理逻辑除了会使得整个调和完成的时间延长外，在 Pod3 因为一些原因无法创建成功时，也会阻塞 Pod2 的升级操作。在 v0.5.0 的调和逻辑中，我们将原来串行的处理模式修改为并行，会同时执行 Pod3 的创建以及 Pod2 的原地升级操作。两个操作相互独立，对于应用发布过程中效率的提升和错误的容忍都有了很好的优化。CollaSet 新增 operationDelay-Seconds 字段支持 Pod 变更前等待
在 Operating 中，PodOpsLifecycle 负责管理运维动作触发的 Pod 运维生命周期，涉及到缩容、更新、以及删除等运维动作。这些运维变更中涉及对容器的删除或重启操作，若流量摘除后直接删除容器会发生长连接请求无响应等情况。例如，在大语言模型的场景下，一个推理长连接可能需要保持数分钟，直到流式的结果计算推送完成后，这个 长连接才可以被安全的关闭。此时期望摘除流量后，等待一段时间再删除容器，方便容器应用处理剩余的长连接请求。在 v0.5.0 版本 CollaSet 支持通过配置 operationDelaySeconds 控制 Pod 运维变更流量摘除完成后，容器关停之前，添加一段等待时间，以便应用能有足够的时间处理长连接中的剩余请求。在用户程序没有配置针对 SIGTERM 信号的处理逻辑时，operationDelaySeconds 可以起到与 pod 上的 terminationGracePeriodSeconds 类似的作用。不过更方便的是，由于仅配置在 CollaSet 的 Spec 上，在进行修改时，不会触发到 pod 的重启或重建动作，可以减少运维参数调整对于服务可用性的影响。如果 operationDelaySeconds 与 terminationGracePeriodSecond 两个字段同时被配置，在摘流成功后，用户程序最多可能需要等待 (operationDelaySeconds + terminationGracePeriodSeconds) 之后才会被强制删除。
在 Kubernetes 中，不同类型的资源之间存在拓扑关联关系。前序资源通过 labelSelector，name reference 等方式来表明对于后序资源的依赖关系。如 Service 通过 labelSelector 选中 Pod，Pod 通过 volume name 选中 PersistentVolume。在这两类型关系中，Service/Pod 为前序资源，Pod/PersistentVolume 为后序资源。在这种关系的正向处理逻辑会相对简单，但在一些反向的处理逻辑中（如 pod 的状态变更会影响 service/工作负载 的状态），一般只能通过轮询或者遍历前序资源这样相对笨拙的办法来处理解决。在 Operating 的调和逻辑和可洞察框架（Coming Soon～）的编写中，都需要处理一些这样的关系反向查询的需求。为了将这些拓扑处理逻辑和调和逻辑解耦，我们在 KusionStack 的通用工具项目中开发了资源拓扑(Resource Topology) 工具来处理这样场景。核心的功能点包括：
● 拓扑关系的配置、发现与查询；
● 支持注入针对拓扑节点和拓扑关系的变更时的钩子函数；● 单个节点的变更会通知到拓扑图上与之有关系的所有节点；对于资源拓扑工具的使用姿势与实现细节感兴趣的小伙伴可以查看：https://github.com/KusionStack/kube-utils/blob/main/resourcetopo/README.md
- 修复了删除 CollaSet 时在特定场景会有关联资源遗留的问题；
- 修复了 Pod 被多个 Controller 运维时 PodOpsLifeCycle 卡在流量挂载阶段的问题；
感谢所有 KusionStack 用户和社区小伙伴在此次版本更新过程中提出的宝贵反馈与意见，更多其它资源请参考：- 项目 GitHub 网站：https://github.com/KusionStack/operating
- KusionStack 官网：https://www.kusionstack.io/operating/introduction/
https://github.com/KusionStack/kusionhttps://github.com/KusionStack/operatinghttps://github.com/KusionStack/resourceconsisthttps://github.com/KusionStack/controller-meshhttps://github.com/KusionStack/konfighttps://github.com/kcl-lang/kcl
文章转载自规模化云原生运维。点击这里阅读原文了解更多。
![]()
![]()
联系Linux Foundation APAC
Linux基金会是非营利性组织，是技术生态系统的重要组成部分。
Linux基金会通过提供财务和智力资源、基础设施、服务、活动以及培训来支持创建永续开源生态系统。在共享技术的创建中，Linux基金会及其项目通过共同努力形成了非凡成功的投资。请关注LFAPAC（Linux Foundation APAC）微信公众号。
