kubectl 或其他第三方工具连接到 API 服务器时 TCP 超时

项目
11/19/2024

本文介绍如何排查 kubectl 或其他第三方工具用于连接到 Microsoft Azure Kubernetes 服务（AKS）中的 API 服务器时发生的 TCP 超时问题。为了确保其服务级别目标（SLO）和服务级别协议（SLA），AKS 使用基于核心数垂直和水平缩放的高可用性（HA）控制平面。

现象

遇到重复的连接超时。

原因 1：负责节点到控制平面通信的 Pod 未运行

如果只有一些 API 命令一致超时，则以下 Pod 可能未处于运行状态：

konnectivity-agent
tunnelfront
aks-link

注意

在较新的 AKS 版本中， tunnelfront 并 aks-link 替换为 konnectivity-agent，因此只会看到 konnectivity-agent。

这些 Pod 负责节点与控制平面之间的通信。

解决方案：减少节点主机的利用率或压力

确保托管这些 Pod 的节点不会过度利用或承受压力。请考虑将节点移动到其自己的系统节点池。

若要检查 Pod 托管在哪个节点上 konnectivity-agent 以及节点的使用情况，请运行以下命令：

# Check which node the konnectivity-agent pod is hosted on
$ kubectl get pod -n kube-system -o wide
    
# Check the usage of the node hosting the pod
$ kubectl top node

原因 2：在某些必需的端口、FQDN 和 IP 地址上阻止访问

如果所需的端口、完全限定的域名（FQDN）和 IP 地址未全部打开，则多个命令调用可能会失败。 API 服务器和 kubelet （通过 konnectivity-agent Pod）之间的 AKS 上的安全隧道通信需要其中一些项才能正常工作。

解决方案：打开所需的端口、FQDN 和 IP 地址

有关需要打开哪些端口、FQDN 和 IP 地址的详细信息，请参阅 Azure Kubernetes 服务（AKS）群集的出站网络和 FQDN 规则。

原因 3：应用程序层协议协商 TLS 扩展被阻止

若要在控制平面和节点之间建立连接，konnectivity-agentPod 需要传输层安全性（TLS）扩展才能进行应用程序层协议协商（ALPN）。你可能以前已阻止此扩展。

解决方案：启用 ALPN 扩展

在 Pod 上 konnectivity-agent 启用 ALPN 扩展以防止 TCP 超时。

原因 4：API 服务器的 IP 授权范围不包括当前 IP 地址

如果在 API 服务器上使用授权的 IP 地址范围，如果 IP 未包含在授权范围中，则会阻止 API 调用。

解决方案：修改授权的 IP 地址范围，使其涵盖 IP 地址

更改授权 IP 地址范围，以便涵盖 IP 地址。有关详细信息，请参阅更新群集的 API 服务器授权 IP 范围。

原因 5：客户端或应用程序会泄露对 API 服务器的调用

频繁的 GET 调用可能会累积和重载 API 服务器。

解决方案：使用监视而不是 GET 调用，但请确保应用程序不会泄漏这些调用

请确保使用监视而不是对 API 服务器的频繁 GET 调用。还必须确保第三方应用程序不会泄露任何监视连接或 GET 调用。例如，在 Istio 微服务体系结构中，混音器应用程序中的 bug 会在内部读取机密时创建新的 API 服务器监视连接。由于此行为定期发生，因此监视连接会快速累积。无论缩放模式如何，这些连接最终都会导致 API 服务器过载。

原因 6：Helm 部署中的版本过多

如果在 Helm（Kubernetes 包管理器）的部署中使用过多版本，则节点将开始消耗过多的内存。它还会导致大量 ConfigMap （配置数据）对象，这可能会导致 API 服务器上的不必要的使用高峰。

解决方案：限制每个版本的最大修订数

由于每个版本的最大修订数默认是无限的，因此需要运行一个命令，将此最大数目设置为合理的值。对于 Helm 2，命令是 helm init。对于 Helm 3，命令是 helm 升级。 --history-max <value>运行命令时设置参数。

版本	命令
Helm 2	`helm init --history-max <maximum-number-of-revisions-per-release> ...`
Helm 3	`helm upgrade ... --history-max <maximum-number-of-revisions-per-release> ...`

原因 7：节点之间的内部流量被阻止

AKS 群集中的节点之间可能存在内部流量阻塞。

解决方案：排查“dial tcp <Node_IP>：10250： i/o timeout”错误

请参阅排查 TCP 超时问题，例如“拨号 tcp <Node_IP>：10250： i/o 超时”。

原因 8：群集是专用的

群集是专用群集，但尝试从中访问 API 服务器的客户端位于公共或不同的网络中，无法连接到 AKS 使用的子网。

解决方案：使用可访问 AKS 子网的客户端

由于群集是专用的，并且其控制平面位于 AKS 子网中，因此它无法连接到 API 服务器，除非它位于可以连接到 AKS 子网的网络中。这是一种预期行为。

在这种情况下，请尝试从可以与 AKS 子网通信的网络中的客户端访问 API 服务器。此外，验证网络之间的网络安全组（NSG）或其他设备不会阻止数据包。

第三方信息免责声明

本文中提到的第三方产品由 Microsoft 以外的其他公司提供。 Microsoft 不对这些产品的性能或可靠性提供任何明示或暗示性担保。

联系我们寻求帮助

如果你有任何疑问或需要帮助，请创建支持请求或联系 Azure 社区支持。你还可以将产品反馈提交到 Azure 反馈社区。

通过