＆＃39;无法连接Net / http：TLS握手超时＆＃39; - 为什么Kubectl无法连接到Azure Kubernetes服务器？ （AKS）

时间：2018-06-06 17:46:12

标签： azure azure-kubernetes

  

我的问题（对MS和其他任何人）是：为什么会出现这个问题，用户/客户自己可以实现哪些解决方案而不是Microsoft支持？

显然有一些＆＃39;关于这个问题的其他问题：

  1. Managed Azure Kubernetes connection error
  2. Can't contact our Azure-AKS kube - TLS handshake timeout
  3. Azure Kubernetes: TLS handshake timeout（这个有一些微软反馈）

    4. 在AKS回购中发布了多个GitHub问题：

    1. https://github.com/Azure/AKS/issues/112
    2. https://github.com/Azure/AKS/issues/124
    3. https://github.com/Azure/AKS/issues/164
    4. https://github.com/Azure/AKS/issues/177
    5. https://github.com/Azure/AKS/issues/324

      6. 加上一些推特线程：

      1. https://twitter.com/ternel/status/955871839305261057

        2. TL; DR

          

        Skip to workarounds in Answers below

        目前最好的解决方案是发布帮助票 - 等待 - 或者重新创建你的AKS集群（可能不止一次，交叉你的手指，见下文......）但应该有更好的东西。 至少请允许让AKS预览客户（无论支持级别如何）升级其针对此特定问题的支持请求严重性。

        您还可以尝试扩展群集（假设不会破坏您的应用）。

        GitHub怎么样？

        上述许多GitHub问题已经解决，但问题仍然存在。以前有一个关于这个问题的公告文件，但目前没有这样的状态更新，即使问题仍然存在：

        1. https://github.com/Azure/AKS/tree/master/annoucements

          2. 我发布这个，因为我有一些我在其他地方看不到的新花絮，我想知道是否有人有想法解决这个问题的其他潜在选择。

          受影响的VM /节点资源使用

          我在其他地方没有看到的第一篇文章是节点/虚拟机/实例上的资源使用受上述Kubectl的影响＆＃39;无法连接到服务器：net / http：TLS握手超时＆＃39;问题。

          生产节点利用率

          受影响群集上的节点如下所示：

          net/http: TLS handshake timeout

          利用率和网络的下降与磁盘利用率的增加和我们开始遇到问题的时间段密切相关。

          此图表在过去30天内整体节点/虚拟机利用率通常持平，并且与生产网站流量/更新推送等相关的一些障碍。

          问题缓解后的指标 （已添加事后检查）

          对于上述观点，以下是扩展后退回的相同节点的指标（这恰好缓解了我们的问题，但并不总是有效 - 请参见底部的答案）：

          enter image description here

          注意＆＃39; Dip＆＃39;在CPU和网络中？ Net / http：TLS问题影响我们的地方 - 以及从Kubectl无法访问AKS服务器的时间。似乎除了没有回应我们的请求之外，它还没有与VM / Node通信。

          一旦我们回来（将＃个节点向上扩展，然后退回 - 查看解决方法的答案），度量标准（CPU等）恢复正常 - 我们可以从Kubectl连接。这意味着我们可以创建一个关于此行为的警报（我在Azure DevOps方面询问此问题时遇到了问题：https://github.com/Azure/AKS/issues/416）

          节点大小可能会影响发布频率

          Zimmergren在GitHub上表示他对大型实例的问题少于运行裸骨小节点的问题。这对我来说很有意义，并且可以表明AKS服务器分配工作负载的方式（参见下一节）可能基于实例的大小。

          ＆＃34;节点的大小（例如D2，A4等）:) 我经历过，当运行A4及以上时，我的群集比运行A2时更健康。 （不幸的是，我已经在尺寸组合和集群故障方面获得了十几个类似的经验）。＆＃34; （https://github.com/Azure/AKS/issues/268#issuecomment-375715435）

          其他群集大小影响参考：

          1. giorgited（https://github.com/Azure/AKS/issues/268#issuecomment-376390692）
            2.   

            负责更小型群集的AKS服务器可能会更频繁地受到攻击？

            存在多个AKS管理服务器＆＃39;在一个Az地区

            我在其他地方提到的下一件事是你可以在同一个区域并排运行多个集群，其中一个集群（在这种情况下为我们生产）受到了＆＃39; net / http：TLS握手超时＆＃39;另一个工作正常，可以通过Kubectl正常连接（对我们来说这是我们相同的暂存环境）。

            用户（上面的Zimmergren等）似乎认为节点大小影响此问题对您的影响的可能性似乎也表明节点大小可能与子区域职责分配给子的方式有关区域AKS管理服务器。

              

            这可能意味着重新创建具有不同群集大小的群集将更有可能将您置于不同的管理服务器上 - 缓解问题并降低需要多次重新创建的可能性。

            暂存群集利用率

            我们的两个AKS集群都在美国东部。作为上述＆＃39;生产＆＃39;的参考。我们的群集指标＆＃39;暂存＆＃39;集群（也称为美国东部）资源利用率没有大幅下降CPU /网络IO - 并且在同一时期没有磁盘等的增加：

            net/http: TLS handshake timeout staging instance is reachable via kubectl.

            相同的环境受到不同的影响

            我们的两个群集都在运行相同的入口，服务，容器和容器，因此用户所做的任何事情都不太可能导致此问题突然出现。

            重新创建只是有时成功

            上述多个AKS管理服务器子区域职责的存在对于其他用户在github（https://github.com/Azure/AKS/issues/112）上描述的行为是有意义的，其中一些用户能够重新创建一个集群（然后可以联系） ）而其他人重新创建，仍然有问题。

            紧急情况可能=多次重建

            在紧急情况下（即您的生产网站......像我们的......需要管理）您可以 PROBABLY 重新创建，直到您开始工作碰巧落在不同AKS管理服务器实例上的集群（一个没有受影响的集群），但请注意，这可能不会在您第一次尝试时发生 - AKS集群重新创建并非完全即时。

            那说......

            受影响节点上的资源继续运行

            我们受影响的虚拟机上的所有容器/入口/资源似乎都运行良好，并且我没有任何警报响起以进行正常运行时间/资源监控（除了图表中列出的利用率怪异之外） ）

              

            我想知道为什么会出现此问题以及用户自己可以实现哪些解决方案而不是Microsoft支持（目前有票证）。如果您有任何想法，请告诉我。

            原因的潜在提示

            1. https://github.com/Azure/AKS/issues/164#issuecomment-363613110
            2. https://github.com/Azure/AKS/issues/164#issuecomment-365389154

              3. 为什么没有GKE？

              我知道Azure AKS正处于预览状态，很多人因为这个问题而转移到了GKE（）。这就是说，到目前为止，我的Azure体验一直是积极的，如果可能的话，我更愿意提供解决方案。

              而且...... GKE偶尔会遇到类似的事情：

              1. TLS handshake timeout with kubernetes in GKE

                2. 我有兴趣看看在GKE上缩放节点是否也解决了那里的问题。

