经过Kubernetes实现边缘计算的3种选择

导语：企业对边缘计算有不一样的见解，但不多有人排除他们未来将应用程序组件部署到边缘的可能性，特别是对于物联网和其余低延迟应用程序。

许多组织还认为Kubernetes是在边缘计算环境中运行容器的理想机制，尤为是那些已经为知足其云和数据中心需求而采用了容器编排系统的公司。

在边缘计算中使用Kubernetes的:3个通用规则是：

规则1：避免使用缺少资源池的边缘模型，由于Kubernetes在这些环境中不会提供任何真正的好处。这是由于Kubernetes专为管理集群中的容器部署而设计，也就是说集群是一种资源池。

规则2：将边缘Kubernetes视为更普遍的Kubernetes部署中的特殊用例。

规则3：除非存在大量的边缘资源池，不然请避免使用专门为边缘托管设计的Kubernetes工具。

除了这3个通用规则外，还有三个主要的部署选项能够在边缘环境中运行Kubernetes和容器。

选项1：公有云

在此模型中，公有云提供商托管边缘环境或者该环境是公有云服务的扩展。

此选项的典型用例是加强云前端中的交互性。在这种状况下，边缘是公有云的扩展，而且组织的Kubernetes部署实践应适合云提供商的产品。云提供商对边缘计算的支持可能涉及与提供商的公有云服务集成的本地边缘设备，例如Amazon Snowball。

公有云边缘托管几乎老是经过将云托管选项之一（VM，容器或无服务器功能）扩展到边缘来支持，这意味着Kubernetes不会将边缘视为单独的集群。这种方法很容易实现，但可能须要Kubernetes托管策略（例如亲和力，污点和容忍度）将边缘组件定向到边缘资源。当心; 若是边缘计算的目标是减小延迟，请不要让边缘资源与它们控制的元素相距太远。

在边缘计算架构中，数据在网络外围进行处理-尽量靠近其原始源。

选项2：数据中心外的服务器设施

这种方法涉及在组织本身的数据中心外部的一个或多个服务器设施中进行边缘部署。

该边缘模型的主要用例是工业物联网，其中存在大量的边缘处理要求-至少足以证实将服务器放置在工厂和仓库等位置是合理的。在这种状况下，有两种选择：将每一个边缘托管点视为一个单独的群集，或者将边缘托管仅视为主数据中心群集的一部分。

在边缘托管支持各类应用程序的状况下（这意味着每一个边缘站点都是真正的资源池），请考虑使用专门的Kubernetes发行版，例如KubeEdge，它针对以边缘为中心的任务进行了优化。肯定您的边缘应用程序是否与数据中心Kubernetes部署紧密结合，以及在某些状况下边缘和数据中心是否会备份其余应用程序。

在许多边缘部署中，边缘几乎充当仅运行专用应用程序而不运行资源池的客户端。在这种状况下，可能不须要集成Kubernetes集群。不然，请考虑使用Kubernetes联合身份验证做为统一边缘和数据中心策略进行部署的方法。

选项3：专用器具

在这种状况下，边缘模型由一组专用于工厂或加工设施的专用设备组成。

许多专用的边缘设备基于ARM微处理器，而不是基于以服务器为中心的Intel或AMD芯片。在许多状况下，这些设备与IoT设备紧密相连，这意味着每一个边缘设备都有本身的传感器和控制器社区来管理。这里的应用程序不是可变的，所以整体上来讲，不管是容器化仍是专门用于Kubernetes部署，收益都较少。该模型最多见的用例是智能建筑。

非服务器边缘设备一般与为较小的设备占用空间而设计的Kubernetes版本相关联，例如K3s。可是，某些专用边缘设备可能根本不须要编排。若是设备能够同时或分别运行多个应用程序，或者这些设备中的一组托管协做应用程序组件，则能够考虑使用K3来协调部署。若是这两个条件都不成立，则根据须要将应用程序简单地加载到具备本地或网络存储的设备上。

在某些状况下，应用程序的边缘组件与数据中心中运行的应用程序组件紧密结合。这可能须要管理员同步部署边缘和数据中心组件，并在二者上使用通用的编排模型。在这种状况下，要么将边缘元素合并到主数据中心群集中，而后使用策略将边缘组件托管定向到正确的位置，要么将边缘分离为单独的群集，而后经过联盟对其进行部署和编排。

最终肯定，容器和业务流程是有效使用资源池的工具。对于边缘计算模型在边缘建立小型服务器场的企业而言，Kubernetes和边缘计算是很好的合做伙伴，与主要的Kubernetes部署联合的，单独的，特定于边缘的Kubernetes策略是个好主意。

若是边缘环境更加专业，可是仍然必须结合主要应用托管资源（不管是在云仍是数据中心中）进行部署和管理-将边缘做为一种主机类型适合现有的Kubernetes部署。若是边缘是专业的而且在很大程度上是独立的，则考虑彻底不在边缘计算中使用容器。