前言

在正式開始研究如何安裝 k8s 之前，先來討論看看應該如何挑選合適的 k8s 版本，以及看看這部分相關的文件
我想對於大部分有使用過 k8s 的人 (包含我)，先前應該都不太在意這些事情，就藉著這個機會一起看看吧！

今日目標

• 知道 k8s 版本的生命週期
• 如何挑選合適的 k8s 版本
• 初步了解 k8s 的貢獻準則

Kubernetes Release Cycle

https://kubernetes.io/releases/release/

目前 k8s 更新的頻率，官方定義為每一年三個 1.Y 版本會推出 (也就是 4 個月左右會有新的 minor 版本出現)

💡 補充：在 k8s 1.18 前，會提供 9 個月的 patch 安全性更新
在 k8s 1.19 之後，延長到 1 年的 patch 安全性更新 (但相較於大多數的專案更新速度還是有點快)

一些名詞定義

• issue owners:：創建、分配以及把 issue 轉移至 release milestone 的人
• Release Team：有一個 k8s SIG team 叫做 sig-release，該 team 會負責管理每個 k8s 版本的更新
• enhancement:：每個版本的新增功能，會在開頭的前 4 週定義好 (哪些 issue 可以被稱作為 enhancement。(參考： "Is My Thing an Enhancement?")
• Enhancements Freeze*：*完成所有提交 Enhancements 提議的截止時間，有些會透過特別的審查機制 (KEPs)
• Exception Request：對特定 Enhancements 進行截止日期延長*
• Code Freeze*：在最終發布前的 4 週，即會停止開發新功能，僅修復重要的 bugs 的期間
• Pruning：當 Enhancements 最終沒被開發實作出來，或是不認定為穩定時，會將此 Enhancements 從 milestone 移除的過程。
• release milestone：針對特定 MAJOR.MINOR 的版本會建立一個 milestone，用以存放該版本預計開發的 enhancement。 (參考： release versioning.)

Kubernetes Enhancement Proposals (KEPs)：k8s 的開源審查機制，當貢獻者想要針對 k8s 某些功能進行增加/修補 等等的提案時，就必須遵從該文件的需求提供資訊
每一個 KEPs 都會有代號，方便社群追蹤功能與討論，經過妥善討論且通過的 KEPs 也會直接根據此編號進行後續 github repo 的開發與更新
官方有一份 KEPs 的範例文件，編號為 KEPs-0000，裡面很詳細的列出了文件的需求，包含動機，修改目標，使用情境等等的說明。參考：https://github.com/kubernetes/enhancements/blob/master/keps/sig-architecture/0000-kep-process/README.md
讀者們可以去看看大大們是怎麼貢獻開源專案的…

主要的三個開發階段

簡略介紹一下官方文件的三個階段：

• Enhancement Definition (1 ~ 4 weeks)：在開始的前 4 週，會先定義好哪些功能是要開發的
• Implementation (4 ~ 12 weeks)：實作階段，會將上階段所提出的 Enhancement 開始實作測試
• Stabilization (after 12 weeks)：在實作結束後，會開始 Code Freeze 階段，此階段會確保所有開發的功能皆經過穩定的測試才發布

k8s 各版本生命週期圖

可從上圖看到，核心的開發時期約為 4 個月，接下來官方會提供 8 個月的 Patch 安全性補強

看完了名詞介紹，來看看對應的 github repo

以上述定義，可以先以過往的 keps 搜尋看看在 k8s 的功能中是如何經過縝密的討論與修改後才加入的。
因為筆者也還尚未成長至能夠提供 k8s 貢獻的高度，因此就先從觀察開始，我的步驟如下：

1. 到 github kubernetes/enhancements 的 repo 中，進到 keps 的 folder 內，會發現是依照各種 SIG 來作分類的 https://github.com/kubernetes/enhancements/tree/master/keps
2. 選擇某個 SIG，並閱讀提出 keps 的作者提供的文件，會包含動機以及預計的結果等等 (有的真的寫得非常豐富，像是論文一般的詳細…)
3. 根據此 keps 的編號，查到對應的 issue number，並且觀察底下的討論情況，以及在如何的討論下，可以被打上 “LGTM” 的 labels (意即可以被 merge)
4. 有些會附上 kubernetes/kubernetes 的 PR 編號，就可以看看總共修改的內容等等

我挑選的是 SIG-cli 內的 491-kubectl-diff 這個 keps:

進入後，即可看到動機等等內容：

接著再透過 #491 這個編號，在 github: kubernetes/enhancements 內找到該 issue：

可以在底下的討論找到對應至 github: kubernetes/kubernetes 的 issue 連結:

以上即為 kubectl diff 指令在被新增的歷史過程 ~

另外在閱讀 milestones 的 issue 時，可以挑選有 “lgtm” labels 的 issue，通常代表對應 SIG team 的 member 已經有相關的結論了：

如何挑選合適的 k8s 版本?

https://kubernetes.io/releases/patch-releases/

目前最新的版本為 k8s 1.31 版本，依照上面的介紹，會大約提供一年的維護，因此 1.31 會在 2025/08/28 進入維護模式，2025/10/28 會 EOL

而官方目前提供的版本為 v1.27 ~ v1.31，再舊的版本官方網站就不提供文件了，就會建議升級

因此若是新建的 k8s cluster，筆者建議就安裝當下的最新版吧！否則很快就會面臨 EOL 的問題

至於 patch 的更新，觀察 k8s v1.29 的 note，預計都會每個月更新一次：

結論

本來想直接進入安裝的步驟，但無意間瞄到相關資訊覺得蠻有趣的就看看，結果對於開源小白來說真是燒腦啊 @_@…
若文中有不足或理解錯的部分還請各位大大多多包涵囉… 也歡迎補充~

參考

https://kubernetes.io/releases/release/

https://kubernetes.io/releases/release-managers/

https://kubernetes.io/releases/patch-releases/

https://github.com/kubernetes/enhancements/tree/master/keps/sig-cli/491-kubectl-diff

https://ithelp.ithome.com.tw/articles/10260298