kubectl exec传输文件时标准输出疑似被截断的问题求证

我需要将Kubernetes Pod内一个包含350个文件、总大小约40MB的目录复制到本地，采用Kubernetes官方文档推荐的kubectl exec结合tar的命令：

kubectl exec -n my-namespace my-pod -- tar cf - /tmp/foo | tar xf - -C /tmp/bar

但该操作频繁失败，报错为<归档中某文件>: Truncated tar archive，且每次报错的文件都不相同，仅偶尔能成功。

我的推测是：kubectl在检测到Pod内指定的tar命令执行完成后，会直接终止进程，而不管网络中是否还有待传输的标准输出字节。

我尝试了多种优化方案：

• 使用stdbuf调整输出缓冲
• 修改tar的blocking factor参数
• 添加sleep延长命令运行时间，例如：

  kubectl exec -n my-namespace my-pod -- bash -c 'dd if=<(tar cf - -C /tmp/foo .) bs=16 && sleep 10' | tar xf - -C /tmp/bar
  

其中将bs设为16并配合sleep 10可稳定运行，但bs=1时无需sleep却传输速度极慢。

现求证：我的推测是否正确？kubectl是否会在exec命令结束后截断标准输出？

结论：你的推测完全正确 #

kubectl exec的底层通过Kubernetes API的exec端点建立双向数据流，当Pod内的目标命令（此处为tar）执行完毕退出时，kubelet会立即关闭对应流的写端。而kubectl在接收到流关闭的信号后，会直接终止本地的管道进程，这就可能导致仍在网络传输队列中的最后一批数据被丢弃，最终引发tar归档截断的问题。

这种问题的本质是TCP流的关闭时机不匹配：Pod内的tar命令完成输出后立即退出，kubelet随之关闭连接，但此时TCP栈中可能仍有未发送或未被本地接收的数据包，kubectl没有等待这些数据传输完成就终止了本地的tar进程，进而导致归档文件不完整。

你通过添加sleep解决问题的原理，是延长了Pod内命令的存活时间，给TCP足够的窗口完成剩余数据的传输；而bs=1时无需sleep是因为数据逐字节传输，TCP缓冲能及时将数据发送完毕，代价就是传输效率极低。

另外提供两个更优雅的替代方案（无需依赖sleep）：

• 在Pod内的tar命令后追加cat /dev/null，让进程在tar结束后不立即退出，等待流自然同步：

  kubectl exec -n my-namespace my-pod -- bash -c 'tar cf - /tmp/foo; cat /dev/null' | tar xf - -C /tmp/bar
  

• 使用官方专门的文件复制工具kubectl cp，底层已处理好流同步问题：

  kubectl cp my-namespace/my-pod:/tmp/foo /tmp/bar
  

内容的提问来源于stack exchange，提问作者Ed MacDonald