Kubernetes Deployment详解原创

各位战友大家好，今天呢，我们一起来学习一下deployment控制器，Deployment作为目前行业解决方案的一个首选，那么它相较于RC和RS有哪些不一样的地方？为什么我们要选择他呢？就借今天这个机会，我们一起来深入的交流一下。本次课一共分为12步走，第一，为什么deployment是K8S的一个核心呢？第二，到底是什么？第三，我们学习deployment之前需要掌握哪些概念和知识呢？第4，执行声明文件的三个方式。这三个方式分别对应的什么样的场景？第5，工作原理。我们要了解deployment是怎么一步一步创建破的和管理pod的。

第6，核心特性，它相较于RC和RS多了哪些特性？第7，滚动更新。滚动更新是deploy的一个特色和核心，这也是为什么行业会选择它的一个重要理由。第8，策略对比滚动更新有哪几种方式？这几种方式里又分别有哪些参数？第9，高级发布，本次课呢，我们重点掌握金丝雀发布。当然了，还有蓝绿发布，黑白发布，蓝绿发布和黑白发布目前使用的是比较少的，场景呢，也不是很多，所以不作为本次课的重点。本次课重点围绕金丝雀发布展开。第10版本管理前面我们讲到了可以滚动更新，对吧，那么它不仅可以滚动更新，可以滚动回退。

11、总结和最佳实践。我会将本次课的一个创建。管理滚动更新版本回滚。做一个完整的实验，最后是互动问答。下面开始我们的正题，为什么我们要学好deployment deployment涉及的范围啊，实在是太广了，基本上包含了所有的使用场景，从最基本的一个应用部署，再到业务高峰期的动态扩缩容，再到不误自愈，再到版本的迭代更新和故障回滚，Department都提供了很好的解决方案。

这也是为什么生产环境应用部署率会超过90%的原因，因为它实在是太好用了。再看核心优势，第一，声明式管理。什么是声明式管理？我只需要在雅某文件里面写好我期望的一个状态，K8S呢，就会自动完成所有复杂的操作，我不需要关心这些执行的细节。第二，零停机发布。Deployment可以通过滚动更新的策略，逐步替换掉旧版本，实现业务无感知升级，保障服务的连续性，这一点很重要。第三，自愈容灾破的进程异常，自动重建是吧，节点故障的时候自动将pod。转移到可用的、可靠的节点上，保障了这个put的够可用。

再看弹性扩缩容，Deployment还支持手动或者是基于就是监控或者状态进行一个副本的数量的调整，灵活应对突发流量或业务低谷。第5版本可控，自动记录每次更新的历史版本，一旦发现问题，支持一键快速回滚，风险可控。这个也很重要。最后，生产首选。结合以上我们总结了一些优势，是cot集群中生产环境应用部署的最佳选择。我们一起来看一下deployment的工作原理，创作流程就是先创建deployment deployment会自动生成一个replic side, 它通过replic side间接的去创建和管理扩。

我们通过这张图也不难看出，是吧，Deployment不直接的对接po中间还有一个LIC这个中间人，但是呢，我们又发现relic它有两个是吧，它为什么是两个？正常情况下，一个deployment只会对应一个那个Rep set, 不责维护pod，但是在版本更新的时候呀，会短暂出现两个replic set同时存在。为什么先创建一个新的p side是吧？把旧的迁移到这个新的上面去，同时呢，这个旧的还在运行一部分破的是吧？一部分旧的破的，等新的破的完全跑起来正常之后，再一点一点的删除掉旧的破的，最后等旧的这个repl side空了，就只剩下新的了。这么做就是为了滚动升级，不停服升级是吧？一边上新版本一边下旧版本，全程的业务不中断。

我们再看deployment三大自动化能力，首先第一个声明式更新，只需要在压部文件里改好镜像的版本参数，执行cooper CTL APP类提交，然后K8S呢，就会自动的按照策略完成滚动升级，全程不用手动管新旧，破的的这么一个切换，省心又稳定。第二，自愈能力。Pod崩溃节点故障的时候，Deployment会通过relic site自动重建pod，保证副本数不变，业务呢也不会因为单点故障而中断。第三弹性库松绒之前呢是用手动的库CPLL，然后SKY直接调整副本数，是这种呢是快速应对突发流量的一种方式，但是呢，它有自动的这么一个机制，结合HPA的这么一个控制器，根据CPU和内存使用率的一个情况，自动的增加或者减少破的按需分配资源。

