說明

因為 OCP 是基於 K8s 的延伸，所以在駕馭 OCP 的功能前，總是需要知道「差異」在哪裡。
這篇文章會簡單地從文件和測試環境來比對比對。

K8s 組件

以下看圖說故事，以及作為容器圈炎亞綸的觀察：

• 上圖為 K8s 官方文件給的 Components (組件) 示意圖

• 從 https://kubernetes.io/docs/concepts/architecture/#cloud-controller-manager 這頁看圖，我覺得這張畫得比較漂亮。

Control Plane / Worker

• 拿日常的上班工作當作案例，在某些公司裡，根據分工特性
• 負責「統籌、指揮、調度」的管理階層，叫做老闆、主管、領導、Boss；所處的位置，被稱為皇城、權力核心，而在 K8s 的架構規劃，稱為 Control Plane / 而用來擺放這些程式組件的機器，則稱為 Master Node(s)
• 「被分派工作、純粹付出勞力／算力」的奴隸們，叫做 Worker Node(s)。 顧名思義就是負責出力工作的節點。 各位就像是免洗筷，壞掉了怎麼辦？ 隨時都可以換一組啊！ 公司在錄取員工時，大多只需關注他的肝心不新鮮，耐不耐操； Worker Node 也是，只要架構對了，資源越強越好，不太需要逐一備份這幫奴隸的環境，最好有不用勞工保險、有工作通告時隨叫隨叫的那種。

4 大組件 / 4+1 大組件

1. kube-apiserver / API伺服器 / (皇城總機兼發言人)
   • 顧名思義，是 K8s 的 API Server，是一種伺服器
   • 作為 kubectl / oc 指令的入口。指令是一種 CLI、命令列工具，在使用者打完指令後，工具會轉換成 REST API 和 json 格式，再發送給這個伺服器。
   • 這個伺服器，還會和各個奴隸節點中的 kubelet 傳令兵 以 REST API 溝通。
   • 作為總機，接收到指令後，當然要先確認來者何人？ 所以驗證與授權請求也會在這邊進行。
   • 驗證資料格式是否符合 schema。 總機如果聽不懂請求內容，自然無法處理後續。
   • 在執行上述業務時，會順便把該記錄下來的事情，丟給 etcd 讓它被記錄下來。
     
2. etcd / 分散式 key-value 儲存系統 / (史官)
   • 主要就是記載關於公司的運作狀態，除了皇城的配置，還會記錄現在工作塞給誰了。
     
3. kube-scheduler / 調度器 / (馴獸師)
   • 領班、監工
   • 負責分派 Pod 給 Worker Node 的組件。
4. kube-controller-manager / 核心控制器 / 控制器的老大
   • 是一支 Binary 執行檔，用來管理各種 Controller。
   • 為了讓士、農、工、商，各司其職。
     
   • 好比是個三省六部、皇城中，行政單位各自執掌不同業務的程式。
   • 在高可用的配置下，kube-controller-manager 會運行在複數個 Master Node 中，但只有一個在做事，其他幾個在看戲並且等做事的那個炸裂後，上線取代他。
   • 透過 Leader Election (領導人選舉) 選出老大。
   • 所以 Controller 是什麼？
     • 簡單地說，就是一堆目的不同的控制器，比方說用來管理節點的控制器、管理定時任務的控制器、⋯⋯。
     • 要深入細講的話，這個問題很大喔，後面再說。
5. (選用) cloud-controller-manager / 擴充的控制器
   • 在 K8s 以前，是 API Server 的一部分，不過隨著各家都拿 K8s 去包成產品，為了解耦(Decouple)，所以這邊弄一塊給各個廠商擴充的組件。
   • 參考連結：https://kubernetes.io/docs/concepts/architecture/cloud-controller/

小結

• 皇城 Control Plane，再加入一些 Node 當作奴隸來做事。
• 每個奴隸節點中，有個傳令小兵 kubelet，和 總機 API Server 溝通。
• 叢集的狀態、設定等，都會存放在 etcd 中。
• 工作由 Scheduler 分派決策。

OCP 組件

參考對應版本的文件，連結： https://docs.redhat.com/en/documentation/openshift_container_platform/4.19/html/architecture/control-plane#defining-masters_control-plane

Control Plane 和 K8s 相同的部分

• 參考文件，在 Table 6.1. Kubernetes services that run on the control plane 列出了「4大組件」。
• 這邊要表示，OCP 並沒有「去除」或「改寫」K8s 既有的組件喔。 確保與原生 Kubernetes 的功能都支持。

Control Plane 在 OCP 特有的部分

• 參考文件，在 Table 6.2. OpenShift services that run on the control plane 多出了一「一些東西」。

1. openshift-apiserver / API伺服器 / (皇城總機兼發言人)
   • openshift 加強版總機發言人
   • 專屬的 OpenShift resources 諸如： projects、routes、templates 等。
   • 這個組件，由 OpenShift API Server Operator 管理。

   為了讓 OCP 專屬的炫砲功能，要弄些潮指令 oc 出來給使用者呼叫，當然，預設的 K8s API Server 無法辨別 oc 丟來的內容，所以要生出這個組件。

2. openshift-controller-manager / 核心控制器 / 控制器的老大
   • openshift 控制器的老大
   • 管理 OCP 專屬的 Controller
3. OpenShift OAuth API server / 門禁專屬 API伺服器 / (皇城總機兼發言人的擴充)
   • 是一個 「獨立的API Server」，掌管 OAuth 2.0 相關的 API。
   • 這個組件，由 Cluster Authentication Operator 管理。

   因為 OCP 針對容器叢集設計了身份驗證的機制，並且要讓指令可以做出身份驗證，所以需要對 API Server 進行擴充。

4. OpenShift OAuth server / 門禁 / (宮廷侍衛)
   • 是 「OAuth server」 伺服器本體，用來頒布 Token。
   • 這個組件，也是由 Cluster Authentication Operator 管理。

   是 OCP 針對容器叢集設計了身份驗證的機制，請來的保全大哥。

結論

• OCP 專屬的功能，是以額外增加組件的方式實現功能擴充。 原本 kubectl 可以做的，現在走 oc 送過來指令咧，如果是屬於 K8s 的話，就還是交給原生 K8s 的機制處理； OCP 衍生的功能，就讓衍生的對應組件處理。
• 採聚合層的方式，處理 K8s 指令和 OCP 擴充指令。
• 權力核心的組件，如果是以 Pod 的方式運作，比方說各種 Controller，則這些 Pod 是運作在 Master Node 中。
• 使用下列指令分別觀察 OCP 組件 / 指定 namaspace 中，對應的 Pod

  oc get pods -n openshift-apiserver
  oc get pods -n openshift-controller-manager
  oc get pods -n openshift-oauth-apiserver
  

參考資料

1. Fandom / 台北物語台詞
   連結： https://story-of-taipei.fandom.com/zh/wiki/%E5%8F%B0%E5%8C%97%E7%89%A9%E8%AA%9E%E5%8F%B0%E8%A9%9E
2. Wikipedia / 三省六部
   連結： https://zh.wikipedia.org/zh-tw/%E4%B8%89%E7%9C%81%E5%85%AD%E9%83%A8