擴充CPU與GPU資源管理，OpenShift持續強化K8s支援

早先由Red Hat所發展的OpenShift，向來被視為企業採用或建置平臺即服務（PaaS）的解決方案，分為4種形式提供：以開放原始碼軟體提供的OpenShift Origin，以代管式雲端服務提供的OpenShift Online與OpenShift Dedicated，以商用等級軟體提供的OpenShift Enterprise。到了2016年下半之後，Red Hat將OpenShift Enterprise，改名為OpenShift Container Platform，並在這一年9月推出的3.3版本正式定調。

之所以如此，Red Hat表示，是因為OpenShift部署在AWS、Azure等雲端服務的頻率越來越高，而且也不需繼續強調這是一套企業級軟體，若改用Container Platform來稱呼，對於表達OpenShift部署在各種環境時的應用定位，將更為適合。

而從當時至今，OpenShift Container Platform已發布了5個版本，每一版約間隔3或4個月，今年分別於3月、7月、10月，陸續推出了3.9版、3.10版、3.11版。同時，另一個形式的OpenShift Origin從今年8月起，也改名為OKD（Origin community distribution of Kubernetes），將這邊的軟體定調為Kubernetes的發行版本，而OKD將會隨著Kubernetes版本更新而推出新版，舉例來說，OKD 1.10會包含Kubernetes 1.10。

整體而言，OpenShift Container Platform是架構在三套軟體技術之上，包括Docker格式的Linux容器、Kubernetes調度指揮環境，以及Red Hat Enterprise Linux 7作業系統，並且支援幾種常用的程式語言，像是Java、Ruby、PHP。

而從開始改名到最近發行的版本而言，變化比較大的是3.7版和3.10版。前者增加了Service Catalog、Ansible Broker、Template Broker，以及與AWS眾多雲端服務的整合。

以Service Catalog為例，有了這項特色，企業在OpenShift Container Platform執行的所有應用系統，可以透過這份服務型錄來連接多種現成的服務，開發人員能在裡面尋找程式執行時期的元件（runtimes）、框架與服務，也可以產生應用程式服務，或是將其與OpenShift的應用程式進行綁定黏合（bind）。

從3.7版開始，OpenShift Container Platform開始提供Service Catalog的特色，而這是針對Kubernetes環境的Open Service Broker API（OSB API）所實作出來的。用戶可以將任何部署在OpenShift Container Platform的應用程式，連接到各種Service Brokers。
有了Service Catalog，叢集管理者可以透過單一API規格來整合多種平臺，而在OpenShift Container Platform的網頁主控臺，我們可以在Service Catalog瀏覽目前提供的叢集服務類別，尋找與啟動這些服務，以便與應用程式相互搭配。
對於服務的使用者來說，能夠以簡易、一致的方式，存取不同供應者設立的各種服務，而對於服務供應者而言，也能獲得多種平臺整合為一的好處。

在OpenShift Container Platform 3.7裡面，提供多種立即可用的Service Broker，像是OpenShift Templates Broker、Ansible Service Broker。前者能讓你用OpenShift範本來建立一套Service Catalog服務，後者則是實作了一套OSB API，讓你能夠管理由Ansible Playbook Bundles（APBs）所定義的應用程式。
到了3.9版的OpenShift Container Platform，開始提供AWS Service Broker，整合在AWS OpenShfit Quickstart的參考部署程式碼當中，可供應資料庫、佇列與訊息類型的雲端服務，像是RDS、DynamoDB、EMR、SQS、SNS，以及人工智慧、資安類型的雲端服務，像是Kinesis、Lex、Polly、KMS等。

使用者若要從供應者取得服務，往往要歷經訊息溝通、確認身分、增添應用程式與部署應用程式的步驟，而在OpenShift Container Platform引進的Service Catalog當中，希望提供一個自動化的工作流程，讓使用者更方便尋找所需的服務項目，並且更快取得服務，因此，Red Hat在服務使用者與服務供應者之間，加入了Service Catalog和Service Broker，分別負責服務資訊的列舉與查找功能，以及服務相關執行個體的建立作業。

至於3.10版，則是強化運算層面的功能、推出OpenShift Container Storage（原名為Red Hat Container Native Storage），以及擴充路由層選項（NGINX Router、NGINX Plus Router）。

對於運算的支援，OpenShift Container Platform首先是提升中央處理器的管理。Red Hat在此正式提供了CPU Manager，可同時管理由多個中央處理器所集結的運算資源群組，基於指定的工作負載來區分不同群組，也能針對特定處理器，設定工作負載的限制。

3.10版另一個運算相關新特色，是Device Manager，這是一種透過Kubernetes節點層級的代理程式Kubelet，搭配廠商提供的裝置外掛（Device Plug-in，本身是容器映像），提供存取特定節點硬體資源的方法。

該功能的出現，主要是針對Kubernetes需因應效能密集型的工作負載，而需用到GPU、FPGA、InfiniBand等特殊裝置的狀況，已經日益頻繁，而OpenShift Container Platform在3.10版支援Device Plug-in的API，簡化這類裝置的註冊程序。對此，Red Hat目前已跟Nvidia合作，而能在OpenShift的叢集裡面，安裝與啟用該公司的GPU裝置。

這是近期OpenShift Container Platform的版本演進，以及提供的功能、特色清單，看得出來Red Hat目前維持了每季推出新版的頻率。

產品資訊

Red Hat OpenShift Container Platform 3.10
●原廠：Red Hat(02)7743-2972
●建議售價：廠商未提供
●組成架構：主系統、一般節點、外部etcd節點、Ansible Controller
●作業系統需求：RHEL 7.4/7.5，或是RHEL Atomic Host 7.4.5
●核心元件版本：Docker 1.13.1-x、Kubernetes 1.10、OpenVswitch 2.9.0
●主系統硬體需求：4顆vCPU、16 GB記憶體、42 GB硬碟空間
●一般節點硬體需求：1顆vCPU、8 GB記憶體、17 GB硬碟空間

【註：規格與價格由廠商提供，因時有異動，正確資訊請洽廠商】