3. Containerd 版本发布模型：语义化版本规范、LTS版本策略、版本升级路径、官方支持的版本范围

在生产环境中管理 Containerd 运行时，理解其版本发布模型是制定迁移与回滚策略的基础。Containerd 严格遵循语义化版本规范，并采用长期支持（LTS）与滚动发布相结合的版本策略。本节将系统梳理其版本号构成、LTS 版本选择、升级路径以及官方支持的版本范围，为后续的版本迁移与 Helm 回滚适配提供理论依据。

3.1 语义化版本规范（SemVer）

Containerd 从 1.0 版本开始全面采用 语义化版本 2.0.0（SemVer 2.0.0）规范。版本号格式为 MAJOR.MINOR.PATCH，每个字段的变更含义如下：

3.2 LTS 版本策略与版本选择

Containerd 项目采用 滚动 LTS 策略，而非固定时间窗口的 LTS。每个 MAJOR.MINOR 版本分支在发布后，会经历以下生命周期阶段：

• 活跃开发阶段：新功能合并，频繁发布 PATCH 版本。
• 稳定维护阶段（LTS）：仅接受安全修复和关键 Bug 修复，不再引入新功能。
• 生命周期结束（EOL）：停止所有维护，不再发布任何 PATCH 版本。

截至当前课程编写时，官方推荐的 LTS 版本分支及状态如下：

3.3 版本升级路径

Containerd 官方推荐的升级路径遵循 MINOR 版本逐级升级 原则，禁止跨 MAJOR 或跨多个 MINOR 版本直接跳升。以下是经过验证的安全升级路径：

1. PATCH 升级：在同一 MINOR 版本内升级，例如 1.6.13 → 1.6.14。直接替换二进制文件并重启服务即可，无需额外配置变更。
2. MINOR 升级：例如 1.5.x → 1.6.x。需要先升级到目标 MINOR 的最新 PATCH 版本，再执行跨 MINOR 升级。升级后需验证 CRI 配置兼容性。
3. MAJOR 升级：例如 1.x → 2.x。必须经过完整的测试周期，涉及 API 变更、配置文件格式调整、以及可能的存储格式迁移。

3.4 官方支持的版本范围

Containerd 项目官方维护的版本范围遵循 N-2 支持策略：同时维护最近 3 个 MINOR 版本分支（当前活跃 + 前两个 LTS 分支）。当新 MINOR 版本发布时，最旧的 LTS 分支进入 EOL。具体支持范围如下：

• 当前活跃 MINOR：1.7.x（完全支持，包含新功能与修复）
• 上一个 LTS MINOR：1.6.x（安全修复与关键 Bug 修复）
• 再上一个 LTS MINOR：1.5.x（已 EOL，不再支持）

if 新集群部署:
    选择 1.7.x（最新 LTS）
elif 现有集群升级:
    if 当前版本 < 1.6.x:
        先升级到 1.6.x 最新 PATCH
        再评估是否升级到 1.7.x
    elif 当前版本 == 1.6.x:
        保持 1.6.x 或评估升级到 1.7.x
    elif 当前版本 == 1.7.x:
        保持最新 PATCH 版本
else:
    选择 1.6.x（最稳定 LTS）

3.5 版本发布节奏与 Helm Chart 适配

Containerd 的 PATCH 版本发布频率约为 每 2-4 周，MINOR 版本约为 每 6-9 个月。在 Helm Chart 中适配版本迁移时，需要关注以下关键点：

3.6 版本迁移风险矩阵

基于上述版本模型，在制定 Containerd 版本迁移计划时，建议使用以下风险矩阵进行评估：