☰

Kubernetes OCI 运行时执行失败 - 启动容器进程导致“exec:\”etcdctl\”：在 $PATH 中未找到可执行文件”：未知

tag-icon • tag-icon ubuntu docker kubernetes etcd
Kubernetes OCI 运行时执行失败 - 启动容器进程导致“exec:\”etcdctl\”：在 $PATH 中未找到可执行文件”：未知

背景

通过运行以下命令创建一个新的 Kubernetes 集群kubeadm init --config /home/kube/kubeadmn-config.yaml --upload-certs，然后加入第二个控制平面节点。

kubeadm join VIP:6443 --token <token> \
    --discovery-token-ca-cert-hash sha256:<hash> \
    --control-plane --certificate-key <key> \
    --v=5

问题

etcdctl 命令是否应该返回返回值？要么直接使用命令，要么使用下面显示的 docker exec 方法。我安装了这些软件包：kubeadm、kubectl、kubelet 和 docker。

Kubectl 版本：1.20.1 操作系统：Ubuntu 18.04

来自第一个节点的命令

命令

etcdctl cluster-health

回复

cluster may be unhealthy: failed to list members
Error:  client: etcd cluster is unavailable or misconfigured; error #0: dial tcp 127.0.0.1:4001: connect: connection refused
; error #1: EOF

error #0: dial tcp 127.0.0.1:4001: connect: connection refused
error #1: EOF

命令

docker container ls | grep k8s_POD_etcd

回复

k8s_POD_etcd-<nodename>_kube-system_<docker container id>

命令

docker exec -it k8s_POD_etcd-<nodename>_kube-system_<docker container id> etcdctl --endpoints=https://<node ip>:2379 --key=/etc/kubernetes/pki/etcd/peer.key --cert=/etc/kubernetes/pki/etcd/peer.crt --cacert=/etc/kubernetes/pki/etcd/ca.crt member list

回复

OCI runtime exec failed: exec failed: container_linux.go:349: starting container process caused "exec: \"etcdctl\": executable file not found in $PATH": unknown

编辑

升级到 v3.2 etcdctl API

命令

etcdctl endpoint status

回复

Failed to get the status of endpoint 127.0.0.1:2379 (context deadline exceeded)

答案1

OP 提到的错误是由于容器中不存在 etcdctl 可执行文件引起的。

为什么？因为他使用了错误的容器。请看以下命令：

docker container ls | grep k8s_POD_etcd
be510c179ced   k8s.gcr.io/pause:3.2   "/pause"  2 days ago  Up 2 days   k8s_POD_etcd-minikube_kube-system_2315889f8b2b54f1b9d43feafe941d01_0

注意容器是k8s.gcr.io/pause:3.2。它不是 etcd 容器。

但为什么？这个暂停容器是什么？我不会回答这个问题，因为有人已经在这里回答了：暂停容器是什么。

我将尝试回答一个更好的问题：实际的 etcd 容器在哪里？

让我们看一下相同命令的输出，但使用稍微修改过的 grep 命令；让我们使用 grep 来etcd：

docker container ls | grep etcd
c989e7d1d25b   0369cf4303ff           "etcd --advertise-cl…"   2 days ago       Up 2 days k8s_etcd_etcd-minikube_kube-system_2315889f8b2b54f1b9d43feafe941d01_0
be510c179ced   k8s.gcr.io/pause:3.2   "/pause"                 2 days ago       Up 2 days k8s_POD_etcd-minikube_kube-system_2315889f8b2b54f1b9d43feafe941d01_0

现在我们有两行输出，一行是之前找到的 pause 容器，第二行是我们的 etcd 容器，名字以 开头k8s_etcd_etcd。我们看看能不能在这个容器上运行 docker exec：

$ docker exec -it k8s_etcd_etcd-<nodename>_kube-system_<docker container id> etcdctl version
etcdctl version: 3.4.13
API version: 3.4

我们可以！

总而言之：看起来你从一开始就看错了容器。

答案2

这是客户端无法建立连接时context deadline exceeded返回的不明确错误。如果您想查看确切的错误消息，您应该设置（有关详细信息，请参阅grpcETCDCTL_API=2这里）。

中的证书/密钥对应/etc/kubernetes/pki/etcd/如下所示：

# ls -l /etc/kubernetes/pki/etcd/
total 32
-rw-r--r--    1 root     root          1017 Nov 12 15:32 ca.crt
-rw-------    1 root     root          1679 Nov 12 15:32 ca.key
-rw-r--r--    1 root     root          1094 Nov 12 15:32 healthcheck-client.crt
-rw-------    1 root     root          1675 Nov 12 15:32 healthcheck-client.key
-rw-r--r--    1 root     root          1180 Nov 12 15:32 peer.crt
-rw-------    1 root     root          1675 Nov 12 15:32 peer.key
-rw-r--r--    1 root     root          1180 Nov 12 15:32 server.crt
-rw-------    1 root     root          1679 Nov 12 15:32 server.key

# etcdctl --version
etcdctl version: 3.3.1
API version: 2

# ETCDCTL_API=3 etcdctl snapshot save snapshot.db \
  --cacert /etc/kubernetes/pki/etcd/ca.crt \
  --cert /etc/kubernetes/pki/etcd/server.crt \
  --key /etc/kubernetes/pki/etcd/server.key
Snapshot saved at snapshot.db

# ETCDCTL_API=3 etcdctl --write-out=table snapshot status snapshot.db
+----------+----------+------------+------------+
|   HASH   | REVISION | TOTAL KEYS | TOTAL SIZE |
+----------+----------+------------+------------+
| b9d500f7 |    72966 |       1194 |     4.9 MB |

确保你申请正确的证书/密钥对。 还，本指南可以帮助您。

请注意，etcd 需要几个与证书相关的配置选项，可以通过命令行标志或环境变量来实现。它的基本设置可以在这里找到这里。

答案3

如果你正在使用 Alpine，请尝试

docker exec -it <container-id> sh

这可能是由于排序错误而发生的，您可能需要运行 /bin/bash 或 /bin/sh，具体取决于容器中的 shell。

原因记录在 Git 的 ReleaseNotes 文件中，这里也有很好的解释 -Windows 版 Git 中的 Bash：怪异之处

更多解决方案：

相关内容