Kubernetes – API

Kubernetes – API


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

将 API 添加到 Kubernetes

向 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(例如 v1alpha1)

  • 这个版本可能有问题;启用的版本可能有错误

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

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

测试级别

  • 版本名称包含 beta(例如 v2beta3)

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

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

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

稳定水平

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

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

觉得文章有用?

点个广告表达一下你的爱意吧 !😁