00:00
好,那我呢,先来给大家补充上一个问题,上一次呢,我们部署完了若一,但在我某一次关机,然后再开机以后,我发现呢,若一这一块有呢,有一些应用部署出现异常了。若一的这几个微服务开始报错,而报错的整个原因呢,排查起来其实倒不是这一块的问题,而是出现在我们部署的有状态副本及那的问题。因为我们现在的这个NAS呢,我们是连向数据库的,所以呢,如果我们关机再开机以后,有可能会导致这样,我们一关机一开机,我们NUS的这个pod呢,K8S给我们开始重启,一重启以后呢,它要连上数据库。但有,有时我们这个数据库有可能没有准备就绪。所以呢,那斯就连不上数据库,那那S连不上数据库以后呢,他就开始会报一些异常,而且呢,并且不会在数据库恢复以后再重试重新连接上。所以我们会看到在NAS的这个日志里边呢,有no data source set,那S只要不准备就续号,那我们的这些微服务啊,其实将会有大面积的不可用。
01:07
所以我们要解决其他的这些问题,比如我们来随便进一个sister。所以我们来看它的这个日志。这个日志呢,好多报的都是这个什么client这个客户端啊,连server连不上,都是连我们这个库斯连不上的。所以呢,我们想要把这些问题解决,解决NAS就行了,而这个NAS怎么解决呢?我们引入一种机制。就是我们现在想要做的顺序,就是能不能等my circle整个都启动成功了以后,再让K8S启动那这个pod。其实想要做按顺序启动这个事情挺麻烦,他有另外一种情况就能解决。比如我们让K8S启动NAS pod的时候,我们明确的告诉K8SNAS在什么情况下才算它真正的启动成功,如果呢,拉斯没有启动成功,我们就让K8S重试。
02:01
举一个例子,我现在呢,进入NAS的这个控制台,如果那克S一切启动成功,你访问NAS的,因为我们na克S是8848端口,所以我访问本机的。8848下的NAS这个路径它呢就一定是访问通的,再举一个例子,我现在呢,把这个NAS先给它干掉。然后呢,我再来启动一份新的。因为现在呢,已经有my circle了,所以我们新的拉斯一定会启动成功。看一下这块呢,一定是启动成功的,那如果它启动成功呢,我再来使用我访问他8848127.0.0.1冒号8848下的这个NAS回车。哎,我们发现呢,它其实是有有访问动静的,不会给我们打印什么,呃,连接有问题。我们在这呢,访问它是OK的啊,访问它是OK的,只要没有报错,虽然给我们没有返回什么数据。
03:02
如果我们访问8848的话呢,它返回的是一个404页面,而8848下的这个S这个路径,它会给我们呢,有返回值。所以呢,我们现在来看一下,包括此时如果我们再来连上NAS,我们此时来连上我们的NAS。我把我们拉S的集群外地址。只要拉古斯一切部署成功。我们在这呢,连上NAS也是可以的,我先登出,所以呢,NAS的其实它的整个登录也叫login,这是logn页。也就是说你呢,只要访问拉库S的8848能访问的通,那说明我们拉S就是启动成功了。这是我们在某一次,我在某一次开机以后呢发现的问题,但是我们要叫NAS。所以呢,我就利用这个机制,我呢可以让T8S做一个什么事,叫健康检查。
04:07
就是呢,K8S起的这个pod,由K8S不停的检查这个pod是好的还是坏的,如果是坏的话呢,让K8S把这个pod重启,所以我们把这个机制呢,叫健康检查机制。健康检查机制呢,可以让K8S不断的给这个pod发送请求,比如我们让K8S呢,每隔一秒就给我们的这个NAS8848就给这个路径发请求,只要我们发请求是通过的,那说明这个pod就是健康的,如果呢,不通过,说明这个pod呢有问题,那有问题呢,K8S就认为这个pod是呃,我们启动完蛋的,那K8S呢,就应该把它干嘛,不断的尝试重启。所以呢,我现在在NAS的这一块,我在我们来把它改一下就行,我来编辑配置模板,在容器组模板里边,我们是按照这个镜像来起那库S的,我点一个修改。
05:01
修改呢,我们走到下边这呢,会有一个叫健康检查器,我们使用它。而且呢,我们使用就绪检查,就是呢,我们这个NAS是不是已经OK了,如果OK的话呢,那我们这个NAS一切正常,如果没有OK,我们那S没就绪,那我们就应该让K8S不断的尝试重启,当然这还有一个最重要的叫存活检查。就绪检查,如果那克斯就绪了,说明能接收请求了,其实我们接下来呢,访问那克斯的负载均衡网络的那个service,那克斯就能处理请求了,而我们现在呢,其实就不就绪。不太重要,我们更重要的是存活,我们认为只要那克S的8848没有访问通,那S就算是没有正常的存活,就是应该让K8S重新启动,所以我在这呢点一个它,我让K8S呢,自己检查请求,检查什么请求。检查拉这个路径的请求单是8848端口。
06:01
初始延迟呢,我们可以给一个一定的初始延迟,比如延迟上20秒以后,来开始检查我们的这个拿是否存活。这个超时时间一,超时时间一指的是,比如我写一个三指的是什么呢?这是我们K8S起的,那support就是呢,我每次给你拿发请求最多呢,三秒以内你就得给我返回,如果三秒以外你给我返回,我也认为你这是没有存活探测频率十,也就说我每隔十秒可以给你发一次这个请求。探测你是不是存活的?然后呢,我就来点击一个对号,我们相当于呢,添加了一个存活检查的这个命令,我点一个对号,我点一个保存,点一个确定。那这样的话呢,以后我们这个NAS到底有没有正常活着,然后呢,我们在这儿K8S就会自己判断。K8S呢,会利用这个探针存活探针,我们这个检查,然后呢,我们在这个存活探针呢,一直会每隔十秒。
07:01
20秒之后,每隔十秒检查我们8848这个端口,而现在呢,我们其实是活着的,所以呢,以后呀,我们利用这个机制,那能做到效果是什么呢?就算我们K8S掀起了NAS。它呢,每隔十秒一检查,拿X88斯八端口有问题,然后呢,他就把那X删了再重启,直到什么时候就检查没问题呢,直到我们马S狗容器它只要启动起来了,那斯在某一次它启动以后呢,能连上马S了,那S就能正常启动了,我们的存活探针检测就能检测成功了,所以我们把这种存活检查机制我们称为叫探针。那我们利用呢,相当于一个小小的这个请求,我们能就就能检查那克斯有没有活着。好,那我们最终呢,就是利用这个健康检查机制,我把这个拿古斯呢重新改一下。以后呢,我们就算重启我们的这个项目来我们这个存活检测,只要一通过以后。大家会发现剩下的这些微服啊,等一段时间它就会自己恢复,因为我们spring cloud连那S的时候,如果第一次连不上那S,它会等一阵尝试重连,所以呢,等一阵以后呢,它会自己恢复。
08:12
或者呢,大家着急的话呢,可以把它先删了,然后呢,让他再起一个。也是一样的效果的。比如现在我们兴起的,现在就OK了,只要拉S我们就去这些微服务呢,就能OK。把这个删了。来重启。好,所以呢,这就是我们啊发现的问题,发现问题呢,大家就排查就行了,主要我们利用存活探征可以呢,判断拉斯如果没有健康的情况下,我们让K8S呢,给我们重新再启动一个NAS。
我来说两句