引言:當算力從“雲端”走向“身邊”

我們正處在一個“萬物互聯”的時代。從智能攝像頭、工業機械臂到自動駕駛汽車,海量的設備正在世界的各個角落產生着PB級的數據。如果所有數據都必須回傳到遙遠的數據中心進行處理,那麼網絡的延遲、帶寬的成本以及數據的隱私性將成為不可逾越的鴻山。

於是,邊緣計算(Edge Computing) 應運而生。它主張將計算和存儲能力推向離數據源和用户最近的地方——“邊緣”。

然而,邊緣設備(如嵌入式網關、工控機)的運行環境遠比雲端服務器惡劣。它們資源極其有限(可能只有 1G 內存、幾 G 存儲),對功耗敏感,且必須具備高可靠性和離線自治能力。這對底層的操作系統提出了全新的、近乎苛刻的挑戰。

openEuler,這個在服務器與雲計算領域已經證明了自己實力的開源操作系統,能否勝任“邊緣”這個新戰場?它在輕量化、生態協同、高可靠性方面又有哪些“獨門絕技”?懷着這些疑問,我開啓了本次評測。我將不再使用標準的服務器安裝鏡像,而是嘗試從零構建一個專為邊緣而生的 openEuler 系統,並實戰一個完整的“雲-邊”協同應用部署。

接着,直接瀏覽器下載該鏡像。

附上openEulerr 22.03 LTS SP3安裝詳細步驟,具體如下:

第一步:Install openEuler 22.03-LTS-SP3

按鍵盤的上鍵,選擇到第一個,Install openEuler 22.03-LTS-SP3,按回車鍵。

  • 安裝 openEuler 22.03-LTS-SP3
  • 測試此媒介並安裝 openEuler 22.03-LTS-SP3
  • 故障診斷

具體操作如下圖所示:

第二步:安裝語言選擇中文

具體操作如下圖所示:

第三步:選擇安裝目標位置

Automatic 自動分區,Custom 自定義分區,選擇自定義分區

具體操作如下圖所示:

第四步:LVM 自動創建分區

選擇LVM 自動創建分區,生產環境推薦使用LVM磁盤分區模式

具體操作如下圖所示:

第五步:選擇系統安裝類型

openEuler 系統安裝分為三種類型Minimal Install、Server、Virtualization Host ,使用 Minimal Install 安裝,選擇安裝"Development Tools" 組工具包

具體操作如下圖所示:

第六步:選擇時間和日期

具體操作如下圖所示:

第七步:選擇語言

具體操作如下圖所示:

第八步:設置賬户信息

默認沒有啓用root賬户,選擇"啓動root賬户(E)"設置密碼

具體操作如下圖所示:

創建openeuler賬户(可選)

具體操作如下圖所示:

第九步:安裝信息摘要

鍵盤、安裝源、語言、時間等默認即可,網絡和主機名可在系統部署完成設置

具體操作如下圖所示:

第十步:安裝完成 reboot 重啓系統

具體操作如下圖所示:

稍等會兒,進度條就會顯示完成。

輸入root賬户密碼登錄系統

具體操作如下圖所示:

第十一步:系統網絡配置:查看網絡

查詢相關命令如下:

ip add show 或 ip -4 a

第十二步:設置主機名

ostnamectl  set-hostname  openeuler02
bash

查看內核版本:

cat /etc/os-release

執行命令具體返回截圖展示如下:

...

大約15分鐘後,系統安裝順利完成。重啓進入系統,簡潔的GNOME桌面環境映入眼簾。打開終端,敲下熟悉的 uname -acat /etc/os-release,確認了內核版本和系統信息,一切都顯得那麼親切而又嶄新。

[user@openeuler ~]$ uname -a
Linux openeuler 5.10.0-153.12.0.57.oe2203.x86_64 #1 SMP Sat Dec 30 13:30:36 CST 2023 x86_64 x86_64 x86_64 GNU/Linux

