Kubernetes CustomResourceDefinitions 和 API server aggregation(1)

https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/

在 Kubernetes 里，Resource 也叫资源，实际上是 Kubernetes API 里的一个 Endpoint 类型，比如内置的 Pod，也是一种资源类型。Custome Resources 自定义资源是在 Kubernetes 的默认配置下，对资源类型的扩展。

实际上，自定义资源类型只是让用户可以创建和查询到资源对象，当结合 Custom Controller 自定义控制器，才能像 Kubernetes 里其他对象一样去做 CRUD 的操作。通过自定义控制器，可以控制自定义资源的生命周期。通过这种贯穿于 Kubernetes 里的控制循环的思想，可以让集群里的资源对象按照预定义的状态，不断地去调整。

在官网里提示的，有两种方式来让用户去扩展 Kubernetes 的资源类型。

1. CustomResourceDefinitions: 复用 Kubernetes 的 API Server，CRDs + CRD Controller
2. API server aggregation: 需要编写 API Server，提供更细粒度的控制

这两种方式，其实挺不好理解的。简单理解的话，就是后者需要写更多的代码，去创建自己的 API Server，这里说的 API Server 跟 Master 上的 API Server 是一个类似的概念，都不完全相同，这里的 API Server 更想表达的意思是为了实现自定义资源来扩展 Kubernetes 的功能或者说工作负荷，用户需要按照 API Server 的模式来去创建自己的 API Server，然后通过 aggregate 这一层组件来实现聚合，也就是说，用户为了增加自定义资源，并且希望注册到 Core API Server 中，是需要写更多的代码的，但是他比前者带来一个更显著的好处就是，他的灵活性是更高的，毕竟你写的是类似 Core API Server 的东西，关于资源的存储、认证这些都可以做的更加灵活。

目前社区上看到很多的 Operator 多数是基于 CustomResourceDefinitions 来做的，例如 Spark Operator，Tf Operator 等等。

Operator 的模式，是由 coreos 提出的，结合自定义资源和自定义控制器的常见套路。定义一个自定义资源并不难，甚至非常简单，也就几行 yaml，或者代码里一个 struct 结构体就完事了，真正比价麻烦的是写一个自定义控制器来控制这个自定义资源对象。