腾讯云容器服务健康状态检测同尘科技

边缘场景下的弱网络会触发 Kubernetes 驱逐机制，引起不符合预期的 Pod 驱逐动作。边缘计算情景下，边缘节点与云端的网络环境十分复杂，网络质量无法保证，容易出现 API Server 和节点连接中断等问题。如果不加改造直接使用原生 Kubernetes，节点状态会经常出现异常，引起 Kubernetes 驱逐机制生效，导致 Pod 的驱逐和 EndPoint 的缺失，最终造成服务的中断和波动。 为解决这个问题，边缘容器服务 首创分布式节点状态判定机制。该机制可以更好地识别驱逐时机，保障系统在弱网络下正常运转，避免服务中断和波动。

需求场景

在边缘场景下，需面对云边弱网络的环境。边缘设备位于边缘云机房和移动边缘站点，与云端连接的网络环境较为复杂，既包含云端（控制端）和边缘端的网络环境不可靠，也包含边缘节点之间的网络环境不可靠。

智慧工厂

以智慧工厂为例，边缘节点位于厂房仓库和车间，控制端 Master 节点在腾讯云的中心机房内。示意图如下：

仓库和车间内的边缘设备同云端集群之间的网络较复杂，因特网、5G、WIFI 等形态均有可能，网络质量差次不齐没有保障。 相比于云端的网络环境，仓库和车间内的边缘设备之间是本地网络，网络质量优于同云端集群之间的连接，相对而言更加可靠。

音视频拉流场景

音视频拉流场景如下图所示：

考虑到用户体验及公司成本，音视频拉流经常需要进行提高边缘缓存命中率减少回源、将用户请求的同一文件调度到同一个服务实例以及服务实例缓存文件。 在原生 Kubernetes 的情况下，如果 Pod 因为网络波动而频繁重建，一方面会影响服务实例缓存效果，另一方面会引起调度系统将用户请求调度到其他服务实例。这两点都会对 CDN 效果造成很大甚至不能接受的影响。 事实上，边缘节点完全运行正常，Pod 驱逐或重建其实是完全不必要的。为了克服这个问题，保持服务的持续可用，TKE 边缘容器团队提出了分布式节点状态判定机制。

需求痛点

原生 Kubernetes 处理方式

云边弱网络是影响了运行在边缘节点上的 kubelet 与云端 APIServer 之间通信，云端 APIServer 无法收到 kubelet 的心跳或者进行续租，无法准确获取该节点和节点上 Pod 的运行情况，如果持续时间超过设置的阈值，APIServer 会认为该节点不可用，并做出如下操作：失联的节点状态被置为 NotReady 或者 Unknown 状态，并被添加 NoSchedule 和 NoExecute 的 taints。 失联的节点上的 Pod 被驱逐，并在其他节点上进行重建。 失联的节点上的 Pod 从 Service 的 Endpoint 列表中移除。

解决方案

设计原则

在边缘计算场景中，仅依赖边缘端和 APIServer 的连接情况来判断节点是否正常并不合理，为了让系统更健壮，需要引入额外的判断机制。 相较于云端和边缘端，边缘端节点之间的网络更稳定，可利用更稳定的基础设施提高准确性。边缘容器服务首创了边缘健康分布式节点状态判定机制，除了考虑节点与 APIServer 的连接情况，还引入了边缘节点作为评估因子，以便对节点进行更全面的状态判断。经过测试及大量的实践证明，该机制在云边弱网络情况下提高了系统在节点状态判断上的准确性，为服务稳定运行保驾护航。该机制的主要原理如下：每个节点定期探测其他节点健康状态集群内所有节点定期投票决定各节点的状态云端和边缘端节点共同决定节点状态首先，节点内部之间进行探测和投票，共同决定具体某个节点是否存在状态异常，保证大多数节点的一致判断才能决定节点的具体状态。其次，即使节点之间的网络状态通常情况下优于云边网络，但也应该考虑边缘节点复杂的网络情况，其网络并非100%可靠。因此，也不能完全信赖节点之间的网络，节点的状态不能只由节点自行决定，云边共同决定才更为可靠。基于这个考虑，做出如下设计：

方案特性

