news 2026/2/17 20:36:11

in argocd ‘/tmp/_argocd-repo/../.git/index.lock‘: No space left on

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
in argocd ‘/tmp/_argocd-repo/../.git/index.lock‘: No space left on

Unable to load data: Failed to checkout FETCH_HEAD:
git checkout --force FETCH_HEADfailed exit status 128: fatal: Unable to create
‘/tmp/_argocd-repo/637eecbf-7342-4ad9-a02c-aeabf9a667f5/.git/index.lock’: No space left on device

================================

问题核心定位

报错No space left on device是关键 →ArgoCD 组件(通常是argocd-repo-server)所在节点的磁盘空间耗尽,导致 Git 拉取代码时无法创建.git/index.lock临时文件,最终 checkout 失败。

分步解决方案

1. 紧急排查:确认磁盘空间占用(定位问题节点)

首先找到argocd-repo-serverPod 所在节点,并检查节点磁盘使用情况:

# 1. 找到argocd-repo-server的Pod名称和所在节点kubectl get pods -n argocd -l app.kubernetes.io/name=argocd-repo-server -o wide# 示例输出(重点看NODE列):# NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES# argocd-repo-server-7f98d7689c-9x8zl 1/1 Running 0 1d 10.244.2.3 node-01 <none> <none># 2. 登录节点(或通过kubectl exec直接检查Pod挂载的磁盘)# 方式1:登录节点检查磁盘sshnode-01df-h# 查看所有磁盘挂载点的使用率(重点看 / 或 /tmp 分区)# 方式2:直接在argocd-repo-server Pod内检查磁盘kubectlexec-n argocd argocd-repo-server-7f98d7689c-9x8zl --df-h

关键排查点

  • 节点的根分区(/)或/tmp分区使用率 ≥ 95%;
  • ArgoCD 的临时目录(/tmp/_argocd-repo/)所在分区满了。
2. 紧急释放空间(临时解决)
(1)清理 Pod 内临时文件(ArgoCD 缓存)

ArgoCD repo-server 会缓存 Git 仓库数据,清理缓存可快速释放空间:

# 进入argocd-repo-server Podkubectlexec-n argocd -it argocd-repo-server-7f98d7689c-9x8zl -- /bin/sh# 清理临时仓库目录(核心)rm-rf /tmp/_argocd-repo/*# 清理其他临时文件rm-rf /tmp/*exit
(2)清理节点上的无用文件(长期)

登录节点后执行以下操作释放空间:

# 1. 清理docker/containerd镜像(最有效)docker system prune -a -f# 清理未使用的镜像、容器、卷(containerd用 ctr images prune -a -f)# 2. 清理K8s无用Pod(已终止的)kubectl delete pods --all-namespaces --field-selector=status.phase=Failed kubectl delete pods --all-namespaces --field-selector=status.phase=Succeeded# 3. 清理节点日志(/var/log 目录)find/var/log -type f -size +100M -delete# 删除大于100M的日志文件journalctl --vacuum-size=1G# 清理systemd日志# 4. 检查大文件(定位占用空间的文件)du-sh /var/lib/docker/*# 查看docker目录大小find/ -type f -size +1G -execls-lh{}\;# 查找大于1G的文件
3. 长期解决方案(避免再次发生)
(1)给 ArgoCD Repo Server 配置临时目录持久化/扩容

修改argocd-repo-server的 Deployment,为/tmp目录挂载临时存储卷,并设置大小限制:

# 编辑argocd-repo-server的Deploymentkubectl edit deployment argocd-repo-server-n argocd

spec.template.spec.containers[0]下添加volumeMounts,并在spec.template.spec下添加volumes

spec:template:spec:containers:-name:argocd-repo-server# 原有配置...volumeMounts:-name:tmp-dirmountPath:/tmp# 设置目录大小限制(可选)resources:limits:ephemeral-storage:10Gi# 限制临时存储使用10Girequests:ephemeral-storage:5Givolumes:-name:tmp-diremptyDir:medium:Memory# 用内存作为临时目录(更快,也可改为emptyDir: {}使用磁盘)sizeLimit:5Gi# 限制临时目录大小
(2)配置 ArgoCD 仓库缓存自动清理

ArgoCD 支持配置仓库缓存的 TTL(过期时间),修改argocd-cmConfigMap:

kubectl edit configmap argocd-cm -n argocd

添加以下配置,让缓存自动过期清理:

