Kubernetes API
Kubernetes 控制面 的核心是 API 服务器。 API 服务器负责提供 HTTP API，以供用户、集群中的不同部分和集群外部组件相互通信。
Kubernetes API 使你可以查询和操纵 Kubernetes API 中对象（例如：Pod、Namespace、ConfigMap 和 Event）的状态。
大部分操作都可以通过 kubectl 命令行接口或 类似 kubeadm 这类命令行工具来执行， 这些工具在背后也是调用 API。不过，你也可以使用 REST 调用来访问这些 API。
如果你正在编写程序来访问 Kubernetes API，可以考虑使用 客户端库之一。
OpenAPI 规范
完整的 API 细节是用 OpenAPI 来表述的。
Kubernetes API 服务器通过 /openapi/v2 末端提供 OpenAPI 规范。
你可以按照下表所给的请求头部，指定响应的格式：
| 头部 | 可选值 | 说明 |
|---|---|---|
Accept-Encoding |
gzip |
不指定此头部也是可以的 |
Accept |
application/[email protected]+protobuf |
主要用于集群内部 |
application/json |
默认值 | |
* |
提供application/json |
Kubernetes 为 API 实现了一种基于 Protobuf 的序列化格式，主要用于集群内部通信。 关于此格式的详细信息，可参考 Kubernetes Protobuf 序列化 设计提案。每种模式对应的接口描述语言（IDL）位于定义 API 对象的 Go 包中。
API 变更
任何成功的系统都要随着新的使用案例的出现和现有案例的变化来成长和变化。 为此，Kubernetes 的功能特性设计考虑了让 Kubernetes API 能够持续变更和成长的因素。 Kubernetes 项目的目标是 不要 引发现有客户端的兼容性问题，并在一定的时期内 维持这种兼容性，以便其他项目有机会作出适应性变更。
一般而言，新的 API 资源和新的资源字段可以被频繁地添加进来。 删除资源或者字段则要遵从 API 废弃策略。
关于什么是兼容性的变更、如何变更 API 等详细信息，可参考 API 变更。
API 组和版本
为了简化删除字段或者重构资源表示等工作，Kubernetes 支持多个 API 版本，
每一个版本都在不同 API 路径下，例如 /api/v1 或
/apis/rbac.authorization.k8s.io/v1alpha1。
版本化是在 API 级别而不是在资源或字段级别进行的，目的是为了确保 API 为系统资源和行为提供清晰、一致的视图，并能够控制对已废止的和/或实验性 API 的访问。
为了便于演化和扩展其 API，Kubernetes 实现了 可被启用或禁用的 API 组。
API 资源之间靠 API 组、资源类型、名字空间（对于名字空间作用域的资源而言）和
名字来相互区分。API 服务器可能通过多个 API 版本来向外提供相同的下层数据，
并透明地完成不同 API 版本之间的转换。所有这些不同的版本实际上都是同一资源
的（不同）表现形式。例如，假定同一资源有 v1 和 v1beta1 版本，
使用 v1beta1 创建的对象则可以使用 v1beta1 或者 v1 版本来读取、更改
或者删除。
关于 API 版本级别的详细定义，请参阅 API 版本参考。
API 扩展
有两种途径来扩展 Kubernetes API：
接下来
- 了解如何通过添加你自己的 CustomResourceDefinition 来扩展 Kubernetes API。
- 控制 Kubernetes API 访问 页面描述了集群如何针对 API 访问管理身份认证和鉴权。
- 通过阅读 API 参考 了解 API 端点、资源类型以及示例。