OpenShift 架構解析：Control Plane、Operator 與網路設計

想把 OpenShift 用好，先得搞懂它的架構。不然出了問題，連要看哪裡都不知道。

OpenShift 架構比原生 Kubernetes 多了不少東西，但核心邏輯其實不難理解。本文從高階架構圖開始，一層一層拆解，讓你建立完整的技術認知。如果你對 OpenShift 還不熟悉，建議先閱讀 OpenShift 完整指南。

---

OpenShift 架構總覽

高階架構圖

OpenShift 架構可以分成四大層次：

┌─────────────────────────────────────────────────────────┐
│                    應用程式層                            │
│         Pods │ Deployments │ Services │ Routes          │
├─────────────────────────────────────────────────────────┤
│                  OpenShift 平台服務                      │
│   Console │ Monitoring │ Logging │ Registry │ Pipelines │
├─────────────────────────────────────────────────────────┤
│                    Kubernetes 層                         │
│        API Server │ Scheduler │ Controllers             │
├─────────────────────────────────────────────────────────┤
│                   作業系統層                             │
│              Red Hat CoreOS (RHCOS)                      │
├─────────────────────────────────────────────────────────┤
│                   基礎設施層                             │
│          雲端 │ 虛擬化 │ 裸機 │ 邊緣                    │
└─────────────────────────────────────────────────────────┘

與原生 Kubernetes 的差異

OpenShift 不只是「Kubernetes + 一些工具」，它在架構層面有幾個根本差異：

面向	Kubernetes	OpenShift
作業系統	任意 Linux	RHCOS（不可變）
安裝方式	kubeadm 等多種	統一安裝程式
元件管理	手動或 Helm	Operator 統一管理
預設安全	較寬鬆	SCC 嚴格限制
網路插件	可選擇	OVN-Kubernetes
升級機制	手動協調	Operator 自動化

設計理念

Red Hat 在 OpenShift 4.x 的設計有幾個核心理念：

1. 不可變基礎設施（Immutable Infrastructure）

節點的作業系統（RHCOS）是唯讀的，設定變更透過 Machine Config Operator 統一派送。好處是：

• 所有節點設定一致
• 變更可追蹤、可回滾
• 減少人為操作錯誤

2. 一切皆 Operator

OpenShift 自身的所有元件都用 Operator 管理。Operator 是「會自我管理的應用程式」，知道如何安裝、升級、修復自己。

3. 預設安全

安全不是事後加上去的，而是內建在架構裡。預設啟用 SCC（Security Context Constraints）、網路隔離、映像檔掃描。

插圖：展示 OpenShift 四層架構的詳細組件圖。每一層用不同...

場景描述： 展示 OpenShift 四層架構的詳細組件圖。每一層用不同顏色區分，最底層是基礎設施（灰色），往上是 RHCOS 作業系統層（深藍），再上是 Kubernetes 核心層（藍色），最上是 OpenShift 服務層（紅色）。每層內標註主要組件名稱。

視覺重點：

• 主要內容清晰呈現

必須出現的元素：

• 依據描述

需要顯示的中文字： 無

顏色調性： 專業、清晰

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

Slug: openshift-four-layer-architecture

---

Control Plane 組件

Control Plane（控制平面）是叢集的大腦，負責接收請求、做決策、維護狀態。

API Server

API Server 是叢集的唯一入口。

所有操作——不管是 kubectl 指令、Web Console 點擊、還是 Operator 的請求——都必須經過 API Server。

kubectl ─────┐
Web Console ─┼───→ API Server ───→ etcd
Operator ────┘         │
                       ↓
              Controller Manager
                  Scheduler

API Server 的職責：

• 驗證請求的身份（Authentication）
• 檢查請求的權限（Authorization）
• 驗證請求的格式（Admission）
• 將狀態寫入 etcd

etcd

etcd 是叢集的記憶體。

所有叢集狀態都存在 etcd 裡：Pod 定義、Service 設定、ConfigMap、Secret⋯⋯全部。

etcd 特性：

• 分散式鍵值儲存
• 強一致性（Raft 共識演算法）
• OpenShift 預設 3 節點，確保高可用

etcd 的健康直接影響整個叢集。如果 etcd 掛了，叢集就無法接受任何變更。

Controller Manager

Controller Manager 負責「讓現實符合期望」。

你說「我要 3 個 Pod」，Controller Manager 就確保隨時都有 3 個 Pod 在跑。少了就補，多了就砍。

OpenShift 有多個 Controller：

• Deployment Controller：管理 Deployment 的 ReplicaSet
• ReplicaSet Controller：確保 Pod 數量正確
• Node Controller：監控節點健康
• Service Controller：管理雲端負載平衡器

Scheduler

Scheduler 決定 Pod 跑在哪個 Node。