data:# 仓库缓存TTL:1小时(可根据需求调整,如24h)repo.cache.ttl:1h# 禁用不必要的缓存(可选)repo.cache.enabled:"true"

修改后重启argocd-repo-server

kubectl rollout restart deployment argocd-repo-server -n argocd
(3)监控节点磁盘使用率(提前预警)

配置 Prometheus + Grafana 监控节点磁盘使用率,设置告警阈值(如使用率≥85%时告警):

  • 监控指标:node_filesystem_usage_bytes/node_filesystem_size_bytes
  • 告警规则示例:
    groups:-name:node-disk-alertrules:-alert:NodeDiskFullexpr:100 * (node_filesystem_usage_bytes{mountpoint="/"}/ node_filesystem_size_bytes{mountpoint="/"})>85for:5mlabels:severity:warningannotations:summary:"节点 {{ $labels.node }} 磁盘使用率过高"description:"节点 {{ $labels.node }} 的 / 分区使用率已达 {{ $value | humanizePercentage }},请及时清理空间。"
4. 验证修复效果
# 重启argocd-repo-server(确保配置生效)kubectl rollout restart deployment argocd-repo-server -n argocd# 检查Pod状态kubectl get pods -n argocd -l app.kubernetes.io/name=argocd-repo-server# 重新触发ArgoCD同步(验证Git checkout是否正常)argocd appsync<your-app-name># 或在UI上手动同步

常见问题补充

  • 如果是ArgoCD部署在PVC上导致空间满
    检查 ArgoCD 使用的 PVC(如argocd-repo-server的数据卷),执行kubectl exec -n argocd argocd-repo-server-xxx -- df -h /data,若/data分区满,需扩容 PVC:
    kubectl patch pvc<pvc-name>-n argocd -p'{"spec":{"resources":{"requests":{"storage":"20Gi"}}}}'
  • Git checkout 仍失败
    确认清理完空间后,删除 ArgoCD 对应的 repo 缓存目录(/tmp/_argocd-repo/<repo-id>),再重新同步。

========================================

d-wx------. 4 argocd argocd 4096 Nov 4 05:06 _argocd-repo
$ du -hs
du: cannot read directory ‘./_argocd-repo’: Permission denied

问题核心

当前du -hs权限拒绝,是因为_argocd-repo目录的权限为d-wx------(仅拥有者有写入+执行权限,无读取权限),且你当前执行命令的用户不是argocd(目录属主),导致无法遍历目录统计大小。

解决方案(按优先级排序)

1. 以argocd用户身份执行du(推荐,无风险)

利用kubectl exec直接切换到argocd用户(Pod 内默认属主),或用sudo(节点上)读取目录:

# 场景1:在argocd-repo-server Pod内操作(推荐)kubectlexec-n argocd -it argocd-repo-server-<pod后缀>--su- argocd -c"du -hs /tmp/_argocd-repo"# 场景2:如果在节点的/tmp目录下(需节点有sudo权限)sudo-u argocddu-hs ./argocd-repo
2. 临时修改目录权限(应急清理,清理后恢复)

若无法切换用户,可临时添加目录的读取权限,统计/清理后再恢复(避免权限漏洞):

# 1. 临时添加读权限(仅目录所有者可执行)kubectlexec-n argocd -it argocd-repo-server-<pod后缀>--chmodu+r /tmp/_argocd-repo# 2. 统计大小kubectlexec-n argocd -it argocd-repo-server-<pod后缀>--du-hs /tmp/_argocd-repo# 3. 清理目录内文件(核心:释放空间)kubectlexec-n argocd -it argocd-repo-server-<pod后缀>--rm-rf /tmp/_argocd-repo/*# 4. 恢复原权限(关键:避免安全风险)kubectlexec-n argocd -it argocd-repo-server-<pod后缀>--chmodu-r /tmp/_argocd-repo
3. 直接强制删除目录(终极应急,无权限也能删)

若仅需清理空间,无需统计大小,可直接用root用户强制删除目录(Pod 内kubectl exec默认是root):

# Pod内root用户直接删除缓存目录(会自动重建,无影响)kubectlexec-n argocd -it argocd-repo-server-<pod后缀>--rm-rf /tmp/_argocd-repo/*