再看滚动更新，滚动更新也是K8S的默认的更新策略，我们一起来看一下它是怎么样完成这个流程的。首先先创建一个新版本的pod是吧，等新版本的pod完全就绪以后，可以接收流量了，再把旧的pod给终止。循环，直至所有破的全部更新完成。优势就是业务全程运行，用户呢是没有任何感知的。

然后流量是吧，切换的过程当中也会避免一个瞬间的过载，第三支持暂停，继续回滚，还能通过一些个这两个参数max search和max unavailable参数进行调整更新的节奏，适配不同风险。总结一下，就是通过更新了分批的替换，实现了服务的无中断版本升级，这个也是deployment的首选更新策略。Toment的两种更新策略，第一个rolling update, 这个是默认的滚动更新，是渐进式分批替换，破的新旧版本共存，实现服务零停机，适合生产环境高可用的无状态应用，但会临时占用双倍资源，优先考虑。

第二种是create重建式更新，它是先全删掉旧的pod，再全建新的pod，没有版本共存的问题，更新快，不占用额外资源，但会导致服务中断，适合测试环境新旧不兼容或者是有状态应用的场景。高级发布金丝雀发布核心思想呢，就是先把新版本小范围的发布给少量用户，验证一下我们这个新版本的稳定性没问题了，再慢慢的扩大覆盖范围，最后全量上线。核心目标其实很简单啊，就是用最小的影响范围提前发现新版本的bug或者是性能问题，把风险控制在早期，能避免一上线就大面积翻车的一个问题。第三是名字的由来，为什么叫金丝雀发布呢？以前矿工下井的时候会带一只金丝雀是吧？因为这个金丝雀啊，对这个有毒气体比人会更敏感一些，能够提前预警这个风险。在这个软件发布的时候也是一样，新版本就像是这只金丝雀，帮我们提前去看一下，诶，这个对系统稳定。

怎么样，是不是有没有bug，或者是其他一些风险问题在里面，总而言之，金丝雀发布是目前主流的一种发布方式，也是我们发布的首选。第4句实现方式1调整滚动更新参数实施步骤第一步就是要修改策略配置rolling update的参数设定marks surge和marks an available, 这个该怎么配置呀？我们来看一下这个具体的配置啊。MARKX4是1允许超出副本数上限一个坡度。

比方说原有我deploy定义的副本数是5，那么maxx设置1的话，就会可以在更新的时候同时存在，呃，6个破的。对吧？这个很好理解，再看下面的参数mark available不允许任何旧的破的下限，也就是说不允许你这个破绽是处于不可用的情况下，也就是说这6个你都得给我活着，对吧？不允许销毁，通过这样的目的就完成了一个金丝雀发布，是不是就会有少量的流量会被分发到那个新上线的破绽呀？

对吧，既然诶这个目的达到了，是不是就可以开始观测新版本的pod运行的一些状态，是不是性能行不行，有没有bug，对吧，都可以在这个阶段来确认，如果没有问题了，然后我们再恢复我们的策略，是吧，把那个max啊，Available调整成1。开始逐步的滚动发布。金丝雀发布实现方式2，通过暂停滚动更新的方式来实现。核心原理就是先触发deployment的滚动更新，然后又立即执行暂停操作是集群停留在新旧版本pod并存的中间状态，以便对新版本进行流量验证和观测。这个具体是怎么操作呢？是吧？第一，我们先使用cooper CTL pat命令更新pod里面某个容器的镜像。

