📚 课程目录第4章预拉取机制

4、预拉取机制：DaemonSet预拉取、InitContainer预拉取、Sidecar预拉取模式对比

在Kubernetes集群灾备场景中，镜像预拉取的核心目标是在故障切换或扩容触发前，将目标镜像提前分发到所有工作节点，避免Pod启动时因镜像拉取延迟导致服务中断。Kubernetes生态中主要有三种预拉取实现模式：DaemonSet预拉取、InitContainer预拉取和Sidecar预拉取。三种模式在部署粒度、生命周期、资源消耗和灾备适用性上存在显著差异。

4.1 三种预拉取模式概述

对比维度	DaemonSet预拉取	InitContainer预拉取	Sidecar预拉取
部署对象	集群级DaemonSet，每个节点运行一个Pod	目标Deployment的Pod内InitContainer	目标Deployment的Pod内Sidecar容器
生命周期	长期运行，独立于业务Pod	Pod启动时执行，完成后退出	与业务容器同生命周期，持续运行
镜像拉取时机	DaemonSet Pod启动时（可提前数小时/天）	业务Pod启动流程中，严格串行	业务Pod启动时，与主容器并行
资源占用	每个节点额外1个Pod（含容器运行时）	仅启动阶段占用临时存储和网络	持续占用CPU/内存（需配置资源限制）
灾备适用性	★★★★★ 全节点预覆盖，适合大规模集群	★★★☆☆ 仅预热本Pod镜像，节点级覆盖弱	★★☆☆☆ 适合热备场景，资源开销大
镜像更新策略	DaemonSet滚动更新，全节点同步	随业务Deployment更新触发	随业务Deployment更新触发
失败影响范围	单个节点预拉取失败不影响其他节点	Pod启动失败，影响业务可用性	Sidecar异常可能影响主容器网络/存储

4.2 DaemonSet预拉取模式

DaemonSet预拉取是集群灾备中最推荐的方案。通过部署一个专用的预拉取DaemonSet，在每个节点上运行一个只负责拉取镜像的Pod，将灾备镜像提前分发到所有节点本地缓存中。

  核心优势：预拉取操作完全独立于业务Pod，即使业务Deployment尚未部署，镜像已存在于节点本地。故障切换时，业务Pod启动无需等待镜像拉取，实现秒级启动。

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: image-prefetch
  namespace: disaster-recovery
spec:
  selector:
    matchLabels:
      app: image-prefetch
  template:
    metadata:
      labels:
        app: image-prefetch
    spec:
      initContainers:
      - name: prefetch
        image: <disaster-image>:<tag>
        command: ["/bin/sh", "-c", "echo 'Image pulled to node cache'; sleep 5"]
        imagePullPolicy: Always
      containers:
      - name: pause
        image: gcr.io/google_containers/pause:3.9

注意：DaemonSet预拉取会占用节点磁盘空间。若预拉取镜像较大（如超过2GB），建议结合节点本地存储监控，避免因镜像缓存撑满根分区导致节点异常。建议设置DaemonSet的spec.updateStrategy.rollingUpdate.maxUnavailable为10%~25%，控制并发拉取对节点网络和磁盘I/O的冲击。

4.3 InitContainer预拉取模式

InitContainer预拉取将镜像拉取逻辑嵌入业务Pod的初始化流程中。在业务容器启动前，InitContainer先运行并拉取指定镜像，完成后退出，主容器随后启动。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: business-app
spec:
  template:
    spec:
      initContainers:
      - name: prefetch
        image: <disaster-image>:<tag>
        command: ["/bin/sh", "-c", "echo 'Prefetch complete'; exit 0"]
        imagePullPolicy: Always
      containers:
      - name: main-app
        image: <business-image>:<tag>

适用场景：InitContainer模式适合单个Pod内需要预热多个辅助镜像（如sidecar代理、日志采集器）的场景。但注意：InitContainer串行执行会延长Pod启动时间，在灾备切换时可能增加RTO（恢复时间目标）。

4.4 Sidecar预拉取模式

Sidecar预拉取通过在业务Pod内增加一个长期运行的Sidecar容器，持续保持目标镜像的热度。该模式常用于需要实时同步镜像版本或维持容器运行时缓存的热备场景。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: business-app
spec:
  template:
    spec:
      containers:
      - name: main-app
        image: <business-image>:<tag>
      - name: prefetch-sidecar
        image: <disaster-image>:<tag>
        command: ["/bin/sh", "-c", "while true; do sleep 3600; done"]
        imagePullPolicy: Always
        resources:
          requests:
            cpu: 50m
            memory: 64Mi
          limits:
            cpu: 100m
            memory: 128Mi

风险提示：Sidecar模式会持续占用节点资源，且Sidecar容器与主容器共享网络和存储卷。若Sidecar容器异常退出，可能触发Pod重启策略，影响业务连续性。在灾备场景中，除非有明确的实时缓存需求，否则不推荐作为主要预拉取手段。

4.5 三种模式架构对比

下图展示了三种预拉取模式在集群节点上的部署架构差异：

4.6 灾备场景选型建议

大规模集群灾备（节点数 > 50）：优先选择DaemonSet预拉取。独立生命周期、全节点覆盖、滚动更新可控，是灾备预拉取的标准模式。
小规模集群或单节点灾备：可选用InitContainer预拉取，减少额外资源开销，但需接受Pod启动延迟。
热备场景（要求镜像实时同步）：谨慎使用Sidecar预拉取，必须配置严格的资源限制和健康检查，避免Sidecar异常影响主容器。
混合策略：生产环境推荐DaemonSet + InitContainer组合：DaemonSet负责全节点基础镜像预热，InitContainer负责业务Pod特有辅助镜像的按需拉取。

最佳实践：在灾备演练中，建议通过kubectl get pods -n disaster-recovery -o wide验证DaemonSet预拉取Pod是否在所有节点上正常运行。同时使用crictl images或nerdctl images检查节点本地镜像缓存是否包含目标灾备镜像。