近十年來,資訊科技領域在經歷一場技術大變革,這場變革正將我們由傳統IT架構及其所支撐的臃腫應用系統時代,遷移至雲原生架構及其所支撐的敏捷應用系統時代。在這場變革中,新技術的出現、更新和淘汰之迅速,以及新技術的架構整合度、複雜度之高,都是前所未有的。從虛擬化到雲端計算,從虛擬機器到容器,從微服務到無伺服器計算,技術的持續演進和推陳出新在不斷重構企業的組織文化和商業邏輯的同時,也在推動企業朝著數字化、智慧化時代邁進。 

但是,頻繁更新的技術及其複雜程度給IT從業者,尤其是企業開發人員,也帶來了空前的挑戰,如何在保證業務高速發展的前提下,仍然保持持續創新的能力和對眾多新技術的學習研究、掌握應用的能力,是每位IT從業者都在思考和權衡的問題。此外,如何從複雜多變的軟體技術體系中把握住未來的技術趨勢,並將之提前佈局應用到業務創新領域,以便掌握競爭先機,這是每個企業的技術負責人必須考慮的問題。平臺技術和開源社群為我們提供瞭解決問題的途徑,而這也正是我們選擇OpenShift開源PaaS平臺的原因之一。 

1.3.1 OpenShift及其發展簡史 

OpenShift是由RedHat推出的企業級Kubernetes平臺,其主要目標是構建以OCI(Open Container Initiative)容器封裝和Kubernetes容器叢集管理為核心,對應用生命週期進行管理並實現DevOps工具鏈等完整功能的開源容器PaaS平臺。OpenShift對應用的持續開發、多租戶部署和安全管控等進行了優化,並在Kubernetes的基礎上增加了以開發人員和操作管理為中心的工具集,以便實現應用程式的快速開發、輕鬆部署、簡單擴充套件和全生命週期的維護。OpenShift在上游開源社群的版本名稱是OKD(最初叫Origin),OKD版本與Kubernetes發行版本相對應,如OKD 1.10對應Kubernetes 1.10。

 

需要指出的是,OpenShift並非在誕生之初就是以Docker和Kubernetes為核心的PaaS平臺。OpenShift誕生於2011年,主要依賴於Linux容器來部署和執行使用者應用程式,在OpenShift的v1和v2版本中,使用的一直是RedHat自己特定於專有平臺的容器執行時和容器編排引擎。早期的OpenShift使用一種稱為“Gear”的專有容器技術,並通過一種稱為“Cartridge”的技術來製作容器模板。隨著2013年Docker容器技術的問世和流行,RedHat開始與Docker公司合作,並在2014年8月宣佈將在OpenShift v3版本中採用Docker容器。隨著Docker容器技術的普及,以Mesos、Docker Swarm和Kubernetes為主的大規模容器叢集編排排程引擎開始出現,RedHat也逐漸意識到容器編排引擎在OpenShift中的重要性,並在進行了一系列調研之後選擇了Kubernetes作為OpenShift v3版本的排程引擎。

 

2015年,對於RedHat來說具有劃時代意義的OpenShift v3版本誕生,由OpenShift v1和v2版本中基於“Gear”和“Cartridge”的技術,完全重構為v3版本中基於Docker和Kubernetes的技術,OpenShift v3開始以標準和開放的姿態領跑PaaS。在Kubernetes之上,OpenShift v3又引入了強大的使用者介面,通過原始碼到映象(Source-to-Image,S2I)和管道(Pipeline)技術快速建立和部署應用程式,OpenShift v3版本迅速獲得了大量開發者,併成為PaaS當仁不讓的王者。然而,OpenShift的發展並未停止,在2018年完成對CoreOS的收購,對Service Mesh(Istio)和Serverless(Knative)等技術的整合,並使用Kubernetes Operator來實現應用程式管理的自動化之後,RedHat在2019年釋出了OpenShift v4版本(如圖1-11所示)。OpenShift v4版本的問世,意味著全棧融合PaaS時代的到來,向上通過Operator實現應用全生命週期的自動化管理,向下通過CoreOS實現基礎設施的自動化管理。也許未來,裸機以上都將在OpenShift的統管之下!

 

圖1-11 OpenShift發展簡史

 

1.3.2 OpenShift與雲原生架構

 

在雲原生架構時代,我們在談數字化轉型的時候,實質上就是在談組織架構、應用流程和基礎架構設施的轉型。近十年來,我們的開發流程從瀑布到敏捷再到DevOps,應用架構從單體到多層再到微服務架構,軟體交付與封裝經歷了物理機、虛擬機器再到容器,應用執行的基礎設施也從傳統資料中心到主機託管再到雲端計算(如圖1-12所示),技術的變革在多個維度同時進行,雲端計算、DevOps、容器、微服務架構等技術的成熟與普及,事實上也預示著雲原生時代的到來。

 

在雲原生時代,企業應該如何構建自己的雲原生平臺,以支撐其數字化轉型過程中的應用雲化遷移呢?企業若要從下至上地構建自己專屬的雲原生平臺,其過程將是極其複雜的。我們以完全採用開源技術棧構建雲原生平臺為例,首先需要通過Linux、OpenStack、Ceph等開源系統和叢集軟體構建IaaS層,然後再基於Kubernetes和Docker技術來構建PaaS層。事實上難度是在PaaS層的構建上,因為在PaaS層,基於Kubernetes的功能,我們還需要自己實現對多語言執行環境、各類中介軟體、資料庫等服務編目的支援,實現應用的自動構建與部署、基於CI/CD和DevOps的應用全生命週期管理,實現映象倉庫、日誌、監控、服務追蹤、安全和多租戶等叢集管理功能,實現基於Web的叢集管理和自助服務的極好使用者體驗,實現對諸如Istio等微服務架構和Knative等Serverless應用架構的支援。

 

