lite

共计 4369 个字符，预计需要花费 11 分钟才能阅读完成。

这篇文章主要介绍了 lite-apiserver 怎么实现的相关知识，内容详细易懂，操作简单快捷，具有一定借鉴价值，相信大家阅读完这篇 lite-apiserver 怎么实现文章都会有所收获，下面我们一起来看看吧。

引言

在 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（如 flannel\kube-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 数据。

关于“lite-apiserver 怎么实现”这篇文章的内容就介绍到这里，感谢各位的阅读！相信大家对“lite-apiserver 怎么实现”知识都有一定的了解，大家如果还想学习更多知识，欢迎关注丸趣 TV 行业资讯频道。