跳至主要内容

主機管理

使用者可以從主機頁面檢視和管理 Harvester 節點。第一個節點總是預設為叢集的管理節點。當有三個或更多節點時,最先加入的另外兩個節點會自動晉升為管理節點,以形成 HA (高可用性) 叢集。

備註

由於 Harvester 建立在 Kubernetes 之上並使用 etcd 作為其資料庫,當有三個管理節點時,最大節點故障容許度為一個。

host.png

資訊

Harvester 在每個節點上保留 CPU 資源用於系統級操作。如需更多資訊,請參閱 共享 CPU 集區的計算。這就是 CPU 欄位上顯示的總核心數略少於每個節點實際 CPU 核心數的原因。

節點維護 (Node Maintenance)​

管理員使用者可以啟用維護模式(選取 ⋮ > Enable Maintenance Mode)以自動從節點驅逐 (evict) 所有虛擬機器。此模式利用 批次移轉 將 可線上移轉的虛擬機器 移動到其他節點,這在您需要重新啟動、升級韌體或更換硬體元件時非常有用。至少需要兩個活動節點才能使用此功能。

不可移轉的虛擬機器 可能會阻止節點啟動維護模式。發生這種情況時,您必須識別並手動關閉這些虛擬機器。如需更多資訊,請參閱 線上移轉 (Live Migration)。

如果您想強制個別 VM 關機而不是移轉到其他節點,請為這些 VM 新增標籤 harvesterhci.io/maintain-mode-strategy 以及以下值之一:

  • Migrate: 將 VM 線上移轉到叢集中的另一個節點。如果未設定標籤 harvesterhci.io/maintain-mode-strategy,這是預設行為。
  • ShutdownAndRestartAfterEnable: 節點切換到維護模式後重新啟動 VM。VM 將被調度到不同的節點上。
  • ShutdownAndRestartAfterDisable: 啟用維護模式時關閉 VM,並在停用維護模式時重新啟動 VM。VM 留在同一個節點上。
  • Shutdown: 啟用維護模式時關閉 VM。VM 保持關機狀態,不會重新啟動。

您可以在 Enable Maintenance Mode (啟用維護模式) 畫面上強制集體關閉節點上的所有 VM。這將停用使用 harvesterhci.io/maintain-mode-strategy 標籤的個別設定。

如果您想在關閉 VM 之前執行特殊指令,請考慮使用 容器生命週期掛鉤 (container lifecycle hook) PreStop。

node-maintenance.png

封鎖節點 (Cordoning a Node)​

封鎖的節點標記為不可調度 (unschedulable)。當您想防止新工作負載被調度到某個節點上時,封鎖非常有用。您可以解封 (uncordon) 節點使其再次可供調度。

cordon-node.png

刪除節點 (Deleting a Node)​

警告

在從 Harvester 叢集中移除節點之前,請確定其餘節點是否有足夠的運算和儲存資源來接管要移除節點的工作負載。請檢查以下項目:

  • 叢集目前的資源使用量(在 Harvester UI 的 Hosts 畫面上)
  • 其餘節點為所有卷冊維持足夠複本的能力

如果其餘節點沒有足夠的資源,當您移除節點時,VM 可能會移轉失敗,卷冊可能會降級。

1. 檢查節點是否可以從叢集中移除。​

您可以根據叢集中其他節點的數量和可用性,安全地移除控制平面節點。

  • 叢集有三個控制平面節點和一個或多個工作節點。

    當您移除控制平面節點時,工作節點將被晉升為控制平面節點。Harvester v1.3.0 允許您為每個加入叢集的節點指派角色。在較早的 Harvester 版本中,工作節點是隨機選取進行晉升的。如果您偏好晉升特定節點,請參閱 角色管理 和 Harvester 設定 以取得更多資訊。

    備註

    自動節點晉升僅在從叢集中刪除控制平面節點時發生。這不包括因健康檢查失敗而導致節點不可用的情況。不健康的節點會保留其角色。

  • 叢集有三個控制平面節點且沒有工作節點。

    在移除控制平面節點之前,您必須向叢集新增一個新節點。這確保叢集始終有三個控制平面節點,即使一個控制平面節點故障也能形成法定人數 (quorum)。

  • 叢集只有兩個控制平面節點且沒有工作節點。

    不建議在這種情況下移除控制平面節點,因為 etcd 資料在單節點叢集中不會被複製。單一節點故障可能會導致 etcd 失去法定人數並關閉叢集。

