00:00
那下一个我们的DEMO。DEMO呢，确保全部或者一些的node运营在一个pod的副本上。全部或一些，这是一个非常关键的概念。也就意味着，其实在我们的K8S里，它的调度的选择是可以被我们的管理员所控制的，并不是只能由K8S自己去决定。这在我们后边的调度策略里，会教大家怎么去把对应的pod放在对应的node上去运行，哪些node我不想要运行，一些pad也是可以被定义的，主要是通过我们的标签选择，或者是我们所谓的污点。去决定的，那现在呢，我们不讲这么多，我们只给大家灌输一个概念，后面我会给大家详细讲解。好，并且当node加入集群时候，他也会被他们新增一个pod，当node被节电移除时，也会被回收。好，并不是在我们的命令下达的一瞬间有哪些node，那些node上就会进行pod，而后面新加一些note以后，这些note并不会运行这些po，并不是哈，并不是，而是一个动态持续的过程，只要这个我们的DEMO它在持续运行，它没有被删除，那在这整个周期之内。
01:23
对应的node上都会运行我想要运行的pod。并且需要注意一下，只有一个，也就DEMO赛并不可以去定义超过一个以上的副本。因为它的默认只有一个，也只能定义为一个。如果你需用需要有多个pod需要运行在我们对应的no之上的话，你就可以通过定义多个DEMO set的方案去实现。需要注意一下。好，删除，对梦赛呢，我将会删除他创建的所有跑。还是那句话，DEMO赛引导起来的D都是被我们DEMO赛所管理的，你的管理者已经没有了，那你就不应该存在，这个很好理解对吧？那包括底下给大家讲解了一些常用的一些典型的用法，比如集群的存储。
02:12
那我们之前说过，我们的学过我们的MFS，那它的窗搜端完全就可以运行在我们的。什么蒙赛之上对吧，提供一个存储能力。那比如我们每个路上运行一些日志的收集程序，比如我们的front和我们的logsh，那这都可以去在每个节点上帮我们收集数据以后到我们的1K里，对吧，一个去汇总，一个去展示数据索引。好，还有最后一个我们的每个no上运行的一个监控程序。比如我们之前学过的我们的ZBZ的A端完全就可以运用在每个no上的一个DEMO，那可以通过我们DEMO set去部署，更便于我们去实现，因为它可以确保每个no度节点尤且只有一个，哪怕他死了以后是不是还会被启动，对吧，好，DEMO site。
03:13
那如果我有一些。类似于脚本的方案需要去执行的话。那前面几种就不太友好了，这时候我们就需要引入一个新的。会让引入两个新的我们的管理器，一个是job，一个是我们的job。大家会发现，如果我今天写了一个备份脚本，我把它放在我们的crown table里，Linux的操作系统内置的crown table里去执行的话。如果他没有对应的纠错功能在脚本里得到体现的话。你是不是有点害怕？哎，万一这个可能他没有正常执行怎么办？我们一般都会有这样的忧虑，对吧？但对于job来说，你就不需要去考虑了，原因是什么呢？教母会有自己的纠错能力，也就意味着如果在里面运行的这么一个脚本没有以零的代码退出的话。
04:05
它会重新执行这个程序，也就意味着你叫我去实现了我们一个管理控制器呢。他呢，更。倾向于去以。这种所谓的脚本的运行的方案机制的这么一个管理。这么一个po的管理。好，那也意味着以较保资源控制器管理的这么一个pad呢，我可以在里面去部署对应的脚本，对吧，以确保它正常运行。那并且这里也说了，他会保证批处理的任务一个或多个炮的成功结束，这是什么概念呢？我现在呢有一个脚本，这个脚本如果正常出的话，是以零代码正常退出的，这时候脚本就会记录它的正常退出的次数为一。那我是可以定义叫不成功退出，退出的次数的个数的。比如我定义为四。
05:02
它正常退出一次，我的次数加一，他又运行一遍，以零退出，那变成二，以此类推，变成三变成四，那变成四，达到我的要求以后，这个job。成功退出这个腾冲对数的含义就是这个叫保执行，完成了我就不需要运行了，需要大家注意一下。好，Job的生命周期也就等于我们的里面的炮的运行至成功数目以后结束。那如果我想要有一个根据时间去循环的这么一个job的话，这时候就需要借助到我们的cn job的控制器了。这里也说了，在给定的时间内只运行一次，周期性的在给定时间内运行。它比较类似于我们在Linux操作系统里的CN和cn table。一个是我们的定时计划任务，一个是我们的循环计划任务，对吧，典型的一个对比并且可job其实它也是通过创建在特定的时间创建job去实现的，在特定的时间循环创建job去实现我们的c c job。
06:22
并且它的配置方案其实跟我们的ta一模一样，分时、日月、周这么一种方案去实现。好，但是它的运行呢，有一些前提，比如你的K8S集群必须要大于1.8版本，其实到今天为止，基本上所有的公司，我说线上的哈，基本上都已经升级至1.14了，1.15还太新，1.14是没有问题的，因为很多的一些新的功能，比如我们的PVC的稳定版，比如我们的LS的调的稳定版，都是在1.13以后去实现的，包括1.1中完成完整的运行方案，在1.8的话，确实是太老了，所以c job其实在你的生态环境中，你根本都不需要去考虑啊，我到底能不能被运行，基本上是没问题的。
07:17
好典型的用法，给您的时间调度叫果运行，这就是它的原理，对吧？然后呢，周期性的创建运行的效果，比如数据库备份啊，发送邮件啊等等，都可以在我们的job中去执行，也就意味着如果遇到批处理级别的任务job job是你的一个最好的选择方案。那我们之前讲了哪些了？一般的一些应用程序。我们可以部署在我们的RC和我们的。不是RC哈，RRC已经被退出历史舞台了，对吧？RSRS和我们deployment，如果是一些类似于守护技能的方案，我们可以部署在我们set里。如果是一些我们的批处理的脚本，我们可以运营在我们job job里。
08:02
那我们之前也说过，对于do来说，对于doc来说，它更适用于运行的是我们的。叫什么无状态服务，那有状态服务怎么办呢？在我们的dock里，Dock给我们解决方案是我们的一个以存储卷的方案去加载对应的数据，对吧？在K8S里，它不仅有存储键，还给我们一个以特殊的一个控制器叫step set去完成我们的有状态服务的解决，当然说是这样说啊，其实现在还是有很多的一些应用程序，有状态的应用程序不方便部署我们的set会要不方便进部署进我们的K8S。那到底有哪些不方便部署进呢？比如我们的my circle，其实至今没有一个太好的解决方案可以把my circle这一个有状态服务部署进我们的K8S。
09:02
当然并不说不可以哈，我只是说没有那么，没有那么想象中的稳定。那比如另一些数据库，比如我们的DB，那就非常稳定的能够被部署进我们的K8S，它也是有状态服务对吧？好需要大家注意一下，那C呢，还有一些特点，比如第一个。这也是为什么它能作为所谓的有状态服务。部署的原因，第一个就是我们的稳定的持久化方案，Pod重新调度以后，还是能够访问到相同的持化数据，基于PVC去实现。这是怎么理解呢？假设现在我有几个我们的。容器是被我们的step。去部署的。好，那部署完成以后呢，他们可能都用到同一个我们的存储券，或者用到不同的存储线也是可以的哈，比如用到同一个存储券，这样是不是更为简单一点，对吧？好，那有一天呢，这个炮的死亡了。
10:03
那我们stepc的这个控制器是不是为了维持这个副本数目，会重新创建对应的，对吧？那他们还会继续使用上一个退出时用到的这么一个存储卷。也就这里的持续化数据并不会丢失。需要大家注意一下，这就是我们所谓的稳定的持久化存储的方案。好，当然这里是基于PVC去实现的，PVC是什么东西呢？我们后面会给大家去讲。下一个是我们的稳定的网络标识。Pod重新调度以后，Pona和我们的house name会不会不会改变，这个很重要，在我们很多服务里呢，我们再去创建对应的一些啊服务的连接方案的时候，都会以我们的po name为连接。对象或者house name为连接对象，那如果我的pod被重新建立以后，比如死亡以后，重新建立以后，它的名称发生改变了，这个肯定是非常不友好的，对吧？对于我们后边的自动化流程来说是非常非常不友好的，我们需要重新去寻找对应的服务的储新，重新去建立所谓对应的连接关系肯定是不太方便的。那对于我们step来说，它可以确保每一个port，它的name和name在sta的生命周期里完全不变。
11:30
很重要。它呢，是通过我们的无头服务去实现的，也就是没有class IP的，可以理解为没有IP地址和端口的class IP，这样可能更好理解一点。那还有就是我们的有序部署和我们的有序收缩。有序部署的含义就是pod的部署是有顺序的，在部署或扩展的时候，根据自定义的顺序进行，依次进行机从零到N1，在下一个po运行之前，所有的pod必须是running或ready的状态，基于可去实现。
12:09
好，这里需要注意一下，为什么是基于经历的可能呢？而不是基于我们所谓的呃，Stop或stop，或者是我们的read去实现的。原因是不管是start stop和read，它都需要去更改我们的内部容器的镜像，但对于来说，它是不需要更改的，只需要在sta set，在你的pod里面前面。对吧？在你的pad里面的容器均匀之前的前面加一你的C并不会对你的原有pod结构发生改变，所以这使它的解决方案怎么去实现这里的running或ready。这个在之前我们的炮的生命周期里已经给大家讲的足够详细了，自己动动脑袋应该能想得通，对吧，好。那有序收缩，有序删除，你会发现在扩展的时候，部署的时候它是零到N1的，在删除的时候它是N1到零的，这是一个倒叙关系，有很多人就会不理解了，对吧？哎，你创建的时候零到N1，为什么删除的时候不是零到N1呢？原因是给大家去讲解一下，你就应该能够明白。
13:21
那过来呢，给大家画一张图，我们看一下。好，现在我有这么一个结构，底下呢是我们的一个数据库，比如就是我们的MYSQL。上面呢，运行了我们的一些PPFPM。好在上面呢，运行了我们的一个实现了一个反向代理，对吧。
14:02
那这样的一种结构在部署的时候，你会发现我们应该部署谁啊，其实应该从底往上部署。也就意味着它是应该先部署我们的马SL，第一个部署级别在部署我们的PPLPM，第二个部署级别以及最终的N，这是一个部署顺序，那如果我想把这个服务给停止的话，它的顺序恰巧是相反的，你发现了吗？我是不是应该先填inx？然后我停我们的PPM，然后我再停买S，有可多人就会说了，那为什么不应该先听买SQL呢？那假设我们现在先把MYSQ停了，那这里的PIPM和nux是不是还在运行状态？那请求是不是有可能到？那就有可能到PM就有可能报错，很好理解吧，所以它的部署顺序你会发现它跟它的启动顺序恰好是相反的。
15:10
能理解我的意思吧，很重要这个概念对吧？好，那这个呢，是我们的step。那现在是不是又多了一个选择了，有状态服务部署至我们的is deploy？对吧，需要与我们的node为节点的部署进我们的DEMO side是一些批数理任务的话，部署在我们的job和job。有状态服务，那最后一个IPA是干嘛的呢？自动扩展，你可以理解为它并不是一个控制器，而是一个控制器的附属品。比如我先部署了一个RS。那我再去确定hpa。去运行管理这个RS，比如我先部署了一个deployment，我再去创建一个P去管理deployment。
16:06
能理解我的意思吗？它并不是一个直接的控制器，需要大家注意一下。它是以控制这些控制器为。木板的。好。那为什么需要这个控制器呢？它给我们实现的就是一个自动的扩容缩方案。可以基于我们的一些。指标去实现，比如CPU大于80%的时候，你给我扩容到十个节点。那CPU小于60%的时候，你给我恢复到四个节点。那这里的过程呢，就可以以HP的定义去实现。当然我们的K8S集群本身呢，是不支持这个功能的，它需要加一个资源收集的方案，给我们的HP提供一个资源的性能的指标，他才能去帮我们去做调整。这个在后面呢，我们的呃，实验中呢，也会给大家演示一次，没问题吧，好，那这个呢，就是我们的控制器的一些类型，包括它的一些意义，以及每种控制器适合在什么时候去运行，一定一定要好好的去理解一下，对吧，这样才可以在你去部署的时候做到心中有数。
17:20
好，那这节课呢，我们就先讲到这里，下节课呢，我们会大家去把每一种控制器给实现一下，当下我们的step set和我们的hpa呢，暂时就实现不了了，因为set需要接助到存储，Hpa呢需要借助到我们的呃，资源的收集模块，我们现在还做不到，那在后面的课程中呢，我们会讲解一个的时候，把它给大家去演示一下，没问题吧，比如讲解到我们的存储的时候，给大家演示我们step set，讲解到我们的资源利用的时候，给大家讲解到我们的HP。好，那这节课我们就先到这里，我们下节课再见。
我来说两句