當你建立一個 Pod，Scheduler 會：

1. 過濾不符合條件的 Node（資源不足、標籤不符、污點排斥）
2. 對剩下的 Node 評分
3. 選分數最高的 Node

評分因素包括：

• 資源使用率（偏好較空閒的 Node）
• Pod 分散度（同一 Deployment 的 Pod 盡量分開）
• 節點親和性（根據標籤偏好）

OAuth Server

OAuth Server 是 OpenShift 特有的元件，處理身份驗證。

Kubernetes 原生只有基本的認證機制，OpenShift 加入完整的 OAuth 2.0 實作：

• 支援多種身份提供者（LDAP、AD、GitHub、Google）
• 發放 OAuth Access Token
• 管理使用者與群組

# OAuth 設定範例
apiVersion: config.openshift.io/v1
kind: OAuth
metadata:
  name: cluster
spec:
  identityProviders:
  - name: ldap
    type: LDAP
    ldap:
      url: "ldap://ldap.example.com/ou=users,dc=example,dc=com?uid"

---

Worker Node 架構

Worker Node 是實際跑應用程式的地方。

節點組成

每個 Worker Node 上跑著：

組件	功能
Kubelet	節點代理，管理 Pod 生命週期
CRI-O	容器運行時，執行容器
OVN-Kubernetes	網路插件，處理網路
Node Problem Detector	偵測節點問題

CRI-O 容器運行時

OpenShift 使用 CRI-O 而非 Docker：

• 專為 Kubernetes 設計的輕量級運行時
• 符合 OCI（Open Container Initiative）標準
• 比 Docker 更精簡、更安全

CRI-O 只做一件事：跑容器。不像 Docker 還包含映像檔建構、網路管理等功能。

Kubelet 配置

OpenShift 的 Kubelet 設定透過 Machine Config Operator 統一管理：

# KubeletConfig 範例
apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  name: custom-kubelet
spec:
  machineConfigPoolSelector:
    matchLabels:
      pools.operator.machineconfiguration.openshift.io/worker: ""
  kubeletConfig:
    maxPods: 250
    podPidsLimit: 4096

節點擴展

OpenShift 透過 Machine API 管理節點：

• Machine：代表一個節點實例
• MachineSet：管理一組相同配置的 Machine
• MachineAutoScaler：自動擴展 MachineSet

# MachineSet 範例
apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  name: worker-us-east-1a
spec:
  replicas: 3
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-machineset: worker-us-east-1a

插圖：展示單一 Worker Node 內部組件配置。外框是 No...

場景描述： 展示單一 Worker Node 內部組件配置。外框是 Node，內部分成幾個區塊：Kubelet（與 API Server 連線）、CRI-O（管理多個容器）、OVN-Kubernetes Agent（處理網路）。用箭頭標示組件間的互動關係。

視覺重點：

• 主要內容清晰呈現

必須出現的元素：

• 依據描述

需要顯示的中文字： 無

顏色調性： 專業、清晰

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

Slug: openshift-worker-node-components

---

Operator 機制深度解析

Operator 是 OpenShift 4.x 最重要的架構創新。

什麼是 Operator？

Operator 是一種設計模式：把應用程式的營運知識編碼成程式。

傳統做法：

1. 人看文件學習怎麼裝
2. 人手動執行安裝步驟
3. 人處理升級、備份、故障

Operator 做法：

1. Operator 知道怎麼裝（程式碼寫好了）
2. Operator 自動執行安裝
3. Operator 自動處理升級、備份、故障

Operator Lifecycle Manager（OLM）

OLM 是「管理 Operator 的 Operator」。

OLM 負責：

• 從 OperatorHub 安裝 Operator
• 管理 Operator 的升級
• 處理 Operator 之間的相依性

# Subscription 訂閱 Operator
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: elasticsearch-operator
  namespace: openshift-operators
spec:
  channel: stable
  name: elasticsearch-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace

OpenShift 內建 Operator

OpenShift 自身的元件全都是 Operator：

Operator	管理對象
Cluster Version Operator	叢集版本、升級
Machine Config Operator	節點設定
Console Operator	Web Console
Ingress Operator	Router、Ingress
Monitoring Operator	Prometheus、Alertmanager
Logging Operator	日誌收集

查看所有 ClusterOperator：

oc get clusteroperators

輸出範例：

NAME                                       VERSION   AVAILABLE   PROGRESSING   DEGRADED
authentication                             4.16.0    True        False         False
console                                    4.16.0    True        False         False
ingress                                    4.16.0    True        False         False
monitoring                                 4.16.0    True        False         False

自訂 Operator 開發

企業也能開發自己的 Operator。常見工具：

