边缘计算架构_Openshift为边缘计算提供三节点架构部署

首页 > 边缘计算架构_Openshift为边缘计算提供三节点架构部署

边缘计算架构_Openshift为边缘计算提供三节点架构部署

当一个IT组织开始走到需要实施网络边缘的旅程时，他们很快意识到面对的挑战与他们在传统数据中心内所经历的挑战不同。

第一个挑战是空间。与更大的核心或区域数据中心同类产品相比，许多边缘站点的物理尺寸更小，因此，需要仔细计划好，尝试在未为其专门设计的空间中安装硬件。
第二个挑战是运行环境。还必须解决的可能面对的冷热温度变化，天气，无线电辐射，缺乏外围设备安全性以及设备可靠电源和冷却设备供应有限等问题。
第三个挑战是远程的网络连接，连接质量可能变化很大，并且通常很慢或不可靠。

在这些挑战中，最有影响力的挑战可能是现场IT人员很少甚至没有IT能力。这就需要采用最少干预或专有技术的集中式部署，再加上集中式管理，以确保为工作负载提供一致的环境，而不管它们是部署在数据中心内还是部署在远程边缘位置。

例如，在工厂中部署集群以处理数据聚合和机器学习分析时，我们需要在恶劣环境中建立集群，在该环境中，由于不能由于连接问题而中断生产。我们还需要在计划外的情况下添加新硬件，同时保持完整的高可用性功能。这就要求我们构建尽可能小的群集，以提供本地控制平面，本地存储和计算，以满足要求苛刻的AI / ML或大数据工作负载的需求，同时确保工作连续性。

现在，想象将这些需求放在石油钻塔，卫星，空间站或紧急情况下，在这些情况下，空间，重量，电力预算和网络需求受到更加严重的限制。

在上述所有情况下，我们必须：

提供真正的高可用性。
无论WAN连接状态如何，都可以继续稳定运行。
将其部署限制到最小的占用空间中。
节省大量成本。

因此，我们重新设计了Red Hat OpenShift的各个部分，以减少提供完全自动化集群所需的最少机器数量。通过允许OpenShift定义同时具有主管和辅助角色的节点，我们将最低配置从五台减少到三台服务器。从OpenShift 4.5开始全面支持，这种较小的占用空间将很快具有OpenShift容器存储(OCS)支持，以在超融合配置中的同一服务器上提供Ceph存储集群的配置，从而消除了网络上的离散存储占用空间，进而消除了降低采购成本和持续运营成本。

尽管我们在这些部署中看到的大多数目标工作负载现在都是基于容器的，但我们确实经常看到其中一些依赖虚拟机。在这里，基于KubeVirt项目的OpenShift虚拟化(也完全受OpenShift 4.5支持)变得非常重要。通过使用Kubernetes引入对VM的管理，可以在单个平台上简化您的工具集。无需添加其他API即可维护虚拟化基础架构。只要您在物理硬件上部署紧凑型集群，就可以通过Kubernetes API进行虚拟化。

运行三节点OpenShift Compact集群

三节点设置(称为紧凑型群集)的最低要求如下：

3台物理机(我们计划很快在虚拟机中支持此设置)
基本操作系统：Red Hat Enterprise Linux CoreOS
6个CPU
24GB RAM
120GB磁盘空间

当然，这些最低要求将需要适应打算在这些计算机上托管的工作负载，但它们仅是指导下的最低规范。

为了实施您的部署，您将需要执行以下准备步骤：

1：先决条件

紧凑型群集的前提条件与标准OpenShift安装相同。这些先决条件包括但不限于以下条件：

确保网络连接准备到位。
为API和Ingress设置或安装外部负载平衡器。
群集的DNS条目准备到位。
您可能需要Openshift CLI工具。
DHCP地址保留或使用静态IP。

请熟悉官方文档，以获取有关所有先决条件的更多信息。

需要注意的一件事是，对引导节点的要求仍然适用。因此，在计划安装三节点群集时，您将需要临时考虑第四个节点。安装完成后，可以删除引导程序。

引导节点是临时的，并且可以是在您的环境中运行的VM或便携式计算机上的VM，只要对引导节点具有适当的先决条件(例如DNS，网络连接等)即可。

还要注意的另一点是，API负载平衡器和Ingress负载平衡器的端点应指向所有节点的IP。

2：设置

暂存环境并满足先决条件后，现在可以创建install-config.yaml文件。该文件与标准安装相同，但工作副本数设置为0。

这是一个例子：

apiVersion: v1baseDomain: example.comcompute:- hyperthreading: Enabled  name: worker  replicas: 0controlPlane:  hyperthreading: Enabled  name: master  replicas: 3metadata:  name: ocp4networking:  clusterNetwork:  - cidr: 10.128.0.0/14    hostPrefix: 23  networkType: OpenShiftSDN  serviceNetwork:  - 172.30.0.0/16platform:  none: {}fips: falsepullSecret: '{"auths": ...}'sshKey: 'ssh-ed25519 AAAA...'

一旦你创建了安装-config.yaml文件，运行openshift安装创造体现在同一目录命令作为安装-config.yaml文件。您将看到以下输出：

$ openshift-install create manifestsINFO Consuming Install Config from target directoryWARNING Making control-plane schedulable by setting MastersSchedulable to true for Scheduler cluster settings

请注意有关将Master节点标记为可调度的标签。此消息表明您将安装一个三节点群集，其中主节点也将充当工作节点。通过查看调度清单来验证这一点。

$ cat manifests/cluster-scheduler-02-config.ymlapiVersion: config.openshift.io/v1kind: Schedulermetadata:  creationTimestamp: null  name: clusterspec:  mastersSchedulable: true    policy:name: ""status: {}

3：安装

此时，安装将继续正常进行。您应遵循官方文档页面上的其余安装说明。下一步是创建点火文件，并在所有主节点和引导节点上安装Red Hat Enterprise Linux CoreOS。

从设置到持续管理

但是，建立现场集群并不是故事的结局，因为能够管理它们的机群将至关重要，特别是如果没有IT专家会在现场进行管理的话。

我们的第一个建议是尽一切可能在整个部署中维护相同的配置。这通常意味着通常禁止在服务器上进行手动配置更改，以确保一致性并减少潜在的错误。远程连接或OpenShift Web控制台的使用应仅限于调试，并且任何配置更改都应链接到集中式过程，就像处理代码一样。这是通常所谓的GitOps的基础，并使用诸如ArgoCD的专用工具是确保对车队进行正确配置管理的可能途径之一。但是，由于您还需要一种集中状态，基于策略部署工作负载以及执行所有类型的集中管理任务的方法，因此我们也提供了一种工具来完成此任务。8月初发布的用于Kubernetes的红帽高级集群管理(又名ACM)已经过测试，可以处理数千个集群，并且包括GitOps工具，可用于构建基于策略的集群管理。ACM应该部署在所有边缘群集都可以连接到的中央位置的群集上。

最后，您的某些工作负载可能需要提供一种机制，以将新数据传递到其处理单元，例如用于机器学习推理过程的新模型。