阿里云余额充值 阿里云 ACK 节点磁盘空间满（Docker/Containerd 目录爆满）自动清理指南

阿里云 ACK 节点磁盘空间满（Docker/Containerd 目录爆满）自动清理指南

当阿里云 ACK 节点磁盘空间满，最常见根因是 Docker/Containerd 镜像缓存、容器日志与临时文件长期堆积。本文给出可落地的自动清理方案，并延伸到账号购买、实名认证/企业认证、充值续费、支付方式、风控审核、资源限制与成本控制，帮助你在海外与跨境业务场景下做出稳妥决策。

问题分析：哪些目录在悄悄吃掉空间

• /var/lib/docker 或 /var/lib/containerd：镜像层与容器层增长，镜像更新频繁的 CI/CD 环境尤为明显。
• /var/log/containers 与 /var/log/pods：JSON 日志未限流或未轮转，长跑服务与高并发日志最易爆。
• 系统日志：journald、内核与守护进程日志未设置保留策略。
• 临时工作目录：应用写入 /tmp、/var/tmp 未清理，构建型任务、批处理作业多见。

解决方案：分层自动化，避免重复救火

层 1：预防（Kubernetes 与节点策略）

• 为业务容器设置 ephemeral-storage requests/limits，并在命名空间下用 LimitRange/ResourceQuota 兜底，限制单 Pod 本地写入。
• 限制容器日志：为日志驱动配置 logrotate 或应用侧日志切割；JSON 日志建议按大小与时间双阈值轮转。
• 镜像治理：统一基础镜像、合并层、删除构建缓存；给镜像清晰的生命周期，减少节点上历史版本堆积。
• ACK 托管场景下，kubelet 参数通常不可直接改，建议通过节点池的初始化脚本（cloud-init/自定义数据）一次性下发 logrotate、journald 策略。

层 2：在节点上定期清理（Docker 与 Containerd 分开处理）

在每个工作节点以 DaemonSet 或系统级定时任务方式执行清理脚本，频率视业务而定（常见 15-60 分钟）。核心动作：

• Docker 运行时（存在 /var/run/docker.sock）
  • 删除无用资源：

    docker system prune -af --filter "until=24h"
    docker image prune -af --filter "until=72h"

  • 压缩过大的容器日志：

    find /var/lib/docker/containers -name "*-json.log" -size +200M -exec truncate -s 20M {} \;

• Containerd 运行时（ACK 新版默认）
  • 镜像层回收（以 k8s.io 命名空间为例）：

    ctr -n k8s.io images prune

  • 清理退出容器与残留：

    crictl ps -a --state=exited -q | xargs -r crictl rm

  • 压缩容器日志：

    find /var/log/containers -name "*.log" -size +200M -exec truncate -s 20M {} \;
    find /var/log/pods -name "*.log" -size +200M -exec truncate -s 20M {} \;

• 系统日志与临时文件：
  • journald：

    journalctl --vacuum-size=1G --vacuum-time=7d

  • 按年龄清理临时目录：

    find /tmp -type f -mtime +3 -delete

实践要点：清理脚本需在特权容器或节点上 root 权限执行；排除系统与运维关键进程；先做非生产演练，确认不影响业务 Pod。

层 3：告警驱动的自动闭环（云监控 + 云助手）

1. 在云监控为节点 ECS 实例配置系统盘使用率阈值（如 80%）。
2. 告警触发后，通过云助手在对应实例执行已备案的清理命令；或用事件服务联动函数计算/运维编排再下发云助手命令。
3. 在命令模板中区分 Docker/Containerd，执行不同清理逻辑；记录执行日志到对象存储或日志服务以便审计。

这种旁路式触发不依赖集群调度，即使 Pod 因磁盘满无法拉起，也能完成清理并恢复节点。

对比表格：Docker vs Containerd 的清理差异

成本控制与资源规划

• 磁盘扩容 vs 自动清理：
  • 短期爆满、镜像迭代频繁：先做自动清理，避免无谓扩容。
  • 长期高写入（日志、缓存）：考虑将系统盘或数据盘在线扩容，并为文件系统扩容；结合日志外采集（如侧车直发到日志服务/对象存储）。
• 拉取成本与冷启动：频繁 prune 可能导致镜像反复下载，增加外网带宽与启动时延。可用企业版镜像仓库、同地域仓库或镜像加速降低拉取成本。
• 日志留存策略：只保留必要的本地副本，长期归档放到便宜的存储，并设定 TTL；避免本地长期堆积。
• 节点规格选择：为高日志/高镜像翻新业务单独的节点池，系统盘更大、IOPS 更高，减少互相影响。