2. 檢查卷冊狀態。​

  1. 存取 嵌入式 Longhorn UI。

  2. 前往 Volume (卷冊) 畫面。

  3. 驗證所有卷冊的狀態均為 Healthy (健康)。

3. 從要移除的節點驅逐複本。​

  1. 存取 嵌入式 Longhorn UI。

  2. 前往 Node (節點) 畫面。

  3. 選取要移除的節點,點擊 Operation (操作) 欄中的圖示,然後選取 Edit node and disks (編輯節點和磁碟)。

  4. 配置以下設定:

    • Node Scheduling (節點調度): 選取 Disable (停用)。
    • Evict Requested (請求驅逐): 選取 True。
  5. 點擊 Save (儲存)。

  6. 返回 Node 畫面,驗證要移除的節點的 Replicas (複本) 值為 0。

important

如果其餘節點無法接受來自要移除節點的複本,則無法完成驅逐。在這種情況下,某些卷冊將保持在 Degraded (降級) 狀態,直到您向叢集新增更多節點。

4. 管理不可移轉的虛擬機器。​

檢查是否有任何 不可移轉的虛擬機器。

提示
  • 為每個不可移轉的虛擬機器建立備份或快照。
  • 盡可能變更虛擬機器以讓它們在其他節點上執行。
  • 手動停止其餘的不可移轉虛擬機器。

5. 從要移除的節點驅逐工作負載。​

如果您的叢集執行的是 Harvester v1.1.2 或更高版本,您可以在節點上啟用 維護模式 以自動線上移轉 VM 和工作負載。您也可以 手動線上移轉 VM 到其他節點。

如果節點狀態為 Maintenance (維護),則所有工作負載已成功驅逐。

node-maintain-completed.png

important

如果叢集只有兩個控制平面節點,Harvester 不允許您在任何節點上啟用維護模式。您可以使用以下指令手動排空 (drain) 要移除的節點:

kubectl drain <node_name> --force --ignore-daemonsets --delete-local-data --pod-selector='app!=csi-attacher,app!=csi-provisioner'

再次強調,不建議在這種情況下移除控制平面節點,因為 etcd 資料不會被複製。單一節點故障可能會導致 etcd 失去法定人數並關閉叢集。

6. 刪除 RKE2 服務並關閉節點。​

  1. 使用 root 帳戶登入節點。

  2. 執行腳本 /opt/rke2/bin/rke2-uninstall.sh 以刪除節點上執行的 RKE2 服務。

  3. 關閉節點。

備註

有一個關於節點強制刪除的 已知問題。 問題解決後,您可以跳過此步驟。

7. 移除節點。​

  1. 在 Harvester UI 上,前往 Hosts 畫面。

  2. 找到您想要移除的節點,然後點擊 ⋮ > Delete (刪除)。

delete.png

角色管理 (Role Management)​

硬體問題可能會迫使您更換管理節點。在較早的 Harvester 版本中,準確地將特定的工作節點晉升為管理節點並不容易。Harvester v1.3.0 透過引入以下角色改進了此流程:

  • Management (管理):允許節點在 Harvester 晉升節點為管理節點時獲得優先權。
  • Witness (見證):限制節點在特定叢集中作為見證節點(僅作為 etcd 節點運作)。
  • Worker (工作):限制節點在特定叢集中作為工作節點(永不晉升為管理節點)。
警告

Harvester 目前僅允許叢集中有一個見證節點。

有關將角色指派給節點的更多資訊,請參閱 ISO 安裝。

多磁碟管理 (Multi-disk Management)​

新增額外磁碟​

使用者可以從編輯主機頁面檢視和新增多個磁碟作為額外資料卷冊。

  1. 前往 Hosts 頁面。
  2. 在您想要修改的節點上,點擊 ⋮ > Edit Config。

Edit Config

  1. 選取 Storage 頁籤並點擊 Add Disk (新增磁碟)。

Add Disks

警告

