【云原生系列】第二篇 为什么K8s API需要resourceVersion

最新推荐文章于 2025-09-10 20:37:29 发布
原创 最新推荐文章于 2025-09-10 20:37:29 发布 · 1.5k 阅读 · 3 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#云原生 #kubernetes #分布式

本文探讨了Kubernetes(K8s) API中的resourceVersion的重要性，它用于实现增量监听和数据同步，确保在分布式环境中数据的一致性和效率。resourceVersion与Etcd的revision紧密相关，但在K8s中作为独立的版本标识。文章详细阐述了Get请求的三种情况，并解释了resourceVersion在K8s控制器组件如Deployment、ReplicaSet和Scheduler中的作用。

系列文章目录

第一篇 为什么Etcd的Watch不会丢数据？
第二篇 为什么K8s API需要resourceVersion？

提示：写完文章后，目录可以自动生成，如何生成可参考右边的帮助文档

文章目录

前言

K8s控制器模式的核心在于快速且高效地获取数据变化。
举个例子，Deployment控制器需要感知到新建的deployment资源，然后驱动replicaset控制器创建出Pod。

获取数据变化依赖于Etcd v3高性能watch特性，而在watch特性中，版本号revision是数据增量同步的核心。

为什么需要版本号，而不是每次都获取最新数据呢？

如果没有版本号，client或者server出现异常后，因为不能获取到异常过程中的数据，就会出现数据丢失。简言之，版本号是数据增量同步的核心。
当client因网络异常出现闪断之后，可以通过版本号从etcd快速获取异常后的数据，无需进行全量同步。

K8s中通过什么实现增量监听逻辑呢？

答案是Resource Version

为什么不直接用etcd的revision呢？
Resouce version又和etcd revision有啥关系呢？

resourceVersion的维护其实是利用了底层存储etcd的Revision机制，资源对象的每次修改，都会引起resourceVersion变化，且集群范围内唯一；
从k8s源码中可以看到resourceVersion就是Etcd中的modRevision

一、resource初体验

查看任意pod的yaml文件，在metadata部分，都可以看到resourceVersion字段

