腾讯云：从lite-apiserver看SuperEdge边缘节点自治

小提示：您能找到这篇{腾讯云：从lite-apiserver看SuperEdge边缘节点自治}绝对不是偶然，我们能帮您找到潜在客户，解决您的困扰。如果您对本页介绍的腾讯云：从lite-apiserver看SuperEdge边缘节点自治内容感兴趣，有相关需求意向欢迎拨打我们的服务热线，或留言咨询，我们将第一时间联系您！

引言

< ">在SuperEdge 0.2.0版本中，lite-apiserver进行了重大的架构升级和功能增强。本文将从lite-apiserver实现及其与其它SuperEdge组件协同的角度，分析SuperEdge的边缘自治能力，给大家的研究和选型提供参考。

< ">边缘节点自治

< ">在云边协同的边缘计算场景中，边缘节点通过公网与云端连接。边缘节点众多，网络环境复杂，网络质量参差不齐。边缘节点需要与云端弱网或断网情况下，继续正常工作，已运行的业务不受影响，达到边缘节点自治的目的。为了实现边缘节点自治，需要处理以下场景：

< ">1.边缘节点与云端断连，但是它本身正常，上面运行的业务容器应该不被驱逐，也没有新的业务容器调度到该节点上

< ">2.边缘节点与云端断连时，边缘节点上的Kubernetes组件和业务容器可继续运行

< ">3.边缘节点与云端断连时，边缘节点重启后，节点上的Kubernetes组件和业务容器可运行

< ">4.边缘节点与云端恢复后，边缘节点上的数据与云端保持一致

< ">SuperEdge使用分布式节点健康检查组件edge-health来处理场景1，使用lite-apiserver来应对场景2、3、4。

< ">lite-apiserver是运行在边缘节点上的轻量级apiserver，它代理节点上所有组件和业务容器访问云端kube-apiserver的请求，并对请求结果做高效缓存。在云边断连的情况下，利用这些缓存提供服务，实现边缘自治的能力。

< ">lite-apiserver设计特性

< ">lite-apiserver除了满足边缘节点自治的功能需求外，还需要满足以下设计特性：

< ">作为边缘节点上访问云端kube-apiserver的唯一“出口”，lite-apiserver需要支持所有类型的Client，包括以bin（如kubelet等）或pod（如flannelkube-proxy等）形式运行的Kubernetes组件，以及以InCluster方式访问kube-apiserver的业务容器。更进一步，如果边缘节点网络环境特殊，需要以代理等方式才能访问云端kube-apiserver时，只用给lite-apiserver设置代理，所有组件即可正常访问云端kube-apiserver，不需要每个组件做单独的配置。

< ">支持缓存所有类型资源

< ">支持缓存所有类型资源，Kubernetes内置资源和Custom Resources。边缘节点上运行的Kubernetes组件和业务容器的请求kube-apiserver的资源多样，如果只缓存部分资源类型或仅支持Kubernetes内置资源类型，在云边断连时，可能因为读取不到对应的缓存导致组件或业务失败，达不到边缘节点自治的效果。当然，支持所有类型资源的缓存（尤其是Custom Resources），也给数据的解析和处理带来了不小挑战。

< ">安全

< ">边缘节点分布广制作微信小程序免费泛，环境复杂，更容易造成安全风险。安全问题也在边缘计算和Kubernetes管理中越来越受重视。给lite-apiserver赋予一个访问权限，其代理的所有请求扔掉自身的权限方式，都使用lite-apiserver的权限访问云端的kube-apiserver，是一种常见的访问控制方案。由于lite-apiserver需要访问和处理所有类型的资源，则该权限必然是一个“超级”权限。在这种情形下，某一个边缘节点上的恶意程序就可以通过lite-apiserver对集群的所有资源进行操作，可能对整个集群进行恶意破坏。因此，从安全角度，lite-apiserver从设计上不应拥有一个“超级”权限，可以使用Kubernetes组件和业务容器原有的认证和鉴权方式，访问云端kube-apiserver。

< ">支持多种缓存存储

< ">根据IDC对边缘计算分层的定义，边缘分为Heavy Edge（边缘数据中心）和Light Edge（低功耗计算平台）。针对不同的场景，lite-apiserver可以采用不同的缓存存储策略来达到更优的效果。在Light Edge中，lite-apiserver使用文件存储缓存以降低其本身的系统开销，提升通用性。在Heavy Edge中，lite-apiserver可采用KV存储等提升读写性能。

< ">下面我们将从lite-apiserver的架构和关键技术方面，介绍其如何实现以上的功能需求和设计特性。

