江晓龙的博客

原因其实也简单，我们虽然只是将存储数据的目录删除了，但是并没有删除Storageclass创建的PVC啊，当Jenkins再次重新部署时，Storageclass发现之前为Jenkins创建过PVC，那么就可以接着使用，没必要再创建一个新的PVC，占用系统资源。3）通过Pod输出的日志，我们基本上就可以定位问题所在了，Pod要挂载Storageclass创建的PVC卷，挂载的这个PVC卷原来可能创建过，但是存储空间被删除了，从而导致无法被挂载，PVC卷，已经存在了。意思是说无法挂载这个。

原因其实也简单，我们虽然只是将存储数据的目录删除了，但是并没有删除Storageclass创建的PVC啊，当Jenkins再次重新部署时，Storageclass发现之前为Jenkins创建过PVC，那么就可以接着使用，没必要再创建一个新的PVC，占用系统资源。3）通过Pod输出的日志，我们基本上就可以定位问题所在了，Pod要挂载Storageclass创建的PVC卷，挂载的这个PVC卷原来可能创建过，但是存储空间被删除了，从而导致无法被挂载，PVC卷，已经存在了。意思是说无法挂载这个。

基于这种情况，可以在K8S集群中定义Service资源对象，充电一个负载均衡器的作用，定义一个唯一的服务访问入口，这个地址可以是域名也可以是Service资源的地址，由Service资源管理一个服务的所有Pod资源，服务之间的调用就可以通过Service资源访问到具体的Pod资源。3）查看Service资源的详细信息后，发现没有关联上任何一个Pod资源，那么问题也就出在了Service资源这里，Service资源管理Pod资源是通过标签选择器进行关联的，下面我们来查看Pod定义的标签列表。

在K8S集群中部署的应用程序都是以Pod的形式部署的，我们在部署Pod资源时都会指定Pod资源的副本数，但是这个数量是写死的，平时可能启动10个Pod副本就可以满足日常的业务需求，但是当压力增大时，启动的10个Pod副本可能无法满足并发请求，从而就会造成影响。

每一台Node节点中默认限制最多运行110个Pod资源，当一个应用程序有成百上千的Pod资源时，如果不扩容Node节点或者修改最大Pod数量限制，那么就会导致部分Pod资源无法正常运行，因为节点已经没有资源可以被调度了。2）从Pod的详细信息中可以得知，3个节点中，没有一个节点符合Pod的资源设置，其中有2个节点内内存不足和一个节点是Master，污点不能被容忍。当Pod资源数量太多，已经达到了Node节点默认的110个Pod时，新创建的Pod资源会一直处于Pending状态，并且大量的Pod会频繁重启。

2、ApiServer将创建Pod的请求告知Scheduler组件，Scheduler组件会通过某种计算方式，将请求的资源进行调度分配，将Pod与Node的调度关系进行绑定并告知ApiServer。在K8S集群中，Pod资源是最小的单元，任何服务都是以Pod的形式部署运行的，Pod资源需要调度到具体的Node节点中运行，在日常运维中，可能会遇到Pod资源无法调度的问题。3）Node节点上的确是存在污点，当Node节点关机无响应后，K8S会为Node节点自动添加一个不可调度的污点，从而使Pod资源无法调度。

在一个Node节点中可以运行多个Pod资源，每一个Pod资源中可以运行一个容器或者多个容器，同时共享一个网络存储资源，一般情况下，一个Pod资源中会运行一个容器，如果Node节点不可用，就会导致该Node节点上运行的Pod容器不可用，Node节点是否健康，会直接影响该节点下所有应用程序容器的监控状态，都会处于不可用的状态，甚至会影响K8S集群。Kubelet组件负责Pod资源的创建、挂载volumes、监测Pod资源、调用Docker运行容器、上报Pod资源的状态以及Node节点的状态。...

无论是什么原因，只要是无法解析域名，就按照下面几步进行排查：1）排查Coredns组件的运行状态是否出现异常，查看运行日志获取关键信息。2）查看Node节点的/etc/resolv.conf文件中DNS地址是否配置正确，再进入到Pod中查看/etc/resolv.conf文件中DNS地址是否配置正确。3）通过K8S资源编排文件中的dnsConfig配置参数，手动配置搜索域。...

当程序出现丢包后，可以使用tcpdum抓包工具进行分析，一般出现丢包的现象后，在抓包时就会显示发送了大量的SYN的数据包，但是不会返回ACK包。Pod资源可能会由于网络原因产生丢包的现象。