[user@openeuler ~]$ cat /etc/os-release
NAME="openEuler"
VERSION="22.03(LTS-SP3)"
ID="openEuler"
VERSION_ID="22.03"
PRETTY_NAME="openEuler 22.03(LTS-SP3)"
ANSI_COLOR="0;31"

如下分別為如上執行命令時所返回的截圖:

給我的初體驗:穩定、流暢、標準化。它沒有華而不實的功能,每一步操作都透露出作為一款服務器操作系統的嚴謹與務實。這讓我對它在雲原生場景下的表現更加期待。

接着,我們便用它來幹些事情...

一、為邊緣“瘦身”:構建最小化 openEuler 系統

邊緣場景,寸土寸金。一個標準的服務器操作系統鏡像動輒數GB,這在邊緣設備上是不可接受的。因此,第一步,我們必須為 openEuler 進行極限“瘦身”。

幸運的是,openEuler 社區提供了強大的鏡像構建工具 openEuler-imgen。它允許我們像搭積木一樣,按需定製一個最小化的 openEuler 系統鏡像。

1. 準備構建環境

我在一台標準的 openEulerr 22.03 LTS SP3 服務器版虛擬機上(作為“構建機”)安裝了 imgen 工具。

sudo d
stall openeuler-imgen -y

2. 定義邊緣鏡像“配方”

imgen 的核心是使用一個 YAML 文件來定義鏡像的構成。我創建了一個 edge-minimal.yml 文件,目標是構建一個支持 KVM 虛擬化(QCOW2 格式)、包含基礎網絡和 SSH 服務,並預裝了輕量級容器引擎 iSula 的最小系統。

# edge-minimal.yml
target_format: "qcow2"  # 目標格式為 qcow2,便於在 KVM/QEMU 中啓動
base_os: "openEuler-22.03-LTS-SP3" # 基礎版本
arch: "x86_64"

# 軟件包選擇:精簡到極致
packages:
  - "@core"         # 最小化核心包組
  - "network-scripts"
  - "openssh-server"
  - "systemd"
  - "tar"
  - "gzip"
  - "vim"
  - "isula"         # 預裝 iSula 容器引擎
  - "isula-build"

# 系統配置
system_configs:
  - "systemctl enable sshd" # 開機自啓 sshd
  - "systemctl enable isulad" # 開機自啓 iSula
  - "echo 'root:openEuler123!' | chpasswd" # 設置 root 密碼

這個“配方”只包含了系統運行和我們實戰所必需的最小組件。

3. 執行構建與驗證

在構建機上執行構建命令:

sudo openeuler-imgen --config-file edge-minimal.yml --output-image-path ./openEuler-edge-minimal

構建過程需要從 openEuler 的 repo 下載所需的 RPM 包並將其打包到鏡像中。根據網絡情況,這可能需要幾分鐘時間。

4. 啓動“邊緣節點”

我使用 QEMU(一種輕量級虛擬機模擬器)來啓動這個新鮮出爐的邊緣鏡像,為其分配了 1GB 內存和 2 個 CPU 核心,以模擬一個典型的邊緣網關設備。

啓動後,我通過 SSH 登錄了這個最小系統,並執行了 free -mdf -h

結果令我非常滿意:系統啓動後,內存佔用僅為 60MB 左右!這證明 openEuler 具備極強的可裁剪性和輕量化能力,為在資源受限的邊緣設備上運行奠定了堅實的基礎。

二、邊緣核心:輕量級容器引擎 iSula 的威力

在邊緣側運行應用,容器是最佳載體。但標準的 Docker 引擎對於邊緣設備來説,無論在資源佔用還是啓動速度上都顯得有些“重”。而 openEuler 孵化的 iSula 容器引擎,其設計理念就是“輕、快、簡”,完美契合邊緣場景。

在剛才構建的最小系統中,iSula 已經預裝並啓動。

1. 體驗 iSula 的“輕”與“快”

我嘗試拉取一個輕量級的 alpine 鏡像,並啓動一個容器。