自 Harvester v1.0.2 起,我們不再支援將分割區作為額外磁碟新增。如果您想將其作為額外磁碟新增,請務必先刪除所有分割區(例如,使用 fdisk)。

  1. 為磁碟選取供應程式 (Provisioner)。
  • LonghornV1 (CSI):這是預設供應程式。

    Provisioner LonghornV1

    如果區塊裝置從未被強制格式化過,您必須將 Force Formatted (強制格式化) 設定為 Yes。

    Force Format

  • LonghornV2 (CSI):如果您想使用 Longhorn V2 資料引擎,請選取此供應程式。

    Provisioner LonghornV2

  • LVM:如果您想使用 本地儲存 為您的工作負載建立持久性卷冊,請選取此供應程式。

    Provisioner LVM

  1. 點擊 Save。

  2. 在主機詳細資訊畫面上,驗證磁碟是否已新增且設定了正確的供應程式。

如果您希望 Longhorn 卷冊資料儲存在特定的節點或磁碟上,您也可以新增 儲存標籤 (storage tags)。儲存標籤只能與 LonghornV1 (CSI) 和 LonghornV2 (CSI) 供應程式一起使用。

disk tag 01

disk tag 02

備註

為了讓 Harvester 識別磁碟,每個磁碟都需要有唯一的 WWN。否則,Harvester 將拒絕新增磁碟。 如果您的磁碟沒有 WWN,您可以使用 EXT4 檔案系統格式化它,以協助 Harvester 識別磁碟。

備註

如果您在 QEMU 環境中測試 Harvester,您需要使用 QEMU v6.0 或更高版本。舊版本的 QEMU 總是會為 NVMe 磁碟模擬產生相同的 WWN。這將導致 Harvester 無法新增額外磁碟,如上所述。但是,您仍然可以使用 SCSI 控制器新增虛擬磁碟。WWN 資訊可以在磁碟掛接操作時手動新增。有關更多詳細資訊,請參考 腳本。

儲存標籤 (Storage Tags)​

儲存標籤功能僅啟用某些節點或磁碟用於儲存 Longhorn 卷冊資料。例如,效能敏感的資料可以只使用標記為 fast、ssd 或 nvme 的高效能磁碟,或只使用標記為 baremetal 的高效能節點。

此功能支援磁碟和節點。

設定​

可以透過 Harvester UI 在主機頁面上設定標籤:

  1. 點擊 Hosts -> Edit Config -> Storage
  2. 點擊 Add Host/Disk Tags (新增主機/磁碟標籤) 開始輸入並按下 Enter 鍵以新增標籤。
  3. 點擊 Save 以更新標籤。
  4. 在 StorageClasses 頁面上,建立一個新的 StorageClass 並在 Node Selector 和 Disk Selector 欄位選取這些定義的標籤。

節點或磁碟上現有的所有已調度卷冊將不受新標籤的影響。

備註

當為一個卷冊指定多個標籤時,磁碟和(磁碟所屬的)節點必須具有所有指定的標籤才能使用。

移除磁碟​

移除磁碟之前,您必須先驅逐磁碟上的 Longhorn 複本。

備註

複本資料將自動重建到另一個磁碟以保持高可用性。

識別要移除的磁碟 (Harvester 儀表板)​

  1. 前往 Hosts 頁面。
  2. 在包含該磁碟的節點上,選取節點名稱並前往 Storage 頁籤。
  3. 找到您想要移除的磁碟。假設我們想要移除 /dev/sdb,磁碟的掛載點是 /var/lib/harvester/extra-disks/1b805b97eb5aa724e6be30cbdb373d04。

Find disk to remove

驅逐複本 (Longhorn 儀表板)​

  1. 請遵循 此章節 啟用嵌入式 Longhorn 儀表板。
  2. 存取 Longhorn 儀表板並前往 Node 頁面。
  3. 展開包含該磁碟的節點。確認掛載點 /var/lib/harvester/extra-disks/1b805b97eb5aa724e6be30cbdb373d04 在磁碟清單中。

Check the removing disk

  1. 選取 Edit node and disks。

Edit node and disks

  1. 捲動到您想要移除的磁碟。
  • 將 Scheduling (調度) 設定為 Disable (停用)。
  • 將 Eviction Requested (請求驅逐) 設定為 True。
  • 選取 Save。不要選取刪除圖示。

Evict disk

  1. 磁碟將被停用。請等待直到磁碟複本數量變為 0 再繼續移除磁碟。

Wait replicas

