哎，说真的，看到“依赖缺失怎K8sEx”这个关键词，我CPU都要烧干了！😭 这不就是我这周刚刚经历过的噩梦吗？！如果你也是个运维小白，或者正在被Kubernetes折磨得死去活来,那咱俩可得好好抱头痛哭一下。
你们知道吗，K8s这东西，就像一个超级严格的女朋友/男朋友，你少给它一个“依赖”的承诺（比如配置文件、镜像标签），它立马就给你脸色看。依赖缺失这四个字，简直是我在kubectl get pods时最不想看到的红色警报！😤
先说症状哈！ 我的Pod状态一直是ImagePullBackOff，或者CrashLoopBackOff，刚开始我还以为是镜像拉不下来，结果登录到节点上一看，好家伙，不是镜像问题，是权限问题！或者说是配置依赖问题，那一刻，我的心里真的是一万头草泥马奔腾而过……我就想问一句：K8sEx，你到底想让我怎么样？！
其实吧，“依赖缺失”在K8s里是个笼统的说法，它不仅仅是说某个包没装，对于咱们这些“搞基”的工程师来说，它往往指的是资源对象之间的引用关系断裂，你的Deployment里引用了一个不存在的ConfigMap，或者Service选了错标签的Pod，再或者你的Pod需要挂载一个PVC，而那个PVC还处于Pending状态——因为它的StorageClass依赖的底层插件根本就没部署！😱
这种时候，我告诉你，千万别慌！我一开始就慌了，结果就是对着屏幕发呆，感觉自己像个傻子，后来我学会了“三步走”排查法,真的绝绝子！
第一步：看Events！ 这不是废话！kubectl describe pod xxx 一定要看底下的Events部分，那里面写的明明白白，0/1 nodes are available: 1 node(s) had taint...”，或者“MountVolume.SetUp failed for volume ... : secret ... not found”，看到没？这就是依赖缺失的直接证据！我当时看到“secret not found”的时候，真想抽自己两巴掌，原来是我把Secret名字拼错了，就少了个s！这就像出门忘带钥匙，你明明是要开A家的门，结果拿的是B家的钥匙,能不报错吗？
第二步：理清对象树！ 脑袋里一定要有一张依赖关系图，Deployment -> ReplicaSet -> Pod -> ConfigMap/Secret/PVC，就像一个家族谱系，你得顺着这个链条去查！是不是上面的某个“长辈”（比如CRD）没装？或者Helm部署的时候Values文件里的依赖项没匹配上？老实说，我上次就是因为Helm Chart里传递了错误的global.image.registry，导致整个应用的镜像地址直接404了，这难道不是一种依赖缺失吗？精神的缺失啊！
第三步：请出绝招kubectl get all！ 别笑！真的要全量看一遍，有时候你只盯着自己的名字空间看，结果人家服务跑在别的namespace里，这就好比你想去隔壁老王家里借酱油，结果发现隔壁是空的，你得去楼下老李家找，跨namespace的依赖一旦缺失，你排查一整天都找不到，我当时那个急啊，后来还是kubectl get events -A帮我找到了真凶——原来是有个Namespace被卡在Terminating状态，导致里面的资源全都没起来,而这又是另一个服务依赖的底层组件。
说到这，我不得不夸一句K8sEx（这破玩意儿），它虽然严格，但也确实是“真爱”，一旦你把依赖缺失这个坑填平了，整个集群的稳定性和弹性真的是杠杠的，那种从“CrashLoopBackOff”到“Running”的瞬间，我的天，那种成就感，比中了彩票还开心！🥳
我想跟所有正在踩坑的朋友说：遇到依赖缺失别气馁，把它当成是K8s给你的小考验，慢慢排查，总有一天你会成为那个“一眼定BUG”的大神，毕竟，在哪跌倒，就在哪躺会……不是，在哪跌倒,就在哪把依赖补上！
好了，今天的吐槽+自救指南就到这里，如果觉得我的话糙理不糙，或者你也经历过这种生无可恋的时刻,欢迎交流。
学习网络安全可以加QQ：123456789（记得备注“K8s道友”哦！）
