转:crictl ps提示[unix:///var/run/dockershim.sock unix:///run/containerd/containerd.sock unix:///run/crio/crio.sock unix:///var/run/cri-dockerd.sock]. As the default settings are now deprecated, you should set the endpoint instead.

 在虚拟机上完成上面master安装后，重启系统，关闭了firewall 后，出现错误

• 错误

  • # crictl ps|grep kube-apiserver WARN[0000] runtime connect using default endpoints: [unix:///var/run/dockershim.sock unix:///run/containerd/containerd.sock unix:///run/crio/crio.sock unix:///var/run/cri-dockerd.sock]. As the default settings are now deprecated, you should set the endpoint instead. WARN[0000] image connect using default endpoints: [unix:///var/run/dockershim.sock unix:///run/containerd/containerd.sock unix:///run/crio/crio.sock unix:///var/run/cri-dockerd.sock]. As the default settings are now deprecated, you should set the endpoint instead. E0410 14:43:54.969196 2572486 remote_runtime.go:390] "ListContainers with filter from runtime service failed" err="rpc error: code = Unavailable desc = connection error: desc = \"transport: Error while dialing dial unix /var/run/dockershim.sock: connect: no such file or directory\"" filter="&ContainerFilter{Id:,State:&ContainerStateValue{State:CONTAINER_RUNNING,},PodSandboxId:,LabelSelector:map[string]string{},}" FATA[0000] listing containers: rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dialing dial unix /var/run/dockershim.sock: connect: no such file or directory"

• 解决

  • # cat > /etc/crictl.yaml << EOF

    > runtime-endpoint: unix:///run/containerd/containerd.sock

    > image-endpoint: unix:///run/containerd/containerd.sock

    > timeout: 10

    > debug: false

    > EOF

    [root@119-132 ~]# crictl ps

    CONTAINER           IMAGE               CREATED             STATE               NAME                ATTEMPT             POD ID              POD

    [root@119-132 ~]# systemctl restart kubelet

    [root@119-132 ~]# crictl ps |grep apiserver

    0d0963b6ea4b5       cdcab12b2dd16       21 seconds ago      Running             kube-apiserver            4                   4b240b09343c1       kube-apiserver-119-132

    [root@119-132 ~]# kubectl get nodes

    NAME      STATUS     ROLES           AGE   VERSION

    119-132   Ready      control-plane   36d   v1.28.2

    119-134   NotReady   <none>          35d   v1.28.2

    [root@119-132 ~]#

    应该是可以了

• 分析

  • 简单来说：第一次正常，是因为 crictl 侥幸“蒙对了”；重启后不正常，是因为环境变了，它“猜错了”。

    以下是详细的技术原因拆解：

    1. 第一次为什么正常？（侥幸命中默认列表）

    你第一次执行 crictl ps 时，它还没有配置文件，因此会使用内置的默认端点列表按顺序尝试连接：

    /var/run/dockershim.sock

    /run/containerd/containerd.sock <-- 你的在这里

    /run/crio/crio.sock

    /var/run/cri-dockerd.sock

    关键点： 当时你的环境里，第一个路径（dockershim.sock）不存在，但 crictl 报错后并没有立即退出，而是迅速尝试了第二个路径（containerd.sock），发现能连上，于是正常工作了。这让你产生了“没问题”的错觉。

    2. 重启后为什么不行了？（默认行为变了）

    重启电脑后，情况发生了微妙但关键的变化：

    运行时环境重置：某些系统服务或套接字文件的初始化顺序可能改变。

    crictl 的默认逻辑更严格了：在较新版本或某些系统配置下，crictl 在尝试第一个路径并遇到“致命”错误（如权限拒绝或文件不存在） 时，可能不会优雅地继续尝试下一个，而是直接抛出错误并退出。

    超时或阻塞：第一次尝试连接一个不存在的 dockershim.sock 可能会遇到更长的超时或更严重的错误，导致整个命令失败，根本没机会试到第二个路径。

    结果就是： 它卡在了第一个错误的路径上，根本没去尝试第二个正确的路径，所以你看不到容器。

    3. 配置 /etc/crictl.yaml 的本质作用

    你创建的配置文件，本质上是跳过了那个“猜”的过程，直接告诉 crictl：

    “别费劲试第一个了，直接去 /run/containerd/containerd.sock 找。”