oot@localhost ~]# # 查看 API Server 容器状态（使用 containerd） crictl ps | grep kube-apiserver # 如果没有输出，检查 kubelet 日志 journalctl -xeu kubelet --no-pager | grep -i "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. E0425 16:09:12.004584 77829 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="&Containe

<think>好的，我现在需要帮助用户解决Kubernetes API Server容器未正常运行的问题，涉及使用crictl查看容器状态、分析kubelet日志以及处理runtime默认endpoints的报错。让我先理清思路，确保每个步骤都覆盖到。 首先，用户的问题集中在API Server容器状态异常，所以应该从最基本的容器状态检查开始。这时候想到使用crictl命令，因为引用[2]提到crictl是专门为k8s设计的工具，可以管理Pod、容器和镜像。用户可能已经知道crictl，但需要具体步骤。比如，先列出所有容器，找到API Server的容器ID，再查看详细状态和日志。这里要注意权限问题，可能需要sudo，尤其是如果用户遇到权限错误的话。 接下来是kubelet日志分析。kubelet负责管理节点上的容器，如果API Server有问题，kubelet日志可能会有线索。引用[4]提到查看日志时的超时问题，可能涉及网络或配置错误。用户需要知道如何定位kubelet日志的位置，通常是journalctl查看，或者直接去/var/log目录找。日志中的关键错误比如连接失败、证书问题、资源不足都需要逐一检查。 然后是runtime连接错误的问题。用户提到默认endpoints报错，这在引用[2]的示例中出现过，使用crictl时警告默认endpoints被弃用，并出现连接超时。这可能是因为用户的环境使用了不同的容器运行时，比如containerd或CRI-O，而crictl默认尝试dockershim导致失败。需要指导用户正确配置crictl的endpoint，比如设置–runtime-endpoint参数指向正确的socket文件，如unix:///run/containerd/containerd.sock。同时，引用[3]提到OCI和CRI的关系，用户可能需要确认当前运行时是否支持CRI接口，并确保其正常运行。 另外，可能要考虑版本兼容性问题，比如Kubernetes版本是否与容器运行时兼容。例如，Dockershim已经被弃用，用户可能在使用较新的Kubernetes版本，而仍配置了docker作为运行时，导致问题。这时候需要引导用户迁移到containerd或CRI-O，并更新crictl的配置。 最后，综合所有步骤，形成一个结构清晰的排查流程：先检查容器状态，再查日志，然后处理runtime连接问题，同时考虑其他可能因素如证书、网络、资源等。要确保用户按照步骤操作时能逐步排除问题，并理解每个步骤的目的。可能还需要提醒用户检查API Server的Pod定义是否正确，以及节点资源是否足够。 需要注意引用相关的内容来支持建议，比如引用[2]关于crictl的配置，引用[3]关于CRI和OCI的关系，帮助用户理解为什么需要调整endpoint。同时，确保回答中的命令和路径准确，避免用户执行时出错。如果有不确定的地方，比如不同发行版的日志路径可能不同，需要适当说明或建议通用方法。</think>### Kubernetes API Server 容器状态问题排查指南 #### 一、使用 crictl 检查容器状态 1. **查看容器运行状态** ```bash sudo crictl ps -a | grep "kube-apiserver" ``` 输出示例： ``` CONTAINER_ID IMAGE STATUS NAME xxxxxxxx k8s.gcr.io/pause Running kube-apiserver ``` - **STATUS 异常（如 `Exited`）**：需结合日志分析具体原因[^2] 2. **查看容器日志** ```bash sudo crictl logs <CONTAINER_ID> ``` 重点关注： - 证书错误（如 `x509: certificate has expired`） - 端口占用（如 `address already in use`） - 连接运行时失败（如 `failed to connect to runtime service`） --- #### 二、分析 kubelet 日志 1. **查看 kubelet 日志** ```bash journalctl -u kubelet --since "10 minutes ago" | grep "apiserver" ``` 或直接查看日志文件（路径因系统而异）： ```bash tail -f /var/log/kubelet.log ``` 2. **常见错误类型** - **PLEG 异常**： `PLEG is not healthy` 表示容器运行时响应延迟，需检查容器运行时状态[^2] - **CRI 连接失败**： `failed to get runtime version: rpc error` 需检查容器运行时服务是否正常 - **证书过期**： `x509: certificate signed by unknown authority` 需更新证书 --- #### 三、解决 runtime 默认 endpoints 报错 **典型报错**： ``` WARN[0000] image connect using default endpoints... ERRO[0002] connect endpoint 'unix:///var/run/dockershim.sock'... deadline exceeded ``` **解决方案**： 1. **确认当前容器运行时** ```bash ps -ef | grep -E "(containerd|dockerd|crio)" ``` 2. **配置 crictl 专用 endpoint** 创建配置文件 `/etc/crictl.yaml`： ```yaml runtime-endpoint: "unix:///run/containerd/containerd.sock" # 根据实际运行时修改 timeout: 10 debug: false ``` 验证配置： ```bash crictl --runtime-endpoint=unix:///run/containerd/containerd.sock ps ``` 3. **Dockershim 替代方案** 如果仍依赖 Docker，需明确 Kubernetes v1.24+ 已移除 Dockershim，需使用 cri-dockerd 适配器[^3] --- #### 四、其他关键检查项 1. **检查 API Server 静态 Pod 配置** 验证 `/etc/kubernetes/manifests/kube-apiserver.yaml` 是否包含错误配置（如错误挂载路径） 2. **检查节点资源** ```bash free -h # 内存 df -h # 磁盘 top # CPU ``` 3. **验证网络连通性** ```bash curl -k https://localhost:6443/healthz # 检查 API Server 健康端口 ``` ---