临时卷(Ephemeral Volume)

临时卷会随着 Pod 的删除而消失，常用于缓存、构建产物或临时文件。它们轻量、易用，但不适合保存需要长期保留的数据。

本节补充了临时卷类型、容量配置、资源限制与调度影响，帮助你在实际场景中做出正确选择。

什么是临时卷

最常用的是 emptyDir。另外 Kubernetes 也支持 generic ephemeral volume，可通过 StorageClass 动态分配短期存储。

典型场景

运行时缓存与临时文件
数据处理中的中间结果
sidecar 与主容器共享数据
CI/批处理任务的临时空间

emptyDir 基础

emptyDir 在 Pod 调度时创建，Pod 删除后释放：

volumes:
  - name: scratch
    emptyDir:
      sizeLimit: 1Gi

挂载到容器：

volumeMounts:
  - name: scratch
    mountPath: /tmp

内存盘 emptyDir

需要更高性能时可用内存盘：

emptyDir:
  medium: Memory
  sizeLimit: 512Mi

它会占用节点内存，容量过大可能导致 OOM。

Generic Ephemeral Volume

可以通过 StorageClass 分配短期 PVC：

volumes:
- name: cache
  ephemeral:
    volumeClaimTemplate:
      spec:
        accessModes: ["ReadWriteOnce"]
        storageClassName: fast-ssd
        resources:
          requests:
            storage: 5Gi

该 PVC 会随 Pod 创建和删除，适合批处理或短期任务。

Sidecar 共享示例

主容器写日志，sidecar 读取并处理：

containers:
- name: app
  image: my-app:latest
  volumeMounts:
  - name: shared
    mountPath: /var/log/app
- name: shipper
  image: busybox
  command: ["sh", "-c", "tail -F /var/log/app/app.log"]
  volumeMounts:
  - name: shared
    mountPath: /var/log/app

最佳实践

尽量为 emptyDir 设置 sizeLimit。
缓存可重建，避免存放关键数据。
需要极低延迟的临时数据可用内存盘。
统一临时目录路径，便于清理脚本生效。

示例：构建工作区

CI 或构建任务需要短期空间，可用临时卷：

volumes:
  - name: workspace
    emptyDir: {}
volumeMounts:
  - name: workspace
    mountPath: /workspace

构建产物要在 Pod 退出前上传到对象存储或持久卷。

调度与磁盘压力

临时存储会受到节点磁盘压力影响，空间不足时 Pod 可能被驱逐。可以通过事件观察 eviction 或 disk pressure：

kubectl describe node <node>

资源请求与限制

可以为临时存储设置 requests/limits：

resources:
  requests:
    cpu: "100m"
    memory: "256Mi"
    ephemeral-storage: "1Gi"
  limits:
    cpu: "500m"
    memory: "512Mi"
    ephemeral-storage: "2Gi"

这样调度器会保证节点有足够空间。

生命周期与清理

临时卷与 Pod 生命周期绑定，Pod 被重建或迁移到其他节点时，数据会丢失。缓存类数据要可重建，避免依赖临时卷保存关键状态。

大小限制与行为

emptyDir.sizeLimit 是软限制，超过后可能被驱逐。建议同时设置 ephemeral-storage requests/limits，提升调度可预测性。

Generic Ephemeral 与 PVC 的区别

Generic Ephemeral Volume 会随 Pod 创建和删除，适合短期任务或批处理；PVC 适合需要长期保留的数据。不要用临时卷替代数据库存储。

容器日志与磁盘压力

容器日志同样会占用节点临时存储。日志过多会触发 disk pressure 导致 Pod 被驱逐，建议配置日志轮转或集中采集。

示例：初始化缓存

用 init 容器预热缓存：

initContainers:
- name: warm-cache
  image: busybox
  command: ["sh", "-c", "echo warm > /cache/seed.txt"]
  volumeMounts:
  - name: cache
    mountPath: /cache
containers:
- name: app
  image: my-app:latest
  volumeMounts:
  - name: cache
    mountPath: /cache

可观测性

查看节点临时存储与 Pod 消耗：

kubectl describe node <node>
kubectl top pod -A

在 Pod 内部查看磁盘使用：

kubectl exec -it <pod-name> -- df -h

安全注意事项

临时卷位于节点文件系统，不适合存放敏感数据。若必须使用，建议采用内存盘并严格控制大小。

涉及合规数据时，优先避免写入临时卷或在写入前加密。

不适合临时卷的场景

数据库或需要长期保存的数据
审计日志或合规数据
用户上传文件

常见问题

Pod Pending：节点临时存储不足。
Evicted：磁盘压力触发驱逐。
IO 慢：节点磁盘被其他工作负载占满。

排查命令：

kubectl describe pod <pod-name>
kubectl get events -A

如频繁驱逐，减少缓存占用或把任务分散到更多节点。

实操要点

先做快速盘点：kubectl get nodes、kubectl get pods -A、kubectl get events -A。
对比“期望状态”和“实际状态”，kubectl describe 往往能解释漂移或失败原因。
名称、Label、Selector 要一致，避免 Service 或控制器找不到 Pod。

快速检查清单

资源定义与业务意图一致。
Namespace、权限、镜像与环境匹配。
上线前具备健康探针与可观测日志。
临时存储使用量有边界。

实战补充

把快速入门应用到真实业务时，建议固定一套检查项：资源 requests、就绪探针、日志覆盖、告警阈值、回滚步骤。清单要短小、可重复，并随仓库一起维护，这样每次发布都能快速对齐标准。

排障路径

从现象入手，不要先猜原因。先看事件，再看日志，最后验证流量路径和配置版本是否一致。若访问异常，先确认 readiness 和 endpoints，再逐段排查入口到后端的链路。记录每一步改动，方便回滚和复盘。

小练习

在测试环境做几次常见操作：扩缩容、重启单个 Pod、调整一项配置并验证效果。通过这些小练习，你能更直观地感受到系统收敛速度和异常时的行为。

维护与责任

明确服务归属、值班人和升级窗口，准备常见故障的处理步骤。依赖服务也需要纳入监控和备份计划，确保问题出现时能快速定位和恢复。

交付提醒

发布后用用户视角快速验证一次：访问核心接口、观察延迟和错误率，确认新旧 Pod 的状态稳定。如果涉及存储或网络，顺手核对磁盘用量、DNS 和 endpoints 是否正常。

回滚预案

写下最小可行的回滚步骤，包括需要恢复的配置、镜像版本和校验方式。这样在出现异常时可以迅速还原，而不是现场临时拼步骤。