由于不正确的容器命令，Kubernetes pod 失败答案

【问题标题】：Kubernetes pod failing because of incorrect container command由于不正确的容器命令，Kubernetes pod 失败
【发布时间】：2021-07-14 19:34:23
【问题描述】：

我正在创建一个出口操作员。我有一个通过命令make deploy IMG=my_azure_repo/egress-operator:v0.1 从makefile 创建的吊舱egress-operator-controller-manager。 pod 失败，它在 pod 描述中显示错误为：

  State:          Waiting
  Reason:       RunContainerError
  Last State:     Terminated
  Reason:       StartError
  Message:      failed to create containerd task: OCI runtime create failed: container_linux.go:380: starting container process caused: exec: "/manager": stat /manager: no such file or directory: unknown
  Failed     44s (x3 over 59s)  kubelet  Error: failed to create containerd task: 
  OCI runtime create failed: container_linux.go:380: starting container process caused: 
  exec: "/manager": stat /manager: no such file or directory: unknown

我怀疑在manager.yaml 下command: 下/manager 被执行了。
谁能告诉我这个manager.yaml 出了什么问题以及/manager 在command: 下是否有效部署.yaml

调试更新
现在我没有运行 Dockerfile，而是在本地构建并运行 image_azure_repo/egress-operator:v0.1（在同一个 ubuntu 18 VM 上），当我尝试使用 docker exec -it <container_id> /bin/bash 登录时，出现错误：

OCI runtime exec failed: exec failed: container_linux.go:380: 
starting container process caused: exec: "/bin/bash": stat /bin/bash: 
no such file or directory: unknown

这是我在 pod 描述中看到的类似错误。而不是 /bin/bash ，我还尝试了 docker exec 和 /bin/sh 并且只有 sh ；它给出了同样的错误

【问题讨论】：

听起来你没有使用正确的图像——看看他们的 Dockerfile，应该有 /manager 的东西。要么它不是正确的版本，要么不是控制器。您的标签中提到一些v0.1 是否正常，而该 Makefile 中的默认值会使用 manager-$gitref 之类的东西？
@SYN-：我跟着 github.com/monzo/… 进行部署 IMG=my_azure_repo/egress-operator:v0.1 。
如果您检查该图像的本地副本，您确定其中有 /manager 吗？
我尝试在本地单独运行 Dockerfile，构建成功，但“docker run -d imageName”没有保持容器正常运行。当 docker run in 执行时，容器正在退出。所以我无法登录到容器并确认 /manager 是否存在
当然，/manager 复制到的基本映像没有外壳。您可以将最后一个 FROM 切换为 alpine:latest 之类的东西，以防您想检查。虽然如果您处于运行docker exec 的阶段，那么这意味着容器运行，不是吗？毕竟它设法找到了它的入口点？

标签： kubernetes makefile kubernetes-pod kubernetes-deployment kubernetes-operator

【解决方案1】：

这应该与 libc 不匹配。

Golang 默认使用 glibc，而 alpine 使用 musl。

你可以试试这些来解决它：

使用 glibc 使用基础映像
在您的 alpine 映像中安装 glibc

【讨论】：

我可以用 glibc 代替 alpine 使用相同的 distroless 映像吗？并在 dockerfile 中安装 glibc ？
当然可以。但是我不确定distroless有哪个libc，可能默认是glibc你不用安装
@PapEr-：我在 /manager 未发现问题的地方使用 distroless。根据 distroless doc github.com/GoogleContainerTools/distroless/blob/main/base/… ，他们正在使用 glibc。引用链接：“大多数其他应用程序（以及需要 libc/cgo 的 Go 应用程序）应该以 gcr.io/distroless/base 开头，其中包含 gcr.io/distroless/static 中的所有包，以及 - glibc”跨度>
@solveit 那么你能确定你使用的是哪个 distroless 映像吗？从我发现的有问题的仓库中，它是无发行版/静态的，没有 libc 就裸露了
@PapEr-：我按照github.com/GoogleContainerTools/distroless/blob/main/base/… 用 distroless/base 替换了 distroless/static，它现在可以工作了。非常感谢。你是天才:-)

【解决方案2】：

在 Dockerfile 中，您提到的入口点是 ENTRYPOINT ["/manager"] 但不应该是 ENTRYPOINT ["./manager"]
关于 "starting container process caused: exec: "/bin/bash": stat /bin/bash: " ，似乎基本映像没有/bin/bash 它可能只有/bin/sh

【讨论】：