我的问题（对 MS 和其他任何人）是：为什么会出现这个问题，用户/客户自己而不是 Microsoft 支持可以实施哪些解决方法？
关于这个问题显然还有“一些”其他问题：
以及发布到 AKS 存储库的多个 GitHub 问题：
- https://github.com/Azure/AKS/issues/112
- https://github.com/Azure/AKS/issues/124
- https://github.com/Azure/AKS/issues/164
- https://github.com/Azure/AKS/issues/177
- https://github.com/Azure/AKS/issues/324
加上一些推特线程：
TL;博士
当前的最佳解决方案是发布帮助票证 - 并等待 - 或重新创建 AKS 群集（可能不止一次，交叉手指，见下文......）但应该有更好的东西。至少请允许 AKS 预览客户，无论支持层级如何，都可以针对此特定问题升级他们的支持请求严重性。
您还可以尝试扩展您的集群（假设这不会破坏您的应用程序）。
GitHub呢？
上述许多 GitHub 问题已在解决后关闭，但问题仍然存在。以前有关于该问题的公告文档，但即使问题继续出现，目前也没有此类状态更新可用：
我发布这篇文章是因为我有一些我在其他地方没有看到的新花絮，我想知道是否有人对解决这个问题的其他潜在选择有想法。
受影响的虚拟机/节点资源使用
我在其他地方没有提到的第一部分是受上述 Kubectl '无法连接到服务器：net/http：TLS 握手超时'问题影响的节点/虚拟机/实例上的资源使用情况。
生产节点利用率
我受影响的集群上的节点如下所示：
利用率和网络 io 的下降与磁盘利用率的增加和我们开始遇到问题的时间段密切相关。
在此图表之前，过去 30 天的整体节点/VM 利用率通常持平，与生产站点流量/更新推送等有关的一些颠簸。
问题缓解后的指标（添加事后分析）
至此，以下是同一节点在向上扩展然后向下扩展后的指标（这恰好缓解了我们的问题，但并不总是有效 - 请参阅底部的答案）：
注意到 CPU 和网络中的“下降”了吗？ 这就是 Net/http: TLS 问题对我们产生影响的地方——以及当 AKS 服务器无法从 Kubectl 访问时。似乎除了没有响应我们的请求之外，它还没有与 VM / 节点交谈。
一旦我们回来（将 # 个节点向上缩放一个，然后向下缩放——查看解决方法的答案），指标（CPU 等）就恢复正常——我们可以从 Kubectl 连接。这意味着我们可能会针对这种行为创建一个警报（我在 Azure DevOps 方面询问这个问题时遇到了问题：https ://github.com/Azure/AKS/issues/416 ）
节点大小可能会影响问题频率
Zimmergren 在 GitHub 上表示，与运行裸骨小节点相比，他在使用较大实例时遇到的问题更少。这对我来说很有意义，并且可能表明 AKS 服务器分配工作负载的方式（请参阅下一节）可能基于实例的大小。
“节点的大小（例如 D2、A4 等）:) 我体验过，在运行 A4 及更高版本时，我的集群比运行 A2 时更健康。（我有十几个类似的不幸的是，有大小组合和集群故障的经验）。” （https://github.com/Azure/AKS/issues/268#issuecomment-375715435）
其他集群大小影响参考：
负责更小集群的 AKS 服务器可能会更频繁地受到攻击？
一个 Az 区域中存在多个 AKS 管理“服务器”
我在其他地方没有提到的下一件事是，您可以在同一个区域中并排运行多个集群，其中一个集群（在本例中为我们的生产）受到“net/http：TLS 握手超时”的影响另一个工作正常，可以通过 Kubectl 正常连接（对我们来说，这是我们相同的暂存环境）。
用户（上面的 Zimmergren 等）似乎认为节点大小会影响此问题影响您的可能性，这一事实似乎也表明节点大小可能与将次区域职责分配给次区域 AKS 的方式有关管理服务器。
这可能意味着重新创建具有不同集群大小的集群更有可能将您放置在不同的管理服务器上——减轻问题并降低需要多次重新创建的可能性。
暂存集群利用率
我们的两个 AKS 集群都位于美国东部。作为上述“生产”集群指标的参考，我们的“暂存”集群（也包括美国东部）资源利用率没有 CPU / 网络 IO 的大幅下降——并且同期磁盘等也没有增加：
相同的环境受到不同的影响
我们的两个集群都运行相同的入口、服务、Pod、容器，因此用户所做的任何事情也不太可能导致此问题出现。
重建有时会成功
上述多个 AKS 管理服务器子区域职责的存在与其他用户在 github ( https://github.com/Azure/AKS/issues/112 )上描述的行为是有道理的，其中一些用户能够重新创建一个集群（然后可以联系），而其他人重新创建并仍然有问题。
紧急情况可能 = 多次再创造
在紧急情况下（即您的生产站点......像我们的......需要管理），您可能只是重新创建，直到您获得一个恰好落在不同 AKS 管理服务器实例上的工作集群（一个不是受影响）但请注意，这可能不会在您第一次尝试时发生 - AKS 群集重新创建并不是即时的。
那就是说...
受影响节点上的资源继续发挥作用
我们受影响的虚拟机上的所有容器/入口/资源似乎都运行良好，并且我没有任何警报响起以进行正常运行时间/资源监控（除了上面图表中列出的利用率异常）
我想知道为什么会出现这个问题，以及用户自己可以解决哪些问题，而不是 Microsoft 支持（目前有票）。如果您有想法，请告诉我。
原因的潜在提示
- https://github.com/Azure/AKS/issues/164#issuecomment-363613110
- https://github.com/Azure/AKS/issues/164#issuecomment-365389154
为什么没有 GKE？
我了解 Azure AKS 处于预览阶段，并且很多人因为这个问题而迁移到 GKE ()。也就是说，到目前为止，我的 Azure 体验一直是积极的，如果可能的话，我更愿意提供一个解决方案。
而且... GKE 偶尔也会遇到类似的情况：
我很想看看在 GKE 上扩展节点是否也解决了那里的问题。
