Kubernetes 集群从 1.20 升级到 1.24 版本时，最核心的注意事项是 DockerShim 的移除。从 1.24 版本开始，Kubernetes 不再支持 Docker 作为容器运行时，必须迁移至 containerd 或 cri-dockerd。升级前需全面检查集群对 Docker Engine 的依赖，包括遥测和安全代理。建议在业务低峰期操作，升级控制面后及时升级节点池，包括 kubelet 和容器运行时。同时需关注废弃 API 的变化，进行前置检查，配置多副本部署策略和 Pod Disruption Budget (PDB) 以确保高可用性，并做好备份恢复预案，以防升级失败导致服务中断。
Kubernetes 1.23 到 1.24:一次让 Reddit 宕机超 5 小时的升级踩坑
Kubernetes 版本和组件升级对我们来说，依然是一个容易“搬起石头砸自己脚”(footgun) 的巨大隐患。事实上，这也正是导致我们 3.14 宕机的主要诱因。太长不看版 升级必要与风险：升级工作 (尤其是 Kubernetes 集群升级) 存在一定风险，但又是必须推进的任务。我们将通过充分的测试与验证尽可能降低风险，尽管如此，后续仍有大量工作等待完成; 隐蔽的升级深坑：在我们操作的特定集群上，从 Kubernetes 1.23 升级到 1.24 的过程中，我们踩到了一个前所未见且极其隐蔽的坑。我们花了几个小时才最终决定回滚 (而回滚本身也是一个高风险操作); 备份恢复的痛点：备份恢复令人讨厌。我们现有的流程有大量问题需要改进。但幸运的是，这次它奏效了; 后知后觉的根因：直到我们恢复完成数小时后，才发现了那个极其隐蔽的根本原因; 还没有全军覆没：并非所有服务都中断了。我们的现代服务 API 层都保持弹性运行，但这影响了依赖关系中最关键的遗留节点，因此影响范围仍然包括大多数用户流，我们的现代化进程中仍需更多工作; 将危机化为动力：我们决心利用这次宕机事件，彻底改变我们长期以来的一些主要架构和流程决策，确保未来的集群升级安全无恙。故障的开始 这事说起来有点讽刺意味。我们团队刚完成了一次之前不太成功的 Kubernetes 升级经验总结，那次问题并不严重，而且根因也已经完全解决了。所以我们又开始对同一个集群进行另一次升级了。（发布时间是 2026 年 4 月 18 日）
kubernetes 集群准备好升级到 v1.24 了吗？这里包含了需要注意的事项
kubernetes 集群准备好升级到 v1.24 了吗？这里包含了需要注意的事项 本文概述了 Kubernetes v1.24 版本中 Dockershim 的弃用，指导集群管理员应对策略，包括检查依赖、迁移至 containerd 或其他运行时，并强调了与 Docker 运行时的兼容解决方案 cri-dockerd。早在 2020 年 12 月，Kubernetes 就宣布弃用 Dockershim。在 Kubernetes 中，dockershim 是一个软件 shim，它允许您将 Docker 引擎用作 Kubernetes 中的容器运行时。在即将发布的 v1.24 版本中，我们将移除 Dockershim，弃用和移除之间的间隔，符合项目在弃用后至少一年支持功能的政策。如果您是集群操作员，则本指南包含您在此版本中需要了解的实际情况。此外，您需要做些什么来确保您的集群不会倒塌! 首先，这对你有影响吗？如果您正在滚动自己的集群或不确定此删除是否会影响您，请保持安全并检查您是否对 Docker Engine 有任何依赖关系。请注意，使用 DockerDesktop 构建的应用程序容器，不是集群的 Docker 依赖项。由 Docker 创建的容器镜像符合开放容器倡议 (OCI),这是一种 Linux 基金会治理结构，围绕容器格式和运行时定义行业标准。它们可以在 Kubernetes 支持的任何容器运行时上正常工作。如果您使用来自云提供商的托管 Kubernetes 服务，并且您没有显式更改容器运行时，那么您可能不需要做任何事。AmazonEKS、Azure AKS 和 Google GKE 现在都默认使用 containerd，但如果您有任何节点自定义，您应该确保它们不需要更新。要检查节点的运行时，请遵循找出节点上使用的容器运行时。无论您是滚动自己的集群还是使用来自云提供商的托管 Kubernetes 服务，您都可能需要迁移依赖于 Docker Engine 的遥测或安全代理。我有一个 Docker 依赖项。现在怎么办？如果您的 Kubernetes 集群依赖于 Docker Engine，并且您打算升级到 Kubernetes v1.24(出于安全和类似原因，您最终应该这样做),您需要将容器运行时从 Docker Engine 更改为其他内容或使用 cri-dockerd. 由于 containerd 是一个毕业的 CNCF 项目和 Docker 本身的运行时，因此作为替代容器运行时是一个安全的选择。幸运的是，Kubernetes 项目已经记录了更改节点容器运行时的过程，以 containerd 为例。切换到其他支持的运行时之一的说明类似。我想升级 Kubernetes，我需要保持与 Docker 作为运行时的兼容性。我有哪些选择？不要害怕，您不会被冷落，也不必冒着停留在旧版本 Kubernetes 上的安全风险。Mirantis 和 Docker 联合发布并正在维护 dockershim 的替代品。该替换称为 cri-dockerd（截至 2022 年 4 月 4 日）
升级节点池
升级节点池 升级集群 Kubernetes 版本时，请在控制面升级后及时在业务低峰期完成节点池的升级。节点池升级包括 kubelet 升级和容器运行时升级。执行升级操作前，ACK 会提供前置检查，识别并提示可能影响升级的风险因素，以便实现平滑升级。注意事项 节点伸缩 若集群启用了节点伸缩功能，为保证自动伸缩功能不受影响，集群在升级成功后会自动更新 cluster-autoscaler 组件至最新版本。集群升级后，请确认 cluster-autoscaler 组件版本是否正常。更多信息，请参见启用节点自动伸缩。集群升级期间，伸缩模式为极速模式的节点可能会因节点关机而无法完成升级。如果升级结束后存在节点因极速模式未被升级，建议手动移除该节点。升级集群至 1.18 版本后，ACK 会默认配置节点资源预留。如果集群未配置资源预留且节点水位较高，升级后存在 Pod 驱逐后无法被快速调度的风险。请为节点预留部分资源，推荐 CPU 使用率不超过 50%,内存使用率不超过 70%。更多信息，请参见节点资源预留策略。在 1.24 及以下版本的集群中，如果工作负载的 Pod 只配置了启动探针 (Startup Probe),Pod 会在 kubelet 重启后出现短暂的 NotReady 现象。建议您采用多副本部署策略，将工作负载分散在多个节点上，以确保在某个节点重启期间仍有足够的可用 Pod。如果某个 Pod 通过 LoadBalancer 类型的 Service 的 SLB 地址访问同一节点上的另一个 Pod，并且该 Service 的 externalTrafficPolicy 设置为 Local，那么在节点轮转后，两个 Pod 可能不再位于同一个节点上，继而导致网络不通。自定义操作系统镜像非 ACK 官方严格验证。ACK 无法完全保证升级成功。集群升级需要使用 yum 下载升级所需的软件包。如果您的集群曾自行修改节点的网络配置或者使用了自定义的操作系统镜像，需确保节点的 yum 能正常使用。您可以执行 yum makecache 进行检查。如果您对集群有过配置更改，例如打开了 SWAP 分区、曾通过黑屏操作修改 kubelet 配置或运行时配置等，集群升级过程有可能失败，或自定义配置可能会被覆盖。通过替盘方式升级节点时，ACK 会进行节点排水操作，遵循 Pod Disruption Budget(PDB) 的前提下将节点上的 Pod 驱逐至其他可用节点。为确保服务高可用性，建议您采用多副本部署策略，将工作负载分散在多个节点上，同时为关键业务配置 PDB，控制同时中断的 Pod 数量。节点排水的默认超时时间为 30 分钟。如果在超时时间内未能完成 Pod 迁移，ACK 将终止本次升级以确保业务稳定性。通过替盘方式升级节点时，ACK 将按照节点池当前的配置 (例如节点登录方式、标签、污点、操作系统镜像、运行时版本) 重新初始化（搜索结果收录于 2026 年 1 月 22 日）
升级集群说明
升级集群说明 为避免过期版本集群存在的安全和稳定性风险，获得最新的 kubernetes 能力和技术支持，建议您及时升级集群版本.ack 提供升级前置检查，支持配置不同升级策略和升级节奏，并提供升级进度监控，以便实现集群的平滑升级。为什么需要升级 版本不再支持创建，过期补丁版本也不再支持创建，详情请参见 过期版本集群存在安全隐患和稳定性风险。集群版本过期后，将无法享受新 kubernetes 版本支持的功能特性及缺陷修复，无法获得及时有效的技术支持，面临无法修复安全漏洞的风险。建议您及时主动升级集群，以便享用最新的功能特性，缺陷修复和更及时的技术支持。重要 升级集群时，ack 会对您的集群进行前置检查，但无法保证检查出所有不兼容的功能配置和 api.根据 安全责任共担模型，请您通过帮助文档，控制台信息，站内信等渠道关注版本发布情况，并在集群升级时提前了解相应版本的升级注意事项。升级影响 ack 提供分阶段，分批次的升级策略，确保集群升级过程中业务 pod 的连续性和稳定性。前置检查：控制面和节点池升级前均提供前置检查，识别集群中潜在的兼容性风险，例如废弃 api，组件版本，节点状态，磁盘状态等，并提供修复建议。前置检查结果不会影响集群业务的运行。控制面：ack 托管集群：api server 由 ack 托管运行，升级过程中会滚动重启，正常情况下不影响应用的正常运行。当应用强依赖于 api server 时可能因短暂断链而需要重连重试。ack 专有集群：升级过程中，ack 会对每个 master 节点逐个进行原地升级。正常情况下不影响应用的正常运行。当应用强依赖于 api server 时可能因短暂断链而需要重连重试。节点池：分批升级节点，确保服务连续性。支持自定义批量升级策略 (每批次执行最多节点数，每批次间隔时间等),控制升级对业务的影响。原地升级时，不涉及磁盘替换和节点初始化，业务 pod 正常运行，服务不会中断。替盘升级时，涉及节点排水，系统盘更换和节点初始化。但请注意以下影响：替盘升级时，ack 会进行节点排水操作，遵循 pdb 的前提下将节点上的 pod 驱逐至其他可用节点。为确保服务高可用性，建议采用多副本部署策略，将工作负载分散在多个节点上，同时为关键业务配置 pdb，控制同时中断的 pod 数量。替盘升级时，ack 将按照节点池当前的配置 (例如节点登录方式，操作系统镜像，容器运行时版本) 重新初始化节点。正常情况下，更新节点池配置需通过 编辑节点池（撰于 2025 年 8 月 8 日）
FAQ
Kubernetes 1.24 版本移除了什么关键组件？
Kubernetes 1.24 版本移除了 Dockershim，不再支持将 Docker 引擎直接用作容器运行时。
升级过程中如何保证业务连续性？
建议采用多副本部署策略，将工作负载分散在多个节点上，同时为关键业务配置 PDB，控制同时中断的 Pod 数量。
如果必须依赖 Docker 运行时怎么办？
可以使用 cri-dockerd 作为 dockershim 的替代品，或者将容器运行时迁移至 containerd。