Kubernetes是以应用为中心的技术架构与思想理念，以一套技术体系支持任意负载，运行于任意基础设施之上；向下屏蔽基础设施差异，实现底层基础资源统一调度及编排；向上通过容器镜像标准化应用，实现应用负载自动化部署；向外突破中心云计算的边界，将云计算能力无缝拓展是边缘及现场，快速构建云边一体基础设施。

将云原生技术从中心拓展到边缘，不仅实现云边基础设施技术架构大一统，同时业务实现云边自由编排部署。但是相对Kubernetes在中心云革命性的创新，在边缘场景优势明显，同时缺点也非常致命，在边缘资源有限，网络受限不稳定等特殊情况，所以需要根据不同的业务场景，选择不同Kubernetes边缘方案。

从技术架构来看，Kubernetes是典型的分布式架构，Master控制节点是集群“大脑”，负责管理节点，调度Pod以及控制集群运行状态。Node工作节点，负责运行容器（Container），监控/上报运行状态。在边缘计算场景存在以下比较明显的挑战：

1. 状态强一致且集中式存储架构，属于中心云计算的大成产品，基于大规模的池化资源的编排调度实现业务持续服务。
2. Master管控节点与Worker工作节点通过List-Watch机制，实现状态任务实时同步，但是流量流量较大，Worker工作节点完全依赖Master节点持久化数据，无自治能力。
3. Kubelet承载太多逻辑处理，各种容器运行时各种实现的兼容，还有Device Plugin硬件设备驱动，运行占用资源高达700M；对资源有限的边缘节点负担太重，尤其是低配的边缘设备。

边缘计算涉及的范围大，场景复杂，没有统一的标准；Kubernetes开源社区的主线版本并没边缘场景的适配计划。

针对中心云计算及边缘计算这种云边分布式架构，需要将Kubernetes适配成适合边缘分布式部署的架构，借助Kubernetes的优势，弥补Kubernetes的不足，通过多集群管理实现统一管理，实现中心云管理边缘运行，整体分为三种方案：

集群 Cluster：将Kubernetes标准集群下沉至边缘，优点是无需Kubernetes做定制化研发，同时可以支持Kubernetes多版本，支持业务真正实现云边架构一致；缺点就是管理资源占用多。方案比较适合区域云/中心云，边缘计算/本地计算以及规模较大的产业边缘场景。

单节点 Single Node：将Kubernetes精简，部署在单节点设备之上，优点与集群 Cluster方案一致，缺点Kubernetes能力不完整，资源的占用会增加设备的成本，对业务应用无法保证云边一致的架构部署运行，是一个中庸方案，没有解决实际问题。

边缘节点 Remote Node：基于Kubernetes二次开发增强扩展，将Kubernetes解耦适配成云边分布式架构的场景，中心化部署Master管理节点，分散式部署Worker管理节点。