前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >kubectl apply 之后客户端做了什么?

kubectl apply 之后客户端做了什么?

原创
作者头像
Duncan_
发布于 2023-01-03 14:43:26
发布于 2023-01-03 14:43:26
2K0
举报

kubectl apply 之后客户端做了什么?

前言

在学习 kubernetes 源码过程中,看到 kubectl apply 源码里面有个很有意思的现象。起初我以为当我们执行 kubectl apply -f deployment.yaml 之后,客户端会把 deployment.yaml 完整地发送给 api-server,然后让 api-server 重新渲染这个 deployment 资源并更替旧的资源。

实际上却并非这样,当我们执行 kubectl apply 的时候,默认是采用的是 client-side apply 模式。客户端会先会生成一个增量的 patch 对象,然后在发送给 api-server 进行 patch 操作。而生成这个增量信息生成的算法,是通过三路数据合并得到的。

本文源码选取

kubectl 的源码本身应该在 git@github.com:kubernetes/kubectl.git 仓库。但是在 kubernetes 大仓里面也有一个用于发布到公共类库的镜像源码。所以我直接下载 kubernetes 大仓 git@github.com:kubernetes/kubernetes.git ,查看源码更加方便一些。我的 kubectl 客户端版本是 v1.21.3,所以就切换到对应标签 v1.21.3

kubectl apply 执行流程

下面用伪代码大概描述下 kubectl apply 的执行流程

WechatIMG222.jpeg
WechatIMG222.jpeg

在这个流程中,首先是准备了三路合并的资源对象, modifiedcurrentoriginal。其中 modified 是从用户传入的文件中获取的资源对象。current 则是从 api-server 获取的实际运行的资源对象信息。original 则是从 current 资源对象的 lac(last-applied-configuration) 注解中获取的上一次 apply 的原始拷贝。

这个三路资源对象数据的关系可以这样理解,current 是上一次三路合并里面 modified 资源对象基础上,增加一些必填项、默认值、状态信息以及服务端修改之后的资源对象。由于 current 已经被修改了,所以需要使用一个注解把原本没有修改的资源对象信息给记录下来,所以其实本次三路合并的 original 实际就是上一次三路合并的 modified 的拷贝信息。

接着 kubectl apply 对三路资源对象比较分析,得出一个增量数据 patch。这个 patch 是遵循 kubernetes 自己定义的 strategic merge patch 格式的增量信息,内容包含了本次需要更改、增加以及删除的字段操作信息,也包含了更新 lac 注解内容。最后通过 api-serverpatch 接口,完成了对目标资源对象的更新操作。

三路资源对象合并,生成增量 patch

下面我们仔细阅读一下 strategicpatch.CreateThreeWayMergePatch 源码,看看 patch 内容是怎么产生的。

源码解析在代码的注解中

代码语言:go
AI代码解释
复制
func CreateThreeWayMergePatch(original, modified, current []byte, schema LookupPatchMeta, 
    overwrite bool, fns ...mergepatch.PreconditionFunc) ([]byte, error) {

	...
	deltaMapDiffOptions := DiffOptions{
		IgnoreDeletions: true,
		SetElementOrder: true,
	}
	// 对比 current 与 modified,忽略删除字段的操作,只返回新增和修改字段的操作
	deltaMap, err := diffMaps(currentMap, modifiedMap, schema, deltaMapDiffOptions)
	if err != nil {
		return nil, err
	}
	deletionsMapDiffOptions := DiffOptions{
		SetElementOrder:           true,
		IgnoreChangesAndAdditions: true,
	}
	// 对比 original 与 modified, 忽略新增和修改内容,只返回删除的字段的操作
	deletionsMap, err := diffMaps(originalMap, modifiedMap, schema, deletionsMapDiffOptions)
	if err != nil {
		return nil, err
	}

	mergeOptions := MergeOptions{}
	// 合并新增、修改以及删除操作
	patchMap, err := mergeMap(deletionsMap, deltaMap, schema, mergeOptions)
	if err != nil {
		return nil, err
	}

	...

	// 这里 original 和 current 的 diff 可以理解为默认值、状态字段以及服务端的更改。
	// 当 overwrite == true ,客户端的更改将会覆盖服务端的更改。
	// 当 overwrite == false ,客户端更改如果与服务端更改有冲突,则会报错。
	if !overwrite {
		changeMapDiffOptions := DiffOptions{}
		changedMap, err := diffMaps(originalMap, currentMap, schema, changeMapDiffOptions)
		if err != nil {
			return nil, err
		}

		hasConflicts, err := MergingMapsHaveConflicts(patchMap, changedMap, schema)
		if err != nil {
			return nil, err
		}

		if hasConflicts {
			return nil, mergepatch.NewErrConflict(mergepatch.ToYAMLOrError(patchMap), mergepatch.ToYAMLOrError(changedMap))
		}
	}

	// 最后返回这次客户端更改的增量操作集合
	return json.Marshal(patchMap)
}

