K8s常见故障排查思路

step_1: kubectl get node

1. 查看集群节点是否处于 Ready 状态
        a. 如果是Ready状态,再使用kubectl describe node <nodeName>, 资源使用率
        b. 如果是NotReady,则使用kubectl  get node -owide 查看对应的节点,然后登陆到对应节点上, 查看kubelet 和docker 服务是否正常;

step_2: kubectl get cs

1. 查看集群关键组件的状态是否是 Healthy
        a. 如果是,不予理睬
        b. 如果是Unhealthy 状态,使用则使用kubectl  get node -owide 查看对应的节点,然后登陆到对应节点上查看kubelet 和docker 服务是否正常;

step_3: kubectl -n <namespace> get pod -owide <-w>

查看pod 是否处于running 状态

step_4: kubectl -n <namespace> describe pod <podName>

查看非running 状态到具体可能原因

step_5: kubectl -n <namespace> logs -f <podName> [-c <containerName>]

原文地址:https://blog.51cto.com/noican/2433632

时间: 2024-10-10 21:39:04

K8s常见故障排查思路的相关文章

AD常见故障排查思路

AD常见故障 活动目录在域环境中起着非常关键的作用,它与各种应用联系紧密,如域用户登录.访问域内共享资源.部署组策略等都需要通过活动目录.活动目录不仅内部的众多功能模块联系密切,而且网络的连通性,网络协议和安全策略等有关,所以处理活动目录时必须综合考虑. 在实际应用中,可能会遇到以下几种AD故障类型. 域连接失败:将计算机加入到域的时候,提示找不到域. 域无法登录:客户端登录域的时候始终提示用户名或密码不正确,或登录域后,无法正常访问网络共享. 域登录缓慢:客户端在登录域的时候非常缓慢,严重影响

AD常见故障排查---运维笔记

在维护AD的时候会经常出现一些故障,良好的问题解决方法,可以在尽可能短时间内解决问题. 一·常见故障类型 (1)域连接失败:加入域时,提示找不到域. (2)域无法登陆:登录时密码不正确或登录后访问不了共享资源. (3)域登录缓慢:登录时非常缓慢 . (4)组策略部署失败:组策略未生效,或只对部分部分用户账户生效. (5)域控制器之间复制失效:AD数据或DNS记录不能同步更新. 二·AD常见故障排查思路 (1)确认单一用户账户的的故障:在于控制器中查找用户账户的所有信息点去判断故障点及其原因. (

51CTO学习笔记--Linux运维故障排查思路与系统调优技巧视频课程(高俊峰)

51CTO学习笔记--Linux运维故障排查思路与系统调优技巧视频课程 第一课 Linux运维经验分享与思路 1.一般把主机名,写到hosts下    127.0.0.1    hostname,因为很多应用要解析到本地.oracle没有这个解析可能启动不了. 2.注释掉UUID以及MAC地址,需要绑定网卡的时候,这个可能会有影响. 3.磁盘满了无法启动,  var下木有空间,无法创创建PID等文件,导致文件无法启动,按e   进入single  然后b  重启进入单用户模式. 4.ssh登陆系

【集群实战】NFS服务常见故障排查和解决方法

NFS,全名叫Network File System,中文叫网络文件系统,是Linux.UNIX系统的分布式文件系统的一个组成部分,可实现在不同网络上共享远程文件系统. NFS由Sun公司开发,目前已经成为文件服务的一种标准之一(RFC1904,RFC1813). 其最大的功能就是可以通过网络,让不同操作系统的计算机可以共享数据,所以可以把NFS看做是一个文件服务器.NFS缺点是其读写性能比本地硬盘要差一些. 一.NFS服务常见故障排查: NFS服务出现了故障,主要从以下几个方面检查原因: (1

Linux运维常见故障排查和处理的33个技巧汇总

作为linux运维,多多少少会碰见这样那样的问题或故障,从中总结经验,查找问题,汇总并分析故障的原因,这是一个Linux运维工程师良好的习惯.每一次技术的突破,都经历着苦闷,伴随着快乐,可我们还是执着的继续努力,从中也积累了更多的经验,这就是实践给予我们的丰厚回报. 下面汇总了我做项目过程可能出现的故障及解决方法,看看是否与你有共鸣,并对你有帮助? 第一:常见问题解决集锦   1.shell脚本不执行    问题:某天研发某同事找我说帮他看看他写的shell脚本,死活不执行,报错.我看了下,脚本

cpu突然飙升故障排查思路

处理过线上问题的同学基本上都会遇到系统突然运行缓慢,CPU 100%,以及Full GC次数过多的问题. 当然,这些问题的最终导致的直观现象就是系统运行缓慢,并且有大量的报警. 本文主要针对系统运行缓慢这一问题,提供该问题的排查思路,从而定位出问题的代码点,进而提供解决该问题的思路. 对于线上系统突然产生的运行缓慢问题,如果该问题导致线上系统不可用,那么首先需要做的就是,导出jstack和内存信息,然后重启系统,尽快保证系统的可用性. 这种情况可能的原因主要有两种: 代码中某个位置读取数据量较大

rsync 常见故障排查及思路

当我们在进行rsync操作时,会遇到各种各样的问题,那么下面就对通过客户端返回的错误信息进行分析: 有很多新手,在客户端进行rsync推拉操作时,不清楚到底有没有出现错误,那么我们可以输入以下命令来进行查看, 在命令行输入   echo $?    回车后如果显示0,则表示没有出现错误.恭喜你,操作成功.但不幸的是,也会由于操作等其他原因出现各种错误,下面就进入主题: 常见错误: 1.  No route to host (113) [[email protected] oldboy]# rsy

Linux系统运维故障排查思路

一些处理问题的一般思路   1)重视报错提示信息,每当错误出现,都会给出错误提示信息,一般情况下,这个提示基本定位了问题的所在,因此一定要重视这个报错信息,如果对这些错误信息视而不见,问题永远都得不到解决.   2)查询日志文件.有时候报错信息只是给出了问题的表面现象,要想更深入的了解问题,必须查看想应的日志文件,二日志文件有分为系统日志文件(/var/log),和应用程序日志文件,结合这两个日志文件,一般就能定位问题所在.   3)分析定位问题.这个过程是比较复杂的,根据报错信息,结合日志文件

20170413B端业务访问故障排查思路

现象: 1.全国用户电视端页面无法显示,刷不出版面. 2.后端服务无法打开,报错,504,502   显示服务器端业务故障超时. 3.其他业务也出现缓慢情况,并不严重. 排查: 1.系统服务排查,常规负载检查,apache配置,本地curl测试,查看apache进程状态被挂起,发现系统本地访问80端口不通,重启服务无效~ 2.mysql 数据库未见明显报错异常,刷页面到504页面  应该还没到bd访问,排除数据库问题 3.从多个客户traceroute我们域名来检测下网络,结果都不通..  怀疑