账号购买、实名认证/企业认证、充值续费与支付方式要点

• 账号购买与开通：
  • 国际站新账号常见默认配额较低（ECS/云盘/公网），与 ACK 节点扩容、云助手并发等相关。项目上线前先完成配额申请。
  • 阿里云余额充值 选择计费模式时，磁盘与节点一般建议按量起步 + 预算告警，稳定后再考虑包年包月降低成本。
• 实名认证与企业认证：
  • 未完成认证可能限制购买或提高风控概率，影响磁盘扩容、节点新增等操作的及时性。
  • 企业认证通常有更高的额度与更快的配额审批；跨团队协作时可建立多个 RAM 身份，分权给运维与安全审计。
• 充值续费与支付：
  • 为云监控、日志服务、函数计算等“清理链路依赖服务”开启自动续费并设置余额告警，避免欠费导致告警/自动化失效。
  • 国际站支付建议绑定信用卡（支持 3D Secure）或稳定的 PayPal 账户；大额一次性扩容前提前验证支付通道。

风控审核与资源限制：如何不被卡脖子

• 容易触发风控的动作：新账号短时大量创建/扩容云盘、频繁失败的支付、不同国家/地区快速登录切换。
• 应对：预留实施窗口，提前提交配额申请与工单说明用途；必要时提供企业资质与项目描述，降低风控拦截概率。
• 资源限制规划：
  • 阿里云余额充值 为每个地域的 ECS、云盘、快照和日志写入量预留余量；对自动扩容的节点池设置硬上限与预算告警。
  • 云助手命令并发度受限时，分批对节点执行清理，避免大规模同时下发导致失败。

阿里云余额充值 业务场景建议

• 高并发日志业务：以日志侧车直发到集中式存储 + 本地只保留 1-3 天；本地日志按大小截断，节点每日自动清理。
• 镜像迭代频繁的 CI/CD：构建环境独立节点池，启用定时 prune；镜像仓库同地域部署，减少重复拉取时延与费用。
• 批处理/临时作业：作业结束即清理临时目录；为这类 Pod 单独设置较低的 ephemeral-storage 上限。
• 跨境多地域：在就近地域部署镜像与日志服务，避免跨地域写入造成成本与时延上升；清理脚本模板按地域维护。

常见错误（避坑清单）

• 直接删除 /var/lib/containerd 或 /var/lib/docker/overlay2 下的随机目录，容易破坏仍在运行的容器层。
• 对所有镜像执行 prune -a，导致冷启动潮；应基于“时间 + 标签”过滤并分时清理。
• 截断日志时删除了符号链接或权限变更，导致日志采集失败；应只 truncate 文件，不改属主属组。
• 在业务高峰时段做全量清理，引发瞬时拉取风暴；建议在低峰期执行重度清理、在高峰期只做轻量截断。
• 把 /var/lib/kubelet/pods 当作可清理目录，导致临时卷丢失；该目录不要动。

FAQ

• 清理后业务会中断吗？ 只截断日志与删除未被引用的镜像，不会中断已运行容器；删除被引用镜像或容器则可能影响业务，需谨慎。
• 阿里云余额充值 没有 ctr/nerdctl 怎么清理 Containerd？ 可通过 crictl 与日志截断完成 80% 需求；若需 images prune，建议在节点安装 ctr（随 containerd 提供）。
• 如何判断镜像“未被使用”？ 以容器/Pod 实际引用为准；在清理脚本中先列出运行中容器引用的镜像 ID，再排除这些 ID。
• 日志到底留多久合适？ 与合规和排障窗口相关。现场常用 3-7 天本地 + 长期集中式存储归档；本地仅用于近期回溯。
• ACK 托管集群能改 kubelet 回收阈值吗？ 多数托管场景不建议直接改系统组件，优先用资源配额、日志策略与节点清理脚本达成目标。
• 阿里云余额充值 遇到支付/风控导致扩容失败怎么办？ 先启用清理脚本保底，临时释放空间；并并行处理支付验证、提交配额与风控说明，恢复后再做长期扩容。

选择建议（落地顺序）

1. 先在测试环境验证“日志截断 + 镜像回收”脚本，确保对运行中容器无副作用。
2. 上线云监控阈值告警与云助手命令模板，形成自动化闭环。
3. 对高风险业务启用资源配额与独立节点池，降低相互影响。
4. 评估 2-4 周趋势后，再决定是否扩容系统盘/新增数据盘，并调整预算与自动续费。
5. 在国际站完善实名认证/企业认证与支付通道，提前申请配额，减少风控阻断带来的实施不确定性。