当出现Pod资源网络连接超时时，都可以按照如上思路镜像排查和分析。如果还是无法解决问题，可以试着在目标端抓包然后进行分析。在目标端进行抓包时会发现请求的源IP都是K8S Node节点的地址，没有Pod资源的IP，这时因为Pod在请求集群之外的服务时，会将IP通过NAT方式转换成Node节点的IP，由Node节点去请求对应的服务。...

下图报错的大致意思为sa用户systemanonymous没有权限对jenkins命名空间下的pod进行操作，奇怪的是我yaml中明明已经指定了sa用户jenkins-sa，并且jenkins-sa是绑定的cluster-admin角色，按理说不可能对某个命名空间下的pod资源无操作权限，而且使用anonymous用户表示的是rbac资源认证失败，只有失败的情况下才会使用anonymous用户。不过这一点只是我一点点找出来的，官方并没有明确说明。当我勾选了禁止http证书检查后产生了新的报错。...

在K8S集群中，可能会出现Pod与Pod之间无法通信的现象，也就是说Pod无法跨Node主机进行通信，Pod与Pod之间网络不通讯会导致无法请求Pod中的服务，Apiserver也可能会无法获取Pod的运行状态，产生一系列问题。1）首先排查Calico网络组件的运行日志，可以在日志中获取关键信息，如果是Pod网络与物理机网络重合导致的网络不通讯，会在日志中看到相应的报错内容，此时我们就需要修改Pod网段的IP地址了。6）增加新的Node节点，验证是否是新的Pod地址，然后驱逐旧Node节点中的Pod。...

K8S集群有自己独立的内部网络，整个集群的通信都需要依赖网络插件，常见的网络插件有Calico、Flannel、Canel等等。Pod与Pod之间的通信故障是经常会出现的现象，可以去排查网络组件Calico和Kube-proxy这两个组件。Pod自身网络出现问题，会导致Pod中多个容器通信出现异常，具体排查网络组件Calico即可解决问题。当出现此故障时，一定是Calico网络组件产生了问题，需要排查具体的日志。...

使用Kubeadm方式部署的K8S集群，在初始化的时候生成的Token的有效期为1天，当过期之后Token就无法使用了，也就意味着，在Node节点执行。Node节点加入集群时不光要指定Token值还需要指定CA证书的HASH值，HASH值是永不过期的。命令加入K8S集群时就会失败，可以通过下面的方法重新生成Token。不管是Node节点还是Master节点部署完成后，都是无法使用。命令时会报错权限的问题，需要手动进行配置。...

Pod资源中容器都是提供具体的应用程序服务的，如果没有健康检查机制，那么K8S集群就不知道Pod资源的运行状态，只要Pod处于Running状态，K8S就会认为里面的容器以及服务都是健康的，如果是这种现象，那么K8S集群的故障自愈就起不到作用了。当经过这两种健康检查检测后，容器的状态才会成为Ready，并且就绪性检测会每隔一段时间就会检测。当Ready的值为1/1时，才能对外提供服务。两种探针的方式都相同，分别有HTTPGet方式、TcpSocket方式、Exec方式三种。......

ExitCode137容器被杀死后，会返回该状态码，表明容器收到了SIGKILL信号，与Linux汇总的kill-9效果类似，当收到该类退出码，很有可能就是健康检查失败后，触发了自愈机制，将Pod删除重建了，最有可能的原因就是容器消耗的资源超出了配额限制，最终引发了OOM。根据经验判断，容器状态异常，很有可能与容器中运行服务的资源消耗有关，当超出配额限制，就会导致容器异常，健康检查失败也会导致容器状态异常。当一个Pod资源中的容器是由于触发了OOM，导致容器异常退出，此时的容器状态就是非正常的。...

Error状态是CrashLoopBackOff状态之前的一个错误状态，Pod资源处于Error状态的原因可能有以下几种：1）排查Pod的状态2）查看Pod运行的详细日志从中获取线索3）排查容器运行的日志获取关键信息4）排查Kubelet日志以及Node节点系统日志从中获取关键信息...

Error状态是CrashLoopBackOff状态之前的一个错误状态，Pod资源处于Error状态的原因可能有以下几种：1）排查Pod的状态2）查看Pod运行的详细日志从中获取线索3）排查容器运行的日志获取关键信息4）排查Kubelet日志以及Node节点系统日志从中获取关键信息......

