kubectl cp 报 tar not found：文件复制需要容器内的归档工具

本地文件存在，kubectl cp 却报 exec: "tar": executable file not found in $PATH，或在复制时返回退出码 126。完整错误明确指向 tar 时，先核对被选中的容器镜像是否提供它。只看退出码，不能排除其他执行权限或运行时错误。

kubectl 的文件复制通过容器执行归档工具来传输内容。镜像只有应用二进制，或删除了 tar 的精简镜像，并不因此具备这项复制能力。宿主机装好 tar，也不会给容器补上可执行文件。

确认命令选中了哪个容器

同一 Pod 的应用容器、代理容器可能使用不同镜像。以下为只读诊断示例，命名空间、Pod 和容器名均需替换：

kubectl get pod app-0 -n team-app -o yaml
kubectl exec -n team-app app-0 -c app -- tar --version

先查看实际运行的镜像和容器状态，再检查 tar 能否执行。部分 tar 实现不支持 --version，这时应按镜像清单和工具支持的参数确认；“不支持这个参数”与“找不到可执行文件”不是同一种结果。工具存在但未在进程 PATH 中，也会影响按名称执行。

不指定 -c 时，默认选择可能不是需要读写文件的应用容器。复制示例可明确指定：

kubectl cp ./diagnostic.txt team-app/app-0:/tmp/diagnostic.txt -c app

它仍要求该容器具有适用的 tar、目标目录可写，且具备相应的 Pod 执行权限。--no-preserve 调整保留属性的行为，不能消除 tar 依赖。容器已经结束、RBAC 拒绝执行或目标只读时，应处理对应的错误，不要全部归为镜像缺工具。

长期需要复制时，在镜像维护流程中提供工具

项目允许保留诊断工具时，在受维护的镜像中加入兼容的 tar，再按正常构建和发布流程更新。保留旧镜像与部署清单，确认新增工具的架构、运行库、执行路径和应用账户权限。

从其他镜像随手复制一个 tar 二进制，可能继续遇到动态加载器或库缺失；文件放进去不等于能够执行。也不要假设精简镜像有 shell、包管理器或 root 权限，直接在运行容器中临时安装通常无法形成可重复的部署。

必须维持无工具镜像时，优先使用应用已有的导入、导出接口，或设计明确的配置挂载。诊断工具容器拥有自己的文件系统，不会自动获得应用容器根目录。只有文件本来位于可安全共享的卷，才考虑通过有工具的容器访问那个卷，并核对卷访问模式、节点约束、权限与并发写入。

只有一个普通文件，可在已有工具的条件下传输字节

目标没有 tar，但有可用的 cat 时，可以取出一个普通文件。以下例子把结果写入新的本地诊断文件，不覆盖已有副本：

kubectl exec -n team-app app-0 -c app -- cat /tmp/diagnostic.txt > ./diagnostic-copy.txt

这里没有申请 TTY，避免终端处理改变字节或混合输出。先确认本地目标不存在，并检查命令是否成功；本地 shell 会先打开输出文件，远端读取失败也可能留下空文件或不完整副本。

写入容器还需要 shell 和 cat，目标应是明确可写、可覆盖的普通文件。例如在事先确认 /tmp 与新文件用途后：

kubectl exec -i -n team-app app-0 -c app -- sh -c 'cat > /tmp/diagnostic-new.txt' < ./diagnostic.txt

-i 保留标准输入，不加 -t。单文件字节传输不保留目录结构、所有者、文件模式、软链接等元数据，也不能直接替代目录复制。镜像连 cat 或 sh 都没有时，这条路径同样不成立。写入中断可能留下部分文件，不能直接覆盖正在使用的配置。

文件到位后，核对内容和生命周期

复制恢复的标准是原命令成功、目标内容或校验值与源端相符，并且应用账户能按预期使用文件。传输敏感文件时同时检查访问权限，诊断输出不要混入凭据。

容器可写层中的临时文件可能在容器替换后丢失；卷中的文件则可能继续存在。长期配置应纳入镜像、挂载或应用配置流程。需要回退时恢复旧镜像与部署配置，另行恢复被覆盖的文件；部署回退不会自动撤销共享卷中的写入。结束诊断后只清理本次确认创建的文件和工具资源。