GITBOOK-147: No subject

SUMMARY.md

@@ -48,7 +48,7 @@
   * [5.6 服务端和客户端 apply](k8s-yuan-ma-ren-cai-fu-hua-xun-lian-ying/di-wu-zhang-apimachinery/5.6-fu-wu-duan-he-ke-hu-duan-apply.md)
   * [5.7 pod 生命周期和 conditions 浅析](k8s-yuan-ma-ren-cai-fu-hua-xun-lian-ying/di-wu-zhang-apimachinery/5.7-pod-sheng-ming-zhou-qi-he-conditions-qian-xi.md)
   * [5.8 event 源码解析](k8s-yuan-ma-ren-cai-fu-hua-xun-lian-ying/di-wu-zhang-apimachinery/5.8-event-yuan-ma-jie-xi.md)
-  * [5.10 多版本和序列化](k8s-yuan-ma-ren-cai-fu-hua-xun-lian-ying/di-wu-zhang-apimachinery/5.10-duo-ban-ben-he-xu-lie-hua.md)
+  * [5.10 k8s API 组和版本控制初探](k8s-yuan-ma-ren-cai-fu-hua-xun-lian-ying/di-wu-zhang-apimachinery/5.10-k8s-api-zu-he-ban-ben-kong-zhi-chu-tan.md)
   * [5.11 Scheme 解析](k8s-yuan-ma-ren-cai-fu-hua-xun-lian-ying/di-wu-zhang-apimachinery/5.11-scheme-jie-xi.md)
   * [5.12 k8s api-changes（翻译）](k8s-yuan-ma-ren-cai-fu-hua-xun-lian-ying/di-wu-zhang-apimachinery/5.12-k8s-apichanges-fan-yi.md)
   * [5.13 序列化器与序列化器工厂](k8s-yuan-ma-ren-cai-fu-hua-xun-lian-ying/di-wu-zhang-apimachinery/5.13-xu-lie-hua-qi-yu-xu-lie-hua-qi-gong-chang.md)

k8s-yuan-ma-ren-cai-fu-hua-xun-lian-ying/di-wu-zhang-apimachinery/5.10-duo-ban-ben-he-xu-lie-hua.md → k8s-yuan-ma-ren-cai-fu-hua-xun-lian-ying/di-wu-zhang-apimachinery/5.10-k8s-api-zu-he-ban-ben-kong-zhi-chu-tan.md

@@ -1,12 +1,20 @@
-# 5.10 多版本和序列化
+# 5.10 k8s API 组和版本控制初探
 
 ## 前言
 
-Apimachinery 主要完成两个工作，多版本转换和序列化，API多版本是Kubernetes API的重要特性，它跟一般应用的多版本API还不太一样，有它自己的特色，因此搞懂它的相关概念和实现原理是相当有必要的。
+apimachinery 主要完成两个工作，多版本转换和序列化，今天我们来聊聊多版本转换，它跟一般应用的多版本还不太一样，有它自己的特色，因此搞懂它的相关概念和实现原理是相当有必要的。
 
-### 功能介绍 <a href="#gong-neng-jie-shao" id="gong-neng-jie-shao"></a>
+### API 组和版本控制 <a href="#api-groups-and-versioning" id="api-groups-and-versioning"></a>
 
-Kubernetes API多版本这个特性跟很多其他应用的多版本API很不一样，首先就是它有分组的概念，即Group，因为Kubernetes有很多的资源，不太好统一管理，所以采取分而治之的方式，以组的方式去管理，而它的多版本是跟组关联的，即一个组可以同时有多个版本，即Version，而组内的资源种类，即Kind，通过多版本的方式去迭代进化，这三者在Kubernetes中经常合起来表示某个版本的某种资源，即 `GroupVersionKind`，简称 `GVK`；其次就是多版本之间的资源对象可以互相转换，这个是什么意思呢？即底层数据是同一份数据，但是根据调用API的版本不同，可以转换成对应版本的资源对象，比如有一个资源它现在有三个版本的API同时存在：v1, v1beta1, v1beta2，你通过调用v1beta1版本的API，创建了一个该对象，那你通过v1, v1beta1, v1beta2的API，均可以将该对象读出来，或者做其他的操作，那这个特性有什么用呢？谁会去把v1beta1版本的对象转成v1版本来用呢？这是我看到这个特性时，脑海中的第一个问题，通过阅读[官方文档](https://kubernetes.io/docs/concepts/overview/kubernetes-api/#api-groups-and-versioning)可以知道，其实这个特性完全是为了保持API的兼容而设计的，正常情况下，没有人会混着版本去用，它发挥作用的地方主要在升级迭代时，要知道随着API的迭代开发，API会逐渐GA进入到稳定版本，那beta版，以及alpha版则会在某一个阶段被移除，这时候，你用beta版API创建的资源对象，仍然能够用稳定版API来操作，这样就实现了无缝升级。
+Kubernetes 支持多个 API 版本，每个版本位于不同的 API 路径， 例如 `/api/v1` 或 `/apis/rbac.authorization.k8s.io/v1alpha1`。
+
+版本控制是在 API 级别而不是在资源或字段级别完成的，以确保 API 呈现出清晰、一致的系统资源和行为视图， 并能够控制对生命结束和/或实验性 API 的访问。
+
+为了更容易演进和扩展其 API，Kubernetes 实现了 [API 组](https://kubernetes.io/zh-cn/docs/reference/using-api/#api-groups)， 这些 API 组可以被[启用或禁用](https://kubernetes.io/zh-cn/docs/reference/using-api/#enabling-or-disabling)。
+
+API 资源通过其 API 组、资源类型、名字空间（用于名字空间作用域的资源）和名称来区分。 API 服务器透明地处理 API 版本之间的转换：所有不同的版本实际上都是相同持久化数据的呈现，即底层数据是同一份数据。 API 服务器可以通过多个 API 版本提供相同的底层数据，但是根据调用 API 的版本不同，可以转换成对应版本的资源对象。
+
+例如，假设针对相同的资源有两个 API 版本：`v1` 和 `v1beta1`。 如果你最初使用其 API 的 `v1beta1` 版本创建了一个对象， 你稍后可以使用 `v1beta1` 或 `v1` API 版本来读取、更新或删除该对象， 直到 `v1beta1` 版本被废弃和移除为止。此后，你可以使用 `v1` API 继续访问和修改该对象。其实这个特性完全是为了保持API的兼容而设计的，正常情况下，没有人会混着版本去用，它发挥作用的地方主要在升级迭代时，要知道随着API的迭代开发，API 会逐渐 GA 进入到稳定版本，那 beta 版，以及 alpha 版则会在某一个阶段被移除，这时候，你用beta版API创建的资源对象，仍然能够用稳定版 API 来操作，这样就实现了无缝升级。
 
 我们来举个例子体验下，在1.30 版本的Kubernetes中，有一个用来做流控的API，叫FlowSchema，目前有四个版本，v1,v1beta1,v1beta2和v1beta3，我们以v1beta2创建一个FlowSchema对象，然后使用v1beta2和v1beta3分别将这个对象读出来：