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 对象发布到/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

• JSON 从etcd读取并解组为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（例如v1alpha1）

• 这个版本可能有bug；启用的版本可能有错误

• 对错误的支持可以随时取消。

• 建议仅在短期测试中使用，因为支撑可能不会一直存在。

测试版级别

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

• 代码经过全面测试，启用的版本应该是稳定的。

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

• 建议仅用于非业务关键型用途，因为后续版本中可能会出现不兼容的更改。

稳定水平

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

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