Kubernetes 简明教程

Kubernetes - API

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

Kubernetes API serves as a foundation for declarative configuration schema for the system. Kubectl command-line tool can be used to create, update, delete, and get API object. Kubernetes API acts a communicator among different components of Kubernetes.

Adding API to Kubernetes

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

Adding a new API to Kubernetes will add new features to Kubernetes, which will increase the functionality of Kubernetes. However, alongside it will also increase the cost and maintainability of the system. In order to create a balance between the cost and complexity, there are a few sets defined for it.

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

The API which is getting added should be useful to more than 50% of the users. There is no other way to implement the functionality in Kubernetes. Exceptional circumstances are discussed in the community meeting of Kubernetes, and then API is added.

API Changes

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

In order to increase the capability of Kubernetes, changes are continuously introduced to the system. It is done by Kubernetes team to add the functionality to Kubernetes without removing or impacting the existing functionality of the system.

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

To demonstrate the general process, here is an (hypothetical) example −

  1. A user POSTs a Pod object to /api/v7beta1/…​

  2. The JSON is unmarshalled into a v7beta1.Pod structure

  3. Default values are applied to the v7beta1.Pod

  4. The v7beta1.Pod is converted to an api.Pod structure

  5. The api.Pod is validated, and any errors are returned to the user

  6. The api.Pod is converted to a v6.Pod (because v6 is the latest stable version)

  7. The v6.Pod is marshalled into JSON and written to etcd

现在当 Pod 对象存储后，用户可以在任何受支持的 API 版本中获取该对象。例如 −

Now that we have the Pod object stored, a user can GET that object in any supported API version. For example −

  1. A user GETs the Pod from /api/v5/…​

  2. The JSON is read from etcd and unmarshalled into a v6.Pod structure

  3. Default values are applied to the v6.Pod

  4. The v6.Pod is converted to an api.Pod structure

  5. The api.Pod is converted to a v5.Pod structure

  6. The v5.Pod is marshalled into JSON and sent to the user

此流程的含义是必须小心谨慎地进行 API 更改，并做好向后兼容。

The implication of this process is that API changes must be done carefully and backward compatibly.

API Versioning

为了更轻松地支持多个结构，Kubernetes 支持在不同 API 路径（例如 /api/v1 或 /apsi/extensions/v1beta1 ）上的多个 API 版本

To make it easier to support multiple structures, Kubernetes supports multiple API versions each at different API path such as /api/v1 or /apsi/extensions/v1beta1

Kubernetes 的版本化标准在多个标准中进行定义。

Versioning standards at Kubernetes are defined in multiple standards.

Alpha Level

  1. This version contains alpha (e.g. v1alpha1)

  2. This version may be buggy; the enabled version may have bugs

  3. Support for bugs can be dropped at any point of time.

  4. Recommended to be used in short term testing only as the support may not be present all the time.

Beta Level

  1. The version name contains beta (e.g. v2beta3)

  2. The code is fully tested and the enabled version is supposed to be stable.

  3. The support of the feature will not be dropped; there may be some small changes.

  4. Recommended for only non-business-critical uses because of the potential for incompatible changes in subsequent releases.

Stable Level

  1. The version name is vX where X is an integer.

  2. Stable versions of features will appear in the released software for many subsequent versions.