幾年前在Docker聲勢如日中天，但Kubernetes（K8S）尚未火紅之前，紅帽（Red Hat）就已看重Docker與K8S技術整合的價值，旗下的OpenShift從社群發展初期即已納入整合，推動PaaS演進到CaaS（容器即服務）。
2018年初再宣布收購CoreOS，進而補強Day 2的維運管理能力，同時也沿襲自OpenShift 3.9版開始內建資安法規遵循的佈建範本，例如ISO 27001、PCI-DSS、FISMA等，讓企業得以參考最佳實踐建置。
紅帽資深解決方案架構師彭信忠指出，納入CoreOS技術範式主要是針對核心架構的改變，對於使用者而言不會感受到差異。事實上從PaaS演進到CaaS平台，用戶操作模式變化不多，甚至佈建的架構也相同，實際上核心層卻是持續不斷地發展進行優化與改造。
OpenShift跟所有基於K8S調度工具打造的控管方式相同，不管作業系統採用的版本，安裝時必須先拉（Pull）回套件，執行後納入系統服務，即可開始操作，後續維運則是Linux系統常見的Systemd管理方法。目前的OpenShift 3.11版本仍然沿用，預計明年發布的4.0新版，則全部會改以容器操作方式，例如基於Docker Daemon啟動容器服務。
彭信忠說明，改變的目的是為了輔助CaaS維運提升效率，以更簡單的操作方法，為應用服務建立可穩定運行的環境。
以應用為核心思維發展提升運行效率
 |
| ▲紅帽資深解決方案架構師彭信忠提醒，為未來新型態應用建置統一運行平台，或許無法立即彰顯效益，也勢必會面臨來自業務單位的質疑。但是要落實數位化轉型，改造底層架構平台相當關鍵，必須取得高階管理層認同且支持，才得以成功推動。 |
傳統資料中心的實體主機建置數量逐年增長，實際上利用率並不高，才使得硬體虛擬化的做法獲得多數企業認同，持續發展至今可說已相當成熟。但是從應用程式的角度來看，硬體虛擬化後要得以運用來產生價值，仍存在一段差距。
為了讓虛擬化應用變得更有效率，降低開發者資源運用的門檻，業界因此開始轉向尋求以應用為核心發展可提高效率的方法。彭信忠舉例，Java與PHP程式碼的執行階段不同，須盡可能運用封裝的方法事先打包函式庫，以便於應用程式得以快速上線運行，於是產生容器封裝程式碼的概念，跳脫過去虛擬化環境的思維，只是剛好整合了作業系統核心來實作運行。「當然，容器運行環境也有限制之處，就像是Windows作業系統，原生設計的核心結構較難以實作隔離封裝，欲轉換採納容器化技術，勢必得耗費更多時間來落實。」
目前常見的容器化實作方法，首先是工作負載平移（Lift and Shift），也就是把原本應用系統封裝後整個移植到容器環境運行；其次是重構（Refactoring），儘管既有應用系統已相當龐大，仍舊繼續沿用暫時不拆解成微服務；第三種是應用系統基於微服務架構重新撰寫，並運用容器技術封裝運行。
事實上，從應用的角度來發展相關整合技術，彭信忠認為是相當合理的發展方向，畢竟再強大的技術，最終是以商業應用價值來評判，滿足應用需求即為首要具備的能力。而應用的思維則是從最終用戶需求開始，即便是內部員工，如今已經習慣採用各式的App工具來提高生產力，當內部應用系統無法有效率地提供業務所需的功能，IT部門勢必會面臨壓力，必須要有能力快速地滿足各式應用需求，甚至超越預期。
掌握容器狀態強化自動化能力
市場上專注於發展PaaS平台，原本是以虛擬化技術為核心打造容器環境，進展到維運階段時，卻發現功能機制不足之處，因而如今普遍看重K8S提供的控管能力並且納入整合之後，緊接著發展的即是提升K8S維運體驗。
就OpenShift 3.11版本來看，目標即是提供更好的維運體驗，內建設計叢集管理者中控台（Cluster Administrator Console）。彭信忠說明，為了確保應用服務運行，開發者有專屬Console可查看，但維運者則欠缺統整全部叢集狀態資訊的機制，需要進一步整合CloudForms提供統計儀表板。如今的3.11版本設計了叢集管理者中控台，核心是採用K8S發展成熟的Grafana監控與分析，透過儀表板方式呈現統計資訊。
整合CoreOS技術後，OpenShift開始具備Operator框架技術，可協助執行發布，例如部署MySQL叢集，以往必須逐一建立後再設定配置串接，或是在K8S環境中執行事先撰寫好的YAML檔案，Operator則是要把執行部署與維運的邏輯，轉變成為定義檔案，直接套用在K8S環境自動化運作。「Operator已經被廣泛地運用在OpenShift各個環節，甚至接下來的4.0版，會進一步把容器化後的核心函式庫（Library）納入控管。」
Service Mesh監看與保護微服務
前述提及的Operator框架技術可說是Rad Hat發展重點，已被優先納入整合於OpenShift工作流程中。彭信忠指出，現階段的容器是以Image形式呼叫啟用，問題是中介軟體等系統可能會有狀態，意思是容器彼此之間必須綁在一起，才可提供特定價值的服務，但是應用的部署邏輯，其落實的複雜度卻相當高；具備Operator能力後，則可以把應用系統最佳實踐的整體架構事先予以封裝，例如前端應用程式、資料庫、快取等服務，可進一步減少應用配置的程序，同時在封裝時即可套用維運階段所需的操作邏輯定義。例如中介軟體方案AMQ Streams，核心技術為Apache Kafka，由於部署架構規模較大，不容易實作於K8S環境，可透過Operator封裝來降低複雜度。
在各種針對容器環境部署的微服務叢集來進行監看運行狀態的機制中，目前較受社群關注的發展技術是Service Mesh，對此，OpenShift平台上的Service Mesh在3.11版本為預覽，在成為正式發布的功能前，讓企業用戶藉此先行驗證測試。旗下組成元件包含Istio、Kiali、Jaeger等開源專案，監看與保護微服務彼此連接運行，簡化在分布式環境下追蹤根本問題的困難度，同時包含資料流的路線可進一步控制遞送路徑的比重。
「K8S調度運行技術最小單位是一個Pod，以前一個Pod就是一個容器，這是我們對於應用開發者建議的實作模式。」彭信忠說。實際上一個Pod中可涵蓋多個容器，除了應用本體之外，還可以搭配Proxy容器，在應用前方負責監看進出的流量，同時建立用戶端負載平衡機制。既有的Kube-proxy實作方式歸屬於Host層級，而非容器本身，因此可實作Service Mesh在容器環境中增添Proxy，藉此串連複雜的叢集架構，並繪製成拓樸圖來輔助維運。