containerd 插件机制与扩展：snapshotter、shim 与 CNI 的深度定制

containerd 核心（core）：
  - 内容存储（Content Store）：按 digest 寻址的层数据
  - 元数据（Metadata）：镜像、容器、快照的索引（boltdb）
  - 生命周期：API 协调、事件、lease

插件（Plugins）：
  - 通过 init() 注册，启动时按配置加载
  - 各插件通过内部注册表互相调用（依赖注入）
  - 可被替换/扩展而不改核心

// 以 snapshotter 插件注册为例（伪代码）：包 init 里调用 register
func init() {
    plugin.Register("snapshotter.overlayfs", &plugin.Registration{
        Type: plugin.SnapshotterPlugin,
        Init: func(ic *plugin.InitContext) (interface{}, error) {
            return overlay.NewSnapshotter(...)
        },
    })
}

启动时加载流程：
  config 指定 enable/disable → 拓扑排序（按依赖）
  → 初始化每个插件 → 失败则进程退出（daemon 启动即校验）

# 查询已加载插件
ctr plugins ls
# NAME                                   TYPE
# io.containerd.snapshotter.v1.overlayfs io.containerd.snapshotter.v1
# io.containerd.runtime.v2.task          io.containerd.runtime.v2
# io.containerd.grpc.v1.cri              io.containerd.grpc.v1

config.toml 里按需裁剪（边缘设备省内存）：
  [plugins."io.containerd.grpc.v1.cri"]
    disabled = false    # K8s 需要 CRI 插件
裁剪原则：只保留当前场景所需，减少启动开销与攻击面

shim v2（Runtime v2）：
  - 每个容器一个 shim 进程，作为 containerd 与运行时的桥梁
  - 负责容器进程的回收、IO、信号转发
  - 运行时实现 Task Service（start/exec/exit 等）即可接入
代表实现：
  - io.containerd.runc.v2（默认）
  - io.containerd.runsc.v1（gVisor）
  - io.containerd.runwasi.v1.wasmtime（Wasm）

# config.toml 声明一个自定义运行时（如 gVisor）
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runsc]
  runtime_type = "io.containerd.runsc.v1"

# 或通过 CRI 的 runtime handler 在 Pod 里选择
# K8s 里：spec.runtimeClassName: runsc

# K8s RuntimeClass 定义
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata: { name: runsc }
handler: runsc

实现 TaskService 接口：
  Create / Start / Exec / Kill / Wait / Stats / Pause / Resume
关键注意：
  - 复用 containerd 的 event/io 通道，不要自造
  - 处理容器退出后的 shim 退出时机（防止僵尸进程）
  - 测试先用 ctr 手动创建容器，再接入 K8s

snapshotter 负责"层 → 快照"：
  - Mount（挂载点构建，OverlayFS 上下层叠加）
  - Commit（把可写层固化为只读层）
  - 不同后端：overlayfs / native / fuse（Nydus、Stargz）
接口核心：
  Prepare / Mount / Commit / Remove / Stat

懒加载 snapshotter（如 Nydus）：
  - 不一次性拉全部分块，启动时只取元数据 + 需要的分块
  - 通过 FUSE 挂载，按需从远端取数据
  - 适合大镜像、弱网、冷启动敏感场景
对比 OverlayFS：OverlayFS 必须完整落盘后才能挂载

# 启用 nydus snapshotter
# config.toml
[plugins."io.containerd.snapshotter.v1.nydus"]
  root_path = "/var/lib/containerd-nydus"
# 拉取时指定 snapshotter
ctr images pull --snapshotter nydus registry.example.com/app:nydus-v1

□ 复用内容存储：快照数据与 content store 解耦或复用，勿重复存储
□ 保证 prepare/mount 的幂等与并发安全（containerd 会并发调用）
□ 挂载点清理：容器退出后正确卸载，防止挂载泄漏
□ 用 ctr snapshotter 子命令验证再上线

