摘要： 容器cpu异常高和卡顿，导致服务异常。 排查： 1、top -H -p 占用cpu高的pid 2、printf "%x\n" 线程号 结果： 这个负载高，但CPU、MEM都实际利用率不高，一般都是进程或线程数多导致的 3、jstack 占用cpu高的pid | grep 0x161 -A90 4、p 阅读全文

摘要： 背景： Pod处于Terminating 情况一： 排查： 1、kubectl delete pod pod名 依旧是无法拉为Running状态 2、kubectl get node 输出显示两个Node是NotReady 3、两个节点ip可ping通，登陆到节点上执行 systemctl rest 阅读全文

摘要： 背景: 四个同一副本控制集的Pod被频繁的重拉，数日内次数达到了百余次。 问题原因 node资源不足。 排查： 1、kubectl describe pod $pod名 输出只显示就绪探测失败。 就绪探测是当时Pod重拉时候未Running 1/1时显示的，Running 1/1后此报错就不用关注了 阅读全文

摘要： 背景： Pod状态是imagepullbackoff 原因可能有多种: 1、镜像名称无效，例如拼错镜像名称，或者镜像不存在 解：修改镜像名称和标记来解决该问题，或者将正确镜像上传到仓库中。 2、镜像仓库中丢失此镜像及Pod所在节点上丢失了镜像。 解：需要从新上传镜像到仓库中，或者同一Pod部署在了多 阅读全文

摘要： 报错见下图（此结果为启动新的Pod后describe的结果）： 但是Pod的状态是Running的，这个问题属于就绪性探测失败，需要检查就绪性探测失败的原因。 1、查看Pod的就绪性探测写的是什么内容，根据探针内容进行排查。 输出结果显示就绪性探针执行的是一个脚本。 2、登录Pod中查看此脚本内容。 阅读全文

该文被密码保护。 阅读全文

摘要： 在node的/etc/docker/daemon.json中配置了私有镜像仓库地址后已经无法连接此镜像仓库。 背景：已经重启了daemon-reload、docker，但依旧不生效。 报错内容： daemon.json的配置格式： 解决方案：重启daemon-reload与docker时需要先sto 阅读全文

该文被密码保护。 阅读全文

摘要： watch命令可以动态查询系统时间。 watch "date" (watch命令默认每隔2秒刷一次输出结果，使用“-n”参数可以改变默认值。) watch -n 1 "date" （此命令可以输出年月日及时、分、秒，并且为一秒钟刷新一次当前系统时间） watch -n 1 "date +%T" （此 阅读全文

摘要： 问题描述 副本控制集为daemonsets类型Pod，被delete后没有被重新拉起。 原因 此问题Pod所在node的/etc/docker/daemon.json文件被修改过，修改daemon.json时内容写错了，导致重启docker跟daemon-reload失败并报错，于是把daemon. 阅读全文