💡简介

对于GSOC中一个与我课题相关的开源项目——KRO，我感到非常好奇。
因此本文介绍了KRO（Kube Resource Orchestrator），它旨在简化Kubernetes API和资源管理，通过引入自定义资源 ResourceGraphDefinition，将Kubernetes部署及其依赖项封装到单个API中，支持自定义终端用户界面。
此外，本文简单探讨了KRO的需求、核心原理、运作方式以及性能评估课题，并分享了我在调研过程中的思路和反思。

🖼️背景

最近GSOC^[1]开始进入申请阶段了，在浏览相关组织及题目时，发现有个看起来和我的课题调度编排很相关的开源项目——KRO^[2]。因此首先特意调研一下该项目具体是用于做什么的、如何使用。
其次，具体看了看KRO今年的几个题目^[3]，和调度编排本身没什么相关，主要是做一些外围完善工作，例如指标收集、IDE集成、验证和生成测试案例、性能评估。虽然与课题相关性比较小，但可以借此机会更深入地了解kro，尤其是对于性能评估课题，感觉很适合用于深入实践和理解。因此其次是对性能评估问题进行分析，对其中关键名词进行解析。

🧠思路

调研KRO基础信息，了解用于做什么、如何使用、典型场景。
解析KRO性能评估课题。

🔨解决

KRO基础信息

KRO（Kube Resource Orchestrator，读作 “crow”）^[4,5]是一个开源项目，由谷歌云、亚马逊云科技和微软 Azure 联合。该项目试图对 Kubernetes 资源的分组和部署方式进行标准化，旨在简化 Kubernetes API 和资源管理，使平台团队可以更轻松地部署工作负载。
整体来说，确实是个很小众的项目，国内相关博客都很难找到。

需求

Kubernetes 没有提供一种可供平台团队使用的原生方法，让他们能够创建自定义资源组供开发团队使用，许多组织都是使用 Helm 或 Kustomize 等客户端模板工具，或构建自己的自定义 Kubernetes 控制器。事实证明，这些方法往往维护成本高昂，非专业人员难以有效使用。^[5]

有了 kro，你就可以将应用程序及其依赖项组合成单个资源，方便终端用户使用。
—— Abdelfettah Sghiouar 和 Nic Slattery

核心原理

Kro 的核心创新是引入了自定义资源 ResourceGraphDefinition。Kro 将 Kubernetes 部署及其依赖项都封装到了单个 API 中，支持自定义终端用户界面，仅暴露供非平台工程师使用的参数。这种屏蔽隐藏了 Kubernetes 和云提供商 API 端点的复杂性，那在部署上下文中并没有用处。（好抽象，和CRD有什么区别？）^[5]

具体来说，使用kro，可以轻松地配置新的自定义API，这些API可以创建一组Kubernetes对象以及它们之间的逻辑操作。^[4]
- kro利用CEL（通用表达式语言）进行逻辑操作，该语言与Kubernetes webhooks使用的相同语言。
- 使用CEL表达式，可以轻松地将值从一个对象传递到另一个对象，并将条件包含到您的自定义API定义中。
- 基于CEL表达式，kro自动计算创建对象的顺序。
- 可以为API规范中的字段定义默认值，简化最终用户的流程，然后最终用户可以毫不费力地调用这些自定义API来创建分组资源。
  （还得是官方文档说得清楚，简单的报道说得过于抽象了）

运作方式

开发者界面

当最终用户使用自定义API将YAML规范应用于集群时，API会在集群内创建一组资源。

这些资源可以包括原生Kubernetes资源和集群中安装的任何自定义资源定义（CRD）。
其中一些资源可能会在集群之外创建额外的资源。
如下图所示，开发人员调用自定义API，该API创建了部署、入口、服务帐户、普罗米修斯监视器、IAM角色、IAM策略和亚马逊S3桶等资源。这使得开发人员能够以标准化和简化的方式轻松管理和部署他们的应用程序。
资源图定义
当团队在集群中安装Kro时，它会安装一个名为ResourceGraphDefinition（RG）的自定义资源定义（CRD）。平台、安全和合规团队可以通过为ResourceGraphDefinition CRD定义自定义资源来协作创建自定义API。
在下图描述的示例中，平台团队创建了一个具有任意名称“应用程序堆栈”的RG，该RG封装了必要的资源，以及任何其他逻辑、抽象和安全最佳实践。当RGD应用于集群时，会创建一个新的ApplicationStack API，并可供开发人员与之交互。开发人员不再需要直接管理底层基础设施的复杂性，因为自定义API处理所需资源的部署和配置。
资源图定义实例
开发人员团队可以创建应用程序堆栈的多个实例，每个实例都根据其特定要求量身定制。
如下图所示，开发团队A和开发团队B都实例化了自己的应用程序堆栈。
虽然基础资源相似，但开发团队A选择利用Ingress选项将他们的服务暴露在外部，而开发团队B选择将他们的服务保留在集群内部。
这种灵活性允许每个开发团队根据其特定要求自定义其应用程序堆栈。

KRO性能评估课题解析

详情见下回分解～

🏥反思

由于资料较少，调研基础博客后还是没太理解KRO的意义。光看字面意思，感觉CRD完全可以替代，无法理解KRO和CRD之间有什么区别？
好在还是让自己不要偷工减料，去看了英文主页原文，发现主页已经讲得很清楚了。KRO比CRD多的是多个组件之间的逻辑串联关系。
未来会进一步调研[6]，看看具体案例中如何使用KRO；以及结合本次调研结果，进一步分析GSOC中的性能评估课题。