【发布时间】：2018-11-16 12:02:11
【问题描述】：
我的问题（对 MS 和其他任何人）是：为什么会出现这个问题以及用户/客户自己而不是 Microsoft 支持可以实施哪些解决方法？
关于这个问题显然还有“一些”其他问题：
- Managed Azure Kubernetes connection error
- Can't contact our Azure-AKS kube - TLS handshake timeout
- Azure Kubernetes: TLS handshake timeout（这个有一些微软反馈）
多个 GitHub 问题发布到 AKS 存储库：
- 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;DR
当前的最佳解决方案是发布帮助票证 - 并等待 - 或重新创建 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 上扩展节点是否也解决了那里的问题。
【问题讨论】：
-
每次从 Azure VM 到 Azure Kubernetes 集群的 kubctl 执行都会发生在我身上。