My question (to MS and anyone else) is: Why is this issue occurring and what work around can be implemented by the users / customers themselves as opposed to by Microsoft Support?
关于这个问题，显然还有“几个”其他问题:
以及发布到 AKS 存储库的多个 GitHub 问题:
加上一些推特主题:
TL; 博士
当前的最佳解决方案是发布帮助单 — 并等待 — 或重新创建您的 AKS 集群(可能不止一次，交叉手指，见下文...)但应该有更好的方法。 至少请授予让 AKS 预览版客户(无论支持层级如何)针对此特定问题升级其支持请求严重性的能力。
您还可以尝试扩展您的集群(假设这不会破坏您的应用程序)。
GitHub 呢？
上述 GitHub 上的许多问题都已解决，但问题仍然存在。以前有一个关于该问题的公告文档，但即使问题继续出现，目前也没有此类状态更新可用:
我发布这个是因为我有一些我在其他地方没有看到的新花絮，我想知道是否有人对解决这个问题的其他潜在选择有想法。
受影响的虚拟机/节点资源使用情况
我在其他地方没有看到的第一部分是受上述 Kubectl '无法连接到服务器:net/http:TLS 握手超时'问题影响的节点/虚拟机/实例上的资源使用情况。
生产节点利用率
我受影响集群上的节点如下所示:
利用率和网络 io 的下降与磁盘利用率的增加和我们开始遇到问题的时间段密切相关。
在此图表之前的过去 30 天，整体节点/VM 利用率通常持平，与生产站点流量/更新推送等相关的一些颠簸。
问题缓解后的指标 (添加验尸报告)
对于上述观点，以下是相同节点在放大然后缩小后的指标(这恰好缓解了我们的问题，但并不总是有效 - 请参阅底部的答案):
注意到 CPU 和网络中的“Dip”了吗？ 这就是 Net/http: TLS 问题对我们产生影响的地方——当 Kubectl 无法访问 AKS 服务器时。除了不响应我们的请求之外，它似乎没有与 VM/Node 交谈。
一旦我们回来(将 # 个节点按比例放大一个，然后再缩小 - 请参阅解决方法的答案)指标(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)
其他集群大小影响引用:
An AKS server responsible for more smaller Clusters may possibly get hit more often?
一个 Az 区域中存在多个 AKS 管理“服务器”
我在其他地方没有提到的下一件事是，您可以在同一个区域中并排运行多个集群，其中一个集群(在这种情况下为我们生产)受到“net/http: TLS 握手超时”的影响另一个工作正常，可以通过 Kubectl 正常连接(对我们来说，这是我们相同的登台环境)。
用户(上述 Zimmergren 等)似乎认为节点大小会影响此问题影响您的可能性，这一事实似乎也表明节点大小可能与将子区域职责分配给子区域 AKS 的方式有关管理服务器。
That could mean that re-creating your cluster with a different Cluster size would be more likely to place you on a different management server — alleviating the issue and reducing the likelihood that multiple re-creations would be necessary.
暂存集群利用率
我们的两个 AKS 集群都位于美国东部。作为对上述“生产”集群指标的引用，我们的“暂存”集群(也是美国东部)资源利用率在 CPU/网络 IO 方面没有大幅下降——并且在同一时期没有磁盘等增加:
相同的环境受到不同的影响
我们的两个集群都运行相同的入口、服务、pod、容器，因此用户所做的任何事情也不太可能导致此问题突然出现。
重新创造只是有时成功
上述多个 AKS 管理服务器子区域职责的存在与其他用户在 github ( https://github.com/Azure/AKS/issues/112 ) 上描述的行为有意义，其中一些用户能够重新创建集群(然后可以联系)而其他用户重新创建并仍然存在问题。
紧急情况可能 = 多次重新创作
在紧急情况下(即您的生产现场...像我们一样...需要管理)您可以 可能 只需重新创建，直到您获得一个恰好落在不同 AKS 管理服务器实例(未受影响的实例)上的工作集群，但请注意，这可能不会在您第一次尝试时发生 — AKS 集群重新创建并不是即时的.
那说...
受影响节点上的资源继续运行
我们受影响的 VM 上的所有容器/入口/资源似乎都运行良好，我没有任何关于正常运行时间/资源监控的警报(除了上面图表中列出的利用率异常)
I want to know why this issue is occurring and what work around can be implemented by the users themselves as opposed to by Microsoft Support (currently have a ticket in). If you have an idea let me know.
原因的潜在提示
为什么没有 GKE？
我知道 Azure AKS 处于预览阶段，并且很多人因为这个问题已经迁移到 GKE ()。也就是说，到目前为止，我的 Azure 体验一直是积极的，如果可能的话，我更愿意提供解决方案。
而且…… GKE 偶尔会遇到类似的情况:
我很想知道在 GKE 上扩展节点是否也解决了那里的问题。
最佳答案
解决方法 1(可能不适用于所有人)
一个有趣的测试解决方案(对我有用)是增加集群中的节点数量，然后再减少......
或者，您可以(也许)从命令行执行此操作:
az aks scale --name <name-of-cluster> --node-count <new-number-of-nodes> --resource-group <name-of-cluster-resource-group>由于这是一个棘手的问题，而且我使用了 Web 界面，因此我不确定上述内容是否相同或是否有效。
我花了大约 2 分钟的总时间——对于我的情况，这比重新创建/配置集群要好得多(可能多次......)
话虽如此....
Zimmergren 提出了一些好处，即缩放不是真正的解决方案:
“有时它会起作用，在扩展后集群自我修复一段时间。有时它会失败并出现相同的错误。我不考虑扩展此问题的解决方案，因为这会导致其他挑战，具体取决于事物的设置方式。我不会相信 GA 工作负载的例程，这是肯定的。在当前的预览中，它有点狂野西部(和预期)，我很高兴炸毁集群并在连续失败时创建一个新集群。 ” ( https://github.com/Azure/AKS/issues/268#issuecomment-395299308 )
Azure 支持反馈
由于我在遇到上述扩展解决方案时打开了支持票证，因此我能够获得有关上述可能有效的反馈(或更确切地说是猜测)，以下是转述回复:
"I know that scaling the cluster can sometimes help if you get into a state where the number of nodes is mismatched between “az aks show” and “kubectl get nodes”. This may be similar."
解决方法引用:
解决方法不起作用？
如果这对您不起作用，请在下面发表评论，因为我将尝试更新问题出现的频率、是否自行解决以及此解决方案是否适用于 Azure AKS 用户(看起来就像它对每个人都不起作用)。
向上/向下扩展的用户不适用于:
向上/向下扩展 DID 适用于:
电子邮件 Azure AKS 特定支持
如果在所有诊断后您仍然遇到此问题，请不要犹豫发送电子邮件至 aks-help@service.microsoft.com
关于azure - '无法连接网络/http : TLS handshake timeout' — Why can't Kubectl connect to Azure Kubernetes server? (AKS)，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/50726534/