我正在尝试将文件复制到ACS k8s群集上运行的pod中的Windows容器中。
我在Windows 10笔记本电脑上使用这个kubectl命令：
kubectl cp dev-acs-conn-testdn-1981314364-rjc0l:\app\nettrace.etl c:\
我在回复时收到此错误：
错误：存档/ tar：无效的tar标头
我从运行k8s的v1.7.7和v1.7.9以及Server 2016 ltsc和Server v1709的群集中尝试过此操作。我的kubectl.exe是v1.8.5。我有一些有价值的调试文件滞留在我的容器上，任何想法我怎么能让它工作？
答案 0 :(得分：1)
事实证明，＆＃34; kubectl cp＆＃34;命令要求tar在容器中，而不是像我预期的那样在本地系统上。由于Windows并没有附带tar.exe，因此存在问题。
我部署了一个新的pod，其中包含Windows版本的tar.exe及其依赖项。这让我在Server 2016 ltsc容器中得到了进一步的发展。我只需稍微调整一下我的语法，然后就可以了：
kubectl cp dev-acs-conn-testdn-1981314364-rjc0l:/app/nettrace.etl nettrace.etl
但是，此相同的过程不适用于Server v1709容器。当我尝试完全相同的过程时，我得到了这个错误：
tar：无法打开 - ：权限被拒绝
tar：错误无法恢复：现在退出
显然是权限错误，但我不知道该问题是什么权限以及如何更改它们。有什么想法吗？
答案 1 :(得分：0)
回避此问题。现在Windows v1803容器在kubernetes中可以正常工作了，我已经测试了相同的问题，并且一切都正常工作。 Windows v1803开始作为操作系统的一部分与tar.exe一起提供。是的，对微软来说！
一个奇怪的地方是，从吊舱复制到本地系统时，目的地始终是文件夹。它将所有文件从源解压缩到该文件夹，但是，如果您指定一个文件，它仍会创建该名称的文件夹。没什么大不了的，只是奇怪。
对我来说，这个问题的答案是：使用v1803容器映像。是的，这可能不是您想听到的，但现实是Windows容器支持仍处于新生阶段，而从v1803开始，kubernetes支持非常新生。 v1809可能最终成为稳定可靠的地方。