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/下各组件的构建方式。保持规范和统一，有利于降低大型项目的维护成本；对组件名也做了规范化处理。

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

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

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

go 复制代码

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

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

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

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

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

直接复用了 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()。