一 OpenShift特性
1.1 OpenShift概述
Red Hat OpenShijft Container Platform (OpenShift)是一個容器應用程式平臺，它為開發人員和IT組織提供了一個雲應用程式平臺，用於在安全的、可伸縮的資源上部署新應用程式，而配置和管理開銷最小。
OpenShift構建於Red Hat Enterprise Linux、Docker和Kubernetes之上，為當今的企業級應用程式提供了一個安全且可伸縮的多租戶作業系統，同時還提供了整合的應用程式執行時和庫。
OpenShift帶來了健壯、靈活和可伸縮的特性。容器平臺到客戶資料中心，使組織能夠實現滿足安全性、隱私性、遵從性和治理需求的平臺。不願意管理自己的OpenShift叢集的客戶可以使用Red Hat提供的公共雲平臺OpenShift Online。
1.2 OpenShift特性
OpenShift容器平臺和OpenShift Online都是基於OpenShift Origin開源軟體專案的，該專案本身使用了許多其他開源專案，如Docker和Kubernetes。
應用程式作為容器執行，容器是單個作業系統內的隔離分割槽。容器提供了許多與虛擬機器相同的好處，比如安全性、儲存和網路隔離，同時需要的硬體資源要少得多，啟動和終止也更快。OpenShift使用容器有助於提高平臺本身及其承載的應用程式的效率、靈活性和可移植性。
OpenShift的主要特性如下:
- 自助服務平臺：OpenShift允許開發人員使用Source-to-Image(S21)從模板或自己的原始碼管理儲存庫建立應用程式。系統管理員可以為使用者和專案定義資源配額和限制，以控制系統資源的使用。
- 多語言支援：OpenShift支援Java、Node.js、PHP、Perl以及直接來自Red Hat的Ruby。同時也包括來自合作伙伴和更大的Docker社群的許多其他程式碼。MySQL、PostgreSQL和MongoDB資料庫。Red Hat還支援在OpenShift上本地執行的中介軟體產品，如Apache httpd、Apache Tomcat、JBoss EAP、ActiveMQ和Fuse。
- 自動化：OpenShift提供應用程式生命週期管理功能，當上遊源或容器映像發生更改時，可以自動重新構建和重新部署容器。根據排程和策略擴充套件或故障轉移應用程式。
- 使用者介面：OpenShift提供用於部署和監視應用程式的web UI，以及用於遠端管理應用程式和資源的CLi。它支援Eclipse IDE和JBoss Developer Studio外掛，以便開發人員可以繼續使用熟悉的工具，並支援REST APl與第三方或內部工具整合。
- 協作：OpenShift允許在組織內或與更大的社群共享專案。
- 可伸縮性和高可用性：OpenShift提供了容器多租戶和一個分散式應用程式平臺，其中包括彈性，以處理隨需增加的流量。它提供了高可用性，以便應用程式能夠在物理機器當機等事件中存活下來。OpenShift提供了對容器健康狀況的自動發現和自動重新部署。
- 容器可移植性：在OpenShift中，應用程式和服務使用標準容器映像進行打包，組合應用程式使用Kubernetes進行管理。這些映像可以部署到基於這些基礎技術的其他平臺上。
- 開源：沒有廠商鎖定。
- 安全性：OpenShift使用SELinux提供多層安全性、基於角色的訪問控制以及與外部身份驗證系統(如LDAP和OAuth)整合的能力。
- 動態儲存管理：OpenShift使用Kubernetes持久卷和持久卷宣告的方式為容器資料提供靜態和動態儲存管理
- 基於雲(或不基於雲)：可以在裸機伺服器、活來自多個供應商的hypervisor和大多數IaaS雲提供商上部署OpenShift容器平臺。
- 企業級：Red Hat支援OpenShift、選定的容器映像和應用程式執行時。可信的第三方容器映像、執行時和應用程式由Red Hat認證。可以在OpenShift提供的高可用性的強化安全環境中執行內部或第三方應用程式。
- 日誌聚合和metrics：可以在中心節點收集、聚合和分析部署在OpenShift上的應用程式的日誌資訊。OpenShift能夠實時收集關於應用程式的度量和執行時資訊，並幫助不斷優化效能。
- 其他特性：OpenShift支援微服務體系結構，OpenShift的本地特性足以支援DevOps流程，很容易與標準和定製的持續整合/持續部署工具整合。
二 OpenShift架構
2.1 OpenShift架構概述
OpenShift容器平臺是一組構建在Red Hat Enterprise Linux、Docker和Kubernetes之上的模組化元件和服務。OpenShift增加了遠端管理、多租戶、增強的安全性、應用程式生命週期管理和麵向開發人員的自服務介面。
OpenShift的架構：
- RHEL：基本作業系統是Red Hat Enterprise Linux；
- Docker：提供基本的容器管理API和容器image檔案格式；
- Kubernetes：管理執行容器的主機叢集(物理或虛擬主機)。它處理描述由多個資源組成的多容器應用程式的資源，以及它們如何互連；
- Etcd：一個分散式鍵值儲存，Kubernetes使用它來儲存OpenShift叢集中容器和其他資源的配置和狀態資訊。
OpenShift在Docker + Kubernetes基礎設施之上新增了提供容器應用程式平臺所需的更富豐的功能：
OpenShift-Kubernetes extensions：其它資源型別儲存在Etcd中，由Kubernetes管理。這些額外的資源型別形成OpenShift內部狀態和配置，以及由標準 Kubernetes管理的應用程式資源；
Containerized services：完成許多基礎設施功能，如網路和授權。其中一些一直執行，另一些則按需啟動。OpenShift使用Docker和Kubernetes來實現大多數內部功能。即大多數OpenShift內部服務作為由Kubernetes管理的容器；
Runtimes and xPaaS：供開發人員使用的 base image，每個image都預配置了特定的runtime或db。xPaaS提供了一組用於JBoss中介軟體產品（如JBoss EAP和ActiveMQ）的 base image；
DevOps tools and user experience：OpenShift提供了Web UI和CLI管理工具，從而實現配置和監視應用程式、OpenShift服務和資源。Web和CLI工具都是由相同的REST api構建的，可供IDE和CI平臺等外部工具使用。OpenShift 還可以訪問外部SCM儲存庫和容器registry，並將它們的構件引入OpenShift Cloud。
OpenShift不會向開發人員和系統管理員遮蔽Docker和Kubernetes的核心基礎設施。相反，它將它們用於內部服務，並允許將Docker和Kubernetes資源匯入OpenShift叢集，同時原始Docker和資源可以從OpenShift叢集匯出，並匯入到其他基於docker的基礎設施中。
OpenShift新增到Docker + Kubernetes的主要價值是自動化開發工作流，因此應用程式的構建和部署在OpenShift叢集中按照標準流程進行。開發者不需要知道底層Docker的細節。OpenShift接受應用程式，打包它，並將其作為容器啟動。
2.2 Master和nodes
OpenShift叢集是一組節點伺服器，它們執行容器，並由一組主伺服器集中管理。伺服器可以同時充當master和node，但是為了增加穩定性，這些角色通常是分開的。
OpenShift工作原理和互動檢視：
master節點執行OpenShift核心服務，如身份驗證，並未管理員提供API入口。
nodes節點執行包含應用程式的容器，容器又被分組成pod。
OpenShift master執行Kubernetes master服務和Etcd守護程式；
node執行Kubernetes kubelet和kube-proxy守護程式。
雖然在描述中通常沒有宣告，但實際上master本身也是node。
scheduler和management/replication是Kubernetes主服務，而Data Store是Etcd守護程式。
Kubernetes的排程單元是pod，它是一組共享虛擬網路裝置、內部IP地址、TCP/UDP埠和持久儲存的容器。pod可以是任何東西，從完整的企業應用程式(包括作為不同容器的每一層)到單個容器中的單個微服務。例如，一個pod，一個容器在Apache下執行PHP，另一個容器執行MySQL。
Kubernetes管理replicas來縮放pods。副本是一組共享相同定義的pod。
三 管理OpenShift
3.1 OpenShift專案及應用
除了Kubernetes的資源(如pods和services)之外，OpenShift還管理projects和users。一個projects對Kubernetes資源進行分組，以便使用者可以使用訪問許可權。還可以為projects分配配額，從而限制了已定義的pod、volumes、services和其他資源。
OpenShift中沒有application的概念，OpenShift client提供了一個new-app命令。此命令在projects中建立資源，但它們都不是應用程式資源。這個命令是為標準開發人員工作流配置帶有公共資源的proiect的快捷方式。
OpenShift使用lables(標籤)對叢集中的資源進行分類。預設情況下，OpenShift使用app標籤將相關資源分組到應用程式中。
3.2 使用Source-to-image構建映像
OpenShift允許開發人員使用標準原始碼管理倉庫(SCM)和整合開發環境(ide)來發布應用。
OpenShift中的source -to-lmage (S2I)流程從SCM倉庫中提取程式碼，自動判斷所需的runtime，基於runtime啟動一個pod，在pod中編譯應用。
當編譯成功時，將在runtime image中新增層並形成新的image，推送進入OpenShift internal registry倉庫，接著基於這個image將建立新的pod，執行應用程式。
S2I可被視為已經內建到OpenShift中的完整的CI/CD管道。
CI/CD有不同的形式，根據具體場景表現不同。例如，可以使用外部CI工具(如Jenkins)啟動構建並執行測試，然後將新構建的映像標記為成功或失敗，將其推送到QA或生產。
3.2 管理OpenShift資源
OpenShift資源定義,如image、container、pod、service、builder、template等，都儲存在Etcd中，可以由OpenShift CLI, web控制檯或REST API進行管理。
OpenShift的資源科通過JSON或YAML檔案檢視，並且在類似Git或版本控制的SCM中共享。OpenShift甚至可以直接從外部SCM檢索這些資源定義。
大多數OpenShift操作不需要實時響應，OpenShift命令和APIs通常建立或修改儲存在Etcd中的資源描述。Etcd然後通知OpenShift控制器，OpenShift控制器會就更改警告這些資源。
這些控制器採取行動，以便使得資源的最終態反應達到更改效果。例如，如果建立了一個新的pod資源，Kubernetes將在node上排程並啟動該pod，使用pod資源確定要使用哪個映像、要公開哪個埠，等等。或者一個模板被更改，從而指定應該有更多的pod來處理負載，OpenShift會安排額外的pod(副本)來滿足更新後的模板定義。
注意：雖然Docker和Kubernetes是OpenShift的底層，但是必須主要使用OpenShift CLi和OpenShift APls來管理應用程式和基礎設施。OpenShift增加了額外的安全和自動化功能，當直接使用Docker或Kubernetes命令和APls時，這些功能必須手動配置，或者根本不可用。因此強烈建議不要使用docker或Kubernetes的命令直接管理應用。
四 OpenShift網路
4.1 OpenShift網路概述
Docker網路相對簡單，Docker建立一個虛擬核心橋接器（docker0網路卡），並將每個容器網路介面連線到它。
Docker本身沒有提供允許一個主機上的pod連線到另一個主機上的pod的方法。Docker也沒有提供嚮應用程式分配公共固定IP地址的方法，以便外部使用者可以訪問它。
但Kubernetes提供service和route資源來管理pods之間的網路，以及從外部到pods的路由流量。service在不同pods之間提供負載均衡用於接收網路請求，同時為service的所有客戶機(通常是其他pods)提供一個內部IP地址。
container和pods不需要知道其他pods在哪裡，它們只連線到service。route為service提供一個固定的惟一DNS名稱，使其對OpenShift叢集之外的客戶端可見。
Kubernetes service和route資源需要外部（功能）外掛支援。service需要軟體定義的網路(SDN)，它將在不同主機上的pod之間提供通訊，route需要轉發或重定向來自外部客戶端的包到服務內部IP。
OpenShift提供了一個基於Open vSwitch的SDN，路由由分散式HAProxy farm提供。
五 OpenShift永續性儲存
5.1 永久儲存
pod可以在一個節點上停止，並隨時在另一個節點上重新啟動。同時pod的預設儲存是臨時儲存，通過對於類似資料庫需要永久儲存資料的應用不適合。
Kubernetes為管理容器的外部持久儲存提供了一個框架。Kubernetes提供了PersistentVolume資源，它可以在本地或網路中定義儲存。pod資源可以使用PersistentVolumeClaim資源來訪問對應的持久儲存卷。
Kubernetes還指定了一個PersistentVolume資源是否可以在pod之間共享，或者每個pod是否需要具有獨佔訪問權的自己PersistentVolume。當pod移動到另一個節點時，它將保持與相同的PersistentVolumeClaim和PersistentVolumne資源的關聯。這意味著pod的持久儲存資料跟隨它，而不管它將在哪個節點上執行。
OpenShift向Kubernetes提供了多種VolumeProvider，如NFS、iSCSI、FC、Gluster或OpenStack Cinder。
OpenShift還通過StorageClass資源為應用程式提供動態儲存。使用動態儲存，可以選擇不同型別的後端儲存。後面儲存根據應用程式的需要劃分為不同的“tiers”。例如，可以定義一個名為“fast”的儲存類和另一個名為“slow”的儲存類，前者使用更高速的後端儲存，後者提供普通的儲存。當請求儲存時，終端使用者可以指定一個Persistentvolumeclaim，並使用一個註釋指定他們所需的StorageClass。
六 OpenShift高可用
6.1 OpenShift高可用概述
OpenShift平臺叢集的高可用性(HA)有兩個不同的方面：
OpenShift基礎設施本身的HA(即主機)；
以及在OpenShift叢集中執行的應用程式的HA。
預設情況下，OpenShift為master提供了完全支援的本機HA機制。
對於應用程式或“pods”，如果pod因任何原因丟失，Kubernetes將排程另一個副本，將其連線到服務層和持久儲存。如果整個節點丟失，Kubernetes會為它所有的pod安排替換節點，最終所有的應用程式都會重新可用。pod中的應用程式負責它們自己的狀態，因此它們需要自己維護應用程式狀態(如HTTP會話複製或資料庫複製)。
七 Image Streams
7.1 Image Streams
要在OpenShift中建立一個新的應用程式，除了應用程式原始碼之外，還需要一個base image(S2I builder image)。如果原始碼或image任何一個更新，就會生成一個新的image，並且基於此新image建立新的pod，同時替換舊的pod。
即當應用程式程式碼發生更改時，容器映像需要更新，但如果構建器映像發生更改，則部署的pod也需要更新。
Image Streams包括由tag標識的大量的image。應用程式是針對Image Streams構建的。Image Streams可用於在建立新image時自動執行操作。構建和部署可以監視Image Streams，以便在新增新image時接收通知，並分別執行構建或部署。
OpenShift預設情況下提供了幾個Image Streams，包括許多流行的runtime和frameworks。
Image Streams tag是指向Image Streams中的image的別名。通常縮寫為istag。它包含一個image歷史記錄，表示為tag曾經指向的所有images的堆疊。
每當使用特定的istag標記一個新的或現有的image時，它都會被放在歷史堆疊的第一個位置(標記為latest)。之前tag再次指向舊的image。同時允許簡單的回滾，使標籤再次指向舊的image。