关键说明

  1. 权限背景_argocd-repo目录权限d-wx------是 ArgoCD 的安全设计(仅允许写入/执行,禁止读取),避免非授权用户查看仓库缓存;
  2. 清理无风险_argocd-repo是临时缓存目录,删除后 ArgoCD 会重新拉取 Git 仓库数据,不会影响核心配置;
  3. 验证清理效果
    # 清理后检查磁盘空间kubectlexec-n argocd -it argocd-repo-server-<pod后缀>--df-h /tmp

长期优化:避免重复权限问题

在之前配置的argocd-repo-serverDeployment 中,给/tmp挂载emptyDir卷时,可指定目录属主(确保权限可控):

spec:template:spec:securityContext:fsGroup:999# argocd用户的gid(默认999)containers:-name:argocd-repo-serversecurityContext:runAsUser:999# argocd用户的uid(默认999)runAsGroup:999volumeMounts:-name:tmp-dirmountPath:/tmpsubPath:_argocd-repo# 仅挂载缓存子目录volumes:-name:tmp-diremptyDir:sizeLimit:5Gi

如果需要我帮你编写一键清理 ArgoCD 缓存且自动恢复权限的脚本,可以补充完整的执行环境(如 Pod 名称固定前缀、节点权限等),我会针对性完善。

版权声明: 本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若内容造成侵权/违法违规/事实不符,请联系邮箱:809451989@qq.com进行投诉反馈,一经查实,立即删除!
网站建设 2026/2/14 15:32:37

Java 线程池(第十篇):(收官篇)CompletableFuture 异步编排实战 —— 多任务并行、结果汇总、超时控制与线程池协作

completableFuture 异步编排实战 —— 多任务并行、结果汇总、超时控制与线程池协作 如果说前 1–9 篇解决的是 “线程池如何安全、稳定地跑”&#xff0c; 那么这一篇解决的是&#xff1a; 如何把多个异步任务“编排”成一个可读、可控、可维护的并发流程。 这正是现代 Java …

作者头像 李华
网站建设 2026/2/15 22:17:22

EmotiVoice在冥想引导音频中的舒缓语气呈现

EmotiVoice在冥想引导音频中的舒缓语气呈现 在快节奏的现代生活中&#xff0c;越来越多的人开始通过冥想缓解焦虑、提升专注力。而一段真正有效的冥想引导音频&#xff0c;往往不在于说了什么&#xff0c;而在于“怎么说”——语速是否柔和&#xff1f;停顿是否有呼吸感&#x…

作者头像 李华
网站建设 2026/2/15 20:15:22

EmotiVoice性能评测:响应速度、清晰度与情感丰富度全解析

EmotiVoice性能评测&#xff1a;响应速度、清晰度与情感丰富度全解析 在虚拟助手越来越“懂人心”、游戏NPC开始“真情流露”的今天&#xff0c;语音合成技术早已不再是简单的文字朗读。用户不再满足于“能听清”&#xff0c;而是期待“听得动情”。传统TTS系统虽然解决了“说什…

作者头像 李华
网站建设 2026/2/17 9:59:43

Material You动态色彩系统:重塑Android应用主题一致性新范式

Material You动态色彩系统&#xff1a;重塑Android应用主题一致性新范式 【免费下载链接】Seal &#x1f9ad; Video/Audio Downloader for Android, based on yt-dlp, designed with Material You 项目地址: https://gitcode.com/gh_mirrors/se/Seal 在数字化体验日益个…

作者头像 李华
网站建设 2026/2/17 5:17:43

如何用4步实现实时AI视频生成:Wan2.1模型完整指南

如何用4步实现实时AI视频生成&#xff1a;Wan2.1模型完整指南 【免费下载链接】Wan2.1-I2V-14B-480P-StepDistill-CfgDistill-Lightx2v 项目地址: https://ai.gitcode.com/hf_mirrors/lightx2v/Wan2.1-I2V-14B-480P-StepDistill-CfgDistill-Lightx2v 在AI技术快速发展的…

作者头像 李华
网站建设 2026/2/16 19:22:13

Linux内核处理器信息获取的技术演进:从CPUID指令到现代硬件抽象层

Linux内核处理器信息获取的技术演进&#xff1a;从CPUID指令到现代硬件抽象层 【免费下载链接】linux-insides-zh Linux 内核揭秘 项目地址: https://gitcode.com/gh_mirrors/lin/linux-insides-zh 你可能不知道的是&#xff0c;现代Linux内核获取处理器信息的方式已经远…

作者头像 李华