如果你觉得给Kubernetes节点打虚拟机快照和给普通服务器打快照一样是“后悔药随便吃”那我建议你花五分钟看完这篇踩坑记录至少能帮你少熬一个通宵。我这次是在一次组件升级前给一台 worker 节点打了份虚拟化平台快照想着万一升级出问题就恢复回去。结果升级确实出问题了我也确实把快照恢复了噩梦也从此开始——恢复完成之后节点表面一切正常但集群里一堆业务 Pod 卡在 ContainerCreating怎么等都不起来kube-system 里 Calico 的日志翻来覆去就一个词Unauthorized。第一反应是我被黑了冷静下来才发现是 Kubernetes 的证书和 Token 体系被快照“拨回了过去”。这篇文章不光是记录我修复的过程更会把“为什么快照恢复会引发 Calico 认证失败”这件事讲透附上从节点证书、ServiceAccount Token 到时间同步的完整排查链路最后给一份快照恢复前后的自检清单。如果你是新手正在被 ContainerCreating 和 Unauthorized 折腾这篇应该能直接帮你定位到问题如果你还没遇到这坑建议先存着迟早能用上。1. 故障现场一次“非常成功”的快照恢复1.1 恢复动作本身很顺利集群却没有买账先交代一下环境集群是 kubeadm 部署的Kubernetes 版本在 v1.26 这个系列CNI 用的是开源版 Calico数据存储走的是 Kubernetes API datastore也就是常说的 KDD 模式。节点拓扑很简单几台 master 加若干 worker业务负载有 API 服务、数据库、消息队列之类的常见工作负载。打快照的起因和大多数运维事故一样——升级前想留条后路。我在虚拟化平台上选中那台 worker 节点右键创建快照不到一分钟搞完。后来升级过程中果然出了问题我就把节点关机、快照恢复、重新开机。开机后 SSH 能连上docker/containerd 服务是 active 的节点上的 kubelet 也在跑表面看所有东西都在。但业务侧很快开始报警。我执行kubectl get pods -A一眼看到一大片 ContainerCreating而且不是一两个命名空间的问题是分布式的。再去kubectl get nodes这台 worker 节点虽然显示 Ready但状态很不稳定新调度过去的 Pod 一律卡住。这里有一个非常关键的前提我只恢复了一台节点其他节点、API Server、etcd 全部保持原样。这个“单节点状态回拨、集群状态不回拨”的不对称才是后面所有诡异问题的总根源。如果你是把整个虚拟化集群环境里的所有节点一起恢复到同一个快照点反而不会出现这种问题因为状态是一致的。单节点恢复几乎是所有 K8s 快照故障的高发场景。1.2 新手最容易踩的直觉误区遇到 ContainerCreating新手第一反应是“去 describe 看事件”我也是这么干的。但 describe 出来的事件有两个非常误导人的点事件里写的是FailedCreatePodSandBox然后跟着一句network not ready或者直接一串failed to setup network for pod default/test-pod-xxx。看到“network”这个词人的第一反应就是“是不是网络不通是不是防火墙是不是 CNI 配置丢了” 于是我开始疯狂检查网络接口、路由表、防火墙折腾了半天一点进展没有。这里我总结一个教训看到 ContainerCreating 时先做三个快速排除别急着钻网络镜像是否存在/拉取是否成功查 Pod Events 里有没有ErrImagePull或ImagePullBackOff存储卷是否挂载正常检查有没有FailedMount事件节点资源是否不足看kubectl describe node的内存、CPU 是否可分配。这三个都排除之后才轮到网络插件。而我这里的事件信息把矛头明确指向 CNI 网络所以下一步就去看 Calico 组件。真正的问题要等 Calico 的日志出来才算揭开面纱。2. 日志里的 Unauthorized从“网络问题”变成了“认证问题”2.1 为什么 Pod Sandbox 创建不出来锅在 CNI在深入 Calico 日志之前先花半分钟搞清楚 ContainerCreating 和 CNI 的关系。Kubernetes 创建一个 Podkubelet 会通过 CRI 接口通知 containerd 或 docker 创建 sandbox你可以理解成一个 Pod 的“房间”sandbox 创建过程中容器运行时必须调用 CNI 插件让 Pod 有独立的网络命名空间、IP 地址和路由。也就是说Pod 一直停在 ContainerCreating往往是 sandbox 创建失败而 sandbox 创建失败的常见原因就是 CNI 插件没有准备好网络。这套链路大概是kubelet - containerd - CNI plugins - calico-agent/Felix - kube-apiserver最后一步是关键Calico 数据平面Felix需要从 API Server 拿到节点信息、Pod 信息、NetworkPolicy 策略然后在本机创建 veth、路由、iptables 规则。如果 Calico 连不上 API Server或者认证挂了整个节点的网络功能就瘫痪。结果就是房间已经准备好了但前台办不了入住因为没有有效的门禁卡。2.2 calico-node 日志里的 401 Unauthorized 到底在说什么看完节点上的 kubelet 日志后我把视野切换到 Calico 组件。先用kubectl get pods -n kube-system -o wide | grep calico发现这台节点上的 calico-node Pod 不是 CrashLoopBackOff 就是 0/1 Running。然后取日志kubectl -n kube-system logs -f --tail200 calico-node-xxxxx -c calico-node日志大概长这样脱敏后2025-01-20T10:14:02.123Z ERROR remotemonitor/remote_monitor.go:123 Unable to get node: node-name ... HTTP status: 401 Unauthorized 2025-01-20T10:14:05.023Z ERROR kdd/client.go:456 Failed to list resources: ... Unauthorized看到 Unauthorized 的一瞬间我先是一愣这不是网络问题吗怎么冒出来认证问题这里要给新手解释一个 HTTP 状态码的细节401 Unauthorized 表示“认证失败”而不是“授权失败”。通俗讲就是 API Server 压根不认你这个人的身份证件而不是认了你却不给你权限。后者通常是 403 Forbidden。所以日志里的 Unauthorized 是一个信号问题不在网络链路通不通而在你的身份凭证有没有效。那 calico-node 是拿什么凭证去访问 API Server 的在开源 Calico 的 KDD 模式下calico-node 容器内部会挂载一个 ServiceAccount Token通常是 calico-node 这个 SA用 Token Bearer 的方式访问 kube-apiserver。有些老式部署也会显式提供一个 kubeconfig 文件里面包含客户端证书和 CA 数据。无论哪种方式本质都是一份“身份证明”。2.3 网络故障和认证故障在日志上的显著区别常规网络问题在日志里通常会表现成connection refused、dial tcp ... i/o timeout、TLS handshake timeout。而 Unauthorized 说明网络链路其实已经通了TCP 连接建立成功了TLS 握手也完成了只是 API Server 在验证身份的时候拒绝了请求。这个区别非常关键它把排查方向从“网络通不通”直接拉到了“身份凭证对不对”。在看到 Unauthorized 之后我心里反而松了一口气总算找到一条明确的线索了。接下来就是顺着 K8s 的身份体系往下挖。3. 快照恢复为什么能把 K8s 凭证体系“拨回过去”3.1 节点上哪些文件是“身份证”Kubernetes 节点的本地文件系统里藏着大量和身份认证相关的敏感文件。这些文件平时不出问题一旦快照恢复、文件被回拨到旧状态就可能出大事。先列一张对照表位置作用典型失效原因/etc/kubernetes/pki/ca.crt集群 CA 证书校验 API Server 身份CA 轮换后与集群不一致/var/lib/kubelet/pki/kubelet-client-current.pemkubelet 访问 API Server 的客户端证书过期、被 CA 拒绝、CN 与节点名不匹配/var/run/secrets/kubernetes.io/serviceaccount/tokenPod 内 SA Tokencalico-node 等组件使用Bound Token 过期、时间偏移导致校验失败/etc/kubernetes/kubelet.confkubelet 的 kubeconfig证书过期后整个配置失效/etc/cni/net.d/10-xxx.conflistCNI 配置可能内嵌 kubeconfig/CA 数据配置回弹到旧版本/etc/calico、/var/lib/calicoCalico 本地状态和配置数据面状态与集群元数据不一致其中最容易坑人的就是 kubelet 客户端证书。kubeadm 部署的集群kubelet 证书默认有效期是一年快照恢复后如果证书已经轮换过你恢复到的快照里可能根本没有新证书或者只有一份旧证书API Server 一验证就 401。3.2 K8s 的“定时续证”机制为什么会在快照面前失灵Kubernetes 设计了一套自动续证机制kubelet 启动时会检查本地客户端证书如果过期或者剩余时间很短就会拿 bootstrap token 去 API Server 申请新的证书签名请求CSR。很多集群还配置了自动批准 CSR 的控制器所以理论上证书到期了会自动换新平时根本不用管。问题在于快照恢复相当于把文件系统“倒带”了。如果打快照的时间点早于上次证书轮换时间恢复后本地证书就回到了“旧的、已经失效的”状态而 kubelet 的自动续证逻辑看到这份证书“还没到续期窗口”或者“还没过期”其实不一定。真正的乱子在于证书的签发时间和实际使用时间对不上加上节点上的时间也可能被快照回拨于是 API Server 校验时发现证书的 nbf/exp 窗口不对直接拒绝。另外还有一类更隐蔽的问题CA 轮换。如果你的集群做过 CA 替换或轮换API Server 已经用新 CA 签发各个组件的证书但快照里保存的还是旧 CA。恢复节点后节点上的 kubelet 和 Calico 拿着旧 CA 签发的证书去访问 API ServerAPI Server 用新 CA 验签验不过返回 401。这种故障不看 CA 指纹是根本发现不了的。3.3 ServiceAccount Token 的“有效期陷阱”Calico 组件用的 ServiceAccount Token 也不是永久的。自 Kubernetes v1.21 之后Bound ServiceAccount Token 成为默认行为这种 token 带有效期默认由 kube-controller-manager 的--service-account-max-token-expiration控制常见配置是 1 年。当 Pod 启动时kubelet 会把一个带有 exp 字段的 JWT 投射到容器的/var/run/secrets/kubernetes.io/serviceaccount/token里。快照恢复之后Pod 容器文件系统里的 token 可能是旧值旧 token 的 exp 时间如果已经过去API Server 自然返回 401。更头疼的是节点时间如果也被快照回拨JWT 校验的时间窗口会发生偏移可能出现“token 明明没到过期时间API Server 却认为它无效”的诡异现象。记住一句话单节点快照恢复本质上是把节点上的本地状态证书、Token、CNI 残留、时间回退但整个集群的权威状态etcd、RBAC、Node 对象、Secret没有回退。一边是新世界一边是旧文件两边一握手全是身份认证冲突。4. 完整排查链路从 ContainerCreating 到定位证书问题4.1 第一步查 kubelet 日志确认节点身份状态不要一上来就进 Calico先从 kubelet 查起因为如果 kubelet 本身认证失败了节点所有网络动作都会异常Calico 也会被牵连。我先在故障节点上执行journalctl -u kubelet -n 300 --no-pager | grep -iE unauthor|401|certificate|expired|permission|forbidden输出的关键词很关键。如果看到类似这样的日志kubelet.go:xxxx] Unable to register node worker-02 with API server: ... Unauthorized certificate has expired or is not yet valid那就基本锁定是 kubelet 客户端证书的问题。然后立刻检查证书文件openssl x509 -in /var/lib/kubelet/pki/kubelet-client-current.pem -noout -dates -subject -issuer再看系统里的 CA 证书openssl x509 -in /etc/kubernetes/pki/ca.crt -noout -dates -fingerprint -sha256把这份 CA 的指纹拿到集群其他正常的节点上对比一下openssl x509 -in /etc/kubernetes/pki/ca.crt -noout -fingerprint -sha256指纹不一致说明节点上的 CA 已经被“拨回”到旧版本或者集群做过 CA 轮换而这个节点没跟上。这是快照恢复类故障最常见的一种结果。4.2 第二步解析 Calico 的 Token验证访问凭证是否有效确认完 kubelet 证书再回头看 Calico 的访问凭证。calico-node Pod 的容器内部通常会挂载一个 ServiceAccount Token可以直接在容器里查看并解析 JWTkubectl exec -n kube-system calico-node-xxxxx -- cat /var/run/secrets/kubernetes.io/serviceaccount/tokenJWT 的中间一段是 payloadbase64 解出来能看到 exp 和 iat 时间。如果节点上不方便装 jq可以用echo 替换为实际token的中间段 | base64 -d 2/dev/null看到 exp 过去或者 iat 在未来基本可以断定认证失败跟 Token 时间窗口有关。另外如果 Calico 用的是显式 kubeconfig比如通过CALICO_K8S_NODE_REF或者挂载/etc/calico/certs就打开 kubeconfig 看里面的 client-certificate-data、client-key-data 和 certificate-authority-data用同样方式检查有效期和 CA 是否匹配。4.3 第三步检查节点时间别让时间差成了“隐藏帮凶”快照恢复的另一个经典后遗症就是时间不准。虚拟化平台恢复快照时guest 系统的时间可能会回到打快照那一刻或者 NTP 服务没有及时同步。时间偏移对 TLS 证书校验和 JWT 校验都有直接影响证书的有效期“Not Before / Not After”是绝对时间JWT 的 exp 也是绝对时间本地时间不准验证逻辑就会得出“过期”或“未生效”的错误结论。在故障节点上执行date -R timedatectl status chronyc tracking然后到集群里正常的 master 节点上同样执行date -R对比偏差。我这次就发现故障节点比集群其他节点慢了几十秒虽然看上去不多但足够触发时间窗口校验失败。4.4 第四步把现象、日志、时间、指纹汇总成一张对照表排查到了这里我建议把收集到的证据摆在一张表里避免被单一日志带偏现象日志/检查结果指向根因业务 Pod ContainerCreatingFailedCreatePodSandBox network not readyCNI 网络链路中断calico-node CrashLoopBackOff401 Unauthorized认证凭证失效kubelet 无法注册节点certificate has expired / Unauthorizedkubelet 客户端证书回退或过期Calico Token 时间窗口异常exp/iat 与当前时间不一致Bound SA Token 失效 时间偏差CA 指纹不一致节点与集群其他节点对比不同CA 轮换/旧 CA 残留我当时的结果是kubelet 客户端证书被回退成旧证书Calico 使用的 Token 时间窗口也出了问题加上节点时间比集群慢了约 20 秒几件事叠加最终 API Server 对所有来自该节点的请求统一返回 401。5. 修复实战按根因对症下药5.1 路线 A重建 kubelet 客户端证书并重新注册如果确认 kubelet 客户端证书失效最直接的办法是删掉旧证书让 kubelet 重新走一遍 CSR 签发流程。在故障节点上systemctl stop kubelet rm -f /var/lib/kubelet/pki/kubelet-client-*.pem systemctl start kubeletkubelet 重启后会因为找不到有效客户端证书拿着 bootstrap kubeconfig 里的 token 去 API Server 创建新的 CSR。如果集群配置了自动批准证书会很快签发下来如果没有自动批准你需要手动批准kubectl get csr -A kubectl certificate approve csr-name批准后kubelet 会获得新的kubelet-client-current.pem节点状态开始恢复。这里有一个新手容易忽略的细节删除客户端证书时不要动/var/lib/kubelet/pki/kubelet-server.crt那个是 kubelet 自己暴露端口用的服务端证书删了会引发别的问题。如果删除证书后 kubelet 依然报 401重点检查 bootstrap token 是否还有效cat /etc/kubernetes/bootstrap-kubeconfig如果 bootstrap token 对应的 secret 已经被清理或过期kubelet 无法自助续证就需要用kubeadm token create重新生成新的 bootstrap token 并更新配置文件。5.2 路线 B刷新 Calico 的 SA Token让组件重新换证如果确认 Calico 的问题是 Token 过期或被回退最简单的方案是删除 calico-node Pod让 DaemonSet 自动重建。重建后kubelet 会为容器重新投射一个新鲜的 ServiceAccount Tokenkubectl -n kube-system delete pod -l k8s-appcalico-node kubectl -n kube-system delete pod -l k8s-appcalico-kube-controllers注意这个操作一定要在 kubelet 证书修复之后做否则新 Pod 重建后还是拿不到正常网络。删除后观察新 Pod 日志确认 Unauthorized 不再出现。如果重建后依然 401检查 SA 是否还在kubectl -n kube-system get sa calico-node如果 SA 被误删很罕见但确实见过需要重新应用原始 Calico manifestkubectl apply -f calico.yaml如果 Calico 用的是显式 kubeconfig 且证书失效那就直接更新 kubeconfig 里的 client-certificate-data、client-key-data 和 certificate-authority-data或者干脆把 Calico 切回默认的 SA Token 方式省心很多。5.3 路线 C校准时间消除 TLS 和 JWT 校验的“隐形杀手”时间同步是所有认证修复的前置条件。不管证书换没换、Token 刷没刷节点时间必须和集群时间对齐。在故障节点上执行timedatectl set-ntp true chronyc makestep systemctl restart chronyd时间调整之后再观察时间偏移chronyc tracking | grep -i system time对齐之后重启 kubelet 和 Calicosystemctl restart kubelet kubectl -n kube-system delete pod -l k8s-appcalico-node这里要特别强调即使证书和 Token 是完好的只要节点时间和 API Server 时间差得离谱同样会 401。调整时间之后再做一次简单的curl验证比反复看日志更直接curl -k -H Authorization: Bearer token https://apiserver:6443/api/v1/namespaces/kube-system/pods如果返回 200 而不是 401说明认证已经恢复。5.4 路线 D最省事的兜底方案——排空节点重新加回集群如果你排查半步后发现节点上的状态烂到了“无从下手”的程度比如 CA 轮换历史复杂、bootstrap token 彻底失效、证书文件与集群身份体系完全对不上还有一个对于 worker 节点来说终极稳妥的方案把这个节点从集群移除重置后重新加入。在控制面节点上执行kubectl drain node-name --ignore-daemonsets --delete-emptydir-data kubectl delete node node-name然后在故障节点上执行kubeadm reset -f最后让节点重新加入集群kubeadm token create --print-join-command # 复制输出在节点上执行重新加入的节点会获得全新的 kubelet 证书、全新的 Pod 网络身份几乎不会残留旧状态。而且 kubeadm reset 会把 Calico 在节点上残留的路由、iptables 规则、veth 全部清干净比手动修复更彻底。需要提醒的是这个方案只适合 worker 节点master 节点千万不要随便 kubeadm reset。控制面节点承载着 etcd、kube-controller-manager 等关键服务一旦重置影响的是整个集群的可用性必须走更严谨的故障恢复流程。5.5 修复后的验证动作修复不能以“看起来正常”为结束一定要做功能验证。我的验证顺序是kubectl get nodes确保节点 Readykubectl get pods -A确保 calico-node 和 calico-kube-controllers 都是 Running业务 Pod 是否全部 Running跑一个测试 Pod进入容器内部 ping 同 Namespace 下另一个 Pod 的 IP以及 ClusterIP 的 Service验证 Calico 数据平面确实在工作。kubectl run connectivity-test --imagebusybox -- sleep 3600 kubectl exec -it connectivity-test -- wget -qO- http://service.namespace.svc.cluster.local如果 Service 能通说明 Calico 的路由和 iptables 规则已经正常下发整个故障才算真正修复。6. 把这份“坑”变成经验给新手的快照恢复保命清单6.1 快照前至少备份这些关键目录经过这次事故我给自己定了一条规矩给 K8s 节点打快照不能像给普通虚拟机打快照一样草率。打快照之前先把关键的本地凭证目录备份到外部存储目录/文件说明/etc/kubernetes/pki集群 CA、ServiceAccount 密钥、front-proxy CA如有/var/lib/kubelet/pkikubelet 客户端/服务端证书/etc/kubernetes/*.confkubelet.conf 等 kubeconfig/etc/cni/net.dCNI 配置清单/etc/calico、/var/lib/calicoCalico 本地状态/var/lib/etcd如果是控制面节点务必备份 etcd同时记录当时的date -R时间、kubelet 证书的到期时间openssl x509 -in /var/lib/kubelet/pki/kubelet-client-current.pem -noout -enddate以及 CA 指纹。这些东西在恢复后做对比时会救命。6.2 快照恢复后三分钟快速体检恢复快照之后不要急着放业务流量。按这三个顺序快速查一遍身份检查journalctl -u kubelet里有没有 401/证书过期字样openssl x509查 kubelet 证书有效期是否合理CNI 组件检查kubectl -n kube-system get pods -o wide | grep calicocalico-node 是否 Running日志里有没有 Unauthorized时间检查date -R和 NTP 状态是否正常偏差最好在 1 秒以内。这三步花不了三分钟但能避免像我一样被一个看似正常的节点坑两天。6.3 长期建议快照应该是最后手段不是常规操作Kubernetes 节点和普通虚拟机有本质区别节点状态高度依赖本地凭证和运行时数据而且这些数据会随着集群运行不断变化。虚拟机快照只能保存“某一刻的文件状态”一旦集群继续演进快照里的状态就变成了过期状态。比起恢复快照我更推荐把 K8s 节点当成可替换的“牲畜”而不是“宠物”坏了、烂了直接排空重建让系统组件由 DaemonSet、Deployment 自动拉起来远比修复一个状态混乱的节点可控。最后一个很实际的提醒如果真的要打快照选在维护窗口先把节点kubectl cordon把工作负载迁走再打快照。恢复时同样在维护窗口内恢复后立刻按上面的体检清单走一遍确认节点 Ready、Pod Running、网络正常才算真正安全。我在反复踩了证书、Token、时间这几个坑之后的最大体会就是Kubernetes 内部的身份体系就像一串环环相扣的钥匙快照恢复很容易把其中某一环“拨回过去”而其他环还在“现在”两边的锁齿对不上门就打不开。以后再有人问我“在 K8s 节点上恢复快照行不行”我的回答都是先备份凭证、排空负载、验证时间然后祈祷你永远用不上这份备份。