• Operator SDK：Red Hat 提供的開發框架
• Kubebuilder：Kubernetes SIG 的框架
• KUDO：D2iQ 的宣告式框架

Operator 開發步驟：

1. 定義 Custom Resource Definition（CRD）
2. 實作 Controller 邏輯
3. 打包成容器映像檔
4. 發布到 OperatorHub

---

網路架構

OpenShift 網路是很多人覺得複雜的部分，但核心概念其實很清晰。

OVN-Kubernetes

OpenShift 4.x 預設使用 OVN-Kubernetes 網路插件：

• 基於 Open Virtual Network（OVN）
• 支援 Kubernetes NetworkPolicy
• 提供進階功能（Egress IP、多網路）

OVN-Kubernetes 的優勢：

• 效能優於早期的 OpenShift SDN
• 原生支援 IPv6 雙棧
• 更好的可觀測性

Pod 網路

每個 Pod 都有自己的 IP 位址，叢集內的 Pod 可以直接互通。

Pod A (10.128.0.5) ←──→ Pod B (10.128.1.10)
        │                      │
        └──────── OVN ─────────┘

Pod 網路設計：

• 預設 Pod CIDR：10.128.0.0/14
• 每個 Node 分配一個子網段
• Pod 之間使用 Overlay 網路

Service 與 Ingress

Service 提供穩定的存取端點：

Service 類型	說明
ClusterIP	叢集內部 IP（預設）
NodePort	在每個 Node 開 Port
LoadBalancer	雲端負載平衡器

Route 是 OpenShift 特有的 Ingress 實作：

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: my-app
spec:
  host: myapp.apps.cluster.example.com
  to:
    kind: Service
    name: my-app
  tls:
    termination: edge

Route 比 Kubernetes Ingress 更早出現，功能也更完整（如 TLS 重加密、藍綠部署權重）。

Network Policy

Network Policy 控制 Pod 之間的網路存取：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

預設情況下，所有 Pod 都可以互通。套用 Network Policy 後，只有明確允許的流量才能通過。

網路架構設計影響整體效能與安全性。預約架構諮詢，讓我們幫你檢視設計。

插圖：展示 OpenShift 網路架構。上方是外部流量入口（Ro...

場景描述： 展示 OpenShift 網路架構。上方是外部流量入口（Router），中間是 Service 層（ClusterIP），下方是 Pod 網路。用箭頭表示流量方向，標註 OVN-Kubernetes 處理的網路層。

視覺重點：

• 主要內容清晰呈現

必須出現的元素：

• 依據描述

需要顯示的中文字： 無

顏色調性： 專業、清晰

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

Slug: openshift-network-topology

---

儲存架構

儲存概念

OpenShift 使用 Kubernetes 標準的儲存抽象：

概念	說明
PersistentVolume（PV）	叢集層級的儲存資源
PersistentVolumeClaim（PVC）	使用者對儲存的請求
StorageClass	儲存的「規格」，定義如何動態建立 PV

動態供應

大部分情況下使用 動態供應（Dynamic Provisioning）：

1. 使用者建立 PVC，指定 StorageClass
2. StorageClass 的 Provisioner 自動建立 PV
3. PV 與 PVC 綁定
4. Pod 掛載 PVC

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: gp3-csi

OpenShift Data Foundation（ODF）

ODF 是 Red Hat 的軟體定義儲存方案：

• 基於 Ceph 和 Rook
• 提供區塊、檔案、物件儲存
• 跨雲端、跨地域的統一儲存

ODF 適合：

• 需要 ReadWriteMany（RWX）存取模式
• 想要儲存與運算整合
• 需要跨雲端的一致儲存體驗

CSI 驅動程式

OpenShift 支援各種 CSI（Container Storage Interface） 驅動程式：

• AWS EBS CSI
• Azure Disk CSI
• GCP PD CSI
• VMware vSphere CSI
• NetApp Trident
• Pure Storage

---

安全架構

OpenShift 的安全是「預設嚴格」，這跟原生 Kubernetes 的「預設寬鬆」很不一樣。

RBAC（角色型存取控制）

RBAC 控制「誰能做什麼」：

資源	說明
Role	Namespace 層級的權限
ClusterRole	叢集層級的權限
RoleBinding	把 Role 綁定給使用者
ClusterRoleBinding	把 ClusterRole 綁定給使用者

# 給使用者 developer 在 my-project 的編輯權限
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: developer-edit
  namespace: my-project
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: edit
subjects:
- kind: User
  name: developer

SCC（Security Context Constraints）

SCC 是 OpenShift 特有的安全機制，控制 Pod 能做什麼。

預設的 SCC：

SCC	限制程度	說明
restricted	最嚴格	預設，禁止特權操作
restricted-v2	嚴格	新版預設，符合 Pod Security Standards
nonroot	中等	允許非 root 使用者
anyuid	寬鬆	允許任意 UID
privileged	最寬鬆	允許特權容器