当云端判定节点异常，但是其他节点认为节点正常的时候，虽然不会驱逐已有 Pod，但为了确保增量服务的稳定性，将不会再将新的 Pod 调度到该节点上，存量节点的正常运行也得益于边缘集群的边缘自治能力。 由于边缘网络和拓扑的特殊性，经常会存在节点组之间网络单点故障的问题，例如 智慧工厂，仓库和车间虽然都属于厂房这个地域内，但他们间的网络连接仅依靠一条关键链路，一旦这条链路发生中断，就会造成节点组之间的分裂，本文提供的方案能够确保两个分裂的节点组失联后互相判定时始终保持多数的一方节点不会被判定为异常，避免被判定为异常造成 Pod 只能被调度到少部分的节点上，造成节点负载过高的情况。 边缘设备可能位于不同的地区且相互不通，本文提供的方案支持多地域内的节点状态判定，可以方便地将节点依据地域或者其他方式进行分组，实现组内的检查。即使重新分组也无需重新部署检测组件或重新初始化，适应边缘计算的网络情况。分组后，节点只会判定同一个组内的节点状态。

前提条件

该功能需要打开节点的51005端口，以便节点之间进行分布式智能健康探测。

操作步骤

注意边缘检查和多地域检查功能需要一定的部署和配置时间，并非即时生效。

开启边缘检查功能

边缘检查功能默认关闭，请参考以下步骤手动开启：1. 登录 容器服务控制台。2. 在集群列表页面，选择目标边缘集群 ID，进入集群详情页面。3. 选择左侧菜单栏中的组件管理，进入组件管理页面。4. 单击新建，进入新建组件页面。5. 勾选 edge-health，如下图所示：

在参数配置中您可以根据业务需求选择开启全局节点离线免驱逐和使用多地域。如下图所示：

6. 单击完成即可部署组件到目标边缘集群。

开启全局节点离线免驱逐

开启此功能后，会通过 webhook 机制拦截全部的节点驱逐标志即 NoExecute 的 taint，从而防止节点频繁断网重连导致的 Pod 驱逐和重新调度，此功能和多地域检查互斥，开启免驱逐则不会在边缘实际探测节点健康状态。

开启多地域检查功能

这里的多地域在 edge-health 中实际上是 NodeUnit 概念，通过 NodeUnit 才区分不同的节点地域属性，详情请参见 NodeUnit 文档。开启 Edge Health 能力会在所有边缘节点上部署 edge-health 健康监测 Pod。如果这个时候，不使能开启多地域，会默认互相检测所有节点的状态，此时并没有多地域概念，可以将所有节点看作同一地域下的节点进行互相检测。如果想要在不同的地域内部独立进行节点间的健康状态互检，则需要使能开启多地域，此时会修改一个 edge-health-config的 ConfigMap，通知 K8s 要处理多地域的健康检测能力。开启后，节点会根据节点上的 : nodeunits.superedge.io 标签来区分地域。例如，beijing: nodeunits.superedge.io 表明将节点划分到 NodeUnit beijing。标签取值相同的节点视为同一个 NodeUnit。开启多地域功能时，同一个地域内的节点会相互探测和投票。注意如果使能开启多地域能力后，节点不属于任何一个 NodeUnit，该节点不会进行健康检查。如果没有使能开启多地域能力，则一个集群内的所有节点会进行相互检查，即使节点属于 NodeUnit。

控制台添加节点到 NodeUnit

1. 登录 容器服务控制台。2. 在集群列表页面，选择目标边缘集群 ID，进入集群详情页面。3. 选择左侧菜单栏中的节点管理 > 边缘节点池，进入 NodeUnit 列表页面。4. 单击新建，在创建节点池中勾选节点池中的节点。如下图所示：


5. 单击完成。

示例

下面给出一个示例，说明健康状态检测的实际效果：1. 当前有不同私有网络（互相网络不通）的南京一区和南京二区两个地域6个节点，如下图所示：


2. 根据上文描述，使能开启 Edge health能力。这个时候可以在每个节点上的edge-health上查看所有节点之间都会互相探测。3. 使能开启多地域能力，同时给这六个节点各自创建不同的 NodeUnit，并开启 NodeUnit 内节点探测，如下图所示：


4. 这个时候就完整使能了多地域健康状态能力，使用gz-3节点模拟测试如下：可以使用iptables规则模拟和 apiserver 断连：

iptables -I INPUT -s xxx.xxx.xxx.xxx -j DROP  # 这里为云端 apiserver 的 IP 地址

过一段时间后，观察gz-3节点为 NotReady 状态，但是Taint并没有添加node.kubernetes.io/unreachable:NoExecute，所以此节点上的 Pod 并不会被 evict，此节点已经不会被调度新的 Pod 了。

关闭gz-3节点，模拟云端和内网检测均失败的场景，观察节点状态，这个时候为 Kubernetes 标准的节点失效状态，会迁移节点上的 Pod。


容器服务官网1折活动，限时活动，即将结束，速速收藏
同尘科技为腾讯云授权服务中心。
购买腾讯云产品享受折上折，更有现金返利。同意关联立享优惠