跑 Kubernetes 節點的伺服器上，Ubuntu Server 或 Debian 底子帶著幾百個沒人在用的套件——郵件工具、Perl 環境、locale 全套字型、systemd-networkd 跟 NetworkManager 兩個都留著、預設開著 sshd 等著讓全世界跑字典攻擊。Talos Linux 從 2019 年推出時就在挑戰這個預設：既然節點的唯一工作是跑 kubelet 跟 containerd，那 shell、cron、bash、ssh、apt、getty 都可以拿掉。到 2026 年 6 月推進到 v1.13.5，這條路線已經在 Fortune Global 500 客戶身上撐起單一叢集 11,000 節點的規模。
Talos 是由 Sidero Labs 主導的開源專案，原始碼採 MPL 授權，收費的只有商業 Omni 控制平面。這篇聚焦它跟一般 Linux 發行版最斷層的幾個設計選擇——不可變根檔案系統、只由 API 管理、把 SSH 直接拔掉——以及自架 Kubernetes 情境下該不該把節點換過去。
Ubuntu 撐 Kubernetes 節點的隱形成本
拿 kubeadm 起 Kubernetes 叢集的流程，多半是先把 Ubuntu Server 裝好，然後跑一長串 shell script 關掉 swap、禁用不需要的服務、裝 kubelet、設定 iptables、加上 kubelet-config.yaml、還要記得每次核心升級都要重新測試 kernel module 相容性。這套流程能動，但攻擊面跟維運成本都不小。
實務上這種節點會遇到幾個常見問題。SSH 攻擊是最直接的一項——只要對外開 22 port，隔天 auth.log 就是幾千筆爆破紀錄，就算用 key-only 也躲不掉頻寬跟 CPU 消耗。設定漂移則更難察覺：每次手動改設定、apt 升級套件、或 patch 一個 CVE，節點狀態就跟其他節點對不上，叢集裡有幾十臺就更難追蹤。遺產套件是第三層麻煩——kubelet 完全不需要 exim、cups、snapd，但 Ubuntu 預設都留著，任何一個爆漏洞都是進 root 的門。
Talos 對這幾件事的解法激進到不留妥協空間：整個作業系統只有大約 12 支 binary，全部用 Go 寫，userland 沒有 shell，也沒有登入介面。
不可變的根檔案系統與 SquashFS 開機
Talos 開機時把根檔案系統掛成 SquashFS 唯讀映像——這個檔案系統類型跟 Ubuntu Live CD 用的是同一種。整個節點執行期，/usr、/bin、/lib 這些系統路徑完全不能寫入。想改設定？沒辦法直接 vi /etc/nginx.conf，因為 /etc 也是唯讀的。整個節點的可寫入區域只剩下 kubelet 需要的資料目錄、containerd 的 image cache、以及使用者 volume 掛載點。
這個設計把「漂移」問題從根本上封死。節點上跑什麼版本的 kubelet、什麼版本的 containerd、什麼設定，全部由開機時載入的 machine config 決定。升級 Talos 的做法是先把新版映像寫進第二個開機分割區——v1.13 的 staged upgrade 支援讓這件事可以先做完再挑時間重開——下次重開機時切過去，失敗的話回退也只是把 boot flag 切回舊分割區，沒有 rollback script 要維護。
跟 Fedora CoreOS 或 Bottlerocket 是相近的概念，但 Talos 更徹底：Bottlerocket 保留了 admin container 讓管理者可以進去看東西；Fedora CoreOS 還有 rpm-ostree，緊急時還可以進系統。Talos 完全不留這個後門。
SSH 被 talosctl 換掉，管理走 gRPC API
Talos 節點對外只開一個 port：50000，跑的是叫 apid 的服務，走 gRPC over mTLS。所有管理操作——查看記憶體使用、看 kubelet log、重啟 containerd、修改網卡設定——全部都是 API call。命令列工具叫 talosctl，本質上就是一個 gRPC 客戶端。
想連進去看 log？talosctl logs kubelet -n 192.0.2.10。想看網卡狀態？talosctl get addresses。想改設定？改本地的 YAML 檔然後 talosctl apply-config，節點會自己判斷該重啟哪些服務。想除錯需要 tcpdump？v1.13 加了 talosctl debug，在節點上啟動一個特權 container，附上任何映像檔——需要 wireshark 也行、需要 gdb 也行——完全不用 SSH。
這個模型最好用的地方是自動化。想在一百臺節點上升級 kubelet，就是一支 for loop 跑 talosctl upgrade，過程完全 declarative，機器狀態跟 machine config 保持一致，沒有 SSH key 分發、sudoers 設定、Ansible inventory 這些傳統維運的儀式要顧。
v1.13 補上 Cosign 映像驗證與加密 DNS
2026 年釋出的 v1.13 有兩個對生產環境影響最大的更新。
第一個是 ImageVerificationConfig，讓節點在拉取 container image 前用 Cosign 驗證簽章。這件事在 Kubernetes 生態一直沒有乾淨的解法——Kyverno、Connaisseur 這類 admission controller 只能擋在 API server 這一層，但 Talos 自己開機拉的 Kubelet 映像、CNI 映像、控制平面 image 本來就繞過 admission。Talos 把驗證做在 OS 層，讓「叢集啟動所用的所有映像都必須簽章」這個目標第一次能在單一節點策略裡完成。
第二個是 DNS over TLS 跟 DNS over HTTPS 支援。1.13 之前 Talos 只能走純 UDP 53，走出機房的 DNS 查詢會被中間網路完整看到。這對跨地區、跨 ISP 的 Kubernetes 部署是實際的隱私跟安全問題——特別是 pod 名稱可能揭露內部服務命名。1.13 之後可以在 ResolverConfig 裡指定 DoT 或 DoH 上游，並以 name server 為單位設定。同一版本還把 etcd 跟 kube-apiserver 的最低 TLS 版本鎖到 1.3，順便清掉了自訂 cipher suite 的欄位——TLS 1.3 本來就不吃這個。
網路層還加了 VRFConfig 跟 RoutingRuleConfig。多網卡、多 uplink、需要把管理流量跟 pod 流量分開的節點，過去只能靠 systemd-networkd 或手動 ip route 設定，現在都能寫進 machine config 由 Talos 自己維持一致性。
什麼時候不該選 Talos
Talos 不是萬能。有幾種情境反而不適合。
節點上需要跑非 container 工作負載的環境不合適。Talos 的假設是節點只跑 kubelet；想在同一臺機器上另外跑一個裸的 PostgreSQL、Redis、或用 systemd 直接管理 nginx，沒辦法做到——沒有 systemd、沒有 shell、沒有 apt。這種混合情境還是 Ubuntu Server 加 Ansible 更直接。
單機 Kubernetes 或 homelab 的學習用途也未必划算。K3s 裝在既有的 Debian VPS 上五分鐘就能跑起來，遇到問題還能 ssh 進去看 log。Talos 的價值在多節點、需要 declarative 管理的情境，只有一臺節點的話儀式感反而是負擔。
需要跑特殊 kernel module 或閉源驅動的環境也要多評估。Talos 的核心是自己 build 的，也維護一批常見 module（NVIDIA GPU 已經走 CDI），但如果需要某個 out-of-tree module 或自訂 kernel patch，得走 Sidero 的 imager 工具鏈自訂 image，比 Ubuntu 加 DKMS 那條路迂迴很多。
結論
Talos Linux 的價值不在於它是「更輕量的 Linux 發行版」，而是它把 Kubernetes 節點該有的樣子重新定義——沒有 shell、沒有 SSH、沒有可以手動修改的檔案，一切都是 API 呼叫。1.13 把 Cosign 映像驗證、加密 DNS、TLS 1.3 這些現代安全實務做進 OS 層，讓自架 Kubernetes 的攻擊面比拿 Ubuntu 加 kubeadm 那套小到幾乎不成比例。
要在臺灣自架 Kubernetes 叢集，節點的網路品質、機房穩定度跟 IP 資源是決定成敗的三個關鍵。NCSE Network 的臺灣 VPS 服務位於是方電訊機房，Intel Gold CPU 加 NVMe SSD 能提供 Talos 這類工作負載所需的計算跟 I/O 表現，也能搭配 IP Transit 服務串出多節點叢集的低延遲私網。想了解更多可以參考 NCSE Network 的服務介紹。
