Kubernetes叢集：postmarketOS實戰改造

– 15 分鐘閱讀

為何選擇手機開發叢集？

在投入大量時間研究家用伺服器架構後，我發現Raspberry Pi雖然是入門級選擇，但在效能和功耗管理上確實存在侷限。當我瞥見抽屜裡那堆積積被淘汰的智慧型手機時，靈光乍現 - 這些裝置雖然不再適合日常使用，但其運算能力仍相當可觀。

現代應用的運算需求

隨著容器化技術的普及，家用伺服器需要處理的工作負載越來越重。以玄貓的實際佈署經驗來看，以下服務都需要相當的運算資源：

  • CI/CD自動化流程
  • 大型影像處理系統（如Immich）
  • 人臉辨識運算
  • Git版本控制（Forgejo）
  • 密碼管理（Vaultwarden）
  • 媒體串流（Plex/Jellyfin）
  • 監控分析（Prometheus/Grafana）
  • AI對話系統（LobeChat）

雖然單一服務rarely會耗盡系統資源，但當多個服務同時運作，或是執行資源密集的工作流程時，系統負載便會迅速攀升。這時就需要透過水平擴充套件來分散負載，而舊手機正好可以擔任這個角色。

Raspberry Pi的侷限性

在深入研究Raspberry Pi作為Kubernetes節點的可行性後，我發現了幾個關鍵問題：

實體空間效率低 即使是最精簡的外殼設計，Raspberry Pi的體積仍然偏大。當需要佈署多個節點時，空間使用效率便成為一大挑戰。

電源管理複雜 每台Pi都需要獨立電源供應，使用多孔電源時又容易發生供電不穩的問題。這不僅增加了硬體成本，還可能導致整個叢集同時當機。

價效比不理想 一台8GB RAM的Raspberry Pi 5要價約85瑞士法郎（約合新台幣3,000元），相較於改造現有的舊手機，投資報酬率明顯偏低。

根據以上考量，玄貓開始探索將閒置手機改造成運算節點的可能性。這不僅能充分利用現有資源，還能開發出一個更具效能與擴充套件性的家用叢集系統。

postmarketOS：賦予舊手機新生命

為何選擇舊智慧型手機作為運算節點？

在考慮建置小型運算節點時，玄貓發現舊智慧型手機具有許多優勢。雖然 Raspberry Pi 4 是不錯的選擇，但在純運算使用場景中，其 I/O 功能往往未被充分利用。相較之下，舊智慧型手機不僅擁有強大的運算能力，還具備許多內建優勢。

舊智慧型手機的優勢分析

經過多年的技術實踐，玄貓發現舊智慧型手機作為運算節點具有以下優勢：

  1. 效能規格高於預期

    • 八核心 CPU 處理器
    • 6-8GB RAM 記憶體
    • 128GB 以上儲存空間
    • UFS 高速儲存技術

  2. 內建實用功能

    • 電池供電系統可作為不斷電系統（UPS）
    • 內建螢幕可作為監控面板
    • 可調整背光亮度以節省電力

  3. 成本效益極佳

    • 零額外成本（若使用閒置裝置）
    • 不需購買額外的 UPS 與顯示器
    • 整合度高，減少配件支出

主流裝置效能比較

以下是玄貓實際測試過的幾款裝置規格比較：

裝置型號處理器核心RAM儲存空間儲存類別
Xiaomi Redmi Note 11 Pro8核（2x2.2GHz + 6x1.7GHz）4/6/8GB64/128GBUFS 2.2
OnePlus Nord8核（1x2.4GHz + 1x2.2GHz + 6x1.8GHz）6/8/12GB64-256GBUFS 2.1
Raspberry Pi 44核（1.5GHz）2-8GB外接microSD

Linux 在智慧型手機上的挑戰

主線 Linux 支援受限

在將智慧型手機轉換為運算節點時，玄貓遇到的最大挑戰是主線 Linux 支援問題：

  • Android 裝置通常執行高度客製化的 Linux 核心
  • 這種客製化降低了系統安全性與效能
  • 在建置 Kubernetes 叢集時可能會遇到相容性問題

Bootloader 解鎖的技術難點

