潛在隱性成本 link

近年各國針對企業的資訊安全越發重視，部分產業 (如金融產業、半導體業、軍工業) 要求內外網隔離甚至 Air Gap 環境

需要花費大量時間將安裝所需套件、鏡像搬移至內部以實現全離線安裝的需求。 除顯性成本如時間、人力外，企業仍須關注以下議題帶來潛在隱性成本，包含:

1. Kubernetes 版本維護
2. 套件相容性測試
3. 安裝包管理與維護

相較於 Kubernetes 生態系蓬勃發展，軟體版本長年保持高頻更新，企業為確保生產環境持續運作，要求基礎設施保持穩定致使更新頻率較低。 最終導致企業難以長期關注潛在風險，使得每次升級都是種挑戰。甚至無法做出正確的版本路線規劃，從而影響服務可用性

Kubernetes 生命週期 link

Kubernetes 一年約更新 3 個版號，每個版本官方提供 450 天上下的維護支援

由於生態系發展迅速，若與最新版本差異過大將會發生:

1. 開源軟體不再收到更新支援
2. 沒有修補的 CVE 漏洞
3. Kubernetes 物件版本落差過大，導致升級困難

建議保持 > N-2 的版本，比如最新版本為 1.29 則企業生產環境建議最低版本應為 1.27 以確保跟上軟體生態系

gantt
    dateFormat  YYYY-MM-DD
    title       Kubernetes Release Cycle

    section Active
        1.29.x          :active, 1.28, 2023-12-13, 2025-02-28
        1.28.x          :active, 1.28, 2023-08-15, 2024-10-28
        
    section Maintenance
        1.27.x          :done, 1.27, 2023-04-11, 2024-06-28
        1.26.x          :done, 1.26, 2022-12-08, 2024-02-28   
        
    section End of Life
        1.25.x          :crit, 1.25, 2022-08-23, 2023-10-27
        1.24.x          :crit, 1.24, 2022-05-03, 2023-07-28
        1.23.x          :crit, 1.23, 2021-12-07, 2023-02-28
        1.22.x          :crit, 1.22, 2021-08-04, 2022-10-28

另外，Kubernetes 版本若差距過大，原地升級通常無法直接升級至指定版號，比方說 1.18 -> 1.24 的建議升級路徑:

• 1.18 -> 1.19 -> 1.20 -> 1.21 -> 1.22 -> 1.23 -> 1.24

此種路徑不僅將耗費大量時間升級拉長維護時間，跨越多個版號升級中途需要驗證軟體以及 Kubernetes 物件相容性

對於需要常年維持上線的生產環境是無法容忍且風險隨之上升。根據客戶實際案例，我們建議:

1. 保持每 6~8 個月升級頻率
   • 通常每 4 個月釋出新版，新版本初期較不穩定稍微錯開較為適當
   • 若為 CVE 緊急版本，則視情況升級
2. 版本差距 > 3 個大版號
   • 建議採用「先建後拆」模式，同時平行驗證並保證生產環境持續運作
   • 請參考我們的客戶案例

kubespray 與 kubernetes 版本關係 link

Kubespray分支在新版本釋出後，通常舊分支即鮮少更新。 致使若未跟上最新分支即可能安裝到 Kubernetes 版本通常較舊

每次 Kubespray 新版本釋出時會連帶淘汰部分功能與設定，現階段官方建議 不要略過中間任意版本

比如希望將 Kubespray 從 2.21 升級至 2.24 時，需按照 2.21 -> 2.22 -> 2.23 -> 2.24 升級路徑進行

考慮到企業需要長期穩定支援，部分功能與設定若淘汰將導致服務異常，需謹慎思考適合的 Kubernetes 版本與未來升級路線規劃

如認為規劃過於複雜且充滿不確定性，請參考服務方案 由我們協助您!