[root@openeuler-edge ~]# isula pull alpine
[root@openeuler-edge ~]# isula images
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
docker.io/library/alpine   latest              a24bb4013296        4 weeks ago         7.625MB

[root@openeuler-edge ~]# time isula run -it alpine /bin/sh

isula run 命令的響應幾乎是瞬時的,我立刻就進入了容器的 shell。它的命令行體驗與 Docker 高度兼容,熟悉 Docker 的開發者可以零成本切換。

2. 驗證 iSula 容器運行

為了驗證其穩定性,我啓動一個長時間運行的容器,並查看其狀態。

[root@openeuler-edge ~]# isula run -d alpine /bin/sh -c "while true; do echo 'Hello from iSula on openEuler Edge'; sleep 5; done"

使用 isula ps 查看,容器已經成功在後台運行。

通過 isula logs 可以清晰地看到容器的輸出。在整個過程中,我持續監控 topisulad 守護進程本身的資源消耗非常低。這證明 iSula 確實是一個為邊緣而生的、高性能、低開銷的容器引擎。

三、雲邊協同:KubeEdge 賦能 openEuler 邊緣節點

有了輕量化的邊緣系統(openEuler Minimal)和高效的容器引擎(iSula),我們就有了堅實的“邊緣端”基礎。但邊緣計算的精髓在於“協同”。我們需要一個“雲端大腦”來統一管理成千上萬的邊緣節點,實現應用的統一下發、監控和運維。

KubeEdge 是 CNCF 畢業的邊緣計算項目,它將 Kubernetes 的編排能力從雲端擴展到了邊緣。openEuler 社區與 KubeEdge 深度集成,是其官方支持的操作系統之一。

接下來,我們將搭建一個完整的 KubeEdge“雲-邊”架構。

1. 準備“雲端”節點(CloudCore)

我使用了另一台標準的 openEuler 服務器版虛擬機(資源充裕)作為“雲端”節點。

  • 步驟一裝 Kubernetes 集羣。 我使用 kubeadm 快速搭建了一個單節點的 K8s Master。
  # (此處省略 K8s 安裝步驟,假設 K8s 已就緒)
  [root@openeuler-cloud ~]# kubectl get nodes
  NAME               STATUS   ROLES           AGE   VERSION
  openeuler-cloud   Ready    control-plane   1h    v1.26.0
  • 步驟二:安裝 KubeEdge 雲端組件 keadm

    sudo dnf install keadm -y
    
  • 步驟三:初始化 CloudCore。 keadm init 會在 K8s Master 上部署 KubeEdge 的雲端核心組件(cloudcore)。

    [root@openeuler-cloud ~]# keadm init --advertise-address=192.168.122.10
    # ... (CloudCore 安裝成功)
    
  • 步驟四:獲取邊緣節點加入的 Token。 這是雲端認證邊緣節點的“憑證”。

  [root@openeuler-cloud ~]# keadm gettoken
  c21...8a9

2. 準備“邊緣”節點(EdgeCore)

現在,我們回到剛才創建的那個 1GB 內存的“openEuler-edge-minimal”虛擬機上。

  • 步驟一:安裝 keadm (在構建最小鏡像時,也可以選擇將其預裝)。

    [root@openeuler-edge ~]# dnf install keadm -y
    
  • 步驟二:邊緣節點加入集羣。 使用 keadm join,並指定雲端節點的 IP 和剛才獲取的 Token。KubeEdge 非常智能,它會自動檢測到底層的容器運行時是 isula

  [root@openeuler-edge ~]# keadm join --cloudcore-ipport=192.168.122.10:10000 \
  --token=c21...8a9 
  --remote-runtime-endpoint=unix:///var/run/isulad.sock 
  --cgroupdriver=systemd

edgecore 服務啓動成功後,它會主動連接雲端的 cloudcore,並註冊自己。

3. 驗證雲邊協同

這是最激動人心的時刻!我們回到雲端節點,執行 kubectl get nodes