解鎖 Bootloader 是一個需要謹慎處理的過程：

  1. 資料安全風險

    • 解鎖過程會清除所有資料
    • 必須事先完整備份所有重要資訊

  2. 技術門檻

    • 不同廠牌有不同的解鎖流程
    • 部分裝置可能無法順利解鎖
    • 解鎖失敗可能導致裝置無法使用

  3. 保固問題

    • 大多數裝置解鎖後會失去保固
    • 某些功能可能會受到限制

玄貓建議在進行 Bootloader 解鎖前，務必：

  • 詳細研究目標裝置的解鎖方法
  • 確認裝置是否支援解鎖
  • 完整備份所有資料
  • 準備好應對可能的風險

在多年協助企業與個人進行Android裝置客製化的經驗中，玄貓發現引導程式解鎖（Bootloader Unlock）往往是整個過程中最具挑戰性的環節。讓我們探討這個議題，並分享一些實用的建議。

引導程式解鎖的品牌差異

不同品牌對於引導程式解鎖有著截然不同的政策。有些製造商允許直接使用 fastboot oem unlock 指令解鎖，但也有許多品牌設下重障礙，甚至完全禁止解鎖。若您計畫購買二手裝置進行客製化，建議事先了解該品牌的解鎖政策。

不建議購買的品牌

玄貓根據實際經驗，整理出幾個解鎖較為麻煩的品牌：

小米（Xiaomi）裝置的解鎖流程相當繁瑣：

  • 解鎖等待期長達7至30天
  • 需持續保持相同的小米帳號登入
  • 必須使用官方解鎖工具，雖然也有第三方替代方案

華為（Huawei）與榮耀（Honor）則是：

  • 目前已完全禁止解鎖引導程式

推薦考慮的品牌

相對地，這些品牌對開發者較為友善：

  • Google 的 Pixel 系列
  • OnePlus 系列
  • FairPhone 系列

GPL 授權的遵守問題

Linux 核心採用 GPL 授權，要求修改程式碼必須公開分享。然而，許多製造商在發布核心原始碼時態度消極，有些甚至完全不予提供。以小米為例，他們曾多次因未及時釋出某些機型的核心原始碼而受到社群批評。

系統支援的考量

在投入客製化系統開發前，裝置支援度是重要考量。玄貓建議：

  1. 優先選擇社群已支援的裝置
  2. 檢查 postmarketOS Wiki 的「測試中」裝置列表
  3. 使用 pmbootstrap 工具可快速建置測試環境

postmarketOS 簡介

postmarketOS 是一個根據 Alpine Linux 的行動裝置作業系統，採用滾動式更新模式。這個系統特別適合想要在手機上執行完整 Linux 系統的使用者。

在我為多個專案開發客製化系統的過程中，深刻體會到選擇合適的基礎系統有多重要。postmarketOS 提供了穩定的基礎，讓開發者能專注於功能開發，而不需重新開發整個系統架構。

經過多年的技術發展，現今的行動裝置客製化已不再是遙不可及的夢想。透過正確的工具選擇與充分準備，即使是較為複雜的系統移植工作也能順利完成。雖然過程中可能遇到挑戰，但這些經驗往往能帶來寶貴的技術成長。

Linux 在 ARM 架構的演進與機會

隨著 Apple Silicon 的推出以及 aarch64-laptops 和 Linaro 團隊的傑出貢獻，ARM 架構的 Linux 生態系統正快速成長。玄貓觀察到這個趨勢不僅帶來更多的可能性，也為行動裝置帶來了全新的應用場景。目前已有許多主流 Linux 發行版本提供 ARM 架構的支援，包括：

  • Arch Linux ARM
  • Alpine Linux
  • Debian ARM64 Port

這些發展使得將智慧型手機作為伺服器或電腦使用不再是遙不可及的夢想。事實上，現代行動裝置的硬體規格已經相當接近筆記型電腦的水準。

Docker 與容器化在 ARM 的發展

雖然某些軟體發行商仍然預設系統執行在 x86_64 架構上，但隨著 Docker 多平台建置功能的推出，這個情況正在逐漸改善。玄貓在實務經驗中發現，透過正確的設定，大多數容器化應用程式都能在 ARM 架構上順利執行。

建置節點時的關鍵經驗

在建置 ARM 架構的 Linux 節點時，有幾個重要的技術要點需要特別注意：

  1. 防火牆設定的陷阱 postmarketOS 預設使用 nftables 而非 iptables。若發現 Kubernetes 網路出現異常，應優先檢查 /etc/nftables.nft 中的規則設定。

  2. 容器與叢集必要條件 Docker、Kubernetes 和 K3s 都需要特定的核心模組與設定。建議依序執行以下檢查：

