一、引言

        作者公司使用的是K8S底层做云计算，这天有个节点发布的时候卡住了，解决方式分为长短期。       

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

二、云计算简介

    云计算是一种基于互联网的计算模式，它通过将计算资源和服务提供给用户，以按需、弹性和可扩展的方式满足用户的需求。
    传统的计算模式通常需要用户购买、配置和维护自己的硬件和软件基础设施，而云计算则将这些计算资源和服务集中在云服务提供商的数据中心中，用户可以通过互联网按需使用这些资源和服务。  

    云计算底层的进化主要经历了虚拟机到Docker到Kubernetes

1、虚拟机（VM）

    虚拟机是一种基于软件的虚拟化技术，它可以将一台物理计算机分割成多个虚拟计算机，每个虚拟计算机都可以运行独立的操作系统和应用程序。虚拟机技术可以实现硬件资源的共享和隔离，提高资源利用率和安全性。
2、Docker

    Docker是一种基于容器的虚拟化技术，它可以将应用程序及其依赖项打包为一个独立的容器，使得应用程序可以在任何环境中运行，而无需关心底层的操作系统和硬件。Docker技术可以实现应用程序的快速部署、可移植性和隔离性。
3、Kubernetes（K8s）

    Kubernetes是一种基于容器编排的平台，它可以自动化地管理和调度容器化的应用程序，提供了弹性伸缩、负载均衡、服务发现等功能。Kubernetes技术可以实现应用程序的高可用性、弹性扩展和自动化运维。

    云计算从虚拟机到Docker到Kubernetes的过程，可以看作是从基于硬件的虚拟化技术向基于容器的虚拟化技术和容器编排平台的演进。这种演进使得云计算更加灵活、高效和可扩展，为应用程序的开发、部署和运维带来了更多的便利和优势。

 三、分析

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

        那么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 

https://github.com/cri-o/cri-o/issues/3808

四、解决 

        1、重建，临时做法

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

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

五、总结

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

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