You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
在尝试更改 API 之前,您应该熟悉一些现有的 API 类型和[API 约定](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md)。如果创建新的 API 类型/资源,我们还建议您首先发送仅包含新 API 类型提案的 PR。
6
+
7
+
Kubernetes API 有两个主要组件 - 内部结构和版本化 API。版本化 API 的目的是稳定,而内部结构的实现是为了最好地反映 Kubernetes 代码本身的需求。
8
+
9
+
对于 API 更改来说,这意味着您必须在处理更改的方式上深思熟虑,并且必须接触多个部分才能做出完整的更改。本文档旨在指导您完成整个过程,但并非所有 API 更改都需要所有这些步骤。
10
+
11
+
## Operational overview
12
+
13
+
为了浏览本文档的其余部分,对 Kubernetes 中使用的 API 系统有一个深入的了解非常重要。
14
+
15
+
如上所述,API 对象的内部表示与任何一个 API 版本是解耦的。这提供了很大的自由来发展代码,但它需要强大的基础设施来在表示之间进行转换。处理 API 操作有多个步骤 - 即使像 GET 这样简单的操作也涉及大量的机制。
16
+
17
+
这个转换过程在逻辑上是一个以内部形式为中心的“星”。每个版本化 API 都可以转换为内部形式(反之亦然),但版本化 API 不会直接转换为其他版本化 API。这听起来像是一个繁重的过程,但实际上我们并不打算同时保留少量版本。虽然所有 Kubernetes 代码都在内部结构上运行,但它们在写入存储(磁盘或 etcd)或通过线路发送之前始终会转换为版本化形式。客户端应专门使用和操作版本化 API。
0 commit comments