# 檢查 Docker 相容性
curl -L https://raw.githubusercontent.com/moby/moby/master/contrib/check-config.sh | bash

# 檢查 K3s 相容性
curl -L https://raw.githubusercontent.com/k3s-io/k3s/master/contrib/util/check-config.sh | bash

內容解密

以上程式碼主要用於檢查系統是否符合容器化環境的需求：

  • 第一個指令會下載並執行 Docker 的設定檢查指令碼，用於驗證系統是否具備執行 Docker 容器所需的所有核心功能
  • 第二個指令則是下載並執行 K3s 的設定檢查指令碼，確認系統是否滿足 K3s（輕量級 Kubernetes）的執行需求

玄貓在實務操作中發現，不同裝置的核心設定可能有所差異。例如 OnePlus 5T (dumpling) 缺少某些必要的核心設定，而 OnePlus 8 Pro (instantnoodlep) 則完全符合需求。這凸顯了在不同硬體平台上佈署容器化環境時

在多年的系統移植經驗中，玄貓發現 postmarketOS 是一個相當有潛力的手機作業系統選擇。這篇文章將分享如何在 OnePlus 5T（代號：dumpling）上成功安裝與設定 postmarketOS，特別著重於網路連線的部分。

系統需求與相容性

在開始安裝之前，需要注意幾個重要的系統要求：

  1. 核心設定需求：

    • 需啟用 CONFIG_NETFILTER_XTABLES 相關選項
    • 必須開啟 CONFIG_VXLAN 支援
    • CNI（Container Network Interface）可能需要額外的核心功能

  2. 裝置支援狀態： 根據 postmarketOS 官方檔案，OnePlus 5T 目前處於「測試中」狀態。但從玄貓的實際測試經驗來看，基本功能如 Wi-Fi 和 USB 網路都能正常運作。

USB 網路連線設定

postmarketOS 的一個便利特點是內建支援 USB 網路功能。當你將手機連線到電腦時，系統會自動將其識別為 USB 網路裝置。連線成功後，你會看到類別似以下的網路介面資訊：

ip addr show enp0s20f0u1
49: enp0s20f0u1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether ca:fe:ba:be:00:42 brd ff:ff:ff:ff:ff:ff
    inet 172.16.42.2/24 brd 172.16.42.255 scope global dynamic noprefixroute enp0s20f0u1
    valid_lft 3628776sec preferred_lft 3628776sec
    inet6 fe80::504a:1ee0:5015:da8d/64 scope link noprefixroute
    valid_lft forever preferred_lft forever

建立 SSH 連線：

ssh root@172.16.42.1

Wi-Fi 網路設定

成功連線到裝置後，我們可以開始設定 Wi-Fi 連線。首先確認 Wi-Fi 介面狀態：

ip addr show wlan0
4: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether 02:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff

使用 NetworkManager 指令列工具掃描可用的 Wi-Fi 網路：

nmcli d wifi

連線到指定的 Wi-Fi 網路：

nmcli d wifi connect "網路名稱" --ask

若要連線到隱藏的網路，則需要使用不同的指令引數。玄貓建議在設定隱藏網路時，先確認網路名稱的正確性，因為輸入錯誤可能需要重新設定整個連執行緒式。

在這個佈署過程中，有一個重要的提醒：在使用 SSH 連線時，請務必確認正確的 IP 位址是 172.16.42.1，而不是 172.16.42.2。這是玄貓在實際操作中發現許多使用者容易混淆的地方。

透過這些步驟，你就能夠成功在 OnePlus 5T 上建立一個功能完整的 postmarketOS 系統。儘管目前仍處於測試階段，但基本功能的穩定性已經足夠日常使用。持續關注專案發展，未來還會有更多功能支援。 在探討k3s佈署時，我們首先需要確保網路連線的正確設定。透過NetworkManager連線隱藏的WiFi網路後，系統會顯示成功的連線訊息。不過,我們在進行Kubernetes節點設定時需要特別注意一些關鍵要點。

以下是在裝置上佈署k3s的主要步驟與重要觀念:

首先，我們要安裝k3s套件:

apk add k3s

接著建立k3s agent的設定檔，路徑為 /etc/rancher/k3s/config.yaml:

token: "000000::server::f0000"
server: "https://192.168.10.11:6443"
prefer-bundled-bin: true
flannel-iface: wlan0
with-node-id: true
node-label:
- com.example.mylabel/type=foo 
- com.example.mylabel/net=wireless

在 /etc/conf.d/k3s 中設定啟動引數:

export PATH="/usr/libexec/cni/:$PATH"
K3S_EXEC="agent"
K3S_OPTS=""

這些設定內容讓我來為各位解密:

  1. config.yaml的設定說明:
  • token用於節點認證
  • server指定master節點位址
  • flannel-iface指定網路介面
  • node-label定義節點標籤
  1. k3s啟動設定的重點:
  • 設定CNI外掛路徑
  • 指定為agent模式執行
  • 保留擴充引數空間

然而,在實際佈署過程中我發現一個關鍵問題:kernel設定的完整性。在多年的容器化佈署經驗中,我常發現許多特製化的Linux kernel並未預設開啟容器所需的核心功能。這在msm8998 kernel上特別明顯。

kernel需要支援的關鍵功能包括:

  • 容器namespace隔離
  • cgroup資源控制
  • 網路虛擬化功能
  • 容器安全相關選項

所以在佈署k3s之前,我們必須先確認kernel是否支援這些功能。這不僅影響到容器執行,更會直接影響到整個Kubernetes叢集的穩定性與功能完整性。

在確認kernel功能齊備後,我們才能執行:

service k3s start
rc-update add k3s

最後透過 tail -f /var/log/k3s.log 監控節點加入叢集的狀態。這個過程讓我們清楚看到系統運作的細節,有助於問題排查。

未來若要在更多裝置上佈署類別似環境,kernel功能的完整性檢查將是不可或缺的第一步。這個經驗告訴我們,在容器化佈署時不能想當然,必須從底層架構開始確認。

解決 K3s 網路問題與設定最佳化

在進一步探討 K3s 的網路問題之前，我們需要先了解幾個關鍵的網路設定要點。在我多年維護容器叢集的經驗中，網路問題往往是最棘手但也最容易被忽視的部分。

核心網路功能檢查

首先，我們需要確認系統核心是否支援所有必要的網路功能：

# 檢查核心網路模組載入狀態
lsmod | grep -E 'br_netfilter|overlay'

# 確認網路相關的系統引數
sysctl -a | grep -E 'bridge-nf-call-iptables|ip_forward'

這些檢查能幫助我們確認系統是否具備執行容器網路的基本要求。若發現缺少必要的模組，我們需要在系統啟動時自動載入：

# 建立永續性設定
cat > /etc/modules-load.d/k3s.conf << EOF
br_netfilter
overlay
EOF

網路引數最佳化設定

接著，我們需要調整系統的網路引數來確保容器網路正常運作：

# 設定網路橋接引數
cat > /etc/sysctl.d/k3s.conf << EOF
net.bridge.bridge-nf-call-iptables = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.ipv4.ip_forward = 1
EOF

# 立即套用引數
sysctl --system

Flannel 網路除錯步驟

當發現 Flannel 網路無法正常運作時，我建議採取以下步驟：

  1. 檢查 Flannel 網路介面設定：
ip addr show flannel.1
  1. 確認 VXLAN 封裝是否正常：
tcpdump -i flannel.1 -n
  1. 驗證節點間的連線能力：
# 在來源節點執行
ping -c 3 
### 在ARM裝置上的容器化網路除錯實戰

在進行容器化佈署時,網路設定往往是最容易出現問題的環節之一。作為一名資深DevOps工程師,我曾經遇到一個令人困惑的網路問題。當時在一個ARM架構的裝置上執行Kubernetes叢集,發現容器間的網路通訊出現異常。透過分析封包轉發情況,我觀察到一個有趣的現象:

```bash
IP 10.42.3.13 > 10.42.3.11: ICMP echo request, id 10, seq 4, length 64
IP 10.42.3.13 > 10.42.3.11: ICMP echo request, id 10, seq 5, length 64

這些ICMP請求封包顯示,容器之間的網路連線被阻擋了。更令人困惑的是,iptables的NAT規則和FORWARD鏈設定都是正確的。這個問題困擾了我很長一段時間,因為按理說,既然iptables規則允許流量透過,封包不應該被丟棄。

關鍵發現:nftables的影響

經過深入排查,最終發現問題出在nftables的規則上。這個發現讓玄貓意識到一個重要的知識點:在現代Linux核心中,nftables已經取代iptables成為預設的防火牆框架,而iptables實際上是作為nftables的前端介面存在。

重要的是,nftables的規則對iptables是不可見的,但反過來iptables的規則可以被nftables看到。這就解釋了為什麼單純檢查iptables無法發現問題所在。玄貓透過修改 /etc/nftables.nft 設定檔案,終於讓容器可以正常存取網際網路和叢集內的其他容器。

最佳化佈署策略

解決網路問題後,玄貓對節點進行了一些最佳化設定。由於該節點使用Wi-Fi連線,頻寬限制在200 Mbit/s左右,我們為其新增了特定標籤:

com.example.mylabel/net=wireless

這樣就可以根據網路特性來排程工作負載,避免將對網路延遲敏感的服務佈署到這個節點上。

最後,玄貓使用Ansible實作了自動化佈署,並加入了一個省電最佳化:

echo 0 > /sys/class/backlight/c994000.dsi.0/brightness

這個指令可以完全關閉顯示器背光,有效降低裝置功耗。

這次除錯經驗讓玄貓深刻體會到,在容器化環境中,網路問題的排查需要對Linux網路堆積積疊有全面的理解,不能只關注單一元件。同時也提醒我們,在選擇硬體平台時,需要仔細評估其網路功能的支援程度。

後續在擴充套件叢集時,玄貓選擇了OnePlus 8 Pro作為新節點。然而在佈署過程中發現Wi-Fi介面無法識別:

$ ip link show wlan0
ip: can't find device 'wlan0'

這個意外情況提醒我們,即使硬體規格相近的裝置,其Linux相容性也可能存在顯著差異。在選擇佈署平台時,必須進行充分的相容性測試。

在多年的Linux系統開發經驗中，裝置樹（Device Tree）的除錯與設定一直是個充滿挑戰的領域。今天玄貓要分享一個關於QCA6390 Wi-Fi/藍牙晶片驅動問題的實際案例，並詳細說明解決過程。

問題診斷與初步分析

在分析系統日誌時，透過dmesg輸出發現QCA6390 Wi-Fi/藍牙晶片無法正常運作。經過深入檢查，問題根源在於裝置樹（Device Tree）設定中缺少了必要的晶片描述。這種情況在移植新硬體支援時常發生。

尋找解決方案

在搜尋解決方案過程中，發現了一個OnePlus 8T（代號：kebab）的修補程式。由於OnePlus 8T與目標裝置OnePlus 8 Pro的硬體架構相似，這個修補程式提供了寶貴的參考。

重建裝置樹檔案

首先建立新的裝置樹檔案（DTB）：

# 解開原始開機映像檔
unpack_bootimg --boot_img $PMOS_ROOT/chroot_rootfs_oneplus-instantnoodlep/boot/boot.img --format=mkbootimg 

# 複製新編譯的DTB檔案
cp ~/git/linux/arch/arm64/boot/dts/qcom/sm8250-oneplus-instantnoodlep.dtb /tmp/firmware/out/dtb

# 重新封裝開機映像檔
mkbootimg --header_version 2 \
  --kernel out/kernel \
  --ramdisk out/ramdisk \
  --dtb out/dtb \
  --pagesize 0x00001000 \
  --base 0x00000000 \
  --kernel_offset 0x00008000 \
  --ramdisk_offset 0x01000000 \
  --second_offset 0x00000000 \
  --tags_offset 0x00000100 \
  --dtb_offset 0x0000000001f00000 \
  --board '' \
  --cmdline 'clk_ignore_unused pd_ignore_unused pmos_boot_uuid=d86a5f31-2802-4333-b5aa-ff8a59e4d66e pmos_root_uuid=efbc85d5-1ba9-45ff-af90-1eecd5235327 pmos_rootfsopts=defaults' \
  -o boot-repacked.img

驗證與測試

使用fastboot工具更新裝置：

fastboot flash boot boot-repacked.img
fastboot reboot

然而，裝置無法正常開機。這種情況下，由於缺乏序列控制檯（Serial Console）的存取，除錯變得相當困難。

漸進式修改策略

在缺乏完整除錯資訊的情況下，玄貓採用了逐步修改的策略：

  1. 回復到最後一個可正常運作的狀態
  2. 參考其他使用相同晶片的裝置設定
  3. 研究小米平板電腦電腦5 Pro（elish）的裝置樹設定，特別是其PCI0埠的描述

特別值得注意的是，小米平板電腦電腦5 Pro使用相同的晶片，其裝置樹設定提供了重要的參考資訊，包括：

  • 晶片在PCI0埠的設定方式
  • GPIO啟用晶片的必要設定

系統性除錯方法

在沒有序列控制檯的情況下進行除錯，需要採取更有系統的方法：

  1. 建立基準測試環境
  2. 逐一隔離可能的問題來源
  3. 詳細記錄每次修改的結果
  4. 參考相似硬體平台的成功案例

在深入研究sm8250-mainline核心程式碼時，發現許多使用相同晶片的裝置都有類別似的設定模式。這些參考資料為解決方案提供了重要的線索。

在處理這類別問題時，保持耐心和系統性的方法至關重要。雖然沒有序列控制檯帶來了額外的挑戰，但透過仔細的分析和漸進式的修改，最終能找到正確的解決方案。

在面對硬體驅動問題時，經常需要在原始設計和實際運作環境之間找到平衡點。透過這個案例，我們可以看到如何在有限的除錯資訊下，透過系統性的方法來解決複雜的驅動程式問題。

在探索將舊式手機改造成運算節點的過程中，Wi-Fi連線的穩定性是一個關鍵挑戰。本文將分享我在整合OnePlus手機Wi-Fi驅動程式並將其納入K3s叢集的實戰經驗，特別是關於ath11k晶片的調校過程。

Wi-Fi驅動程式的調校歷程

在反覆測試與設定調整後，我成功讓系統識別了ath11k晶片。關鍵的突破點在於正確設定電壓調節器和裝置樹的設定。系統日誌顯示晶片已被正確識別：

# dmesg | grep ath11k
[   11.524348] ath11k_pci 0000:01:00.0: Adding to iommu group 13
[   11.524578] ath11k_pci 0000:01:00.0: BAR 0 [mem 0x60400000-0x604fffff 64bit]: assigned
[   11.524642] ath11k_pci 0000:01:00.0: enabling device (0000 -> 0002)
[   11.524983] ath11k_pci 0000:01:00.0: MSI vectors: 32
[   11.525005] ath11k_pci 0000:01:00.0: qca6390 hw2.0
[   12.796173] ath11k_pci 0000:01:00.0: chip_id 0x0 chip_family 0xb board_id 0xff soc_id 0xffffffff
[   12.796205] ath11k_pci 0000:01:00.0: fw_version 0x10121492 fw_build_timestamp 2021-11-04 11:23 fw_build_id

確認網路介面啟動後（使用 ip link show wlan0 確認），我便能順利連線Wi-Fi網路，並將裝置整合進叢集中執行工作負載。為了推廣裝置再利用的理念，玄貓已將相關修補程式提交至sm8250-mainline核心儲存函式庫在裝置說明頁面新增相關說明。

背光控制的限制

目前系統在背光控制方面仍有待改進。由於裝置樹中缺乏背光描述，現階段無法控制螢幕背光。雖然這個限制對叢集運作影響不大，但這確實是未來可以改善的方向。

叢集運作成果

經過這次整合，我的小型叢集已經擁有三個可用節點，可以順利執行各種工作負載：

$ kubectl get nodes
NAME                               STATUS   ROLES                  AGE    VERSION
k3s-node-dumpling-cf0b07d4         Ready    <none>                 15d    v1.31.2-k3s1
k3s-node-instantnoodlep-e577c75e   Ready    <none>                 2d8h   v1.31.2-k3s1
master-1                           Ready    control-plane,master   14d    v1.31.2-k3s1

這個實驗證明瞭舊式手機確實可以轉化為實用的運算節點。為了協助更多人複製這個成果，玄貓也準備了預先封裝的boot映像檔。但請注意，在使用任何網路上的核心映像檔時都應該謹慎評估安全風險。

這個專案不僅展現了裝置再利用的可能性，更證明瞭ARM架構裝置在叢集運算領域的潛力。透過適當的系統整合與設定，我們能夠讓原本閒置的裝置重獲新生，投入實際的運算任務。這種做法不僅環保，也為小型叢集運算提供了一個經濟實惠的解決方案。

在資源有限的情況下，善用手邊的裝置往往能激發出意想不到的創新應用。期待這個實驗能啟發更多人思考裝置再利用的可能性，為永續運算貢獻一份心力。

玄貓

玄貓

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。