移除磁碟 (Harvester 儀表板)​

  1. 前往 Hosts 頁面。
  2. 在包含該磁碟的節點上,選取 ⋮ > Edit Config。
  3. 前往 Storage 頁籤並選取 x 以移除磁碟。

Remove disk

  1. 選取 Save 以移除磁碟。

拓撲分佈限制 (Topology spread constraints)​

自 v1.1.0 版本起提供

節點標籤 (Node labels) 用於識別每個節點所在的拓撲網域。您可以在 Harvester UI 上設定諸如 topology.kubernetes.io/zone 的標籤。

  1. 前往 Hosts 畫面。
  2. 在清單中找到目標節點,然後選取 ⋮ > Edit Config。
  3. 在 Labels 頁籤上,點擊 Add Label (新增標籤),然後指定標籤 topology.kubernetes.io/zone 和一個值。
  4. 點擊 Save。

該標籤會自動與相應的 Longhorn 節點同步。

Ksmtuned 模式​

自 v1.1.0 版本起提供

Ksmtuned 是一個作為 DaemonSet 部署的 KSM 自動化工具,用於在每個節點上執行 Ksmtuned。它將透過監視可用記憶體百分比率(即 Threshold Coefficient (閾值係數))來啟動或停止 KSM。預設情況下,您需要在每個節點 UI 上手動啟用 Ksmtuned。您可以在 1-2 分鐘後從節點 UI 看到 KSM 統計資訊(查看 KSM 了解更多詳細資訊)。

快速執行​

  1. 前往 Hosts 頁面。
  2. 在您想要修改的節點上,點擊 ⋮ > Edit Config。
  3. 選取 Ksmtuned 頁籤並在 Run Strategy (執行策略) 中選取 Run (執行)。
  4. (選用) 您可以根據需要修改 Threshold Coefficient。

Edit Ksmtuned

  1. 點擊 Save 以更新。
  2. 等待約 1-2 分鐘,您可以透過點擊 Your Node > Ksmtuned tab 檢查其 Statistics (統計資訊)。

View Ksmtuned Statistics

參數​

Run Strategy (執行策略):

  • Stop (停止): 停止 Ksmtuned 和 KSM。VM 仍可使用共享記憶體頁面。
  • Run (執行): 執行 Ksmtuned。
  • Prune (修剪): 停止 Ksmtuned 並修剪 KSM 記憶體頁面。

Threshold Coefficient (閾值係數): 設定可用記憶體百分比率。如果可用記憶體小於閾值,KSM 將被啟動;否則,KSM 將被停止。

Merge Across Nodes (跨節點合併): 指定是否可以合併來自不同 NUMA 節點的頁面。

Mode (模式):

  • Standard (標準): 預設模式。控制節點 ksmd 使用大約 20% 的單個 CPU。它使用以下參數:
Boost: 0
Decay: 0
Maximum Pages: 100
Minimum Pages: 100
Sleep Time: 20
  • High-performance (高效能): 節點 ksmd 使用 20% 到 100% 的單個 CPU,具有更高的掃描和合併效率。它使用以下參數:
Boost: 200
Decay: 50
Maximum Pages: 10000
Minimum Pages: 100
Sleep Time: 20
  • Customized (自訂): 您可以自訂設定以達到您想要的效能。

Ksmtuned 使用以下參數來控制 KSM 效率:

參數 (Parameters)描述 (Description)
Boost如果可用記憶體小於 Threshold Coefficient,每次掃描的頁數增加量。
Decay如果可用記憶體大於 Threshold Coefficient,每次掃描的頁數減少量。
Maximum Pages每次掃描的最大頁數。
Minimum Pages每次掃描的最小頁數,也是第一次執行的設定。
Sleep Time (ms)兩次掃描之間的間隔,使用公式 (Sleep Time * 16 * 1024* 1024 / Total Memory) 計算。最小值:10ms。

例如,假設您有一個 512GiB 記憶體的節點使用以下參數:

Boost: 300
Decay: 100
Maximum Pages: 5000
Minimum Pages: 1000
Sleep Time: 50

當 Ksmtuned 啟動時,將 KSM 中的 pages_to_scan 初始化為 1000 (Minimum Pages) 並將 sleep_millisecs 設定為 10 (50 * 16 * 1024 * 1024 / 536870912 KiB < 10)。

