订阅内容

The cloud native approach to developing and deploying applications is increasingly being adopted in the context of edge computing. However, edge workloads and use cases span a myriad of locations, technical requirements, and physical footprints. 

At Red Hat, we are seeing an emerging pattern in which some infrastructure providers and application owners want a consistent workload life cycle approach across the business. This includes their on-premises, hybrid/multicloud, and edge architectures as well as continuous operations and management of sites that might have intermittent or very low bandwidth connectivity back to a central site.

红帽被评为 2023 年 Gartner® 魔力象限™ 领导者

在 2023 年 Gartner 魔力象限容器管理评选中,红帽被评为最具执行能力和最具远见的品牌。

For example, think of locations such as cruise ships that spend some of their time docked and directly connected to a regional data center, while other times they are out at sea with a slow, high-latency satellite connection. 

We also observed that in these remote locations, as the distance between an edge site and the central management hub grows, the physical space for systems decreases. This means these edge locations operate with very limited space as well as power and cooling, creating an environment suited for a single server. 

Introducing Red Hat OpenShift in a single node 

Until today the smallest supported cluster size (including control and worker nodes) was the three node cluster. As of OpenShift 4.9, we now have a full OpenShift deployment in a single node. This fully supported topology joins the three node cluster and remote worker topologies to offer three options to meet more customer requirements in more edge environments. Single node OpenShift offers both control and worker node capabilities in a single server and provides users with a consistent experience across the sites where OpenShift is deployed, regardless of the size of the deployment.

Because a single node offers both control and worker node functionality, users who have adopted Kubernetes at their central management sites and who wish to have independent Kubernetes clusters at edge sites can deploy this smaller OpenShift footprint and have minimal to no dependence on the centralized management cluster and can run autonomously when needed.

Just like multi node OpenShift, the single node deployment extends the OpenShift experience, taking advantage of the same skills and tools and bringing consistent upgrades and life cycle management throughout the container stack, including the operating system, feature-rich Kubernetes (including cluster services), and applications.

Keep in mind a single node OpenShift deployment differs from the default self-managed/highly-available cluster profile in couple of ways:

  • To optimize system resource usage, many operators are configured to reduce the footprint of their operands when running on a single node OpenShift.

  • In environments that require high availability, it is recommended that the architecture be configured in a way in which if the hardware was to fail, those workloads are transitioned to other sites or nodes while the impacted node is recovered. 

Think cell towers, not data centers

Single node OpenShift focuses on reducing the prerequisites for OpenShift deployment on bare metal nodes, bringing the barrier to entry down to a minimum, further simplifying and streamlining the deployment experience of OpenShift. This is especially useful when deploying environments that need to occupy the absolute smallest footprint and have minimum external requirements.

One example of this use case is seen in telecommunication service providers' implementation of a Radio Access Network (RAN) as part of a 5G mobile network.
In the context of telecommunications service providers' 5G RANs, it is increasingly common to see "cloud native" implementations of the 5G Distributed Unit (DU) components. Due to latency constraints, the DU needs to be deployed very close to the Radio Units (RUs), for which it is responsible. In practice, this can mean running the DU on anything from a single server at the base of a cell tower to a more datacenter-like environment serving several RUs.

A typical DU example is a resource-intensive workload, requiring 6 dedicated cores per DU and several DUs packed on the server, with 16-24 GB of RAM per DU (consumed as huge pages), multiple single route I/O virtualization (SR-IOV) NICs, FPGA, or GPU acceleration cards  carrying several Gbps of traffic each.

One crucial detail of this use case is ensuring that this workload can be "autonomous" so that it can continue operating with its existing configuration, even when any centralized management functionality is unavailable. This is where single node OpenShift comes in.

Seeing it in action

If you would like to get your own single node OpenShift deployment, you are more than welcome to do. We have a blog that walks you through the installation step-by-step.


关于作者

Moran Goldboim joined Red Hat in 2010 and is now a Senior Principal Product Manager.

Read full bio

Eran Cohen joined Red Hat in January 2020. He is a software developer with a passion for infrastructure and technology and has expertise in design, prototype, and execution. He is currently focused on the OpenShift Assisted Installer and Single Node OpenShift.

Read full bio

按频道浏览

automation icon

自动化

有关技术、团队和环境 IT 自动化的最新信息

AI icon

人工智能

平台更新使客户可以在任何地方运行人工智能工作负载

open hybrid cloud icon

开放混合云

了解我们如何利用混合云构建更灵活的未来

security icon

安全防护

有关我们如何跨环境和技术减少风险的最新信息

edge icon

边缘计算

简化边缘运维的平台更新

Infrastructure icon

基础架构

全球领先企业 Linux 平台的最新动态

application development icon

应用领域

我们针对最严峻的应用挑战的解决方案

Original series icon

原创节目

关于企业技术领域的创客和领导者们有趣的故事