前言

本系列文章，打算利用三十篇文章來分析和比較，OpenShift Container Platform 相較於其他種 Kubernetes 的解決方案。 至於為什麼要選這個題目？ 因為工作上遇到了，真的沒有拿錢打廣告。 相信正在閱讀的你，或許也是在工作所需，搜尋到什麼關鍵字，剛好點進來。

自問自答

由於本系列文章始撰寫於 2025/08/18，最新版本的 OCP 是 4.19。 內容可能時間推移與產品迭代而有所不同，因此著重在觀念的部分進行撰寫。

Q1: 什麼是 OCP?

這邊的 OCP 所指的是一種產品的名稱的縮寫，由 Red Hat (紅帽公司) 所推出的 OpenShift Container Platform。 你可以把它理解成由紅帽公司，基於 Kubernetes 這個開源專案，加上 Apache 2.0 License (允許商用、且不用開源你修改的部分；License 需註明原作者)，去改裝出來的產品。

Q2: Kubernetes (K8s) 又是什麼?

• 話說盤古開天闢地的時候，還沒有電腦，沒有虛擬化，也沒有容器的概念。 以下故事從 2014 年，Kubernetes 公開後說起，更多關於 Kubernetes 的歷史，建議可以先去看看 「Kubernetes 的十年」一文；我們先預設大部分的人已經使用容器大量部署，並且在管理上有一定的複雜程度，並且使用。
• 至於 K8s 和 OCP 兩者之間的關係，前面一個問題已經說明：先有開源的 K8s 專案，且允許被改寫改裝變成商用產品，因而在 Red Hat 公司誕生了 OCP 這個產品。
  當然，其他業者也都改裝成自己的樣子，也有各自的特性與生態系，諸如公有雲的解決方案，如 AWS 的 EKS、GCP 的 GKE、Azure 的 AKS、Alibaba 的 ACK ；或是像 VMware 的 Tanzu。
• K8s 和 OCP 兩者之間的差異，這個問題不太容易用幾句話解釋，需要做表格比較。 或者讓我用後面幾篇文章逐一比較。

Q3: 基於什麼理由，選擇付費的 OCP 而非直接用免費的 K8s？

這個問題，通常不是工程師決定的。
端看公司是否願意花錢解決麻煩問題，有錢的話就「直接買產品來用」，從前期的「安裝部署」、完工後的「教育訓練」、定期的「維運」、出問題的時候還可以找廠商「諮詢」。
公司想省錢的話，就直接從開源的專案開始一點一點的蓋，透過支付人力換取類似的功能。
以目前筆者所接觸過採用 OCP 作為容器叢集的多為金融相關產業，這類型的客戶偏好穩定、安全性，另外最大的考量在於 「合規性」，採用 OCP 可以 「落地」，設施和資料都放在自己家。

Q4: 作為學習者，如何開始接觸？

1. 認識 Docker Container
2. 學習 K8s 的觀念與術語
3. 透過 Red Hat Document 學習 OCP 以及其周邊產品的使用方式

結論

1. 不論是否為初學，都很建議花些時間進行測驗 Take a free skills assessment to see where you should start training 來確認自己的知識水平。
2. 那些雲端業者提供的 K8s 解決方案，「控制平面(Control Plane)」是 Fully-Managed，意思是由雲端業者將控制平面，運行在雲端設施中，使用者只能決定要使用的 K8s 版本，以及透過雲端業者提供的界面進行調整，至於控制平面所運作的系統則無法直接觸及；而 OCP 是支援 Self-Managed / Fully-Managed 的容器叢集產品，除了自建叢集的自行管理控制平面，也有由雲端業者事先搞定 OCP控制平面的全託管控制平面。
3. OCP 雖然可以自建叢集，決定要用多少台主機、運算資源作為控制平面的基礎設施，但是「Master Node」只能是「Red Hat CoreOS」。「Worker Node」只能是「Red Hat CoreOS」或「Red Hat Enterprise Linux」
   
   (圖片來源： OCP 官方手冊 / Chapter 2. Introduction to OpenShift Container Platform)

參考資料

1. OCP 官方手冊 / Chapter 2. Introduction to OpenShift Container Platform