Kubectl 似乎正在丢弃标准输出

Question

我正在尝试将一个大目录（约 350 个文件，总共约 40MB）的内容从 Kubernetes pod 复制到我的本地计算机。我正在使用 here 描述的技术。

有时它会成功，但在我的主机上通过管道传输到 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

运行后，我希望本地 /tmp/bar 的内容与 pod 中的内容相同。

然而，往往失败。我目前的理论（我对 kubectl 的工作原理了解非常有限，所以这都是猜测）是当 kubectl 确定 tar 命令已经完成时，它会终止——不管是否有剩余的字节在传输中（结束网络）包含标准输出的内容。

我尝试了各种组合：

1. stdbuf
2. 正在更改 tar 的 blocking factor
3. 使命令运行时间更长（通过添加 && 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 的命令完成后截断标准输出的理论是否正确？
   2. 这个问题有更好的解决方案吗？

Answer 1

也许对于 kubectl 来说，它必须应对的完整命令到底是什么，您可能还不够具体。对于谁应该负责管道过程可能存在歧义。 “--”可能不会指示 kubectl 将其作为命令的一部分包含在内。那可能是被shell拦截了。

你有没有试过把它全部包起来双引号？

CMD="tar cf - /tmp/foo | tar xf - -C /tmp/bar"

kubectl exec -n my-namespace my-pod -- "${CMD}"

这样一来，它将在目标处保存的范围作为监视完成过程的一部分。