containerd 的 CRI 插件负责调用 CNI：
  创建 Sandbox → 调用 CNI ADD → 配置 Pod 网络
  CNI 配置目录与插件二进制由 kubelet 侧管理
网络栈：
  - bridge（默认，宿主 NAT）
  - macvlan/vlan（性能敏感、直连）
  - Calico/Cilium（overlay，K8s 集群常用，见网络篇）

# 查看当前 CNI 配置
crictl info | jq '.config.cni'
# 常见目录
ls /etc/cni/net.d/ /opt/cni/bin/

自定义 CNI 的两个层次：
  1. 编排现有插件：写 net.d 配置（按顺序链式调用）
  2. 实现 CNI 协议：编写 CNI 二进制（标准输入/输出 JSON）
实现要点：
  - CNI 插件是独立二进制，通过环境变量（CNI_COMMAND/CNI_CONTAINERID）入参
  - 命令：ADD / DEL / CHECK / VERSION
  - 返回标准 JSON（cniVersion + interfaces + ips）

常见问题：
  - CNI 配置缺失/插件二进制不在 → Pod 一直 ContainerCreating
  - 插件 ADD 返回错误 → 查看 kubelet 日志中的 cni 错误
  - IP 冲突/路由未下发 → 检查数据面（路由表/iptables）

dockerd → containerd（管理）→ containerd-shim → runc
Docker 的 containerd 集成对用户不可见（docker 命令屏蔽细节）
生产直接使用：K8s + containerd CRI（不经 dockerd）

# 检查 kubelet 使用的运行时
kubelet --container-runtime-endpoint=unix:///run/containerd/containerd.sock
# 节点运行时信息
crictl version
crictl info

# 使用 containerd 的镜像加速配置示例（/etc/containerd/config.toml）
[plugins."io.containerd.grpc.v1.cri".registry.mirrors]
  [plugins."io.containerd.grpc.v1.cri".registry.mirrors."docker.io"]
    endpoint = ["https://registry-1.docker.io", "https://mirror.example.com"]

迁移考虑：
  - 镜像兼容：containerd 支持 Docker 镜像格式，直接可用
  - 命令差异：docker ps → crictl ps / ctr c
  - 网络：K8s 场景由 CNI 接管，不再用 Docker 网络
  - 日志/存储路径变化：/var/lib/docker → /var/lib/containerd

# containerd 原生工具（不经 CRI）
ctr images pull docker.io/library/alpine:3.20
ctr run --rm docker.io/library/alpine:3.20 test echo hi
ctr content ls && ctr snapshots ls && ctr plugins ls
# CRI 工具（K8s 视角）
crictl ps -a; crictl images
crictl logs <cid>
crictl exec -it <cid> sh

# 前台调试运行 containerd
containerd --log-level debug --root /var/lib/containerd-debug
ctr events   # 查看事件流
# pprof 性能剖析（默认 6060）
curl -s "http://127.0.0.1:6060/debug/pprof/goroutine?debug=1" | head -50

□ CRI 只读挂载：ReadOnlyPaths、禁用非必要 capabilities（安全加固）
□ 镜像加速：registry mirrors 回源（见多集群分发篇）
□ 资源：--oom-score-adjust 保护 daemon；合理日志级别
□ GC：image GC 与 container GC 阈值，防磁盘打满

□ containerd 与 CRI/插件版本强相关：升级前查 compatibility matrix
□ 自定义插件（snapshotter/shim）要跟随主版本 API 变动
□ 灰度：先在测试节点升级，验证 ctr plugins ls 与运行稳定再全量
□ 备份：升级前备份元数据（boltdb）与内容存储

□ 大并发拉取：监控 content store 锁竞争，必要时限流
□ 懒加载 snapshotter 与镜像仓库预热配合（避免首次全穿透）
□ 自定义 shim 关注退出清理与信号转发，防僵尸与挂载泄漏
□ 监控指标：grpc 请求延迟、snapshotter 挂载数、GC 执行时间