概述
K8S的控制平面(Control Plane)的核心是API服务器(API server)。API服务器公开一个HTTP API，允许终端用户、集群的不同部分和外部组件相互通信。
Kubernetes API允许您查询和操作Kubernetes中API对象的状态(例如:Pods、Namespaces、ConfigMaps和Events)。
大部分操作都可以通过 kubectl 命令行接口或 类似 kubeadm 这类命令行工具来执行， 这些工具在背后也是调用 API。不过，你也可以使用 REST 调用来访问这些 API。
Kubernetes实现了一种基于Protobuf的序列化格式，主要用于集群内部通信。
OpenAPI 规范
使用OpenAPI记录完整的API细节。
Kubernetes API服务器通过/OpenAPI/v2端点提供OpenAPI规范。您可以使用请求头请求响应格式如下:
|Header|可选值|说明|
|---|---|---|
|Accept-Encoding|gzip|不指定此头部也是可以的|
|Accept|application/com.github.proto-openapi.spec.v2@v1.0+protobuf|主要用于集群内部使用|
|Accept|application/json|默认值|
|Accept|*|提供 application/json|
持久化
Kubernetes通过将对象写入etcd来存储它们的序列化状态。
API组和版本控制
为了简化删除字段或者重构资源表示等工作，Kubernetes 支持多个 API 版本， 每一个版本都在不同 API 路径下，例如 /api/v1 或 /apis/rbac.authorization.k8s.io/v1alpha1。
版本控制是在API级别而不是在资源或字段级别完成的，以确保API对系统资源和行为呈现一个清晰、一致的视图，并支持对生命周期结束和/或实验API的访问控制。
为了更容易地发展和扩展它的API, Kubernetes实现了可以启用或禁用的API组。
API资源通过API组、资源类型、命名空间(用于命名空间资源)和名称进行区分。API服务器透明地处理API版本之间的转换:所有不同版本实际上是相同持久化数据的表示。API服务器可以通过多个API版本提供相同的底层数据。
例如，假设同一个资源有两个API版本，v1和v1beta1。如果您最初使用其API的v1beta1版本创建了一个对象，那么您以后可以使用v1beta1或v1 API版本读取、更新或删除该对象。
API变更
任何成功的系统都需要随着新的用例出现或现有的用例发生变化而成长和变化。因此，Kubernetes设计了Kubernetes API来不断变化和增长。Kubernetes项目的目标是不破坏与现有客户端的兼容性，并在一段时间内保持这种兼容性，以便其他项目有机会适应。
通常，可以经常添加新的API资源和新的资源字段。删除资源或字段需要遵循API弃用策略。
Kubernetes坚定地承诺，一旦正式的Kubernetes API达到通用可用性(GA)(通常是API v1版本)，就会维护它们的兼容性。此外，Kubernetes在任何可行的情况下都保持了对beta API版本的兼容性:如果您采用了beta API，您可以继续使用该API与集群进行交互，甚至在特性稳定之后。
注意:尽管Kubernetes也致力于维护alpha api版本的兼容性，但在某些情况下这是不可能的。如果您使用的是任何alpha API版本，那么在升级集群时，请检查Kubernetes的发布说明，以防API发生变化。
扩展API
Kubernetes API可以通过以下两种方式之一进行扩展:
1.自定义资源(Custom resources)让您可以声明地定义API服务器应该如何提供所选择的资源API。
2.您还可以通过实现聚合层(Aggregation Layer)来扩展Kubernetes API。
易用性
| CRD | 聚合 API |
|---|---|
| 无需编程。用户可选择任何语言来实现 CRD 控制器。 | 需要使用 Go 来编程，并构建可执行文件和镜像。 |
| 无需额外运行服务；CRD 由 API 服务器处理。 | 需要额外创建服务，且该服务可能失效。 |
| 一旦 CRD 被创建，不需要持续提供支持。Kubernetes 主控节点升级过程中自动会带入缺陷修复。 | 可能需要周期性地从上游提取缺陷修复并更新聚合 API 服务器。 |
| 无需处理 API 的多个版本；例如，当你控制资源的客户端时，你可以更新它使之与 API 同步 | 你需要处理 API 的多个版本；例如，在开发打算与很多人共享的扩展时。 |
总结
K8S控制面板的核心实现是由API Service完成，当不满足需求时可通过扩展API来完善功能，通常有2种方式，Custom resources和Aggregation Layer，一般来说Custom resources要与Custom controllers结合使用才能变成一个真正的declarative API(声明式API)。Operator模式 是一个Customer controllers和Custom resources结合的例子。它可以允许开发者将特殊应用编码至kubernetes的扩展API内。