4 个答案:

答案 0 :(得分：4)

解决方法1（可能不适合所有人）

一个有趣的解决方案（对我有用）进行测试是扩展群集中的节点数量，然后退回......

enter image description here

  1. 登录Azure控制台 - Kubernetes服务刀片。
  2. 按1节点扩展群集。
  3. 等待比例尺完成并尝试连接（您应该可以）。
  4. 将群集缩小至正常大小以避免成本增加。

    5. 或者，您可以（可能）从命令行执行此操作：

    az aks scale --name <name-of-cluster> --node-count <new-number-of-nodes> --resource-group <name-of-cluster-resource-group>

    由于这是一个棘手的问题并且我使用了网络界面，我不确定上述内容是否相同或是否可行。

    我花了大约2分钟的时间 - 对于我的情况来说，这比重新创建/配置群集要好得多（可能多次......）

    那就是说......

    Zimmergren提出了一些好处，即Scaling不是一个真正的解决方案：

    “它有时会起作用，群集在缩放后会自我修复一段时间。它有时会出现相同的错误。我不考虑扩展此问题的解决方案，因为这会导致其他挑战，具体取决于设置的方式我不相信GA工作量的常规，这是肯定的。在当前的预览中，它有点狂野的西部（和预期的），我很高兴炸毁集群并创建一个新的不断失败。“ （https://github.com/Azure/AKS/issues/268#issuecomment-395299308）

    Azure支持反馈

    由于我在遇到上述扩展解决方案时打开了支持请求，因此我能够获得有关上述内容的反馈（或者更确切地说是猜测），这是一个释义的回复：

      

    “我知道，如果你进入”az aks show“和”kubectl get nodes“之间节点数量不匹配的状态，缩放群集有时会有所帮助。这可能类似。”

    解决方法参考：

    1. GitHub用户从控制台缩放节点并修复了问题：https://github.com/Azure/AKS/issues/268#issuecomment-375722317

      2. 解决方法不起作用？

      如果这对您不起作用，请在下面发表评论，因为我将尝试保持最新的问题清单列表，问题是否自行解决，以及此解决方案是否适用于Azure AKS用户（看起来并不适合所有人）。

      向上/向下扩展DID的用户不适用于：

      1. omgsarge（https://github.com/Azure/AKS/issues/112#issuecomment-395231681）
      2. Zimmergren（https://github.com/Azure/AKS/issues/268#issuecomment-395299308）
      3. sercand - 规模操作本身失败 - 不确定它是否会影响可连接性（https://github.com/Azure/AKS/issues/268#issuecomment-395301296）

        4. 向上/向下缩放DID适用于：

        1. 我
        2. LohithChanda（https://github.com/Azure/AKS/issues/268#issuecomment-395207716）
        3. Zimmergren（https://github.com/Azure/AKS/issues/268#issuecomment-395299308）

          4. 电子邮件Azure AKS特定支持

          如果您在完成所有诊断后仍然遇到此问题，请随时发送电子邮件至aks-help@service.microsoft.com

