k8s日常问题排障
一般流程
|
|
看核心的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
这些足够了,更多的就得知道底层代码逻辑去判断了。