共计 4305 个字符，预计需要花费 11 分钟才能阅读完成。
引言
在 SuperEdge 0.2.0 版本中，lite-apiserver 进行了重大的架构降级和性能加强。本文将从 lite-apiserver 实现及其与其它 SuperEdge 组件协同的角度，剖析 SuperEdge 的边缘自治能力，给大家的钻研和选型提供参考。
边缘节点自治
在云边协同的边缘计算场景中，边缘节点通过公网与云端连贯。边缘节点泛滥，网络环境简单，网络品质参差不齐。边缘节点须要与云端弱网或断网状况下，持续失常工作，已运行的业务不受影响，达到边缘节点自治的目标。为了实现边缘节点自治，须要解决以下场景：
边缘节点与云端断连，然而它自身失常，下面运行的业务容器应该不被驱赶，也没有新的业务容器调度到该节点上
边缘节点与云端断连时，边缘节点上的 Kubernetes 组件和业务容器可持续运行
边缘节点与云端断连时，边缘节点重启后，节点上的 Kubernetes 组件和业务容器可运行
边缘节点与云端复原后，边缘节点上的数据与云端保持一致
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 也有不少可扩大点，欢送大家积极参与，独特打造一个优良的云原生边缘容器我的项目。
内存中缓存局部高频更新的资源，晋升性能
反对更多品种存储
- 性能和内存优化，适应更宽泛的边缘场景
