From c7b9c935c582965279a6f10c677c10dae1c2730f Mon Sep 17 00:00:00 2001 From: chaoyueshijian Date: Fri, 20 Sep 2024 08:07:28 +0000 Subject: [PATCH] GITBOOK-147: No subject --- SUMMARY.md | 2 +- ...10-k8s-api-zu-he-ban-ben-kong-zhi-chu-tan.md} | 16 ++++++++++++---- 2 files changed, 13 insertions(+), 5 deletions(-) rename 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-zu-he-ban-ben-kong-zhi-chu-tan.md} (90%) diff --git a/SUMMARY.md b/SUMMARY.md index 97a6ba1..915711d 100644 --- a/SUMMARY.md +++ b/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) diff --git a/k8s-yuan-ma-ren-cai-fu-hua-xun-lian-ying/di-wu-zhang-apimachinery/5.10-duo-ban-ben-he-xu-lie-hua.md b/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 similarity index 90% rename from k8s-yuan-ma-ren-cai-fu-hua-xun-lian-ying/di-wu-zhang-apimachinery/5.10-duo-ban-ben-he-xu-lie-hua.md rename to 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 index 150f863..9f4b66d 100644 --- a/k8s-yuan-ma-ren-cai-fu-hua-xun-lian-ying/di-wu-zhang-apimachinery/5.10-duo-ban-ben-he-xu-lie-hua.md +++ b/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 主要完成两个工作，多版本转换和序列化，今天我们来聊聊多版本转换，它跟一般应用的多版本还不太一样，有它自己的特色，因此搞懂它的相关概念和实现原理是相当有必要的。 -### 功能介绍 +### API 组和版本控制 -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分别将这个对象读出来：