Kubernetes是以应用为中心的技术架构与思想理念，以一套技术体系支持任意负载，运行于任意基础设施之上；向下屏蔽基础设施差异，实现底层基础资源统一调度及编排；向上通过容器镜像标准化应用，实现应用负载自动化部署；向外突破中心云计算的边界，将云计算能力无缝拓展至边缘及现场，快速构建云边一体基础设施。
将云原生技术从中心拓展到边缘，不仅实现云边基础设施技术架构大一统，同时业务实现云边自由编排部署。但是相对Kubernetes在中心云革命性的创新，在边缘场景优势明显，同时缺点也非常致命，在边缘资源有限，网络受限不稳定等特殊情况，所以需要根据不同的业务场景，选择不同Kubernetes边缘方案。
1. Kubernetes架构及边缘化的挑战
从技术架构来看，Kubernetes是典型的分布式架构，Master控制节点是集群“大脑”，负责管理节点，调度Pod以及控制集群运行状态。Node工作节点，负责运行容器（Container），监控/上报运行状态。在边缘计算场景存在以下比较明显的挑战：
状态强一致且集中式存储架构，属于中心云计算的大成产品，基于大规模的池化资源的编排调度实现业务持续服务。
Master管控节点与Worker工作节点通过List-Watch机制，实现状态任务实时同步，但是流量流量较大，Worker工作节点完全依赖Master节点持久化数据，无自治能力。
Kubelet承载太多逻辑处理，各种容器运行时各种实现的兼容，还有Device Plugin硬件设备驱动，运行占用资源高达700M；对资源有限的边缘节点负担太重，尤其是低配的边缘设备。
边缘计算涉及的范围大，场景复杂，没有统一的标准；Kubernetes开源社区的主线版本并没边缘场景的适配计划。
2. Kubernetes边缘化运行方案
针对中心云计算及边缘计算这种云边分布式架构，需要将Kubernetes适配成适合边缘分布式部署的架构，借助Kubernetes的优势，弥补Kubernetes的不足，通过多集群管理实现统一管理，实现中心云管理边缘运行，整体分为三种方案：
集群 Cluster：将Kubernetes标准集群下沉至边缘，优点是无需Kubernetes做定制化研发，同时可以支持Kubernetes多版本，支持业务真正实现云边架构一致；缺点就是管理资源占用多。方案比较适合区域云/中心云，边缘计算/本地计算以及规模较大的产业边缘场景。
单节点 Single Node：将Kubernetes精简，部署在单节点设备之上，优点与集群 Cluster方案一致，缺点Kubernetes能力不完整，资源的占用会增加设备的成本，对业务应用无法保证云边一致的架构部署运行，是一个中庸方案，没有解决实际问题。
-
边缘节点 Remote Node：基于Kubernetes二次开发增强扩展，将Kubernetes解耦适配成云边分布式架构的场景，中心化部署Master管理节点，分散式部署Worker管理节点。
3. Kubernetes边缘容器的碎片化
Kubernetes已经成为容器编排和调度的事实标准，针对边缘计算场景，目前国内各个公有云厂商都开源了各自基于Kubernetes的边缘计算云原生项目，比如由华为开源KubeEdge，采用边缘节点 Remote Node方案，深度定制了Kubernetes，精简了Kubelet，Master与Worker通信机制使用了Websocket与quic技术来重构了，是面向边缘计算场景、专为边云协同设计的业界云原生边缘计算框架。KubeEdge于2019年3月正式进入CNCF成为沙箱级项目（Sandbox），也成为CNCF云原生边缘计算项目。并于2020年9月晋升为孵化级项目(Incubating)，成为 CNCF 孵化的云原生边缘计算项目。
总的来说，边缘容器的碎片化严重，导致构建边缘计算平台时难以抉择。从技术架构来看，几个边缘容器产品架构是有差异，总的架构思路主要是将Kubernetes解耦成适合云边，弱网络及资源稀缺的边缘计算场景，本质上没有太大差异；从产品功能来看，几个边缘容器产品功能基本一致，基本上都是云边协同，边缘自治，单元化部署功能等。4. 构建云边一体化云原生平台
围绕Kubernetes容器平台，构建云边一体化云原生基础设施平台能力，是边缘计算平台的佳选择，通过云端统一的容器多集群管理，实现分散式集群统一管理，同时标准化Kubernetes集群规格配置：
标准集群（大规模）：支持超过400个节点的大规模集群，配置为ETCD + Master 3台 8c16G，Prometheus + Ingress 5台 8C16G， N * Work节点；主要是业务规模较大的云原生应用运行场景；
标准集群（中等规模）：支持超过100个节点以内的集群，ETCD + Master + Prometheus 3台 8c16G，N * Work节点；主要是业务规模中等的场景；
边缘原生容器集群：在云端部署集群管理节点，将边缘节点单独部署业务现场，支持运行单业务场景的应用，比如IoT物理设备接入协议解析应用，视频监控分析AI算法模型等业务场景。
按照业务场景需求选择优容器集群方案，其中边缘容器集群方案，与其他集团方案差别较大，其他集群依然保持中心云集群服务一致，基础资源集中并且池化，所有应用共享整个集群资源；而边缘容器集群Master管理节点集中部署，共享使用；Worker节点都是分散在业务现场，按需自助增加，自运维且独占使用。当前边缘容器碎片化严重，短时间很难有大一统的开源产品，边缘原生容器集群的集成，长期来看，建议通过标准的Kubernetes API来集成，这种兼容所有边缘容器的中庸方案。一致性是边缘计算的痛点，在边缘增加一个Cache即可实现断网特殊情况的边缘自治，同时可以保证正常网络情况的数据一致；还有就是Kubelet比较重的问题，随着Kubernetes放弃Docker已经开始精简；同时硬件更新迭代较快，相比少量硬件成本，保持Kubernetes原生及通用性为大。其实更希望Kubernetes社区本身提供适配边缘化方案，同时考虑为Kubelet增加缓存机制。5. 业务应用的云边管运协同
基于中心云的分布式业务应用架构，与云边分布式协同业务应用架构本质上是有很大的差别。在中心云更多的是基于DDD业务领域，将复杂的业务系统拆分成一个个相对独立的服务，整体构建一个松耦合的分布式应用；但是在云边分布式场景下，更多的强调的是集中式管控运营，分散式运作支撑；将管理运营系统集中在云中心，实现中心式管控；将支撑业务实时运作的应用分散至边缘，实现低延迟快速响应。
从业务应用来看，财务/经营，计划/管理两层属于管控运营类的应用，就是需要通过中心云统一汇聚，实现集中化强管控；对延迟不敏感，对安全，大数据分析能力等要求较高；控制，传感/执行，生产过程三层属于运作支撑类应用，也可以优先考虑中心云；如果业务场景对延迟敏感，才考虑通过边缘计算能力，实现分散式低时延响应；从请求响应来看，对时延不敏感（50ms以上）都有限考虑部署在中心云计算及云化的边缘产品（CDN）实现；对延迟敏感（小于10ms），运营商骨干网完全无法支持的，考虑建设边缘计算平台，同时业务面临不小的投入及人员；说的比较抽象，就用实体物流领域为例，对于物流领域，经典的OTW系统（OMS订单的管理系统，WMS仓库管理系统，TMS运输管理系统）；其中OT就属于典型的管理运营系统，所以建议部署在中心云，通过中心云数据汇聚，实现拼单拆单，多式联运等跨区域业务；W是仓库管理系统，管理四面墙的任务，属于运作支撑应用，并且仓库一般都有一些自动化设备，就可以考虑将W部署在边缘。6. 总结
突破中心云计算的边界，将云原生Kubernetes从中心拓展至边缘力，构建云边一体化基础设施。面向业务,不仅统一了广域边缘侧分布式的应用运行时，同时实现了应用的中心化管理和边缘侧运行的云边协同。面向运维,业务的自动化运维、高可靠性保障，降低边缘应用的运维工作量，提升边缘计算业务创新效率。总的来说，Kubernetes云原生是一个庞大且复杂的体系，将整个体系下沉至边缘，面临很大挑战与困难；业务应用想要真正践行边缘的云原生体系，需要从理念、系统设计、架构设计等多方面来公关实现，才能充分发挥边缘的优势及价值。云原生，边缘计算两个领域都在发展，国家也对场景化边缘计算建设提出更高的要求，未来已来，共同期待。2.红帽：Edge computing with Red Hat OpenShift
来源： 巨子嘉
原文地址：http://mtw.so/5xxBqu