OpenShift 版本生命週期：升級策略與支援政策完整指南【2026】

OpenShift 版本生命週期：升級策略與支援政策完整指南【2026】

OpenShift 版本生命週期：升級策略與支援政策完整指南

OpenShift 更新很頻繁，大約每四個月就有新版本。不升級怕落後，升級又怕出事。

理解版本生命週期是維運規劃的關鍵。知道哪些版本還有支援、該什麼時候升級、怎麼規劃升級路徑，才能在穩定和新功能之間取得平衡。

本文將完整介紹 OpenShift 版本管理，幫助你制定合適的升級策略。如果你對 OpenShift 還不熟悉，建議先閱讀 OpenShift 完整指南。

版本命名規則

版本號格式

OpenShift 版本號格式：4.X.Y

• 4：主版本號，目前是 OpenShift 4.x 系列
• X：次版本號（Minor），代表功能更新
• Y：修補版本號（Patch），代表安全和 Bug 修復

範例：

• 4.16.0：4.16 的初始版本
• 4.16.5：4.16 的第 5 個修補版本
• 4.17.0：4.17 的初始版本

發布週期

OpenShift 大約 每 4 個月 發布一個新的次版本：

2024 年
├── Q1：4.15
├── Q2：4.16
├── Q3：4.17
└── Q4：4.18

2025 年
├── Q1：4.18（持續）
├── Q2：4.19（預計）
└── ...

修補版本（4.X.Y）則是根據需要不定期發布，通常每 1-2 週有新的 patch。

EUS vs 一般版本

EUS（Extended Update Support） 是「長期支援版本」：

EUS 的優勢：

• 支援時間更長
• 可以跳過中間版本升級（如 4.14 → 4.16）
• 適合生產環境

生命週期支援政策

支援階段

每個 OpenShift 版本會經歷以下階段：

一般版本生命週期

發布 ─────► Full Support ─────► Maintenance ─────► EOL
            (約 6 個月)         (約 8 個月)

            總共約 14 個月

EUS 版本生命週期

發布 ─────► Full Support ─────► Maintenance ─────► EUS ─────► EOL
            (約 6 個月)         (約 6 個月)      (約 12 個月)

            總共約 24 個月

各版本狀態速查

2025 年版本狀態（請以官方公告為準）：

版本功能比較

4.14 主要功能

• HyperShift GA（託管 Control Plane）
• RHEL 9 作為節點 OS
• OVN-Kubernetes 改進
• Serverless 功能增強

4.16 主要功能

• OpenShift Lightspeed（AI 助手）預覽
• Cluster API Provider 增強
• Multi-architecture 支援改進
• Logging 6.0 引入

4.17 主要功能

• 安全性增強
• 效能優化
• Operator 更新

4.18 主要功能

• OpenShift AI 增強
• Virtualization 改進
• 穩定性提升

API 變更注意

升級時需要注意 API 棄用：

# 檢查使用了即將棄用的 API
oc get apirequestcounts | grep -v "0$"

常見需要注意的 API 變更：

• PodSecurityPolicy → Pod Security Standards
• 某些 Beta API 升級為 Stable
• 舊版 CRD 版本棄用

升級策略規劃

升級路徑選擇

一般升級（逐版升級）：

4.14 → 4.15 → 4.16 → 4.17 → 4.18

每次只升一個次版本，最穩定但頻繁。

EUS 到 EUS 升級：

4.14 → 4.16 → 4.18

跳過中間的奇數版本，減少升級次數。

注意：EUS 到 EUS 升級需要中間步驟：

4.14 → 4.15（暫停）→ 4.16

實際上還是會經過 4.15，但不需要在 4.15 停留太久。

生產環境建議策略

開發環境 ────► 測試環境 ────► UAT ────► 生產環境
  (最新)        (N-1)        (N-1)      (EUS)

例如：
開發：4.18
測試：4.17
UAT：4.17
生產：4.16 (EUS)

升級前準備

1. 確認升級路徑

# 查看可升級的版本
oc adm upgrade

# 查看所有可用版本
oc adm upgrade --include-not-recommended

2. 檢查叢集健康

# 檢查所有 Operator 狀態
oc get clusteroperators

# 確認沒有 Degraded
oc get co | grep -v "True.*False.*False"

3. 檢查 API 相容性

# 檢查是否使用即將移除的 API
oc get apirequestcounts

4. 備份 etcd

# 在 Master 節點上
/usr/local/bin/cluster-backup.sh /home/core/backup

5. 確認應用程式相容性

• 檢查 Operator 是否支援目標版本
• 測試環境先行驗證

升級規劃需要考量業務衝擊與回滾策略。預約架構諮詢，讓我們幫你制定升級計畫。

升級執行

Web Console 升級

最簡單的方式：

1. 進入 Administration → Cluster Settings
2. 查看 Update channel（確認是正確的頻道）
3. 如果有可用更新，點擊 Update
4. 選擇目標版本
5. 點擊 Update 開始升級

升級過程會顯示進度。