當可用記憶體低於 Threshold Coefficient 時,KSM 啟動。如果偵測到它正在執行,pages_to_scan 每分鐘增加 300 (Boost),直到達到 5000 (Maximum Pages)。

當可用記憶體高於 Threshold Coefficient 時,KSM 將停止。如果偵測到它已停止,pages_to_scan 每分鐘減少 100 (Decay),直到達到 1000 (Minimum Pages)。

NTP 設定​

時間同步是分散式叢集架構的一個重要方面。因此,Harvester 現在提供了一種更簡單的方式來設定 NTP 設定。

在以前的 Harvester 版本中,NTP 設定主要可以在 安裝過程中 進行設定。若要修改設定,您需要手動更新每個節點上的設定檔。

從 v1.2.0 版本開始,Harvester 支援在 Harvester UI 設定畫面 (Advanced > Settings) 上進行 NTP 設定。您可以隨時為整個 Harvester 叢集設定 NTP 設定,並且這些設定會套用到叢集中的所有節點。

您可以一次設定多個 NTP 伺服器。

您可以在 Kubernetes 節點中的 node.harvesterhci.io/ntp-service 註解中檢查設定:

  • ntpSyncStatus: 連線到 NTP 伺服器的狀態(可能的值:disabled、synced 和 unsynced)
  • currentNtpServers: 現有 NTP 伺服器的清單
$ kubectl get nodes harvester-node-0 -o yaml |yq -e '.metadata.annotations.["node.harvesterhci.io/ntp-service"]'
{"ntpSyncStatus":"synced","currentNtpServers":"0.suse.pool.ntp.org 1.suse.pool.ntp.org"}

注意:

  1. 請勿修改每個節點上的 NTP 設定檔。Harvester 會自動將您在 Harvester UI 上設定的設定同步到節點。
  2. 如果您是從較早版本升級 Harvester,設定畫面上的 ntp-servers 清單將為空(見截圖)。您必須手動設定 NTP 設定,因為 Harvester 不知道以前的設定,也無法偵測衝突。

雲原生節點設定 (Cloud-Native Node Configuration)​

安裝 Harvester 後,您可能需要自訂一個或多個節點。此過程通常需要更新 執行階段設定 (runtime configuration) 並修改每個節點 /oem 目錄中的檔案,以使變更在重新啟動後持續存在。

在 Harvester v1.3.0 中,這些自訂可以在 Kubernetes 資訊清單 (manifest) 中描述,然後使用 kubectl 或其他以 GitOps 為中心的工具(如 Fleet)套用到底層叢集。

危險

錯誤的設定可能會危及 Harvester 節點的啟動能力,甚至損害叢集的整體穩定性。您可以透過閱讀 Elemental toolkit 文件來了解如何 正確自訂 Elemental,以防止此類問題。

建立 CloudInit 資源​

Harvester 節點自訂僅受限於您的創造力和 Elemental toolkit 標記在語法上能表達的內容。因此,文件無法提供可能的自訂和使用案例的詳盡清單。

範例:您想在所有節點上為預設 rancher 使用者新增 SSH 授權金鑰 (authorized key)。

首先為 CloudInit 資源建立一個 Kubernetes 資訊清單。

檔案: ssh_access.yaml
apiVersion: node.harvesterhci.io/v1beta1
kind: CloudInit
metadata:
name: ssh-access
spec:
matchSelector: {}
filename: 99_ssh.yaml
contents: |
stages:
network:
- authorized_keys:
rancher:
- ssh-ed25519 AAAA...

此資訊清單描述了一個 Elemental cloud-init 文件,該文件將套用到 所有節點(因為空的 matchSelector: {} 欄位匹配所有內容)。.spec.contents 欄位中的 YAML 文件將被渲染為 /oem/99_ssh.yaml(由於 .spec.filename 欄位)。

使用指令 kubectl apply -f ssh_access.yaml 套用此範例。

提示

重新啟動相關的 Harvester 節點,以便 Elemental toolkit 執行器可以在開機時套用新設定。

CloudInit 資源規格 (Spec)​

欄位必要描述
matchSelector是允許您指定將接收設定變更的節點的設定。
filename是出現在 /oem 中的檔案名稱。
contents是將被渲染為 /oem 中檔案的 Elemental toolkit cloud-init 風格檔案。
paused否當設定為 true 時,檔案變更時不會在節點上更新。