答案 1 :(得分：1)

添加另一个答案，因为当上述尝试不起作用时，这是Azure支持官方解决方案。我已经有一段时间没有遇到这个问题了，所以我无法验证这个问题，但是根据我以前的经验，这似乎对我来说很有意义。

在此找到一个完整线程的信用（https://github.com/Azure/AKS/issues/14#issuecomment-424828690）

检查隧道问题

  1. ssh到运行Tunnelfront Pod的代理节点
  2. 获取Tunnelfront日志：“ docker ps”->“ docker logs”
  3. “ nslookup”，其fqdn可以从上面的命令中获取->如果它解析ip，则表示dns有效，然后转到下一步
  4. “ ssh -vv azureuser @ -p 9000”->如果端口正常工作，请转到下一步
  5. “ docker exec -it / bin / bash”，键入“ ping google.com”，如果没有响应，则表示隧道前端吊舱没有外部网络，请执行以下步骤
  6. 使用“ kubectl delete po -n kube-system”重新启动kube-proxy，选择在与tunnelfront相同的节点上运行的kube-proxy。客户可以使用“ kubectl get po -n kube-system -o wide”

我觉得这个特殊的解决方法可以 PROBABLY 自动化（肯定是在Azure方面，但可能是在社区方面）。

通过电子邮件发送Azure AKS特定支持

如果经过诊断，您仍然遇到此问题，请不要犹豫，将电子邮件发送至aks-help@service.microsoft.com

答案 2 :(得分：0)

解决方法2重新创建群集（有点明显）

我正在添加这个，因为有一些细节需要记住，即使我在原来的问题中提到了它，那东西也很长，所以我在这里添加了有关重新创建的具体细节。

群集重新创建并不总是有效

根据我在原始问题中的上述内容，有多个AKS Server实例可以分配给定Azure区域的职责（我们认为）。其中的部分或全部可能会受到此错误的影响，导致您的群集无法通过Kubectl访问。

这意味着，如果您重新创建群集，并且它有些落在同一个AKS服务器上，可能新群集 ALSO 无法访问，需要...

额外的重新创建尝试

可能多次重新创建将导致您最终将新群集登陆到其他AKS服务器之一（工作正常）。  据我所知，我没有看到任何迹象表明所有AKS服务器偶尔会遇到这个问题（如果有的话）。

不同的群集节点大小

  

如果您处于紧要关头并希望最高可能的概率（我们还没有确认此）您的重新创建落在另一个AKS管理服务器上 - 选择不同的节点大小当您创建新群集时（请参阅上面初始问题的节点大小部分）。

我已经打开过这张票，询问Azure DevOps节点大小是否与决定哪些集群由哪些AKS管理服务器管理有关：https://github.com/Azure/AKS/issues/416

支持票证修复与自我修复

由于有很多用户表示问题偶尔会自行解决并且消失，我认为支持实际修复了违规的AKS服务器是合理的（这可能导致其他用户修复了他们的集群 - ＆＃39; Self Heal＆＃39;）而不是修复个人用户的群集。

创建支持票据

对我而言，上述内容可能意味着创建故障单可能是一件好事，因为它会修复遇到同样问题的其他用户群集 - 它也可能是允许针对此特定问题的支持问题严重性升级的论据。

  

我认为这也是一个不错的指标，也许Azure支持还没有弄清楚如何完全解决问题，在这种情况下，创建支持票也可以达到这个目的。

我还询问了Azure DevOps他们是否针对该问题发出警报（基于我根据CPU和网络IO指标变化轻松查看问题的经验）：https://github.com/Azure/AKS/issues/416

如果不是（没有收到回复）那么创建一个票据是有意义的，如果您计划重新创建集群，那么该票证将使Azure DevOps意识到问题导致修复该群集管理服务器上的其他用户。

使群集重新创建更容易的事情

我将补充一点（反馈/想法得到赞赏），但不在我的脑海中：

  1. 要谨慎（明显）了解如何存储用于创建群集的所有YAML文件（即使您不按设计经常为应用重新部署）。
  2. 编写DNS修改脚本以加快指向新实例的速度 - 如果您有面向公众的应用/服务使用DNS（对于Google Domains可能类似于此示例？：https://gist.github.com/cyrusboadway/5a7b715665f33c237996，此处为完整文档：https://cloud.google.com/dns/api/v1/）

答案 3 :(得分：0)

我们只是其中一个集群遇到了这个问题。发送支持票并在5分钟后被工程师回电，询问他们是否可以重新启动API服务器。 2分钟后，它又开始工作了。

原因与他们的消息传递队列中的超时有关。

相关问题
最新问题