故障排除 kOps 集群 ¶

调试 kOps 集群的第一步是运行 kops validate cluster --name <clustername> --wait 10m。如果集群在此期间没有验证，则说明出现问题。

控制平面 ¶

如果上述命令抱怨 API 服务器不可用，则表示控制平面工作不正常。为了进一步诊断，您需要登录到控制平面节点之一。

运行 kops get instances (1.19+) 或查看 AWS 控制台以识别具有主角色的节点。然后 ssh 到列出的 IP 地址。

控制平面上的日志位于 /var/log。假设日志位于那里，除非另有说明。

Nodeup ¶

Nodeup 是负责节点初始配置的过程。这是一个一次性 systemd 服务，称为 kops-configuration.service。您可以通过运行 journalctl -u kops-configuration.service 查看此服务的日志。

如果成功，您应该能够看到以下日志条目

nodeup[X]: success
systemd[1]: kops-configuration.service: Succeeded.
systemd[1]: Finished Run kops bootstrap (nodeup).

请注意，如果节点在一段时间前启动，则此单元的日志可能为空。

如果 nodeup 退出时出现错误或一直循环执行无法继续的任务，则集群很可能配置错误。希望错误消息能提供足够的线索进行进一步调查。

无论如何，我们希望您能提交一个 GitHub 问题，因为我们努力避免集群在 nodeup 过程中出现问题。

API 服务器 ¶

如果 nodeup 成功，核心 kube 容器应该已经启动。在 kube-apiserver.log 中查找 API 服务器日志。

通常问题很明显，例如传递了不正确的 CLI 标志。

etcd 恢复后 API 服务器挂起 ¶

调整 etcd 集群大小或恢复备份后，kubernetes API 可能包含太多端点。您可以通过运行 kubectl get endpoints -n default kubernetes 来确认这一点。此命令应该列出与控制平面节点数量完全相同的 IP 地址。

有关此问题的更多详细信息，请查看备份和恢复文档。

etcd ¶

API 服务器使用两个 etcd 服务器，主服务器和事件服务器。

API 服务器无法正常工作的一个更常见的原因是 etcd 不可用。如果您看到到端口 4001 或 4002 的连接错误，则表示主服务器和/或事件服务器分别不可用。

etcd 集群由 etcd-manager 管理，最有可能的是 etcd-manager 出现了问题，而不是 etcd 本身。etcd 的日志通过 etcd-manager 传递，因此您可以在 etcd.log 和 etcd-events.log 中找到两个日志。由于 etcd-manager 和 etcd 都是基于仲裁的集群，因此这些文件中可能存在一些误导性的错误，这些错误可能表明 etcd 已损坏，而实际上是 etcd-manager 出现了问题。

DNS ¶

故障排除 Kubernetes DNS 可能需要一整本书。Kubernetes 文档中有一篇关于如何调试 DNS 的相当不错的文章。

值得一提的是，DNS 故障通常是 Pod 网络故障的症状。因此，您可能需要确保两个 Pod 可以使用 IP 地址相互通信，然后再开始调试 DNS。

CNI ¶

`/opt/cni/bin` 中缺少文件 ¶

空目录 ¶

如果 CNI bin 目录完全为空，则可能是 nodeup 工作不正常的症状。有关 nodeup 故障排除的更多信息，请参见上面的内容。在大多数情况下，nodeup 会将最常见的 CNI 插件写入该目录，因此它应该很少完全为空。

缺少 CNI 插件文件 ¶

如果目录存在，但缺少 CNI 插件和配置，则表示负责写入这些文件的进程工作不正常。在大多数情况下，这是一个在 kube-system 中运行的 DaemonSet。

在此，值得重复的是，控制平面将在没有 CNI 的情况下工作。大多数控制平面节点不使用 Pod 网络，而是使用主机的网络进行通信。如果您无法与 API 服务器通话，例如运行 kubectl get nodes，则问题不在于 CNI。

如果 API 正在工作，并且 CNI 是通过 DaemonSet 安装的，请检查 Pod 是否正在运行。如果预期存在 Pod，但不存在，则可能是安装 CNI 附加组件时出现了问题。kOps 会定期尝试安装附加组件，因此在控制平面节点上运行 journalctl -f 以发现任何错误。