☰

在 Raspberry Pi 上全新安装 Kubernetes 不起作用

tag-icon • tag-icon kubernetes etcd containerd
在 Raspberry Pi 上全新安装 Kubernetes 不起作用

我正在尝试在四个 Raspberry Pi 集群上全新安装 Kubernetes 1.23.x，每个都运行 x64 版本的 Raspberry Pi OS，但是当我尝试kubeadm init在主节点上运行（甚至在尝试让其他节点加入之前）时，我遇到了一个重大障碍。即：在调用kubeadm init主节点后仅五分钟，集群就停止工作。事实上，它从一开始就没有真正工作过。起初服务器响应说节点未就绪，但 5 分钟后它完全停止响应。

以下是我所做的和我所看到的：我安装了 containerd 和 kubeadm。然后我在主节点上运行以下命令来尝试启动 Kubernetes：

sudo kubeadm init --pod-network-cidr=10.244.0.0/16 \
    --token-ttl=0 --apiserver-advertise-address=192.168.1.194

运行该命令后，随后将 /etc/kubernetes/admin.conf 文件复制到 ~/.kube/config，我可以运行以下命令：

$ kubectl get nodes

NAME           STATUS     ROLES                  AGE     VERSION
k8s-master-1   NotReady   control-plane,master   3m36s   v1.23.4

并且它将继续显示 NotReady 状态约 5 分钟，此后相同的命令会产生非常不同的结果：

$ kubectl get nodes

The connection to the server 192.168.1.194:6443 was refused - did you specify the right host or port?

我不确定为什么会发生这种情况，但它非常一致。我试了几次，kubeadm reset然后又试kubeadm init了一次，连接超时总是发生在 5 分钟的时候。所以上次我尝试这样做时，我决定跟踪下的所有日志文件/var/log/containers/。5 分钟后，它会反复记录到 127.0.0.1:2379 的连接错误的一些变化。例如：

2022-03-09T19:30:29.307156643-06:00 stderr F W0310 01:30:29.306871 1 clientconn.go:1331] [core] grpc: addrConn.createTransport 无法连接到 {127.0.0.1:2379 127.0.0.1 0 }。错误：连接错误：desc =“transport：拨号时出错 dial tcp 127.0.0.1:2379：connect：连接被拒绝”。正在重新连接...

通过谷歌搜索，发现 etcd 似乎正在该端口上运行，但在第 5 分钟时，一堆服务（包括 etcd）开始关闭。我上传了从kubeadm init运行时间到可怕的 5 分钟之前的完整日志，作为要点。

我已经检查过所有端口是否也都打开了。（它们确实打开了。）在前五分钟内，我可以通过 telnet 连接到本地端口 2379。为什么 Kubernetes 无法在我的 Pi 上启动？我遗漏了什么？

更新：根据要求，我可以提供更多详细信息。我看到一篇文章建议将值设置--apiserver-advertise-address为0.0.0.0而不是直接 IP，所以我尝试了，但似乎没有什么区别。我尝试运行，systemctl status kubelet结果显示 kubelet 服务在最初的 5 分钟内处于“活动”状态。

我还运行了kubectl describe node k8s-master-1，它按以下顺序显示了四个事件：

  1. Kubelet 内存充足
  2. Kubelet 没有磁盘压力
  3. Kubelet 具有充足的 PID
  4. Kubelet 未就绪

最后一个事件伴随着以下消息：“容器运行时网络未准备好：NetworkReady=false 原因：NetworkPluginNotReady 消息：网络插件返回错误：cni 插件未初始化。”这让我开始思考。在安装 Flannel（又名 CNI 插件）之前，我一直在等待节点处于就绪状态，但这次我决定在最初的 5 分钟内尝试安装 Flannel，使用以下命令：

kubectl apply -f https://raw.githubusercontent.com/flannel-io/flannel/master/Documentation/kube-flannel.yml

令我大吃一惊的是，它成功了！嗯，有点成功了。主节点最终开始报告“就绪”状态。我注意到我的所有 pod 都出现了，但 coredns pod 除外。然而，过了一会儿，kube-proxy pod（在 kube-system 命名空间中）死机并卡在 CrashLoopBackoff 中，然后 kube-controller-manager 和 kube-scheduler pod 也同样进入了 CrashLoopBackoff。然后，这一次，大约 15 分钟后，整个集群再次像以前一样死机（这意味着我收到了相同的“与服务器的连接被拒绝”消息）。所以我觉得我离成功更近了一点，但距离成功还有很长的路要走。

第二次更新：有几件事：当我安装 flannel CNI 插件时，coredns 似乎未包含在内或不起作用。但是当我安装 weave works CNI 时，它至少会尝试启动 coredns，尽管不幸的是，这些 pod 卡在 ContainerCreating 中并且从未真正激活。因此，根据要求，我提供了一些额外的日志。它们足够长，值得单独上传，所以这里有一个链接到要点包含四个日志：

  1. 跑步kubectl -n kube-system logs pod/coredns-...
  2. 跑步kubectl -n kube-system logs pod/kube-controller-manager-k8s-master-1
  3. 跑步kubectl -n kube-system logs pod/kube-proxy-...
  4. 跑步kubectl describe node k8s-master-1

请注意，在一切终止之前，kube-controller-manager-... pod 会启动，但很快就会陷入 CrashLoopBackoff。而 coredns pod 则从未成功启动。

相关内容