CLI 升級

# 查看目前版本
oc get clusterversion

# 查看可升級版本
oc adm upgrade

# 升級到特定版本
oc adm upgrade --to=4.16.5

# 升級到最新穩定版
oc adm upgrade --to-latest

升級監控

升級過程中監控狀態：

# 監控整體進度
watch oc get clusterversion

# 監控 Operator 狀態
watch oc get clusteroperators

# 監控 Node 狀態
watch oc get nodes

# 查看詳細事件
oc get events -n openshift-cluster-version --sort-by='.lastTimestamp'

升級順序

OpenShift 升級順序：

1. Control Plane（API Server, etcd, Controllers）
   ↓
2. Machine Config（節點設定）
   ↓
3. Worker Nodes（滾動更新）
   ↓
4. Operators（各自升級）

整個過程通常需要 1-3 小時，取決於叢集大小。

升級注意事項

相容性檢查

Operator 相容性：

# 查看安裝的 Operator
oc get csv -A

# 確認 Operator 支援目標版本
# 通常在 Operator 的文件中說明

應用程式相容性：

• 確認 Ingress Controller 設定
• 確認 Network Policy 仍有效
• 確認 PVC 正常運作

Operator 升級

Operator 有自己的升級機制：

# 查看 Operator 訂閱設定
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
spec:
  installPlanApproval: Automatic  # 或 Manual

• Automatic：自動升級（預設）
• Manual：需要手動批准

儲存考量

升級可能影響儲存：

• 確認 CSI Driver 相容性
• 確認 PV/PVC 狀態正常
• 建議在升級前備份重要資料

維護窗口

升級雖然是滾動式，但建議：

• 選擇低流量時段
• 準備好回滾計畫
• 通知相關團隊

常見升級問題

升級卡住

症狀：升級進度長時間不動

排查：

# 查看 Cluster Version 狀態
oc describe clusterversion version

# 查看卡住的原因
oc get clusterversion -o jsonpath='{.items[*].status.conditions}'

# 查看 Machine Config Pool
oc get mcp

常見原因：

• 某個 Operator 升級失敗
• Node 更新卡住
• etcd 健康問題

Operator 不健康

症狀：某個 Operator 顯示 Degraded

排查：

# 查看特定 Operator 狀態
oc describe clusteroperator <operator-name>

# 查看相關 Pod
oc get pods -n openshift-<operator>

# 查看 Pod 日誌
oc logs -n openshift-<operator> <pod-name>

Node 升級失敗

症狀：Worker Node 更新失敗

排查：

# 查看 Machine Config Pool
oc describe mcp worker

# 查看特定 Node
oc describe node <node-name>

# SSH 到 Node 查看
oc debug node/<node-name>
journalctl -u kubelet

回滾策略

OpenShift 不支援直接回滾到舊版本。如果升級失敗：

1. 輕微問題：等待 Operator 自動修復
2. 中度問題：手動修復失敗的組件
3. 嚴重問題：從 etcd 備份還原

最佳實踐：

• 升級前一定要備份 etcd
• 在測試環境先驗證
• 保留足夠的升級時間窗口

常見問題 FAQ

Q1：應該用 EUS 還是一般版本？

生產環境建議用 EUS。原因：（1）支援時間長，減少升級頻率；（2）可以跳版升級，省時省力；（3）更穩定，經過更多驗證。開發測試環境可以用一般版本，提前發現問題。

Q2：升級會影響運行中的應用嗎？

設計良好的應用不會受影響。OpenShift 用滾動更新方式升級 Worker Node，一次只重啟一部分節點。但要確保：（1）應用有足夠的副本；（2）使用 PodDisruptionBudget；（3）有健康檢查設定。

Q3：可以跳過多個版本升級嗎？

EUS 到 EUS 可以（如 4.14 → 4.16）。但不能跳太多版本（如 4.12 直接到 4.18）。升級路徑有限制，要按照 Red Hat 公布的支援路徑。可以用 oc adm upgrade 查看可用的目標版本。

Q4：升級失敗可以回滾嗎？

OpenShift 不支援版本回滾。如果升級到一半失敗，通常要：（1）等待自動修復；（2）手動修復問題；（3）最壞情況從備份還原。所以升級前一定要備份 etcd，並在測試環境先驗證。

Q5：升級需要停機嗎？

理論上不需要。OpenShift 使用滾動更新，Control Plane 和 Worker Node 都是逐個更新。但實務上：（1）某些應用可能短暫不可用；（2）API 可能有短暫中斷；（3）建議在維護窗口進行。

OpenShift 升級是大工程

需要完善的規劃才能確保平穩。從版本選擇到升級執行，每一步都有可能出問題。

預約架構諮詢，讓專家幫你評估升級風險。

參考資源

• OpenShift 完整指南
• OpenShift 架構詳解
• OpenShift 安裝教學
• OpenShift 進階功能指南
• OpenShift Logging 完整指南
• OpenShift 價格與授權分析
• Red Hat OpenShift Life Cycle Policy