在遇到了实例 运行异常 的时候,首先应该按照本节文档,进行初步排查。
注意,这些镜像不可以运行。同时,某些一次性运行后会自动退出的镜像也不可以在平台上运行。
Rainbond会默认为组件分配内存:
该值可以在创建组件时定义,也可以在组件伸缩界面随时修改。然而,不是所有组件都可以用默认内存运行。当内存分配的过小时,会导致组件实例内存使用率过高,甚至根本不会继续启动。
具体表现为:
Rainbond支持 有状态服务类型 和 无状态服务类型 的部署。
有特定的组件要以指定的类型部署。比如 zookeeper、mysql等组件,一定要使用有状态服务类型。否则也可能会遭遇运行异常。
例如MySQL组件,在首次启动时,一定会需要以下三个环境变量中的一个:
如果没有指定这种特定的初始化条件,组件不会进入初始化流程。
需要确定当前组件到底发生了什么,可以查看日志:
Rainbond组件默认配置了健康检查机制。组件启动时,会根据健康检查中配置的端口,以特定的方式检查组件是否正常启动。如检测不通过,则会有运行异常状态。
健康检查的端口,来自于组件开启的端口,默认开启5000端口。所以,务必确认平台上组件开启的端口,和组件运行监听的端口一致。
平台提供全局组件状态查询命令 grctl msg get
该命令返回:
经过 初步排查 后,如果并没有发现有异常的原因,请遵循本节,进行针对组件的深入排查。
切换到问题组件的伸缩界面,获取查询命令:
在管理节点执行该命令,返回组件详情:
针对组件级别的错误排查,由此命令获取的 关键信息 包括:
PodIP 系统分配给pod的IP地址,如果此项为空,检查RainbondSDN(calico/flannel)组件是否正常。
PodStratTime 当前pod启动时间的记录,该记录和 Containers.State.Running 的启动时间对比,可以判断容器是否有过自动重启。如果有重启,参考容器日志查询
根据PodStatus返回值来初步排查问题。
当前组件处于 运行异常 的情况下,该值一定会处于 False 。当该组件正常运行后,该值自动变成 True 。
当pod处于 Initialized 为 False 的状态时,需要借助 POD状态查询 来排查问题POD事件。该状态大多由init容器找不到镜像引起。查询到POD事件后,推送指定镜像即可。
当pod处于 PodScheduled 为 False 的状态时,表明所有可调度计算节点剩余资源都不足以承载该pod。检查计算节点是否都处于可调度状态,确认集群资源是否需要扩充。
根据Containes.State返回值来初步排查问题。
当POD中的某个容器出现这个状态,说明当前容器完成调度,但是无法运行起来。需要借助POD状态查询 来排查问题POD事件,结合 容器日志查询 来加以解决。
在Rainbond平台使用时,用户有时会为组件安装各类插件。需要注意的是,某些插件是不可以同时使用的,比如 服务综合网络治理插件 服务网络治理插件 ,二者同时使用,会导致其中的某一个容器处于 Waiting 状态,并最终导致组件运行异常。这和它们同时工作在POD网络出口有关。
当POD中的某个容器出现这个状态,说明该POD正处于终止退出的过程中。需要借助POD状态查询 来排查问题POD事件,结合 容器日志查询 来加以解决。
当你不知道pod发生了什么问题的情况下,可以借助 kubectl 命令来排查问题。
kubectl describe pods <PodName> -n <Namespace>
一般情况下,我们可以直接关注返回结果中的 Events 事件记录。这里记录了当前POD启动时的全过程,并对错误直接予以显现。常见错误:
docker push <时间信息中拉取失败的镜像名>
Rainbond在组件控制台界面上提供了组件日志输出,该日志集成当前组件下所有POD中所有容器的日志输出。
绝大多数情况下,我们可以在Rainbond组件控制台的日志界面获取到当前组件日志,并借此判断运行异常原因。 一旦Rainbond组件控制台日志没有任何推送,我们需要用下面的手段获取日志
kubectl logs <PodName> <Containers.Name> -n <Namespace>
kubectl logs --previous <PodName> <Containers.Name> -n <Namespace>
如果你在阅读了这篇文档后,组件依然无法运行,你可以: