Kubernetes排障指南：深入解析Container Runtime网络未就绪问题

1. 从一次真实的线上故障说起：当你的Pod卡在Pending状态

那天下午，我正在悠闲地喝着咖啡，突然监控告警就响成了一片。几个核心服务的Pod状态显示为“Pending”，业务流量开始出现波动。我心里咯噔一下，知道今晚的“夜生活”又要开始了。登录到Kubernetes集群，第一件事就是检查这些“罢工”的Pod。

kubectl get pods -n production

果然，好几个Pod都卡在了ContainerCreating或者干脆就是Pending状态。用describe命令深挖一下，在事件（Events）里看到了那个熟悉又讨厌的报错：Container runtime network not ready。这个错误就像K8s世界里的“未解之谜”，它告诉你网络有问题，但具体是哪里的问题，得靠你自己一层层剥开。

简单来说，这个错误是Kubelet（K8s在每个节点上的“管家”）在创建Pod容器时抛出的。Kubelet的工作流程是这样的：它先通过API Server拿到要创建的Pod定义，然后调用底层的容器运行时（比如containerd或Docker）去创建容器。在容器真正启动之前，Kubelet需要确保容器的网络环境已经准备就绪。这个“准备就绪”的标志，就是节点上的网络插件（通常是CNI插件，如Calico、Flannel）已经成功配置好了一个网络接口（比如eth0）并分配了IP地址。

当Kubelet发现它无法为即将诞生的容器准备好这个网络环境时，它就会抛出“Container runtime network not ready”这个错误，并暂停Pod的创建流程。所以，这个错误的本质是节点层面的容器网络初始化失败，它阻断了Pod的生命周期。对于刚接触K8s运维的朋友来说，看到这个错误可能会有点懵，不知道从哪里下手。别急，接下来我就带你像侦探破案一样，把可能的原因和排查方法捋个清清楚楚。

2. 第一现场勘查：系统性诊断与信息收集

遇到问题切忌乱动，先做全面的检查，收集所有线索。这就像医生看病，得先望闻问切。

2.1 检查核心组件状态

首先，我们需要一个全局视角。看看集群的核心组件是否健康。

# 检查所有节点的状态，特别关注NotReady的节点
kubectl get nodes

# 检查核心系统Pod的状态，尤其是kube-system命名空间下的网络插件和DNS
kubectl get pods -n kube-system -o wide

# 查看kubelet服务的运行状态（在出问题的节点上执行）
systemctl status kubelet --no-pager -l

在我遇到的这次故障中，kubectl get nodes显示所有节点都是Ready状态，这初步排除了节点失联这种大问题。但kubectl get pods -n kube-system却发现，CoreDNS的Pod处于Pending状态。这是一个非常强烈的信号，因为CoreDNS是集群内部服务发现的基础，它自己都启动不了，往往意味着底层网络环境存在普遍性问题。

2.2 深入挖掘Kubelet日志

节点状态是Ready，但网络没准备好，这很矛盾。矛盾点就是突破口。我们需要查看Kubelet的详细日志，它是最了解本地容器运行时和网络状态的角色。

# 使用journalctl查看kubelet的日志，重点关注错误和警告
journalctl -u kubelet --since "1 hour ago" | grep -E -i "network not ready|error|fail|cni"

# 或者直接查看kubelet的日志文件（路径可能因系统而异）
tail -f /var/log/kubelet.log

运行上面的命令，你很可能就会看到类似这样的日志条目：

... network: network plugin is not ready: cni config uninitialized
...
... Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugi