伴随着云原生技术在越来越多的企业落地,如今的 Kubernetes 和容器已经完全进入主流市场,成为云计算的新界面,帮助企业充分享受云原生的优势,加速应用迭代创新效率,降低开发运维成本。但在向着云原生架构转型的过程中,也有许多问题需要被解决。比如原生 Kubernetes 的复杂性、容器化应用的生命周期管理,以及向以容器为基础设施迁移的过程中可能出现的服务稳定性挑战等等。
开源云原生应用发布组件 Triton 的出现,就是为了解决企业应用在容器化过程中安全落地生产的问题。Triton 以 OpenKruise 作为容器应用自动化引擎,实现应用负载的扩展增强能力,为原有持续交付系统带来全面升级,不仅解决了应用生命周期管理的问题,包括开发、部署、运维等,同时打通微服务治理,可以帮助研发提升持续交付的效率。
有关 Trion 设计方案、实现原理的详细介绍可以参考这篇文章。本文将从源码级安装、debug、demo 应用发布演示三个方面介绍 Triton 的核心特性以及 Triton 的快速上手使用、开发,最后介绍 Triton 的 Roadmap。由于时间关系,一键安装、Helm 安装的方式正在开发中,会在正式版本 release 中提供。
可以看到我们本次发布的应用名字是 12122-sample-10010
,副本数量是 3,批次大小是 1,有一个金丝雀批次,批次大小是 1,发布的模式是 auto,意味着本次发布只会在金丝雀批次和普通批次之间暂停,后续两个批次会以 batchIntervalSeconds
为时间间隔自动触发。
可以看到我们创建出一个名为 12122-sample-10010-df
的 DeployFlow 资源,通过展示的字段了解到本次发布分为 3 个批次,当前批次的大小是 1,已升级和已完成的副本数量都是 0。
可以看到目前在启动的是 canary
批次,该批次已经处于 smoked
阶段,该批次中的 pod 是 12122-sample-10010-2mwkt
,同时也能看到当前批次中 pod 的拉入状态、拉入时间等信息。
从显示的结果来看,pod 12122-sample-10010-2mwkt
并没有出现在 Service 的 Endpoints
中,意味着当前应用没有正式接入流量:
接下来我们执行拉入操作(Bake),对应 pod 的状态会从 ContainerReady
变为 Ready
,从而被挂载到对应 Service 的 Endpoints 上开始正式接入流量:
再次检查 DeployFlow,Service,CloneSet 的状态后,发现 Pod 已被挂载到 Endpoints,DeployFlow 的 UPDATED_READY_REPLICAS
字段变为 1,金丝雀批次进入 baking
阶段,如果此时应用正常工作,我们再次执行上面的 Next
操作,将 DeployFlow 置为 baked
阶段,表示本批次点火成功,应用流量正常。
金丝雀批次到达 baked
阶段后,执行 Next
操作就会进入后面的普通批次发布,由于我们应用的副本数量设置为 3,去掉金丝雀批次中的一个副本后,还剩 2 个,而 batchSize 的大小为 1,所有剩余的普通批次会分两个批次发布,两个批次之间会间隔 10s 触发。
同样可以使用 auto
或 mannual
模式划分多个批次来执行扩缩容操作。 当一个 CloneSet 缩容时,有时用户倾向于删除特定的 Pod,可以使用 podsToDelete 字段实现指定 Pod 缩容:
CloneSet 被缩容为 2 个副本,被缩容的 Pod 正是指定的那个。该功能的实现得益于 OpenKruise 中增强型无状态 workload CloneSet 提供的能力,具体的功能描述可以参考 OpenKruise 文档。
1 | { |
上面演示的就是 Triton 提供的核心能力。对于基础团队来说,Triton 不仅仅是一个开源项目,它也是一个真实的比较接地气的云原生持续交付项目。通过开源,我们希望 Triton 能丰富云原生社区的持续交付工具体系,为更多开发者和企业搭建云原生化的 PaaS 平台助力,提供一种现代的、高效的的技术方案。
欢迎大家向 Triton 提交 issue 和 PR 共建 Triton 社区。我们诚心期待更多的开发者加入,也期待 Triton 能够助力越来越多的企业快速构建云原生持续交付平台。如果有企业或者用户感兴趣,我们可以提供专项技术支持和交流,欢迎入群咨询。