Kubernetes从零入门（三）：Kubernetes API--资源模型
概述
Kubernetes API 使你可以查询和操纵 Kubernetes 中对象的状态。 Kubernetes 控制平面的核心是 API 服务器和它暴露的 HTTP API。 用户、集群的不同部分以及外部组件都通过 API 服务器相互通信。
大部分操作都可以通过 kubectl 命令行接口或类似 kubeadm 这类命令行工具来执行， 这些工具在背后也是调用 API。不过，你也可以使用 REST 调用来访问这些 API。 Kubernetes 为那些希望使用 Kubernetes API 编写应用的开发者提供一组客户端库。
每个 Kubernetes 集群都会发布集群所使用的 API 规范。Kubernetes 使用两种机制来发布这些 API 规范。Discovery API和OpenAPI文档。kubectl api-resources和kubectl explain的区别就是两种API的典型应用。
Discovery API。它就像餐厅的菜单，只告诉你有哪些菜（API组/版本/资源）和基本吃法（HTTP动词），但不会详细描述每道菜的配方（字段结构）。这种设计很聪明——集群启动时资源可能动态变化（比如CRD），用轻量级API快速列举可避免客户端加载无用数据。kubectl补全功能正需要这种“目录式”查询，如果每次按tab都要下载全套OpenAPI，效率就太低了。
OpenAPI文档更像是详细的菜谱。v3版本特别重要，因为它能精确描述Kubernetes API的树状结构（比如/apps/v1/deployments），包括每个字段类型、是否必填等元数据。用户要是写Operator或者自定义控制器，绝对绕不开它——比如用kubectl explain deployment.spec.replicas时，背后就是OpenAPI在支撑。
API 组
将功能相关的 API 资源逻辑上分组，便于维护和版本控制。例如，所有与应用部署相关的资源（如 Deployment, ReplicaSet）都在 apps组里。核心组（如 Pod, Service）位于遗留的 core API 组，路径是 /api/v1。其他组路径类似 /apis/<group-name>/<version>（如 /apis/apps/v1）。
API 扩展
有两种途径来扩展 Kubernetes API：
- 你可以使用自定义资源来以声明式方式定义 API 服务器如何提供你所选择的资源 API。
- 你也可以选择实现自己的聚合层来扩展 Kubernetes API。
聚合API
是什么： 允许你将一个独立的、自己编写和部署的 API 服务器“挂载”到 Kubernetes API 的总路径下。对用户来说，这个扩展 API 看起来和内置的 Kubernetes API 一模一样（相同的端点、相同的认证/授权机制）。
适用场景： 当你的扩展功能非常复杂，或者需要特定的处理逻辑，无法通过 CRD + Controller 模式简单实现时。