< ">lite-apiserver架构与关键技术

< ">架构

< ">lite-apiserver架构如图

< ">HTTPS Server监听localhost的端口（SurperEdge中为51003）接受Client的Https请求。

< ">Cert Mgr&&Transport Mgr Cert Mgr负责管理连接kube-apiserver的TLS客户端证书。它周期性加载配置的TLS证书，如果有更新，通知Transport Mgr创建或更新对应的transport。Transport Mgr负责管理transport。它接收Cert Mgr的通知，创建新的transport，或者关闭证书已更新的transport的旧连接。

< ">Proxy根据request mtls证书中的Common Name选择对应的ReverseProxy（如果request没有mtls证书，则使用default），将request转发到kube-apiserver。如果请求成功，则将结果直接给Client返回，并调用Cache Mgr缓存数据；如果请求失败，则从Cache Mgr中读取数据给Client。

< ">Cache Mgr根据Client的类型分别缓存Get和List的结果数据，并根据Watch的返回值，更新对应的List数据。

< ">关键技术

< ">1.HTTPS Server

< ">在当前架构下，lite-apiserver只处理本节点的所有请求，使用HTTP Server可以满足性能和安全要求。然而，大部分组件和业务容器采用client-go库访问kube-apiserver，如果使用HTTP Server，Client自己的认证和鉴权信息全部丢失，不符合权限管理的要求。因此必须采用HTTPS Server。lite-apiserver的TLS Server证书，需用kube-apiserver的Server证书相同的CA签发。

< ">2.支持InCluster方式访问

< ">一般的Client通过指定kube-apiserver的URL访问kube-apiserver，使用lite-apiserver时，只需将原来kube-apiserver的URL替换为lite-apiserver的地址即可。在Pod中访问kube-apiserver的推荐方式是通过kubernetes.default.svc这个DNS名称，该名称将会解析为服务IP，然后服务IP将会路由到kube-apiserver。在这种场景下使用lite-apiserver需要一些小小的"魔法"。在SuperEdge中，application-grid-wrapper以DaemonSet的形式部署在每个边缘节点上，通过给kube-proxy只返回本区域内的endpoints来达到访问在区域内闭环的目的。利用这个特性，application-grid-wrapper把kubernetes这个Service的endpoint改为lite-apiserver的地址，返回给本节点kube-proxy，即可支持InCluster方式访问。

< ">3.支持Client的Bootstrap Token和证书轮换

< ">lite-apiserver使用Client自己的认证和鉴权方式，访问云端的kube-apiserver。对于st舆情导控atic token、bootstrap token、service account等方式，lite-apiserver只需透传Http Request的Header中包含的认证鉴权信息即可。对于TLS客户端证书的认证方式，lite-apiserver通过读取配置文件，加载所有Client用到的TLS客户端证书，使用这些证书构造对应的HTTPS请求kube-apiserver。为了支持Client的B电商代运营排名ootstrap Token和证书轮换，lite-apiserver需要周期性的加载和更新这些证书。kube-controller-manager签发的证书默认时间是1年，lite-apiserver加载TLS客户端证书周期不宜过短。但如果证书加载周期时间过长，kubelet使用Bootstrap Token的场景中会存在证书更新不及时的问题。为了处理这些场景，lite-apiserver采用一种“优雅”的证书加载策略：当加载证书出现错误或证书过期时，进入快速加载模式，周期是1s;加载证书均成功时，进入普通加载模式，周期是30min。当证书更新后，lite-apiserver使用client-go[1]提供的closeAll方法，关闭已存在的连接，以防认证鉴权失败。

< ">4.缓存解析和更新

< ">lite-apiserver需要支持缓存所有类型的资源，缓存的解析和更新是lite-apiserver实现的关键之一。lite-apiserver分别缓存每个Client对资源的Get和List请求，这样虽然造成了一定的存储空间的浪费，但是可以支持缓存所有资源类型，尤其是用户自定义资源，并且天然具有资源版本兼容能力，能够处理同一资源存在多个版本的情况。对于Watch类型的请求结果，lite-apiserver采用unstructured.UnstructuredJSONScheme解析出资源的meta信息，进而更新相应的List数据。

< ">展望

< ">SuperEdge正式开源以来，得到了广泛的关注。SuperEdge在快速迭代开发中，lite-apiserver也有不少可扩展点，欢迎大家积极参与，共同打造一个优秀的云原生边缘容器项目。

< ">支持更多种类存储

< ">性能和内存优化，适应更广泛的边缘场景

参考资料

[1] client-go:https://github.com/kubernetes/client-go/blob/master/util/connrotation/connrotation.go#L20