DaemonSet不适合部署Composer本地缓存服务，因其强绑定节点生命周期，而Composer缓存需跨Pod存在、按命名空间隔离、构建时复用，应改用InitContainer+PVC挂载或registry代理方案。
DaemonSet 不适合部署 Composer 本地缓存服务——它根本不是节点级守护进程该干的事。
为什么 DaemonSet 会误伤 Composer 缓存场景
Composer 的 COMPOSER_HOME 缓存目录本质是开发/构建阶段的产物，不是运行时必需的节点级系统服务。DaemonSet 强绑定节点生命周期：新节点加入就拉起 Pod、节点 NotReady 也不删 Pod、删除 DaemonSet 就全量清空所有缓存。但 Composer 缓存需要的是：
- 构建时复用（CI 流水线中多个 Job 共享同一份 vendor 包）
- 跨 Pod 生命周期存在（一个 PHP 应用 Pod 重启不应丢失已下载依赖）
- 按命名空间或项目隔离（不同团队的
composer install不该互相污染）
用 DaemonSet 部署，反而会导致缓存分散在每个节点上、无法统一管理、升级镜像时旧缓存被暴力清空、甚至因节点临时失联造成缓存不可达。
真正该用的方案：InitContainer + PVC 挂载
把缓存从“节点级”降维到“构建单元级”，才是符合 K8s 原生语义的做法。典型做法是：
评估 Kubernetes 集群安全态势，覆盖 RBAC、工作负载安全、网络策略、基础设施即代码（IaC）、运行时监控和密钥管理等 30 项控制项……
- 定义一个只读的
PersistentVolumeClaim（PVC），挂载到 CI Job 或 Build Pod 的/root/.composer/cache - 在
initContainer中执行composer install --no-dev，结果写入 PVC - 主容器直接使用该 PVC 下的
vendor/目录，不重复下载
这样既避免了每次构建都拉镜像和依赖，又不会因节点故障丢失缓存；PVC 可绑定 NFS 或对象存储网关，天然支持多 Job 并发读写（加 accessModes: ReadWriteMany 即可）。
如果非要“统一缓存”，优先考虑 registry 代理而非 DaemonSet
真正需要集群级统一缓存的环节，其实是镜像拉取本身。Composer 的包源（如 packagist.org）没法被 K8s 原生代理，但你可以：
- 部署一个
registry-proxy（如ghcr.io/cesanta/docker_auth+nginx缓存层），拦截对packagist.org的 HTTP 请求 - 让所有 CI Job 的
composer config -g repo.packagist composer https://your-registry-proxy/packagist - 配合
hostPath或emptyDir在代理 Pod 内做磁盘缓存，比 DaemonSet 更轻量、更可控
注意：这种代理必须处理 Packagist 的 JSON API 和 ZIP 包重定向逻辑，不能简单用 proxy_pass —— 否则 Composer 会因 Content-Length 不匹配或签名校验失败而报错 Failed to extract ... invalid phar。
真正容易被忽略的点：Composer 缓存路径的权限。K8s Pod 默认以非 root 用户运行，而 COMPOSER_HOME 若挂载到 emptyDir 或 hostPath，目录属主可能是 root，导致 composer install 权限拒绝。务必在 securityContext 中显式设置 runAsUser 和 fsGroup，否则缓存永远写不进去。