CrashLoopBackOff状态一般都是Pod资源中的容器出现了问题，可以有以下几点原因：CrashLoopBackOff状态存在偶发性，可能上一秒还是Running状态，下一秒就成了CrashLoopBackOff状态了。一般Pod资源处于CrashLoopBackOff状态都是和容器有关，通过排查容器输出的日志即可解决问题。1）首先查看Pod的运行状态可以看到Pod已经处于CrashLoopBackOff状态了，在处于此状态之前，首先处于Error状态，接下来我们进一步进行排查。2）查看Pod运行

K8S集群中Calico组件的Pod状态一直处于Running未就绪的状态，报错内容如下产生该报错的原因是Node节点上出现了冲突的网卡，将有问题的网卡删除后，Calico组件的Pod就能正常启动了。异常的网卡命名都是以br开头的，我们来查询所有以br开头的网卡。将br开头的网卡删除。Pod启动成功，问题解决。...

在检查k8S节点系统日志时发现，有大量的kubelet组件报错，报错内容如下：之前换过一次docker的数据目录，可能存在部分容器无法更新状态的情况，解决方法如下：通过docker system prune清楚无法更新状态的容器，然后重启kubelet与docker组件。...

ImagePullBackOff状态表示容器的镜像拉取失败，可能存在以下几点原因：1）首先查看Pod资源的状态通过命令可以查询出当前Pod处于的状态，在ImagePullBackOff状态之前还会存在一个ErrImagePull的状态，看见这个状态就可以定位出该Pod的镜像没有拉取成功，从而出现了问题。2）查看Pod资源异常状态的输出信息从输出信息中，我们可以获取到大量的排查线索，首先就是这句话拉取镜像失败，紧接着看这句话，这句话的意思就是说没有权限拉取aknow_system的镜像，在接着找线索注意这

Pending状态表示挂起，处于该状态的原因有以下几点：处于Pending状态的原因最有可能的就是调度的Node节点上资源不足了。1）首先去排查节点的资源使用情况，使用命令查看内存的使用情况，命令查看系统的负载及CPU使用情况，查看磁盘的使用情况，快速定位是否是由于节点资源不足而引发的问题。如果资源充足，那么就可以排除是节点自身的问题了。2）被调度的节点可能存在污点配置，当K8S集群安装完成后，Master默认是开启污点的，开启污点的节点不允许被调度，可以进一步使用命令排查节点是否设置了污点操作，如果设置了

K8S部分节点无法启动Pod资源-Pod处于ContainerCreating状态1.Pod长时间处于ContainerCreating状态的原因在日常运维中可能会遇到Pod资源长时间处于ContainerCreateing正在创建的状态，Pod维持这种状态在1-2分钟内还可以接受，如果在10分钟以上甚至更长，那么可能就是出问题了，遇到Pod资源处于非Running状态时，首先需要使用kubectl describe命令查看Pod的详情信息，从中获取报错信息。Pod长时间处于ContainerCrea

K8S集群中Pod资源常见的异常状态以及排查思路1.Pod资源的结构Pod资源中会有一个基础容器Pause容器，每一个Pod资源下都会有一个Pause容器，Pause容器负责创建一个虚拟网络和存储卷，Pod资源中的所有容器都会与Pause共享网络资源以及存储资源，同一个Pod中的多个容器直接通信可以使用localhost的形式直接通信。2.Pod资源常见的几种故障状态Pod资源常见的故障状态大致分为十种：Running状态：处于Running状态Pod资源不一定可用，当Pod资源处于健康检

K8S集群中Pod资源常见问题排查思路以及处理方法文章目录K8S集群中Pod资源常见问题排查思路以及处理方法1.Pod资源的概念2.Pod资源常见问题的排查思路1.Pod资源的概念对于Pod资源的核心概念以及配置详解，可以去阅读这篇文章：[《Kubernetes集群Pod资源结构定义及常用配置参数》][https://jiangxl.blog.csdn.net/article/details/117988304]Pod资源的概念：Pod资源是K8S集群中最小的调度单元，应用程序以容器的身份运行，从

解决Rancher2.5x版本突然无法使用（证书过期大BUG）文章目录解决Rancher2.5x版本突然无法使用（证书过期大BUG）1.Rancher突然无法使用的前因后果1.1.缘由1.2.导致问题产生的因素点2.冷静分析即刻处理问题2.1.排查问题的思路以及过程2.2.Rancher的日志为什么说证书过期了？2.3.解决证书过期的BUG2.4.浏览器再次访问Rancher验证问题是否解决3.Rancher对于此问题的解决方案1.Rancher突然无法使用的前因后果1.1.缘由Rancher可视化