K3s v1.34.9 更新重點整理
K3s v1.34.9+k3s1 跟進 Kubernetes 1.34.9，並更新 Traefik、containerd、CoreDNS 等元件。這次是維運型更新，但 Traefik 介接名稱變更，升級前要先檢查設定。
K3s v1.34.9+k3s1 主要是跟進 Kubernetes 1.34.9，順手更新 Traefik、containerd 和其他內建元件。
說真的，這版看起來很安靜，實際上很有份量。K3s 這種輕量 Kubernetes 發行版，最怕的不是沒新功能，而是元件版本卡住，久了就會讓升級變麻煩。
這次更新把核心堆疊往前推了一小步。對邊緣部署、實驗環境，還有小型正式環境來說，這種小步更新常常比大改版更實際。
| 元件 | 版本 | 變動重點 |
|---|---|---|
| K3s | v1.34.9+k3s1 | 發行版本體更新 |
| Kubernetes | 1.34.9 | 核心控制平面與節點修補 |
| Traefik | v3.7.4 | Ingress 控制器更新 |
| containerd | v2.2.5-k3s2 | Runtime 與環境字串修正 |
| Go | 1.25.11 | 建置工具鏈更新 |
| CoreDNS | v1.14.4 | DNS 元件更新 |
這版到底改了什麼
訂閱 AI 趨勢週報
每週精選模型發布、工具應用與深度分析，直送信箱。不定期，不騷擾。
不會寄垃圾信，隨時可取消。
這次不是單一大功能，而是一串 backport 和元件刷新。最核心的是 Kubernetes 直接對齊到 1.34.9，這代表控制平面和節點層的修補會一起進來。
另外，K3s 也更新了幾個常見內建元件。像是 Traefik chart、containerd、CoreDNS、Flannel、Metrics Server、Helm Controller，還有 Local Path Provisioner，都有不同程度的版本調整。
講白了，這種版本最像「整理倉庫」。你平常不會特別注意，但等到某個元件出問題，才會知道版本一致性有多重要。
- Kubernetes 更新到 1.34.9
- Traefik 更新到 v3.7.4，chart 也升到 v40.x
- containerd 更新到 v2.2.5-k3s2
- Go 更新到 1.25.11
- CoreDNS 更新到 v1.14.4
如果你是跑 K3s 的管理者，這些數字代表的不是「有新東西」，而是「少一點舊坑」。尤其在小型叢集裡，內建元件更新常常比外部套件更容易影響穩定性。
Traefik 這個變更要先看
這次最容易踩雷的地方，是 Traefik chart 升到 v40.x 後，provider 名稱有改。原本從 ingress-nginx 過來的設定，名稱會從 kubernetesIngressNginx 變成 kubernetesIngressNGINX。
這不是字母大小寫的小事。很多團隊的 values 檔、Helm 模板，甚至自動化部署腳本，都會直接寫死這種名稱。你一旦沒改，Ingress 可能就直接失效。
我覺得這種變更最煩。它不會在第一眼就炸給你看，但一上線就可能讓流量導錯地方，然後大家開始懷疑是不是網路壞了，其實只是設定名寫錯。
“The provider name changes from kubernetesIngressNginx to kubernetesIngressNGINX.” — K3s release notes on GitHub
這句話很短，殺傷力很高。它提醒你，K3s 的小版本更新，還是可能帶來設定層面的相容性問題。
如果你的叢集有對外服務，這段一定要先檢查。先比對現有 Helm values，再去 staging 跑一次，別直接在正式環境硬上。
跟前一版比，差在哪裡
如果拿前一版 v1.34.8+k3s1 來看，這次就是一個標準的 patch 升級。Kubernetes 從 1.34.8 推進到 1.34.9，containerd 從 v2.2.5-k3s1 到 v2.2.5-k3s2，Traefik 也跟著進到 v3.7.4。
這些版本號看起來很小，但 Kubernetes 發行版就是這樣。真正影響你的是修補內容，不是數字長得漂不漂亮。
如果你有在管叢集，下面這些差異最值得盯：
- Kubernetes：1.34.8 升到 1.34.9
- containerd：v2.2.5-k3s1 升到 v2.2.5-k3s2
- Traefik：chart 升到 v40.x，Traefik 本體到 v3.7.4
- Go：升到 1.25.11
這些更新的方向很明確。K3s 還是在追上游 Kubernetes，同時把周邊元件一起整理好。這也是它受歡迎的原因之一，因為你不用自己拼一整套發行版。
不過，這次的 ingress 名稱變更也說明一件事。你不能只看 Kubernetes 版本，還要看它包進來的每個元件怎麼變。
生產環境要先做哪些事
先別急著全線升級。最實際的做法，是先把目前的 Traefik 設定抓出來，對照 v40.x 的 migration note。只要你有用 ingress-nginx 轉過來，這一步就不能省。
再來，確認你的自動化流程有沒有寫死舊的 provider 名稱。很多 CI/CD pipeline 平常跑得好好的，結果只是字串改名，就在升級後整串壞掉。
如果你有 air-gapped 環境，這版也很適合先做離線驗證。K3s 一直都有 amd64、arm、arm64 這些安裝資產，對邊緣設備跟內網部署來說很方便。
- 先比對 Traefik values
- 檢查 Helm 模板與自動化腳本
- 先在 staging 跑一次升級
- 離線環境先驗證映像與安裝包
我會建議把這次升級當成「設定審查」來做，而不是單純 patch。這樣比較不會在正式環境踩到 ingress 失效這種低級但很痛的問題。
這版放在整個 K3s 脈絡裡怎麼看
K3s 的定位一直很清楚，就是讓 Kubernetes 變得更容易裝，也更容易維護。它不是要跟大型雲端控制平面拼規模，而是把小型叢集、邊緣環境、實驗室環境先顧好。
這也解釋了為什麼它每次 patch release 都值得看。對大叢集來說，一個小版本可能只是例行維護。對 K3s 使用者來說，一個內建元件的變更就可能影響整個服務入口。
從這次更新來看，K3s 還是在維持同一條路線：版本跟著上游走，內建元件一起整理，讓使用者不用自己補一堆依賴。只是你也得接受，這種便利本來就伴隨設定變更的風險。
放到台灣常見的情境，像是門市邊緣節點、工廠內網服務、校園測試叢集，這種更新就很有感。因為這些地方常常不是沒人管，而是資源很有限，最怕版本散掉。
結論：這版值得升，但先查設定
K3s v1.34.9+k3s1 是一版偏維運的更新。它不是拿來秀功能的，是拿來把叢集維持在可控狀態。
我的建議很直接：先看 Traefik 設定，再安排 staging 升級，最後才碰正式環境。只要你有用 ingress，這步就別偷懶。
如果你的叢集目前還在 K3s 1.34.x，這版很值得排進本週維護清單。你要做的不是觀望，而是先確認自己的設定有沒有被 Traefik 的名稱變更打到。