[root@k8s-node1 ~]# kubectl get po nginx-ds-8vn2h -o yaml
apiVersion: v1
kind: Pod
metadata:
最低0.47元/天 解锁文章
【云原生】kubeadm搭建企业级K8S高可用集群保姆级攻略
景天科技苑
01-04 2325
我们都知道，k8s中有三位大哥：kubelet, kubeadm, kubectl 其中： kubelet是服务，用来调用下层的container管理器，从而对底层容器进行管理。 kubectl是API，供我们调用，键入命令对k8s资源进行管理。 kubeadm是管理器，我们可以使用它进行k8s节点的管理。 今天，我们就基于kubeadm来详细讲讲怎么部署高可用K8S集群
generation 和 resouceversion的区别和用途？
运维老生常谈
11-29 637
常用于控制器（如 Deployment 控制器）来确定资源对象的期望状态是否已经更新，并根据这个值来判断是否需要采取进一步的操作。这两个字段在 Kubernetes 中各自有独特的用途，理解它们的作用对管理 Kubernetes 资源至关重要。来确保只有在该资源对象的当前版本与指定版本相同时才执行更新操作，否则操作会失败。是两个重要的字段，它们用于跟踪和管理资源对象的状态。用于标识资源对象的整体版本，主要用于并发控制和观察资源的变化。) 的更新次数，主要用于控制器来判断资源的期望状态。
K8s源码分析(3)-Resource Version
weixin_46073333的博客
09-04 735
在上一篇文章中我们主要介绍了 kubernetes 中的 resource meta，以及相关的定义，在这里我们主要介绍kubernetesresource 的 version。众所周...
解决Cilium Agent启动瓶颈：CiliumEndpoint列表查询优化指南
最新发布
gitblog_00631的博客
09-10 300
当Kubernetes集群规模超过500节点时，Cilium Agent启动阶段常出现30秒以上的初始化延迟，核心瓶颈在于CiliumEndpoint（CEP）资源的全量列表查询操作。通过对生产环境的火焰图分析发现，`ListCiliumEndpoints` API调用占用了72%的启动时间，主要表现为： - 大量重复的`ciliumClient.CiliumEndpoints(ns).List`...
K8s 资源更新机制详解 （ResourceVersion 与 patch）
小胡子
02-23 818
K8s 资源更新机制详解 （ResourceVersion 与 patch）
k8s-List机制及resourceVersion语义
fourierr的博客
11-20 4110
kube-apiserver 核心职责 提供Restful API；代理集群组件，如dashboard、流式日志、kubectl exec 会话；缓存全量的etcd 数据且无状态服务可水平扩展。
k8s api-resources 查看资源 | apiVersion选择
qq_15138049的博客
11-30 2710
[root@hadoop03 NFS]# kubectl api-resources -o wide NAME SHORTNAMES APIVERSION NAMESPACED KIND VERBS bindings v1
k8s 资源外部版本和内部版本
cbmljs的博客
09-30 1693
k8s resource概念
云原生集群混合云部署：跨云管理K8s集群
AI云原生与云计算技术学院
05-28 946
随着企业数字化转型加速，混合云架构（同时使用公有云和私有云）成为主流选择。Kubernetes作为容器编排的事实标准，在跨云场景中面临集群统一管理、资源调度、服务容灾等挑战。本文聚焦跨云K8s集群管理，解析核心技术原理，提供从架构设计到实战部署的完整解决方案，覆盖多云环境下的资源分配、服务调度、故障转移等关键问题。核心概念：解析混合云与K8s集群联邦的技术内涵算法与模型：调度算法实现与资源分配数学模型实战指南：基于KubeFed/Karmada的跨云集群部署应用与工具：典型场景分析及主流工具链推荐。
【云原生之k8s】k8s基础详解
qq1356059950的博客
08-04 5865
Kubernetes的缩写为：K8S，这个缩写是因为k和s之间有八个字符的关系。Kubernetes是一个可移植的、可扩展的开源平台，用于管理容器化的工作负载和服务，可促进声明式配置和自动化。Kubernetes拥有一个庞大且快速增长的生态系统。Kubernetesd的服务、支持和工具广泛可用。kubernetes，是一个全新的基于容器技术的分布式架构领先方案，是谷歌严格保密十几年的秘密武器----Borg系统的一个开源版本，于2014年9月发布第一个版本，2015年7月发布第一个正式版本。...
【云原生实战】学习笔记（二）k8s(Kubernetes)实战入门
热门推荐
weixin_46703850的博客
02-14 1万+
《云原生实战》是尚硅谷与KubeSphere官方联合打造的云原生系列课程之一 学习内容： ``` 云平台核心 Docker基础 Kubernetes实战入门 KubeSphere平台安装 KubeSphere可视化平台 KubeSphere实战 云原生DevOps基础与实战 微服务基础与实战 ```
K8S的apiVersion含义
qq_50247813的博客
02-21 1385
在kubernetes1.9版本中，引入apps/v1，deployment等资源从extensions/v1beta1，apps/v1beta1和apps/v1beta2迁入apps/v1，原来的v1beta1等被废弃。DaemonSet，Deployment，ReplicaSet和StatefulSet的当时版本迁入apps/v1beta2，兼容原有的extensions/v1beta1。在kubernetes1.8版本中，新增加了apps/v1beta2的概念，apps/v1beta1同理。
【字节面试】K8S中的resource version的作用
weixin_45638974的博客
04-27 459
resource version在Kubernetes（K8S）中，是一个用于标识资源对象版本的字段。
k8s学习第21天--apiversion
qq_34893654的博客
05-06 831
Kubernetes API 版本的主要作用是允许 Kubernetes 集群中的不同组件和工具使用不同版本的 Kubernetes API 对象。这种解耦设计可以提高 Kubernetes 的灵活性、可扩展性和兼容性，使得用户可以根据自己的需要选择合适的 API 版本来管理 Kubernetes 资源。具体来说，API 版本有以下几个重要的作用：标识 Kubernetes API 对象的版本号，方便用户和开发者识别和区分不同版本的 Kubernetes API 对象。
项目启动异常：invalid constant type: 15
梦昼初的博客
03-05 3908
java.io.IOException:invalidconstanttype:15 atjavassist.bytecode.ConstPool.readOne(ConstPool.java:1027) atjavassist.bytecode.ConstPool.read(ConstPool.java:970) atjavassist.b
k8s 关于apiVersion的选择思考
杨仕虎的博客
01-15 1961
Kubernetes API 是基于资源的（RESTful）、通过 HTTP 提供的编程接口 REST：REpresentational State Transfer 直接翻译就是表现层状态转移，这样不便于理解 首先，之所以晦涩是因为前面主语被去掉了，全称是 Resource Representational State Transfer：通俗来讲就是：资源在网络中以某种表现形式进行状态转移。 Resource：资源，即数据（前面说过网络的核心）。比如 newsfeed，friends等； Represe
【博客681】k8s list机制与resourceVersion语义
qq_43684922的博客
07-22 1261
etcd：持久化 KV 存储，集群资源（pods/services/networkpolicies/…）的唯一的权威数据（状态）源；apiserver：从 etcd 读取（ListWatch）全量数据，并缓存在内存中；无状态服务，可水平扩展；各种基础服务（e.g. kubelet、-agent、-operator）：连接apiserver，获取（List/ListWatch）各自需要的数据；
Kubernetes 请求并发控制与数据一致性（含ResourceVersion、Update、Patch简析）
JackXuF的专栏
08-24 6343
      在大型分布式系统中，定会存在大量并发写入的场景。在这种场景下如何进行更好的并发控制，即在多个任务同时存取数据时保证数据的一致性，成为分布式系统必须解决的问题。       悲观并发控制和乐观并发控制是并发控制中采用的主要技术手段，对于不同的业务场景，应该选择不同的控制方法。 悲观锁       悲观并发控制（又名“悲观锁”，Pessimistic Concurrency Con...