简单来说,CreateThreeWayMergePatch 分为三步来生成增量 patch 的。

第一步是对 currentmodifieddiff 操作,忽略删除字段的操作,值保留新增与修改字段的操作,生成 deltaMap

  • 忽略删除字段的操作,是因为 current 里面包含了一些默认值、状态信息以及服务端对于资源对象的一些更改操作,这些并不包含在用户传入的资源对象里面。如果不忽略删除字段操作,这些默认值、状态值以及一些服务端的修改就会被认为是需要做删除的操作字段。
  • 真正需要删除操作的字段,应该是通过 original 和 modified 对比得到的。
  • 除了正常的字段更新,这里还会包含注解的更新,因为注解 "lac" 在前面过程中被 modified 资源对象重新赋值了

第二步对 originalmodifieddiff 操作,忽略新增与修改的字段的操作,保留删除字段的操作,生成 deleteMap

  • 真正需要删除的字段操作,是通过 originalmodified 对比才能够得到的
  • 这里忽略了新增和修改字段的操作,第一是因为这个在第一步已经计算出来了,第二是因为对于一些默认字段的修改操作,currentmodified 对比的结果是修改,而 originalmodified 对比的结果是新增。显然修改操作比新增操作是更加符合对 current 资源对象的操作。

第三步就是合并 deltaMapdeleteMappatchMap

总结

