在 Docker Desktop 中启用 k8s 实验性功能

Question

有谁知道这是否可能？

我在文档中所能找到的只是启用 docker 实验功能的参考，而不是 kubernetes 实验功能的参考。

我尝试了这个，但仍然出现错误。

k alpha debug -it exchange-pricing-865d579659-s8x6d --image=busybox --target=exchange-pricing-865d579659-s8x6d
error: ephemeral containers are disabled for this cluster (error from server: "the server could not find the requested resource").

谢谢

Answer 1

我有同样的意图（就像此功能请求中的其他人一样）。经过几个小时的反复试验，我终于找到了一种方法。

脚步：

1. 根据您尝试编辑的文件，您可能需要完全关闭 Docker Desktop，然后重新启动 WSL。（右键单击托盘图标并按“退出 Docker Desktop”，然后运行wsl --shutdown​​，然后运行wsl​​）
2. 打开[...]/kubeadm/manifestsDocker 文件系统中的文件夹。

在 Windows 上，导航 Windows 资源管理器至：

• 对于 Docker 桌面 4.2.0：\\wsl$\docker-desktop-data\version-pack-data\community\kubeadm\manifests
• 对于 Docker 桌面版 4.11.0：\\wsl$\docker-desktop-data\data\kubeadm\manifests

3. 打开kube-controller-manager.yaml、kube-apiserver.yaml、 和kube-scheduler.yaml文件，添加以下行：

spec:
  containers:
  - command:
    [...]
    - --feature-gates=EphemeralContainers=true     <-- add this line

4. 再次启动 Docker Desktop。

当它已经弄清楚时，看起来很容易，对吧？相信我，发现这一点很痛苦。

我遇到的一些减速问题：

1. 我花了很长时间才找到这些清单文件。（最终使用grepWin找到它，在整个\\wsl$\docker-desktop-data文件夹中搜索我从 Pod 的配置中获取的行的任何匹配项kube-apiserver-docker-desktop，我使用Lens查看了该行）
2. 找到它后，我对这个文档感到困惑。当我阅读 时FEATURE STATE: Kubernetes v1.22 [alpha]，我认为这意味着您需要 1.22 或更高版本的 Kubernetes 才能使用该功能。这引起了一场巨大的白费力气，我试图更改在 Docker Desktop 中启动的 Kubernetes 版本，但 Docker Desktop 似乎不喜欢这个版本。（回想起来，这个问题可能只是下面第 3 点中的次要问题......）
3. 当我第一次更改清单文件时，我使用的是 Notepad++。尽管我喜欢 Notepad++，但它在以下方面显然不如 vscode 聪明：它不会自动检测 yaml 文件的缩进类型。因此，当我按制表符创建缩进以便可以将新标志添加到参数列表时，它会将其添加为制表符而不是空格。这导致 Kubernetes 无法读取该文件。如果 Kubernetes 给出了合理的错误消息，那可能还不错，但它只是给出了消息unexpected EOF。一开始我什至没有看到该错误消息，因为它没有传播到 pod kube-controller-manager-docker-desktop（这是唯一没有立即出错/关闭的相关消息）。无论如何，我当时并没有意识到这是问题所在，所以......
4. 我决定尝试绕过清单文件并将我的修改直接应用于 etcd 数据存储。回想起来，这不是一个好主意，因为 etcd 数据存储非常复杂，工具不合格，文档也不合格。我花了很多时间试图弄清楚如何发送命令来读取和写入数据（最终通过etcdctl在etcd-docker-desktopPod 内调用来做到这一点）。我还花了更多时间编写一个 NodeJS 脚本，该脚本能够以 JSON 形式读取所有数据，将其存储在转储文件中，并且能够将对条目的更改写回，尽管涉及 3 级以上的引用（我最终能够使用stdin传递值而不是作为命令字符串的一部分，以避免引号起始）。在完成上面关于 etcd 读/写的所有工作之后，我发现它无论如何都不起作用，因为如果其他人写入其 etcd 数据存储，Kubernetes 总是会“中断”。（即使您写入了之前存在的完全相同的值 - 通过比较之前和之后的转储来验证）
5. 完成上述所有操作后，我决定最后一次将标志添加到提到的清单文件中。仍然遇到启动失败/错误，但最后，我决定想看看我的更改究竟是什么导致 Kubernetes 拒绝它们。所以我尝试注释掉我添加的行；错误仍然存​​在。当时我想这可能是基于校验和的拒绝。但后来我想，也许 Kubernetes 使用的 YAML 解析器已经过时了，并且对它能够识别的注释很挑剔。因此，我尝试将评论移动到不同的位置，当仅通过将评论移动到根级别来接受清单时，我感到很困惑。我将它移回不同的位置，它工作或不工作，直到我想尝试使该行“半缩进”，因为它位于工作和非工作版本的“中间”。就在那时我注意到该行有一个制表符作为其缩进。然后它就撞到了我; 其他行也使用制表符吗？我查了一下，不，他们使用了空格。就在那时我意识到我已经把最后几个小时浪费在了一些我可以通过简单的缩进更改来修复的事情上。

对于某些人来说，这个故事的寓意是 YAML 是一种糟糕的配置格式，因为它很容易犯这样的小错误。但实际上我更多地将责任归咎于 Kubernetes 用于 YAML 文件的解析器；YAML 解析器会遇到缩进不匹配并给出如此通用的消息，这是不可接受的unexpected EOF。我不知道那个 YAML 解析器的身份是什么，但我已经厌倦了这个主题，所以现在我什至不打算研究它。如果你们中有人发现了它，请为其制作一份问题报告——也许包括这个故事作为现实世界中模棱两可的错误消息可能导致的痛苦的例子。