00:00
接下来我们再来体会一下deployment里边的另外一种能力,叫自愈以及故障转移,那什么是自愈以及故障转移,那可以参照这个动画,比如呢,我们还是在cooper net里边使用p deployment,我们部署一个应用,那我们的deployment有可能在我们四台机器里边部署一些应用,比如我们就部署三份吧,但是呢,应用在长久的运行过程中,总有可能遭遇一些一些这个意外情况,比如我们这个机器宕机了,或者我们这个pod,也就说我们运行中的这个应用,因为应用里边呢还有容器,对吧,这个容器呢,突然发生了内存泄漏啦,或者各种故障,容器呢崩溃了等等等等,我们呢,就希望能出现这些故障的时候,K8S整个集群能感知到哪个应用呢?出现了问题,然后呢能自我修复,比如我们先来说自愈能力,以我们这个pod为例,我们这个pod呢,运行过程中突然崩溃了,崩溃了怎么办呢?当我们集群感知到这个pod崩溃以后。
01:01
我们K8S会尝试重启这个pod,如果重启呢,修复了,那说明一切OK,我们就把这种能力称为自愈能力,当然还有一种情况是你没办法修复的,举一个例子,我们运行这个po的这个机器,突然呢,它宕机了,整个机器呢,或者我们整个机器断电了,它呢没法在集群里边提供服务了,所以我们集群呢,感知到我们这个机器呢,可能已经下线了,这样的话呢,我们这个机器里边甚至于跑的所有应用,因为我们每一个机器未来可能会部署很多运行中的这些pod,我们就希望这个机器一旦下线以后,它里边运行的这些pod能在其他地方再拉起一份,我们把这个过程我们称为什么故障转移,然后相当于把这个机器里边的所有pod转移到别的机器里边再运行了,然后这个机器下线了,就下线了,我们在运行中的应用呢,还是在的,我们把这个过程呢,就成为故障转移,我们把这个过程可给大。
02:01
来做一个简单的演示,还是以我们之前部署的应用为例,我们可以先来看这么一个情况,比如库包CTRL了,Getar pod,我们以前呢,部署的这个应用先来看有几份,我是杠N1好来监控,我们现在部署的这个应用呢?有三份,包括呢,这些应用都部署到哪台机器了?酷标controlr了,Get po,杠OY的,我们来看一下这些应用呢,在NUDE1 node2机器呢,可能都有,那我呢,随便连上一个,比如我来连上NODE1机器。然后呢,我们来模拟这么一件事情,来模拟什么事情呢?假设我们的这个应用来看哪个应用在NODE1,就是我们的这个叫W6SSHC这个应用才弄DE1,那么我们这个pod呢,在弄DE1一定是以容器的方式启动的,所以我可以刀开,我们让他来检查有没有哪一个容器名差不多叫这个样子的,来回车能发现呢,会在我们底层确实有一个容器,这个容器呢以NGS镜像启动的,那我就来模拟第一种,我来把这个呢加到下边。
03:14
好,我来模拟第一种啊,来模拟第一种,我就是把这个容器杀死,就是这个W6SHC,我来模拟这种情况的,这个容器突然给停了,呃,容器呢,可能会有各种原因突然发生了故障,比如我把容器停了,容器停了以后呢,我们来看效果,诶容器区呢,感知到这个WHC呢,已经有问题了,它状态呢是completed,就是已经完成,但这个容器呢,有问题,有问题呢我们来等一会看K8S会来做什么样的事情。来监控整个的变化状态,诶我等了一会以后呢,现在它已经是runninging状态,而且这一块RESTART1标志,我们把这个容器呢自己重启了一次,所以我们把K8S里边的这种我们称为自愈能力,那这种自愈能力呢就会非常好,在我们整个应用线上以后,哪些容器突然出现故障,我们K8S呢,就会把它杀死重启,所以我们把它称为自愈。但有一种情况我们来模拟假设呢,当我们这个NODE1,比如杠oy的,当我们这个NODE1机器直接宕机了,会怎么办?好,我现在呢,给它来进行停机,我来到我们的这个NODE1里边,那停机以后呢,我们NODE1都失联了,对吧,相当于你想还想再NODE1机器上,你把这个呢重启,这是不可能的,所以。
04:36
我们来把它测试一下,我来关机,我直接强制关机,点一个确定好,当我们一关机以后来模拟NOTE1呢,突然炸好,我们这个NOTE1呢,已经连不上了,连不上以后呢,我们来看整个集群会发生什么样的现象,以前我们这个W6HHHC是不是在NODE1,那么来稍等一致,因为集群整个宕期以后呢,会有一个阈值,比如五分钟,我们五分钟内,五分钟感知到这个应用呢,都不能提供服务了,我就给你重启,所以呢,我在这儿视频暂停,我等一会儿给大家看我们最终的效果。
05:09
当然等之前呢,我们大概关注一下W6HC这个应用呢,是55分钟对吧,如果五分钟那大概就是60分钟以后,这个应用呢,可能就会在别的机器会产生,包括呢,我现在使用这个叫库ctrl get port,杠W-W呢我来监控这种呢也是监控,而且呢,这种是我们K8S给我们提供的功能,这样如果他某一个应用发生了哪些问题,它会把整个的这个状态记录啊,列表的方式打印到这。我们要注意就是这个W6HC应用,按照我们以前的想法,那就应该是我们的故障转移,就是这个应用,这个应用干嘛应该从我们那个机器删除,然后呢重新拉起一份,因为我们的以前部署的deployment总是要保证是不是要有三个pod在运行,一旦呢,发现有一个pod已经失联了,出现了问题,那它一定会在别的机器呢再起一台,因为我们现在呢,就只有两个工作节点,NOTE1和NOTE2,所以呢,我们接下来未来兴起的应用一定还会在NOTE2上,好,我们就来等一等这个过程。
06:22
好,我们等了大概五分钟以后,然后我们看到了整个的这个状态变化过程,这个W6HHC,它呢状态已经是terminating,就是相当于把它要中断,然后呢,它会兴起一个叫HZ2XF,然后呢,最终它经过了一系列的状态变化,就是我们的杠W命令,可以打印出我们整个的状态变化过程,这样的话呢,我们最终达到了running状态,就是我们这个容器正在运行了,所以此时我们就会发现,其实真正的正在运行的这几个pod应该是这个这个XN598XPPNH以及HZ2XF就是这三个pod,所以这就是我们说的故障转移,但是有些同学就会想,诶,这个故障转移为啥他要等五分钟这么久吗?因为在我们整个未来集群里边,我们某一台机器可能会会由于网络故障,可能经常会导致失联,上那么一会儿对吧,30秒啦,一分钟啦,两分钟啦,可能都。
07:22
正常,所以如果我们把这个阈值设的很小,诶只要一秒我发现它有问题,我就把它杀死,再在别的机器启动,那你的整个K8S集群那天天在杀泡的,在起泡的,所以呢,我们应该有一个比较合理的阈值,比如我们调整五分钟,或者呢,你们的整个集群比较快,那你可以调成两分钟一分钟都行,这是我们说的自愈以及故障转移,最终呢达到效果就是只要有任何一个pod出现了问题,那我总会给你保证,你以前说你要部署三个应用,那就一定会有三个应用。也就是说我们deployment就是保证我们副本数量的。
我来说两句