Kubernetes - API

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

向 Kubernetes 添加 API

向 Kubernetes 添加新的 API 将为 Kubernetes 添加新功能，从而增强 Kubernetes 的功能。但是，与此同时，它也会增加系统的成本和可维护性。为了在成本和复杂性之间取得平衡，为此定义了几套规则。

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

API 更改

为了增强 Kubernetes 的能力，系统会不断引入更改。Kubernetes 团队这样做是为了向 Kubernetes 添加功能，而不会删除或影响系统的现有功能。

为了演示一般过程，这里有一个（假设的）示例：

• 用户将 Pod 对象 POST 到 /api/v7beta1/...

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

• 将默认值应用于 v7beta1.Pod

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

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

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

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

现在我们已经存储了 Pod 对象，用户可以使用任何受支持的 API 版本获取该对象。例如：

• 用户从 /api/v5/... 获取 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）

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

• 不会取消对该功能的支持；可能会有少量更改。

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

稳定级别

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

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