边缘簇
各种类型的设备 — 音频设备、视频设备、IoT 设备以及各种传感器和执行器。本文将讨论在作为边缘节点的小型边缘簇上部署的容器 — 是的，在 Raspberry Pi 级机器上或 Intel NUC 等小型设备上运行 Kubernetes 簇，并配备足够的计算和存储空间。具体来说，簇运行基于 Kubernetes 的下游分布，例如 K3S 或 MicroK8S，或者在小型簇上运行一个精简的三节点 Red Hat OpenShift 容器平台 (OCP)，作为远离数据中心的本地部署位置的边缘节点。
计算密集型应用程序需要高计算能力来进行数据处理和存储，但 IoT 设备通常无法满足这些要求，因为它们通常受到资源的限制。因此，企业可以将边缘簇用作动态、稳健的环境，运营团队在其中满足所需的存储空间、计算、低延迟、高性能和高带宽。此外，一些高度可用的本地共享服务可能需要 Kubernetes 簇设计提供的可扩展性，例如边缘云部署。
边缘簇通常可以成为企业的逻辑资源边界。高端边缘设备对于企业来说投资成本也较高。许多传统的固定功能或专用设备可能已经部署并列入预算。边缘簇技术为企业提供了一种使用边缘原生方法来现代化和未来化其应用的方式。具体做法是将这些设备与一个小型边缘簇连接，该簇运行设备管理或物联网 (IoT) 平台解决方案。然后，该边缘簇将像一个边缘设备一样进行管理和操作。
边缘簇具有以下主要优势：
- 可扩展：为客户提供根据需求向簇添加额外容量的便利和能力。它可以设置为自动扩展，从而减少运营团队的时间和精力。
- 分布式：边缘簇可处理和分析更多数据，从而避免将数据发送到云所需的费用和时间。
- 合规性：在边缘簇上处理数据也有助于满足监管合规性需求、数据驻留和数据隔离。
- 安全：保护簇上托管的所有应用程序服务器之间的通信安全。
- 高可用性：通过簇的回退选项以及在应用持续平稳运行时根据需要创建新节点的能力，提升了系统的可靠性。
让我们来研究一个零售行业的示例。某零售商因安全召回问题，希望将某一特定产品下架或停止销售。他们需要更新中央库存系统，并将该更新推送至多家商店生效。
在门店中的边缘簇结合 IoT 设备、摄像头和传感器，非常适合支持这一场景。当门店库存系统将某个特定 SKU（库存单位）标记为下架时，门店经理也会收到通知，将实体产品从货架上移除。与此同时，销售点 (POS) 系统会更新以作废该产品的条形码。一个架构良好的边缘簇解决方案能够在大规模环境下实现这种快速操作，而不会产生高成本的延迟或人为错误。
图 1 显示了边缘簇部署在典型的网格布局门店中，配备了安防和库存摄像头、销售点系统 (POS)、入口传感器以及冰柜中的温度传感器：
我们来看另一个例子，这次是在交通运输领域。一艘网络连接受限的货船运载着数百个冷藏集装箱。冷藏集装箱简单来说，就是由集装箱船运载的大型冰箱，用于运输易腐商品，如肉类、蔬菜和药品，以防止变质。集装箱内货物的类型决定了需要维持的温度。
冷藏容器不仅要保持内部温度稳定，还要控制湿度并促进充足的空气流通。即使在船上连接受限的情况下，最好也使用边缘簇来监控和管理冷藏箱的恒温器、风扇和其他重要组件。这种配置还可以实现船上的监控和警报，而无需基于云的基础设施。船舶到达港口时，边缘簇将与船坞或云的边缘枢纽重新连接。只有通过架构良好的边缘簇解决方案，才能大规模地管理这些冷藏设备和其他设备，而无需或只需少量人工干预。
边缘簇可以小到足以放置在快餐店、培训、救护车、信息亭、商店、仓库和生产车间等狭小空间内的可用货架上。我们可以部署与该环境相关的工作量。这些应用程序可能是视频检测应用程序、温度传感应用程序、工单应用程序、任务关键型语音服务甚至 AR/VR 应用程序。
作为上述场景的适度 Kubernetes 簇安装的代表性示例，以下是有关如何使用 K3s 进行实施的一些详细信息。请记住，您也可以使用类似的 Kubernetes 发行版，如 minikube 或 microk8s。下面列出的是包含一个基本的 1 个主节点、2 个工作节点的 K3s (https://k3s.io/) 簇设置。我们将展示在每个组件上运行所需的最少命令集。下表所示为三节点拓扑：
K3S_URL 是主节点的 IP 地址及端口，其中 6443 是 HTTPS 监听端口。请注意，默认情况下，K3s 使用的是 containerd 容器，而不是 Docker。
主节点
$export K3S_URL="https://192.168.0.248:6443" $curl -sfL https://get.k3s.io | sh - $sudo cat /var/lib/rancher/k3s/server/node-token K10e1d3513c6e47d402450465d7726ee6ac1240d62dc11521726aba73461e230bbe::server:79917a97f717e29d5858a6d45b5adccd
Worker 1
$export K3S_KUBECONFIG_MODE="644" $export K3S_URL="https://192.168.0.248:6443" $export K3S_TOKEN="K10e1d3513c6e47d402450465d7726ee6ac1240d62dc11521726aba73461e230bbe::server:79917a97f717e29d5858a6d45b5adccd"
Worker 2
$export K3S_KUBECONFIG_MODE="644" $export K3S_URL="https://192.168.0.248:6443" $export K3S_TOKEN="K10e1d3513c6e47d402450465d7726ee6ac1240d62dc11521726aba73461e230bbe::server:79917a97f717e29d585
从 IBM Edge Application Manager (IEAM) 的角度来看，边缘簇与边缘设备类似，因为两者都安装了边缘代理。图 2 显示了边缘簇的高级组件：
边缘簇本质上是基于 Kubernetes 的边缘节点簇。那么，为什么要将一个小型簇设置为边缘节点呢？每个边缘节点（在此情况下即边缘簇）都在其所有者组织下向交换平台注册。注册信息包括一个仅适用于该边缘簇的 ID 和安全令牌。在该边缘簇上运行一个自治代理进程，用于执行边缘簇所有者设定的策略。同时，自治协议机器人（autonomous agreement bots，简称 agbots）会被分配部署策略，将服务部署到这些边缘簇中。
以上描述了 IBM Edge Application Manager 产品中的步骤，该产品允许在边缘簇上通过 Kubernetes Operator 部署边缘服务，从而实现与边缘设备相同的自主部署机制。这意味着 Kubernetes 作为容器管理平台的全部功能均可供边缘服务使用。
产品知识中心中的此链接详细介绍了在边缘簇上安装边缘代理的步骤。之后，可以在该边缘簇上安装相关应用程序。您可能已经猜到，IEAM 支持 Kubernetes、K3s、MiniKube、Microk8s 和 Red Hat OpenShift。
这篇博客描述了在边缘部署簇所带来的独特商业价值 — 不一定是在最远端的边缘，而是在远程本地部署的边缘节点。重申一下，边缘节点簇功能帮助您管理和部署从管理中心簇到 OCP 或其他基于 Kubernetes 的远程实例的工作量。
边缘簇支持边缘用例，这些用例需要将计算与业务运营放在一起，或者需要比边缘设备所能支持的更高的可扩展性、可用性和功能。此外，由于边缘簇非常接近边缘设备，因此提供支持边缘设备上运行的服务所需的应用程序并不罕见。
有一种较新的开源容器管理工具，可用于开发、管理和运行开放容器倡议 (OCI) 容器。它名为 Podman（Pod Manager 的缩写），是一个非常适合边缘簇的选项。Podman 作为 libpod 库的一部分提供，可用于创建和维护容器。虽然它可以运行 Docker 容器，但目前它只在基于 Linux 的操作系统上运行。您可以在此处了解更多关于 Podman 的信息。
IBM Cloud 架构中心提供了许多混合云和多云参考架构。
您还可以查看新发布的汽车领域边缘相关参考架构。
特别感谢 Joe Pearson 和 David Booz 对本文的审阅。
请务必查看有关边缘计算的系列博客文章中的其他部分：