最后我们了解到,我们经常执行的 kubectl apply ,实际并不是把我们传入的资源文件原封不动的传给 api-server,而是在客户端提前做好处理,得到增量的patch 再向 api-server 发起对目标对象的 patch 操作。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
暂无评论
推荐阅读
实时视频直播客户端技术盘点:Native、HTML5、WebRTC、微信小程序
2017 年 12 月,微信小程序向开发者开放了实时音视频能力,给业内带来广阔的想象空间。连麦互动视频直播技术在 2016 年直播风口中成为视频直播的标配,然而只有在原生的 APP 上才能保障良好的用户体验。
JackJiang
2018/08/29
7.6K0
实时视频直播客户端技术盘点:Native、HTML5、WebRTC、微信小程序
1、前言 2017 年 12 月,微信小程序向开发者开放了实时音视频能力,给业内带来广阔的想象空间。连麦互动视频直播技术在 2016 年直播风口中成为视频直播的标配,然而只有在原生的 APP 上才能保障良好的用户体验。 那时候,在微信小程序中无法进行实时音视频互动。微信小程序在去年 12 月宣布开放实时音视频能力,再加上去年 6 月苹果宣布即将支持 WebRTC,业内一下子千树万树梨花开,前途一片光明。 连麦互动直播技术和微信小程序以及 WebRTC 能产生怎么样的化学作用?开发者在微信小程序或者浏
用户1263954
2018/06/22
5.2K2
即构音视频SDK:跨四平台、三种类型终端,让直播保持低延迟高画质
说到音视频云服务,大多数人可能联想到的是网络直播应用场景,实际上,硬件对音视频云服务的需求也在逐渐提升。而这样的市场需求也推动了整个行业的发展,目前,阿里云、腾讯云和网易云等巨头都已入局,除此之外还有
BestSDK
2018/02/28
2.7K0
即构音视频SDK:跨四平台、三种类型终端,让直播保持低延迟高画质
视频直播连麦技术详解「建议收藏」
云帆加速自成立以来就一直致力于流媒体领域企业服务,尤其对于直播,目前已经推出了针对于不同场景的直播云解决方案,在保证广大用户使用体验的前提下,为客户节省更多的研发成本。无论是传统企业转型,或者是创业企业,云帆加速都将为其直播化提供针对性的解决方案。目前云帆加速已经与流媒体领域50+行业top级客户建立合作关系,并提供服务。
全栈程序员站长
2022/09/15
5.4K0
视频直播连麦技术详解「建议收藏」
视频直播基础知识
视频云,是以Paas服务模式,向开发者提供音视频编解码SDK和开放API,助力移动APP接入音视频功能,用户不需要后台开发和运维人员,就可以开发自己的视频网站或者移动APP应用。视频云主要使用的是流媒体技术,下面就来给大家介绍一下视频云相关的技术。
视频云直播helper
2019/02/22
8.4K0
视频直播基础知识
七牛云技术分享:使用QUIC协议实现实时视频直播0卡顿!
不做任何开发,就能实现弱网环境下实现实时视频直播零卡顿,听上去是不是天方夜谭?看完这篇文章你就知道,我们是如何做到的。
JackJiang
2018/08/29
4.3K1
近期大热的实时直播答题系统的实现思路与技术难点分享
HQ Trivia 号称直播答题的鼻祖,它是一款小知识互动游戏,由短视频社交鼻祖Vine的联合创始人拉斯-尤苏波夫和科林-克罗尔共同开发
JackJiang
2018/08/29
1.8K0
P2P技术如何将实时视频直播带宽降低75%?
实时视频直播经过去年的千播大战后已经成为互联网应用的标配技术,但直播平台的成本却一直居高不下,各个平台除了挖主播、挖网红以外,其背后高额的带宽费用也是他们最大的一块成本。
JackJiang
2018/08/29
5.7K0
技术福利:最全实时音视频开发要用到的开源工程汇总
实时音视频的开发学习有很多可以参考的开源项目。一个实时音视频应用共包括几个环节:采集、编码、前后处理、传输、解码、缓冲、渲染等很多环节。每一个细分环节,还有更细分的技术模块。比如,前后处理环节有美颜、滤镜、回声消除、噪声抑制等,采集有麦克风阵列等,编解码有VP8、VP9、H.264、H.265等。 
JackJiang
2018/08/29
7.2K1
视频直播| 基础原理篇
一、直播难与易 `直播难`:个人认为要想把直播从零开始做出来,绝对是牛逼中的牛逼,大牛中的大牛,因为直播中运用到的技术难点非常之多, 视频/音频处理,图形处理, 视频/音频压缩,CDN分发,即时通讯等技术,每一个技术都够你学几年的。 `直播易`:已经有各个领域的大牛,封装好了许多牛逼的框架,我们只需要用别人写好的框架, 就能快速的搭建一个直播app,也就是传说中的站在大牛肩膀上编程。 二、直播相关概述 1.一个完整直播app功能 1、`聊天` 私聊、聊天室、点亮、推送、黑名单
進无尽
2018/09/12
7.3K0
视频直播| 基础原理篇
视频直播技术干货(十三):B站实时视频直播技术实践和音视频知识入门
直播行业从传统的娱乐直播发展到教育直播、电商直播等形式,产生了很多新的玩法。传统的直播是一位主播展示才艺,观众通过弹幕、送礼物等方式进行互动。随着网络质量不断地提高,用户也对直播平台产生的新的要求,实时互动直播的场景就出现了,观众可以同时观看多位主播之间互动的画面,让直播间的气氛更好。B站直播的连麦PK、视频连线业务就提供了这个能力。主播看到的是对方主播实时的流(延迟400ms以内),而观众看到的是“准实时”的流(延迟2~5s左右)。
JackJiang
2025/03/06
3830
视频直播技术干货(十三):B站实时视频直播技术实践和音视频知识入门
了不起的WebRTC:生态日趋完善,或将实时音视频技术白菜化
有人说 2017 年是 WebRTC 的转折之年,2018 年将是 WebRTC 的爆发之年,这并非没有根据。就在去年(2017年),WebRTC 1.0 标准草案出炉(实际上WebRTC标准草案的早期版本早在2011年就已经发布,WebRTC并非一夜之间就出现的技术),并将于今年正式发布。与此同时,越来越多的浏览器和厂商都开始对它进行广泛的支持,WebRTC 即将成为互联网的基础设施了,或许门槛如此之高的实时音视频技术终有白菜化的那一天。
JackJiang
2018/08/29
3K0
视频直播之基础原理
SDK(Software Development Kit): 软件开发工具包 CDN(Content Delivery Network):内容分发网络
全栈程序员站长
2022/09/15
3.3K0
视频直播之基础原理
后直播时代的技术弄潮儿——TRTC
导语 | 随着移动互联网的发展,音视频逐步从单向观看走向多方互动,更低延时、更多交互的实时音视频技术逐渐成为新的风口。本文是对腾讯云实时音视频高级工程师—蒋磊老师在云+社区线下沙龙的分享整理,为大家解析腾讯实时音视频(TRTC)的关键技术及应用。 点击视频查看完整沙龙回放 一、互联网通信服务的发展 纵观整个互联网通信发展史,最开始是传统通信,主要借助邮件、短信、电话、传真等方式进行通信。到了移动互联网时代,利用IM技术我们在手机上做到了更丰富的通信能力,诞生了QQ、微信等一堆工具。再往后面发展就到了通
腾讯云开发者
2021/01/13
1.6K0
直播系统源码如何实现视频直播以及搭建服务器的?
这几年直播软件在开发的道路上也经历过不少的坎坷,才发展到今天的成熟阶段。越来越多的年轻人喜欢看直播、开直播。同时,随着直播系统源码的诞生,直播软件开发也变得越来越容易。那么如何实现视频直播?直播系统源码如何搭建?现在一一给你解答。
布谷安妮
2020/03/23
3.2K0
直播系统源码如何实现视频直播以及搭建服务器的?
关于网络视频流媒体直播/点播服务流程,你要知道的全在这里了!(新手必看)
网络视频直播存在已有很长一段时间,随着移动上下行带宽提升及资费的下调,视频直播被赋予了更多娱乐和社交的属性,人们享受随时随地进行直播和观看。一般来说,网络视频直播的流程可以分为如下几步: 采集 —>处理—>编码和封装—>推流到服务器—>服务器流分发—>播放器流播放。 下面我们逐步来看一下。
EasyNVR
2020/05/08
1.4K0
视频直播点播平台EasyDSS如何能够降低延迟?
我之前写过很多关于延迟的问题,但是延迟这个问题是在现有视频的技术下必然会存在的问题,或许等到未来5G以上的网络普及时,就能够解决大部分延迟问题。
EasyNVR
2020/07/02
1K0
直播APP的技术难点
直播APP的技术难点在于其对实时性、并发性、稳定性、音视频处理能力和数据安全性的极致要求。这使得直播APP的开发和运维比许多其他类型的APP更为复杂。以下是直播APP开发中主要的技术难点。北京木奇移动技术有限公司,专业的软件外包开发公司,欢迎交流合作。
数字孪生开发者
2025/05/29
1180
直播APP的技术难点
技术干货:实时视频直播首屏耗时400ms内的优化实践
直播行业的竞争越来越激烈,进过2018年这波洗牌后,已经度过了蛮荒暴力期,剩下的都是在不断追求体验。最近正好在做直播首开优化工作,实践中通过多种方案并行,已经能把首开降到500ms以下,借此机会分享出来,希望能对大家有所启发。
JackJiang
2018/11/22
2.9K0
蒋磊:移动直播连麦技术实践(附视频回放)
6月29日,音视频及融合通信技术技术沙龙圆满落幕。本期沙龙特邀请腾讯云技术专家分享关于最新的低延迟技术、全新的商业直播方案等话题,针对腾讯云音视频及融合通信产品的技术全面剖析,为大家带来纯干货的技术分享。下面是蒋磊老师关于直播的一些分类以及连麦直播需要解决的四类问题进行了总结与分享。 讲师介绍: 蒋磊,腾讯云高级工程师,现任职于腾讯云终端研发中心,负责腾讯云视频服务客户端SDK的技术服务工作,曾先后就职于网易、阿里云,负责实时音视频、直播、点播、CDN、即时通信等业务相关技术工作,在音视频及IM业务的实际
腾讯云音视频
2019/07/05
4.5K0
蒋磊:移动直播连麦技术实践(附视频回放)
推荐阅读
相关推荐
实时视频直播客户端技术盘点:Native、HTML5、WebRTC、微信小程序
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档