很多從 Docker 或原生 K8s 遷移過來的應用會遇到權限問題，通常是因為 OpenShift 預設用 restricted SCC。

映像檔安全

OpenShift 內建映像檔安全機制：

• 映像檔簽章驗證：確保映像檔來源可信
• 映像檔掃描：整合 Clair、ACS 掃描漏洞
• 映像檔政策：限制可使用的 Registry

# 限制只能使用特定 Registry 的映像檔
apiVersion: config.openshift.io/v1
kind: Image
metadata:
  name: cluster
spec:
  registrySources:
    allowedRegistries:
    - quay.io
    - registry.redhat.io
    - image-registry.openshift-image-registry.svc:5000

---

高可用性設計

Control Plane HA

OpenShift 生產環境建議 3 個 Control Plane 節點：

• API Server：每個節點都跑，前面放負載平衡器
• etcd：3 節點叢集，Raft 共識確保一致性
• Controller/Scheduler：Leader Election，只有一個 active

                    Load Balancer
                         │
         ┌───────────────┼───────────────┐
         │               │               │
    ┌────▼────┐     ┌────▼────┐     ┌────▼────┐
    │ Master 1│     │ Master 2│     │ Master 3│
    │ API     │     │ API     │     │ API     │
    │ etcd    │◄───►│ etcd    │◄───►│ etcd    │
    │ Ctrl    │     │ Ctrl    │     │ Ctrl    │
    └─────────┘     └─────────┘     └─────────┘

跨區域部署

在雲端環境，建議跨 3 個可用區（AZ） 部署：

• 每個 AZ 至少 1 個 Master、多個 Worker
• 使用 Pod Anti-Affinity 分散應用程式
• 儲存也要跨 AZ（或使用 ODF）

災難復原

災難復原策略：

策略	RPO	RTO	複雜度
etcd 備份還原	小時級	小時級	低
主動-被動叢集	分鐘級	分鐘級	中
主動-主動叢集	近即時	近即時	高

etcd 定期備份是最基本的：

# 備份 etcd
oc get pods -n openshift-etcd
oc rsh -n openshift-etcd etcd-master-0
etcdctl snapshot save /var/lib/etcd/snapshot.db

---

常見問題 FAQ

Q1：OpenShift 架構跟 Kubernetes 差在哪？

主要差異在三個地方：（1）作業系統用不可變的 RHCOS，設定統一由 Operator 管理；（2）所有元件都用 Operator 模式，包括 OpenShift 自己的組件；（3）預設安全機制更嚴格，如 SCC 限制容器權限。底層還是 Kubernetes，但上層包裝完全不同。

Q2：Operator 跟 Helm 有什麼不同？

Helm 是打包工具，幫你把一堆 YAML 打包成 Chart，安裝時展開。Operator 是運行時的管理程式，會持續監控應用狀態並自動處理（升級、備份、故障復原）。Helm 安裝完就結束了，Operator 安裝完才開始工作。兩者可以搭配使用。

Q3：為什麼 OpenShift 用 CRI-O 而不是 Docker？

Docker 功能太多，Kubernetes 只需要「跑容器」這一個功能。CRI-O 專為 Kubernetes 設計，只實作 CRI（Container Runtime Interface），更輕量、更安全、更穩定。而且 Kubernetes 1.24 已經移除 dockershim，Docker 不再是官方支援的運行時。

Q4：etcd 壞了怎麼辦？

如果只壞一個節點，etcd 叢集會自動處理（3 節點容許 1 個故障）。如果壞超過半數，叢集就無法運作，需要從備份還原。所以一定要定期備份 etcd，而且備份要存到叢集外部。OpenShift 4.x 有自動備份機制，但還是要確認備份真的有在跑。

Q5：SCC 一直擋我的應用怎麼辦？

先確認應用是否真的需要那些權限。很多應用其實不需要 root，只是 Dockerfile 沒寫好。如果確實需要，可以：（1）修改 Deployment 的 securityContext；（2）建立 ServiceAccount 並綁定適當的 SCC；（3）最後手段才考慮用 anyuid 或 privileged。

---

OpenShift 架構需要第二意見？

好的架構能節省數倍的營運成本。從 Control Plane 配置到網路設計，每個決策都會影響後續的穩定性與擴展性。

預約架構諮詢，讓我們一起檢視你的容器平台規劃。

---

參考資源

• OpenShift 完整指南
• OpenShift 安裝完整教學
• OpenShift 進階功能設定
• OpenShift 日誌管理設定
• OpenShift 版本生命週期
• OpenShift 價格與授權分析
• Red Hat OpenShift Architecture