返回首頁OpenShift

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

2/4/202614 min 分鐘閱讀

#OpenShift#版本管理#升級#EUS#生命週期

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） 是「長期支援版本」：

版本類型	支援期間	版本號	適用對象
一般版本	~14 個月	奇數版（4.15, 4.17）	願意頻繁升級的團隊
EUS 版本	~24 個月	偶數版（4.14, 4.16, 4.18）	追求穩定的企業

EUS 的優勢：

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

插圖：展示 OpenShift 版本發布時間線。橫軸是時間（202...

場景描述： 展示 OpenShift 版本發布時間線。橫軸是時間（2024-2025），縱軸列出各版本（4.14、4.15、4.16、4.17、4.18）。EUS 版本用紅色長條表示較長的支援期間，一般版本用灰色短條表示較短的支援期間。標註各版本的 EOL 日期。

視覺重點：

主要內容清晰呈現

必須出現的元素：

依據描述

需要顯示的中文字： 無

顏色調性： 專業、清晰

避免元素： 抽象圖形、齒輪

Slug: openshift-version-timeline

生命週期支援政策

支援階段

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

階段	說明	內容
Full Support	完整支援	功能更新 + 安全修復 + Bug 修復
Maintenance Support	維護支援	僅安全修復 + 重大 Bug 修復
Extended Update Support	延伸支援（EUS）	付費延長支援
End of Life（EOL）	終止支援	不再提供任何更新

一般版本生命週期

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

            總共約 14 個月

EUS 版本生命週期

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

            總共約 24 個月

各版本狀態速查

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

版本	類型	狀態	預計 EOL
4.18	EUS	Full Support	2026 Q4
4.17	一般	Maintenance	2025 Q3
4.16	EUS	Maintenance	2026 Q2
4.15	一般	EOL	2025 Q1
4.14	EUS	EUS Support	2025 Q4
4.13	一般	EOL	2024
4.12	EUS	EOL	2024

版本功能比較

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 升級

最簡單的方式：

進入 Administration → Cluster Settings
查看 Update channel（確認是正確的頻道）
如果有可用更新，點擊 Update
選擇目標版本
點擊 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 小時，取決於叢集大小。

插圖：展示 OpenShift 升級流程。從「開始升級」到「升級完...

場景描述： 展示 OpenShift 升級流程。從「開始升級」到「升級完成」，經過「Control Plane 升級」→「Machine Config 派送」→「Worker Node 滾動更新」→「Operator 升級」→「驗證」。每個步驟標註預估時間和關鍵檢查點。

視覺重點：

主要內容清晰呈現

必須出現的元素：

依據描述

需要顯示的中文字： 無

顏色調性： 專業、清晰

避免元素： 抽象圖形、齒輪

Slug: openshift-upgrade-process-flow

升級注意事項

相容性檢查

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 不支援直接回滾到舊版本。如果升級失敗：

輕微問題：等待 Operator 自動修復
中度問題：手動修復失敗的組件
嚴重問題：從 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