matchSelector 欄位可用於根據標籤鎖定特定節點或節點群組。

範例:

matchSelector:
kubernetes.io/hostname: "harvester-node-1"
備註

matchSelector 欄位中列出的所有標籤鍵值對必須與目標節點的標籤相符。

在以下範例中,matchSelector 僅在 harvester-node-1 同時具有值為 role-a 的 example.com/role 標籤時才會匹配該節點。

matchSelector:
kubernetes.io/hostname: "harvester-node-1"
[example.com/role](https://example.com/role): "role-a"

更新 CloudInit 資源​

您可以使用指令 kubectl edit 更新 CloudInit 資源。但是,如果更新 matchSelector 欄位以從自訂中排除一個或多個節點,則需要注意一個警告。請參閱 刪除 CloudInit 資源 章節中關於復原自訂的說明。

# kubectl edit cloudinit CLOUDINIT_NAME

刪除 CloudInit 資源​

您可以使用指令 kubectl delete 從 Harvester 叢集中移除 CloudInit 資源。

# kubectl delete cloudinit CLOUDINIT_NAME
備註

Harvester 無法「復原 (roll back)」先前描述的自訂,因為 CloudInit 資源可以描述任何可以用 Elemental toolkit 自訂表達的內容,包括任意 shell 指令。

在 建立 CloudInit 資源 範例中,YAML 檔案包含 authorized_keys 節。這在 Elemental toolkit 中是一個僅附加 (append-only) 的動作。當資源變更或刪除時,Rancher 中的 authorized_keys 檔案仍將包含舊的公鑰。

您有責任在重新啟動節點之前,修改或建立一個 CloudInit 資源來復原變更(如有必要)。

疑難排解 CloudInit Rollouts​

如果 Elemental toolkit cloud-init 文件未出現在 /oem 中或不包含預期內容,CloudInit 資源的狀態區塊可能包含有用的提示。

# kubectl get cloudinit CLOUDINIT_NAME -o yaml
status:
rollouts:
harvester-dngmf:
conditions:
- lastTransitionTime: "2024-02-28T22:31:23Z"
message: ""
reason: CloudInitApplicable
status: "True"
type: Applicable
- lastTransitionTime: "2024-02-28T22:31:23Z"
message: Local file checksum is the same as the CloudInit checksum
reason: CloudInitChecksumMatch
status: "False"
type: OutOfSync
- lastTransitionTime: "2024-02-28T22:31:23Z"
message: 99_ssh.yaml is present under /oem
reason: CloudInitPresentOnDisk
status: "True"
type: Present

harvester-system 命名空間中的 harvester-node-manager pod 也可能包含關於為何未將檔案渲染到節點的提示。 此 pod 是 daemonset 的一部分,因此值得檢查在感興趣的節點上執行的 pod。

遠端主控台 (Remote Console)​

您可以設定遠端伺服器管理的主控台 URL。此主控台在實體存取受限的環境中特別有用。

  1. 在 Harvester UI 上,前往 Hosts。

  2. 找到目標主機,然後選取 ⋮ > Edit Config。

  1. 指定 Console URL,然後點擊 Save。

範例(使用 HPE iLO):

  1. 點擊 Console 存取遠端伺服器。

輪替過期憑證 (Rotate Expired Certificates)​

如果 RKE2 憑證已過期,您將無法使用 auto-rotate-rke2-certificates 設定來輪替它們。該設定僅在叢集 (cluster.provisioning) 標記為 Ready 時有效。

> kubectl get cluster.provisioning -n fleet-local local -o yaml | yq -e '.status.conditions[] | select(.type=="Ready")'
lastUpdateTime: "2025-10-22T06:41:33Z"
status: "True"
type: Ready

如果 status 欄位的值為 False,您必須按照以下步驟在每個節點上手動輪替憑證:

  1. 使用 root 帳戶登入節點。
  2. 停止 RKE2 服務。
    • 管理節點
      systemctl stop rke2-server
    • 工作節點
      systemctl stop rke2-agent
  3. 輪替 RKE2 憑證。
    /opt/rke2/bin/rke2 certificate rotate
  4. 啟動 RKE2 服務。
    • 管理節點
      systemctl start rke2-server
    • 工作節點
      systemctl start rke2-agent
  5. 重新啟動 rancher-system-agent 服務。
    systemctl restart rancher-system-agent