kubernetes应用构建的演进

阶段1: 原始阶段（v0.2~v0.9.3）

这一阶段没有采用任何应用构建框架，应用构建也没有层次，各组件的构建方式也不统一。

v0.2~v0.4.4： apiserver的main文件集成了组件启动的所有核心逻辑，随着集成功能的增多，main文件的维护越来越困难。另外，controller-manager将服务启动的核心代码放在/pkg目录下，这种不一致也增加了维护成本。

v0.5.1~v0.9.3： 统一cmd/下各组件的构建方式。保持规范和统一，有利于降低大型项目的维护成本；对组件名也做了规范化处理。

阶段2: 精简main文件（v0.10.0~v0.11.0）

这一阶段最大的变化是将很多实现细节从main文件中剥离，并继续保持组件构建范式的统一。

v0.10.0~v0.11.0： 将功能实现的细节剥离出main文件，例如github.com/kubernetes/... ，只有40行左右；另外，将日志和版本功能也统一起来；

阶段3: 应用代码分离（v0.12.0~v1.1.8）

在cmd/目录下新增了app目录，应用初始化、启动等核心代码迁移到该目录下。以kube-apiserver为例：

cmd/
|------ kube-apiserver/
|   |------ apiserver.go
|   └── app/
|        |------ plugins.go
|        └── server.go

并且Kubernetes应用构建开始采用分层设计：

• main入口层：/cmd/kube-apiservrer；
• 应用框架层：cmd/kube-apiserver/app。主要负责应用的命令行参数设置、应用初始化和启动等，不会涉及具体的功能代码；
• 业务层：应用功能的实现代码。

在v0.18.0及之后的版本中，Kubernetes开始自动生成代码，这些代码目录以gen开头，而不仅限于之前版本的文档生成。

阶段4: 命令行参数剥离（v1.2.0~v1.9.11）

该阶段，主要有2大变化：

• 剥离命令行参数设置代码，移至cmd/xxx/app/options目录下。如下所示：
• 引入动态配置功能。通过配置文件，降低组件启动时命令行参数过多导致的阅读、维护和分发成本。v1.2.0引入KubeletConfiguration资源对象，并借助现有机制，实现了配置文件变更和kubelet组件的快速重启。

阶段5: 应用构建框架化（v1.10.0～v1.28.3）

直接复用了 cobra 框架的能力，通过 cobra 框架来构建并启动应用。

稳定后的应用构建模型

Kubernetes应用构建模型根据代码功能，可分为两部分：

• 应用构建（控制面）： 用来构建 Kubernetes 组件，并启动服务。其中，main入口层位于cmd/kube-xxx/xxx.go，而应用构建的具体代码实现位于cmd/kube-xxx/app目录下；
• 业务功能实现（数据流）： Kubernetes 组件功能的具体业务代码实现。更具体地，可以进一步划分如下：
  • 命令行参数设置。在cmd/kube-xxx/app/options目录下，包括实例创建options、补全completion、和验证validation。
  • 应用初始化。主要包括服务的初始化和业务初始化；
  • 服务初始化。主要涉及应用框架的初始化和命令行参数的设置。以APIServer为例，见cmd/kube-xxx/app/server.go中的NewAPIServerCommand()；
  • 业务初始化。跟业务相关的代码初始化，如数据库创建、API 路由初始化、认证授权功能初始化、服务实例的创建和启动等。以APIServer为例，见cmd/kube-xxx/app/server.go中的Run()。

总结