是吧，我们先更新一个嘛，然后立马再用库CTL run out pass.暂停更新，就确保修改生效以后立即停止在金丝雀的一个状态。第二。确认新版本没有异常以后，我们可以用CU CTL run out, 然后是嗯，Resume继续完成剩余实例的全量升级。第三，比方说验证失败了，我们怎么回滚呢？我们可以使用cooper c PL run out and度快速回到上一个稳定的版本，总结一下就是通过步伐更新，然后暂停验证，然后恢复或者是回滚这三步实现实现的低成本可快速回滚的一个金丝券发布也是目前，嗯。

生产环境当中比较常用的一种方式。版本管理有回本，这个也是我们在发布工作当中的最后一道防线，如果说发布有问题了，我们能够及时的快速的回到指定的版本，避免业务受损。首先我们看查看所有历史版本，命令是CU c PL runout history, 然后后面跟上你要查的deploy的名字，这样就可以列出这个deploy控制器所有的版本修订记录，便于追踪变更规迹。第二，查看指定版本详情，可以通过cooper CL runout history deployment, 然后后面跟上deployment的名字。然后再加上那个reversion，等于2，比方说我们要看，因为有好几个版本嘛，因为比方说你这个运行的时间比较长的话，会有很多的版本存在，我们要指定版本，那就通过这种方式。

第三，回滚到上一个版本应该怎么操作？Cooper c t run out anddo deployment, 后面跟上deployment的名字，会默认的回滚到上一次运行的一个版本。最后回滚到指定历史版本应该怎么操作对吧？首先我们知道，首先我们要知道要回到哪个版本，我们可以通过哎，第一个命令查看所有的历史版本，然后我们回滚到指定版本，可以通过cooper CL run out anddo deployment, 然后后面加上deployment的名字，杠杠，To revertion等于几你要回到哪个版本，通过这条命令就可以自由的选择回滚到任意的历史版本当中，在复杂的场景下呢，可以灵活的恢复服务。

最后我们来总结一下今天学习的内容，首先呢，Deployment是K8S应用发布的核心控制器。它提供了声明是自动化的全生命周期管理的能力，支持滚动更新和回滚，是吧？然后生产最佳时间，我们统一使用cooper CTL play进行声明式的资源管理，创建资源也好，删除资源也好，修改资源也好，对吧？然后所有的压迫配置文件必须纳入get版本控制。第三，生产环境优先使用默认的rolling update更新策略。第4，重要应用版本发布前必须使用金丝雀验证流程。

第5，熟练掌握版本回滚操作，为生产环境建立最后一道防线。到E。PPT讲解就已经结束了，如果大家有任何的问题，可以在课后找我们的小助理，也可以找我们的助教去进行一个沟通。下面就开始我们的实验环节。下面就开始我们的实验环节，我们一起来看一下这份压模文件，首先定义了API version.核心组的版本是apps v1，然后定义了T的类型deployment，我们要起一个deployment控制器，然后又定义了原数据，匹配了这个标签。给deploy起了一个名字，下面又定义了规格描述。我们要起4个副本，然后我们要选择标签，标签的这个参数是match labels要选择这个标签。

然后template要起port的了，要定义pod了，Me data.要关联标签是吧，这个得一一对应上，这个格式是固定的。然后我再往下看Spark规格描述，要起一个容器，容器的镜像是N冒号latest，然后容器的拉取策略是not present, 意思就是如果本地有就用本地的，如果本地没有就从远端窗口拉取。然后Name给容器定义了一个名字叫苏斌container。好，就是这样一份压B文件，我们一起来执行一下。哦，不好意思。

好，复制过来了，Cooper CTL create, 杠F，然后这个研文件，注意这里一定要加上杠杠record，不然的话它无法记录我们每次更新的一个版本状态，好回收。提示创建当中对吧，我们一起来看一下它的一个状态，嗯，首先我们看一下历史版本的记录吧，因为这个我们是第一次创建吧，对吧，因为我们使用的是quit第一次创建，我们来看一下。哎，把前面的给删掉。比如说对吧，它就记录了我们的一个版本是吧，REVERSION1第一版，然后修改描述，嗯，是库班CTL create是吧，杠F，然后后面这些。相当于记录了我们第一次执行的一个情况，好，我们再往后看，查看一下验证的结果吧。

