关于kubernetes:从-liteapiserver-看-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 除了满足边缘节点自治的性能需要外，还须要满足以下设计个性：

反对所有 Client 类型

作为边缘节点上拜访云端 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 架构如图

从整体上看，lite-apiserver 启动一个 HTTPS Server 承受所有 Client 的申请（https request），并依据 request tls 证书中的 Common Name 抉择对应的 ReverseProxy（如果 request 没有 mtls 证书，则应用 default），将 request 转发到 kube-apiserver。当云边网络失常时，将对应的返回后果（https response）返回给 client，并按需将 response 异步存储到缓存中；当云边断连时，拜访 kube-apiserver 超时，从缓存中获取已缓存的数据返回给 client，达到边缘自治的目标。

• 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。对于 static token、bootstrap token、service account 等形式，lite-apiserver 只需透传 Http Request 的 Header 中蕴含的认证鉴权信息即可。对于 TLS 客户端证书的认证形式，lite-apiserver 通过读取配置文件，加载所有 Client 用到的 TLS 客户端证书，应用这些证书结构对应的 HTTPS 申请 kube-apiserver。为了反对 Client 的 Bootstrap Token 和证书轮换，lite-apiserver 须要周期性的加载和更新这些证书。kube-controller-manager 签发的证书默认工夫是 1 年，lite-apiserver 加载 TLS 客户端证书周期不宜过短。但如果证书加载周期时间过长，kubelet 应用 Bootstrap Token 的场景中会存在证书更新不及时的问题。为了解决这些场景，lite-apiserver 采纳一种“优雅”的证书加载策略：当加载证书呈现谬误或证书过期时，进入疾速加载模式，周期是 1s; 加载证书均胜利时，进入一般加载模式，周期是 30min。当证书更新后，lite-apiserver 应用 client-go 提供的 closeAll 办法，敞开已存在的连贯，以防认证鉴权失败。

4. 缓存解析和更新

lite-apiserver 须要反对缓存所有类型的资源，缓存的解析和更新是 lite-apiserver 实现的要害之一。lite-apiserver 别离缓存每个 Client 的对资源的 Get 和 List 申请，这样尽管造成了肯定的存储空间的节约，然而也防止了简单的资源版本转换。对于 Watch 类型的申请后果，lite-apiserver 采纳unstructured.UnstructuredJSONScheme 解析出资源的 meta 信息，进而更新相应的 List 数据。

瞻望

SuperEdge 正式开源以来，失去了宽泛的关注。SuperEdge 在疾速迭代开发中，lite-apiserver 也有不少可扩大点，欢送大家积极参与，独特打造一个优良的云原生边缘容器我的项目。

• 内存中缓存局部高频更新的资源，晋升性能

• 反对更多品种存储

• 性能和内存优化，适应更宽泛的边缘场景