一、单副本pod
按照k8s的调度法则,即便某个应用部署了单个pod,此时这个pod所在的node节点宕机了,k8s也会把应用转移到另一个可用的节点上去。
下面就来验证下。
可以看到,demo这个单副本的应用现在是在node3(192.168.0.53)
上,为了更好的验证,我写了个脚本用来调用这个demo应用的接口,获取返回的code值,并启一个定时任务,每10秒钟调用一次。
将192.168.0.53
关机,这时候pod是Unknown
的状态。
过了大概8分钟左右,可以看到调度器又在node1(192.168.0.51)
上会启动了一个pod。
但是根据脚本返回的结果,在这8分钟里面,demo项目的接口是调不通的。
然后我们把node3(192.168.0.53)
再启动起来,集群就会把之前在node3(192.168.0.53)
上的状态为Unknown
的pod给删掉。
二、多副本
接下来测试下多副本的应用。
把刚才的demo应用,点击上边的+
号让副本数来到2。可以看到在node3(192.168.0.53)
上启动了一个新pod,让demo的pod数量达到2个。
这时候把node3(192.168.0.53)
关机,这时候node3(192.168.0.53)
的pod是Unknown
的状态。
等待8分钟左右,可以看到调度器又在node2(192.168.0.52)
上启动了一个pod。在这个过程中,始终还有node1(192.168.0.51)
在提供服务,并且根据脚本返回的结果,demo项目的接口是一直掉的通的。这样就实现了应用的高可用。因此在生产环境部署应用的时候,应该保证每个应用所启的pod数知道为2个。
然后把node3(192.168.0.53)
再启动起来,集群就会把之前在node3(192.168.0.53)
上的状态为Unknown
的pod给删掉。