kubectl 命令详解（一）：api-versions
youzhouliu的博客
04-26 3953
Kubernetes api-versions 命令解释，命令结果的大概介绍。
k8s 怎么基于原生对象对 k8s 对象进行扩展
03-30
<think>嗯，我现在要了解Kubernetes如何基于原生对象来扩展Kubernetes对象。首先，我需要回忆一下Kubernetes的基本概念。Kubernetes是一个容器编排系统，管理容器化应用，它有很多原生对象，比如Pod、Deployment、Service这些。用户可能需要自定义资源来满足特定需求，这时候就需要扩展。 那问题来了，怎么扩展呢？我记得有Custom Resource Definitions（CRD），应该是最常见的方法。用户可以通过CRD定义自己的资源类型，然后使用控制器来管理这些资源的状态。但用户的问题提到是基于原生对象进行扩展，可能CRD是其中一种方式。但还有其他方法吗？比如Aggregated API Servers，或者使用Annotations和Labels来扩展元数据？ 接下来，我需要分步骤理清楚。首先，扩展Kubernetes对象的方式主要有两种：自定义资源（CRD）和聚合层API。CRD允许用户创建新的资源类型，而聚合层API允许将第三方API服务集成到Kubernetes API中，扩展API的功能。另外，用户还可以通过修改现有对象的Annotations或Labels来添加元数据，但这可能不算真正的扩展对象结构。 然后，CRD的具体步骤是怎样的？用户需要定义一个CRD的YAML文件，指定组、版本、作用域（Cluster或Namespaced），以及结构定义（通过OpenAPI v3 schema）。然后应用这个CRD到集群，之后就可以创建自定义资源的实例了。控制器需要监听这些资源的变化，并根据逻辑调整实际状态以匹配期望状态。 聚合API的话，需要部署一个独立的API服务器，并注册到Kubernetes的API聚合层。这样，当用户请求特定的API路径时，Kubernetes会将请求转发到聚合的API服务器处理。这种方法适合更复杂的扩展需求，但实现起来比CRD复杂。 另外，Operator模式是基于CRD和控制器的一种设计模式，用于自动化应用管理。比如Etcd Operator，可以自动处理备份、恢复、升级等操作。Operator的核心就是CRD和对应的控制器。 那么，用户的问题是如何基于原生对象扩展。可能CRD是在原生对象的基础上，添加新的资源类型，而原生对象如Deployment、Service等保持不变。或者，用户可能想扩展原生对象的功能，比如通过Admission Webhooks在创建或修改对象时进行验证或修改，或者使用Mutating Webhooks动态修改对象配置。 另外，Kubernetes的API扩展机制允许在不修改核心代码的情况下添加新功能。比如，Horizontal Pod Autoscaler（HPA）原本只支持CPU指标，但通过自定义指标API，用户可以扩展HPA支持其他指标。 总结起来，扩展Kubernetes对象的主要方法包括： 1. 自定义资源定义（CRD）：添加新的资源类型。 2. 聚合API：集成第三方API服务。 3. 使用Annotations和Labels添加元数据。 4. Admission Webhooks：动态修改或验证对象。 5. Operator模式：自动化管理自定义资源。 需要详细说明每种方法的适用场景和实现步骤。比如CRD适合需要新增资源类型的情况，而聚合API适合需要更复杂逻辑或与其他系统集成的场景。Admission Webhooks适合在对象创建/更新时进行策略实施或默认值设置。 另外，控制器的作用是关键，无论是CRD还是聚合API，都需要有对应的控制器来监听资源变化并执行相应操作。控制器的实现通常使用client-go库，与Kubernetes API进行交互。 最后，应该给出一个例子，比如创建一个CRD的YAML文件，然后创建一个自定义资源的实例，并说明如何部署控制器来管理它。这样用户能更直观地理解整个过程。</think>Kubernetes 允许通过多种方式扩展其原生对象的能力，以下是基于原生对象进行扩展的核心方法及步骤： --- ### **1. 自定义资源定义（Custom Resource Definition, CRD）** **适用场景**：需要定义全新的资源类型，与原生对象（如 Pod、Deployment）形成互补。 **实现步骤**： 1. **定义 CRD** 创建一个 YAML 文件描述自定义资源的元数据，例如： ```yaml apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition metadata: name: myresources.example.com spec: group: example.com versions: - name: v1 served: true storage: true schema: openAPIV3Schema: type: object properties: spec: type: object properties: replicas: type: integer scope: Namespaced names: plural: myresources singular: myresource kind: MyResource ``` - `group`：自定义 API 组名。 - `versions`：支持的 API 版本及结构定义（通过 OpenAPI v3 Schema）。 - `scope`：资源作用域（`Namespaced` 或 `Cluster`）。 2. **部署 CRD** 使用 `kubectl apply -f crd.yaml` 将 CRD 提交到集群。 3. **创建自定义资源实例** 编写自定义资源的 YAML 文件： ```yaml apiVersion: example.com/v1 kind: MyResource metadata: name: my-resource-instance spec: replicas: 3 ``` 4. **开发控制器** 使用 `client-go` 库编写控制器，监听自定义资源的变化并实现业务逻辑（例如根据 `spec.replicas` 创建对应数量的 Pod）。 --- ### **2. 聚合 API（Aggregation Layer）** **适用场景**：需要深度集成第三方服务或实现复杂逻辑的扩展。 **实现步骤**： 1. **部署独立 API 服务** 开发一个独立的 API 服务器（需实现 Kubernetes 的 API 接口规范）。 2. **注册聚合 API** 创建 `APIService` 对象，将请求路由到自定义 API 服务器： ```yaml apiVersion: apiregistration.k8s.io/v1 kind: APIService metadata: name: v1alpha1.example.com spec: service: name: my-api-service namespace: default group: example.com version: v1alpha1 insecureSkipTLSVerify: true groupPriorityMinimum: 1000 versionPriority: 100 ``` 3. **验证聚合 API** 通过 `kubectl get apiservices` 检查状态，确保新 API 已注册。 --- ### **3. 扩展原生对象行为** #### **(1) Admission Webhooks** **适用场景**：动态修改或验证原生对象的配置。 **实现方式**： - **Mutating Webhook**：在对象持久化前修改其内容（如自动注入 Sidecar 容器）。 - **Validating Webhook**：验证对象是否符合策略（如禁止使用高危镜像）。 **步骤**： 1. 开发 Webhook 服务（需 HTTPS 端点）。 2. 创建 `MutatingWebhookConfiguration` 或 `ValidatingWebhookConfiguration` 对象，指定触发条件和目标服务。 #### **(2) 控制器模式（Controller Pattern）** **适用场景**：增强原生对象的能力（如自动清理未使用的 ConfigMap）。 **实现方式**： - 编写控制器监听原生对象（如 Pod、Service）的事件，并触发自定义逻辑。 --- ### **4. 使用 Operator 模式** **适用场景**：自动化管理有状态应用（如数据库、中间件）。 **核心组件**： - **CRD**：定义应用的自定义资源（如 `RedisCluster`）。 - **控制器**：根据资源状态执行扩缩容、备份等操作。 **案例**（以 etcd Operator 为例）： 1. 部署 etcd Operator。 2. 创建 `EtcdCluster` 资源，Operator 自动创建 etcd 集群并管理生命周期。 --- ### **对比与选型** | 方法 | 复杂度 | 灵活性 | 典型用例 | |--------------------|--------|--------|----------------------------| | CRD + 控制器 | 中 | 高 | 自定义业务资源（如 `CronJob` 扩展） | | 聚合 API | 高 | 极高 | 集成外部系统（如 Istio 控制面） | | Admission Webhooks | 中 | 中 | 安全策略、默认值注入 | | Operator | 高 | 高 | 有状态应用自动化管理 | --- ### **总结** - **轻量级扩展**：优先选择 CRD，快速定义新资源。 - **深度集成**：使用聚合 API 或 Operator。 - **行为增强**：通过 Admission Webhooks 或监听原生对象事件。 实际应用中，常组合多种方式（如 CRD + Webhook + 控制器）实现复杂需求。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值