Kubernetes - API

Kubernetes API 是系统声明式配置模式的基石。Kubectl 命令行工具可用于创建、更新、删除和获取 API 对象。Kubernetes API 充当 Kubernetes 不同组件之间的通信桥梁。

向 Kubernetes 添加 API

向 Kubernetes 添加新的 API 将为 Kubernetes 增加新功能，从而提升 Kubernetes 的功能性。然而，这也会增加系统的成本和维护难度。为了在成本和复杂性之间取得平衡，定义了几套规则。

所添加的 API 应至少对 50% 以上的用户有用。在 Kubernetes 中没有其他方式实现该功能。在 Kubernetes 社区会议上讨论特殊情况，然后添加 API。

API 变更

为了提升 Kubernetes 的能力，系统会持续引入变更。这是 Kubernetes 团队在不移除或影响现有系统功能的前提下添加新功能所做的。

为了演示一般流程，这里是一个（假设的）示例 −

• 用户向 /api/v7beta1/... POST 一个 Pod 对象

• JSON 被反序列化为 v7beta1.Pod 结构

• 对 v7beta1.Pod 应用默认值

• v7beta1.Pod 被转换为 api.Pod 结构

• 验证 api.Pod，并将任何错误返回给用户

• api.Pod 被转换为 v6.Pod（因为 v6 是最新的稳定版本）

• v6.Pod 被序列化为 JSON 并写入 etcd

现在 Pod 对象已存储，用户可以通过任何支持的 API 版本 GET 该对象。例如 −

• 用户从 /api/v5/... GET Pod

• 从 etcd 读取 JSON 并 反序列化 为 v6.Pod 结构

• 对 v6.Pod 应用默认值

• v6.Pod 被转换为 api.Pod 结构

• api.Pod 被转换为 v5.Pod 结构

• v5.Pod 被序列化为 JSON 并发送给用户

此流程的含义是，API 变更必须小心进行，并保持向后兼容。

API 版本控制

为了更容易支持多种结构，Kubernetes 支持多个 API 版本，每个版本位于不同的 API 路径，例如 /api/v1 或 /apsi/extensions/v1beta1。

Kubernetes 的版本控制标准定义在多个标准中。

Alpha 级别

• 此版本包含 alpha（例如 v1alpha1）

• 此版本可能存在 bug；启用的版本可能有 bug

• 对 bug 的支持可能随时被放弃。

• 建议仅用于短期测试，因为支持可能并非始终存在。

Beta 级别

• 版本名称包含 beta（例如 v2beta3）

• 代码已完全测试，启用的版本应是稳定的。

• 不会放弃该功能的 支持；可能会有一些小的变更。

• 由于后续版本可能存在不兼容变更，建议仅用于非业务关键用途。

Stable 级别

• 版本名称为 vX，其中 X 是一个整数。

• 稳定版本的功能将在后续多个版本的发布软件中出现。