一、引言

有个节点发布的时候卡住了，解决方式分为长短期。

博主跟运维做了一些分析讨论和解决方案，涉及到许多K8S相关的知识，有兴趣的同学可以看看这个原理分析过程。

二、分析

首先是分析目前节点的状态，可以看出不属于以下几种状态，说明节点处于一种前置未完成的初始化状态。

那么k8s在pending之前需要等什么呢，这里能看出前置节奏还是挺多的，比如需要提供cri准备容器所有的参数

那么从参数方向入手先尝试排查，一般自带参数没必要排查，不太可能是调度系统本身拉取参数失败，因此向运维询问他们使用以下哪种方式挂载了额外的参数文件，这个参数文件又是做什么使用的。

运维内部进行了沟通，运维在istio的enovy中做了一些网关流量处理，参数是通过configmap方式挂载的。这里和报错信息显示挂载envoy的配置文件失败一致。

有了具体方向就要查为什么会产生这样的错误了，按说cm作为业界常用的配置文件方式不应该有这种问题，让运维把内核日志和k8s日志考了一份，都能看出sysytemd挂载失败，所以节点一直在等待systemd挂载成功

再看之前的日志，这个问题出现不是一两天了，在k8s、cri的社区都有人提出issue，但是最终都是要升级版本Check the Systemd is alive in kubelet · Issue #110763 · kubernetes/kubernetes · GitHub

1、重建，临时做法

2、升级，长期耗时还要调研

3、探测，这边博主分析了一下为什么重建就能解决，调度到其他宿主机上去了，那么对于有问题的宿主机是不是可以进行探测，然后设置调度算法规则过滤掉，在《深入理解k8s》中提到的第三种调度规则就是针对物理机的，那么可以更新node的Taint，把有问题的宿主机过滤掉

云环境下的组件非常之多，随时有版本不对应或者升级解决bug的情况，这是非常坑的事情，碰到问题就要定位，最后就是升级。

但是做好探测，利用好k8s的调度规则还是可以提前规避掉许多问题的。