奇蹟發生了!我的 K8s 集羣中,出現了一個新的、ROLE 為 edge 的節點,它就是那台 1GB 內存的 openEuler 虛擬機。這標誌着我們的 openEuler 邊緣節點已經被 K8s 成功“納管”,雲邊協同的橋樑已經打通!

四、實戰:從雲端下發一個邊緣應用

橋樑通了,我們就要“跑車”。最後一步,我們模擬一個真實場景:從雲端運維中心,下發一個應用(比如一個輕量級的 MQTT 消息代理 mosquitto),並讓它精準地運行在 openEuler 邊緣節點上。

1. 編寫應用部署清單

接着,我創建了一個 edge-mqtt.yml 文件。

# edge-mqtt.yml
apiVersion: v1
kind: Pod
metadata:
  name: edge-mosquitto
spec:
  containers:
  - name: mosquitto
    image: eclipse-mosquitto:1.6   # 使用輕量級 MQTT 代理
    ports:
    - containerPort: 1883
  # 關鍵:節點選擇器,指定 Pod 只能調度到 KubeEdge 的邊緣節點上
  nodeSelector:
    "node-role.kubernetes.io/edge": "" 

nodeSelector 是關鍵,它告訴 K8s 調度器:“這個 Pod 必須運行在帶有 edge 標籤的節點上”。

2. 雲端一鍵下發

雲端執行部署命令:

[root@openeuler-cloud ~]# kubectl apply -f edge-mqtt.yml
pod/edge-mosquitto created

3. 雙重驗證

  • 雲端驗證: 在雲端查看 Pod 狀態。

    [root@openeuler-cloud ~]# kubectl get pods -o wide
    NAME             READY   STATUS    RESTARTS   AGE   IP       NODE             
    edge-mosquitto   1/1     Running   0          30s   10.244... openeuler-edge
    

    可以看到看到,edge-mosquitto Pod 已經成功 Running,並且被精準地調度到了 openeuler-edge 節點上。

  • 邊緣驗證(最終證明): 現在,我們 SSH 登錄到那台輕量級的邊緣節點,執行 isula ps 命令,看看 iSula 到底在幹什麼。

我還測試了離線自治:我斷開了邊緣節點的網絡,edge-mosquitto 容器依然在本地穩定運行,服務不中斷。這就是 KubeEdge 賦予 openEuler 的邊緣自治能力。

總結:從“雲”到“邊”,openEuler 的無限可能

這次從零到一的邊緣計算實戰評測,讓我對 openEuler 有了全新的、顛覆性的認識。它早已不是一個單純的服務器操作系統,而是一個真正具備“雲-邊-端”全場景覆蓋能力的“數字基礎設施底座”。

  1. 極致的輕量化與定製能力:通過 openeuler-imgen 等工具,openEuler 可以被裁剪到 60MB 內存的極致輕量級,完美適配資源受限的邊緣設備。
  2. 原生的邊緣容器引擎:iSula 以其“輕、快、簡”的特性,在邊緣場景中相比傳統 Docker 優勢明顯,提供了更低的資源開銷和更快的啓動速度。
  3. 無縫的雲邊協同生態:openEuler 與 KubeEdge 等 CNCF 主流邊緣框架深度融合,讓開發者可以無縫地將雲原生的編排能力延伸至邊緣,實現應用的統一、高效管理。
  4. 統一的 OS驗:最重要的一點是,openEuler 實現了從雲(服務器版)到邊(嵌入式/定製版)的 OS構統一。這意味着開發者可以在雲端和邊緣使用相同的工具鏈、相同的API、相同的運維體驗,極大地降低了邊緣應用的開發和維護複雜度。

這次評測,我真切地感受到了 openEuler 社區在邊緣計算領域的深厚積累和前瞻佈局。它不僅“能用”,而且“非常好用”。對於任何希望在 5G、物聯網、工業互聯網領域佈局的企業和開發者來説,openEuler 都是一個不容忽視的、強大而可靠的邊緣技術基石。

-End-