我正在尝试将一个大目录（大约350个文件，总共大约40 MB）的内容从Kubernetes pod复制到我的本地机器上。
有时它会成功，但非常频繁的是，通过管道传输到我的主机上的tar xf命令的标准输出似乎被截断了。<some file in the archive being transmitted over the pipe>: Truncated tar archive
源目录中的文件不会更改。错误消息中的文件通常不同（即：它看起来在不同的地方被截断）。
作为参考（从上面第行到第行的文档中复制），这是我尝试做的模拟（我使用了不同的pod名称和目录名称）：kubectl exec -n my-namespace my-pod -- tar cf - /tmp/foo | tar xf - -C /tmp/bar
运行之后，我希望我的local /tmp/bar的内容与pod中的内容相同。
我目前的理论（我对kubectl的工作原理了解非常有限，所以这都是推测）是，当kubectl确定tar命令已经完成时，它就会终止--不管是否有包含标准输出内容的剩余字节在传输（通过网络）。
我尝试了以下各项的各种组合：

1. stdbuf
   1.更改tar的blocking factor
   1.使命令的运行时间更长（通过添加&& sleep <x>）
   我不打算列出我尝试过的所有组合，但这是一个使用所有组合的示例：kubectl exec -n my-namespace my-pod -- stdbuf -o 0 tar -b 1 -c -f - -C /tmp/foo . && sleep 2 | tar xf - -C /tmp/bar
   我可以让这个命令的组合非常可靠地工作。例如，忘记stdbuf和-b 1，只休眠100秒，即：kubectl exec -n my-namespace my-pod -- tar -c -f - -C /tmp/foo . && sleep 100 | tar xf - -C /tmp/bar
   但是更多的实验让我相信tar的块大小（512字节，我相信？）仍然太大（-b的参数是块的计数，而不是这些块的大小）。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那么小，让睡眠“那么大”才能让它工作。但这至少给了我两个可以摆弄的变量。我确实发现，如果我设置bs=1，我就不必睡眠......但移动所有数据（一次一个字节）花了很长时间。
   所以，我想我的问题是：
   1.我的理论是，kubectl在确定给exec的命令已经完成后截断标准输出，这是正确的吗？
   1.这个问题有更好的解决办法吗？