Get deployment, 然后后面写上你deployment的名字，我们的deployment叫苏冰回车。是不是ready了，全部都ready了，对不对？来，我们再来看一下破的状态。好，稍等啊，我复制一下命令。回撤。好，我们这个破的已经全部起来了，一共有4个对吧，现在我们就需要配置金丝雀发布所需要的patch参数。来，我再复制一下。复制过来。执行，我们一起来看一下这条命令哈，我使用了库CTL patch这个命令意思就是我要在这个deployment的基础之上添加哎，这些参数。你看我添加了什么参数。添加了这个markx search1和markx unavailable0这个参数，这个在之前PPT的部分我们详细讲解过，这里就不再赘述了。

好，这里patch就已经配置完成了，我们一起来输出这份压木，来看一下它具体的一个配置情况，是不是没有任何问题了，对不对，已经写入到雅某当中了，下面呢，我们就不发更新是吧？来看一看它究竟是怎么一个情况。来，回收好，一起来分析一下这条命令，Cooper s CTL patch, 诶，又执行了一个patch，他做了一件什么事情？他修改了我containers里的这个镜像，把原来njax冒号lettx的镜像替换成NS冒号V2版本的一个镜像，替换完之后，我立马又做了一个什么动作，对吧？我立马又做了一个cooper s TL run out past.

暂停这个deployed的更新。也就是说刚触发替换，我就更新，使当前的这个deploy达到金丝雀的一个状态。我们可以一起来看一下哈。我们输出，哎，这几这些炮的。对吧，通过创建时间我们可以判断。其这个下面四个是三分钟之前创建的，最上面这一个是51秒的，51秒之前创建的这个就不难判断出51秒这个就是我们替换的那个pod。然后我们再看一下更新的一个状态，没错。好，因为现在已经被暂停了嘛，所以说现在还是在等待更新当中，目前一个是吧，已经起来了，还有4个老的在运行当中。

好，我们继续往后走，这个阶段金丝雀的阶段是不是就是一个验证的阶段呀，验证有好有坏，那么比方说验证通过了，我们怎么让它全量的替换呢？我们就通过cooper run out.Um, 然后deploy苏冰恢复它的全量更新，也就是解除暂停。我们一起来看一下。如说。好，恢复成功了，我们一起来看一下它的更新状态吧。诶。好。好，我们再来看一下刚的我我就嗯，W加上。是吧，通过创建时间，我们也能判断15秒，17秒，19秒都是在一个创建销毁，创建销毁，从而把旧的替换成新的这么一个过程，对不对。

好，我们看一下他的状态。哦，对，我刚才还在等这个2分多钟的，实际上这个2分多钟的就是我第一次执行替换那个命令以后，就已经创建好了，对吧，所以说现在。已经把旧的全部都替换成新的了。金丝从金丝雀再到全量发布的这么一个过程就演示完了，当然了，比方说如果我们现在这个版本，哎，你发现有一定的问题，我要回退到之前的版本，那应该怎么做呢？当然了，还是有命令，还记不记得刚才我们看过一个历史版本啊，再来看一下，哎，现在里面记录了2条这个deploy的更新状态。

是不是比方说这个2现在有问题了，我想回退到1，应该怎么办？这个地方我也给大家准备了一个命令。诶，执行cooper runout undo deploy, 苏斌就能回到之前的一个状态来。执行，我们再来看一下pod的一个情况，对不对。符合预期吧，Container creating容器创建当中。好，通过这个创建时间。我们也可以判断，它已经从老的那个从新的又替换回老的了。这个怎么验证呢？我们可以get，嗯，Deploy.他然后苏冰输出他的鸭某，然后grape查看它的镜像嘛，这1。

Hey.对不对。我们最初使用的镜像是安吉斯冒号雷斯，是不是就回退回去了呢？这样实验的效果就达到了。实验到这里就已经做完了，相信各位战友对deployment金丝雀版本的滚动更新和回滚都有了一个清晰的认识，在后续的课程当中，我们还会讲到破的其他的控制器，希望在下次课之前我们要把deployment以及RC和RS都吃透，这样的话在后续的学习当中呢会更游刃有余。话不多说，就到这里，我们下次课再见。