k8s日常问题排障
一般流程
|
|
需要确保无SWAP,否则kubelet起不来
然后需要
|
|
看平面容器起来了没有,没有的话就得看容器日志排查问题
然后
|
|
看核心的namespace的pod有没有起来,有没有ready,有问题的pod名字就describe一下
下面所有示例都用kube-system作为查询的namespace,实际看你要查什么服务对应的namespace
|
|
如果正常pull拉得到镜像,那就得查log了
|
|
如果pod有多个容器类型,比如有api的,有controller的,那就得-c指定容器类型
|
|
有时候报错是一长串,得--tail 100
|
|
有时候得实时追踪,得-f
|
|
类似的,也有命令实时看pod的
|
|
pod有可能因为调度器问题马上拉起来又被删了,执行这些命令查询查不到任何东西
这时得查job
|
|
得查events
|
|
有时候因为状态改变太快了,job和events也得-w实时打印,操作后查看状态改变前后耗时以及出现了什么状态
有时候pod需要修改deployment的pull的镜像的版本(常见本地开发完备了要更新上集群测试),项目的manifest.yaml已经kubectl apply -f了
这时候就需要
|
|
查询需要修改的pod名字对应的deployments名字
然后edit
|
|
这时候起来的修改器类似vim和vi,可用/查询,可用 上下查看查到的关键词,用exit退出编辑,用:wq写入修改和退出修改器
修改后使用命令:
|
|
查询对应的pod有没有被重建,有没有如期ready
如果未能如期起来和替换,那么手动delete掉pod,因为有设置spec.replicas在deployment中,所以会重建pod
|
|
有时候需要本地开发,本地启动api和controller,那么就需要集群中设置对应的服务的pod的副本数量修改为0,避免调度冲突
|
|
在编辑器中找到spec.replicas字段并修改数值,然后保存退出(:wq)。
修改后使用以下命令监控副本数量变化:
|
|
或
|
|
还有查node状态
|
|
一般的k8s运维看BUG这些足够了,更多的就得知道底层代码逻辑去判断了。