而這一切的實現,對於很多企業而言,將會是個極大的挑戰。因為這需要整合來自眾多開源社群的軟體,而每一個開源軟體的應用都意味著極大的學習成本、時間成本以及不確定性風險。然而,驅動開源社群、整合開源技術正是OpenShift的價值所在。如圖1-13所示,RedHat以OpenShift為中心,以其多年在開源社群的耕耘為基礎,以開源方式集成了使用者所能想到和用到的各種開源軟體。從這個層面上來講,我們可以認為OpenShift本身就是個整合創新引擎。

 

 圖1-12 資訊科技的變革

圖1-13 OpenShift生態圈整合創新引擎

 

因此,藉助OpenShift構建企業級雲原生平臺將會事半功倍。因為在最新的OpenShift v4版本中,藉助不可變容器作業系統CoreOS,裸機以上部分,OpenShift已完全實現自動化接管。當然,OpenShift也支援在公有云、私有云和混合雲上部署實現,目前已支援在AWS、Azure、GCP、OpenStack和vSphere等公有云和私有云平臺上的自動部署。因此,藉助企業級開源PaaS平臺OpenShift,企業雲原生平臺的構建將可一步到位。如圖1-14所示,OpenShift已基本整合並實現了雲原生平臺所需的全部軟體和功能。

 

圖1-14 OpenShift構建企業雲原生平臺

 

1.3.3 OpenShift與Kubernetes

 

Kubernetes是主流的容器編排引擎,也是CNCF孵化出的最成功的專案。在一定程度上,可以認為OpenShift的成功離不開Kubernetes社群的支援,或者說正是Kubernetes的成功賦予了OpenShift極強的生命力,Kubernetes已成為OpenShift不可分割的一部分。前文提到,OpenShift v3以後的版本都是基於CRI容器技術和Kubernetes重構的版本,那麼OpenShift與Kubernetes之間究竟有什麼關係?企業為什麼不直接使用Kubernetes而要選擇使用OpenShift呢?或者說選擇OpenShift的企業使用者將會獲得什麼好處呢?本節中我們將就這幾個問題進行重點討論,以消除很多使用者對於OpenShift和Kubernetes的困惑。

 

首先,我們要清楚OpenShift更偏向於一個產品,而Kubernetes是一個開源專案。這就意味著OpenShift在安全性、易用性、多租戶和使用者體驗等方面必然優於Kubernetes,這是一個產品區別於一個開源專案最明顯的地方(OpenShift企業級功能特性如圖1-15所示)。舉一個比較直觀的例子,OpenShift 的使用者介面介面體驗要遠優於Kubernetes原生介面。OpenShift的商業產品叫作OpenShift容器平臺(OpenShift Container Platform,OCP),通過訂閱RedHat的OCP服務,企業使用者可以獲得來自RedHat的專業服務和支援,而如果使用Kubernetes,就只能獲取社群的技術支援,這是很多企業使用者在進行技術選型時的一個重要考慮因素。另外,OpenShift也提供了開源版本OKD,OKD具有與商業版本類似的功能,只是RedHat不提供技術支援和服務,使用者需要自己對OKD有較為深入的理解。(幫助使用者理解OKD正是我們寫作本書的目的所在。)

 

圖1-15 OpenShift企業級功能特性

 

其次,OpenShift發行的每個版本與Kubernetes基本上是對應的,Kubernetes每年大概發行4個版本,與之對應的OpenShift版本通常會滯後1到3個月發行,在這段時間內RedHat會對最新的Kubernetes版本進行測試,並在缺陷(Bug)和效能問題修復後,整合各種經過驗證的中介軟體服務和功能軟體,如用於CI/CD管道的Jenkins、用於監控的Prometheus、用於視覺化的Grafana、服務網格Istio、無伺服器計算Knative等。所以,OpenShift在穩定性和軟體整合度上要遠優於直接使用Kubernetes。

 

最後,雖然OpenShift是基於Kubernetes實現的,但是OpenShift也會反饋並驅動Kubernetes的發展。OpenShift的產品屬性決定了其目標使用者是企業而非個人,因此OpenShift中很多企業級的需求和功能最終也會反饋到Kubernetes社群中,如Kubernetes中的Ingress、Deployment的部分功能實現就分別來自OpenShift中的Route和Deployment Configurations。另外,Kubernetes中基於角色的訪問控制(RBAC)功能也源自OpenShift。所以說,就企業使用者而言,OpenShift有更多適合企業使用的功能,而Kubernetes通常需要在企業使用者反饋後才能開發出這些功能。OpenShift的產品屬性決定了其會主動滿足企業使用者需求,而Kubernetes的專案屬性決定了其是被動響應企業使用者需求。

 

總體而言,從功能上來看,Kubernetes具備的功能特性OpenShift一定具備,但是OpenShift具有的某些企業級功能特性Kubernetes卻不一定擁有。從整合度上來看,OpenShift是基於Kubernetes的高度整合產品,如果將OpenShift看成作業系統,那麼Kubernetes就是這個系統的核心。系統極客只需安裝核心,然後自己編譯安裝需要的依賴軟體,也能執行應用程式,但是對於普通使用者而言,一個僅有核心系統的使用成本和代價都是極高的。簡單來說,Openshift是一個用於構建、部署和智慧化管理生產環境中Kubernetes應用程式的完整平臺,通過OpenShift這個完整的PaaS平臺,我們即可一步到位地邁向雲原生時代!

 

購買連結:https://item.jd.com/12640959.html

 

 

 

感謝您的閱讀,歡迎關注我的微信公眾號:

&n