导语： 企业对边缘计算有不同的看法，但很少有人排除他们将来将应用程序组件部署到边缘的可能性，特别是对于物联网和其他低延迟应用程序。
许多组织还认为 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 部署。如果边缘是专业的并且在很大程度上是独立的，则考虑完全不在边缘计算中使用容器。