相关疑难解决方法(0)
"无法连接Net/http:TLS握手超时" - 为什么Kubectl无法连接到Azure Kubernetes服务器？(AKS)
我的问题(对MS和其他任何人)是:为什么这个问题发生了,用户/客户自己可以实现哪些解决方案而不是Microsoft支持？
关于这个问题,显然有一些"其他"问题:
多个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问题已经解决,但问题仍然存在.以前有一个关于这个问题的公告文件,但是目前还没有这样的状态更新,即使问题仍然存在:
我发布这个,因为我有一些我没有在其他地方看到的新花絮,我想知道是否有人有想法解决问题的其他潜在选择.
受影响的VM /节点资源使用情况
我在其他地方没有提到的第一篇文章是节点/ vms /实例上的资源使用情况,这些资源使用受上述Kubectl"无法连接到服务器:net/http:TLS握手超时"问题的影响.
生产节点利用率
我受影响的集群上的节点如下所示:
利用率和网络的下降与磁盘利用率的增加和我们开始遇到问题的时间段密切相关.
在此图表之前的整个节点/ VM利用率在过去30天内基本持平,并且与生产站点流量/更新推送等相关的一些颠簸.
减轻问题后的度量标准(已添加事后检查)
对于上述观点,以下是在扩展然后退回之后相同节点的指标(这恰好缓解了我们的问题,但并不总是有效 - 请参见底部的答案):
请注意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)
其他群集大小影响参考:
负责更小型集群的AKS服务器可能会更频繁地受到攻击？
一个Az区域中多个AKS管理'服务器'的存在
我在其他地方没有提到的下一件事是你可以在同一个区域并排运行多个集群,其中一个集群(在这种情况下为我们生产)被'net/http:TLS握手超时'命中另一个工作正常,可以通过Kubectl正常连接(对我们来说这是我们相同的临时环境).
用户(上面的Zimmergren等)似乎认为节点大小影响此问题将影响您的可能性这一事实似乎也表明节点大小可能与子区域责任分配给子区域AKS的方式有关管理服务器.
这可能意味着重新创建具有不同群集大小的群集将更有可能将您置于不同的管理服务器上 …
推荐指数
解决办法
查看次数