2.1.3　OpenShift對Kubernetes的增強(qiáng)

從最新Kubernetes社區(qū)代碼貢獻(xiàn)的排名可以看出紅帽在Kubernetes社區(qū)具有重大的影響力，并發(fā)揮著舉足輕重的作用，如圖2-3所示（https://www.stackalytics.com/cncf?project_type=kubernetes）。

早期的Kubernetes功能尚弱，紅帽的OpenShift補(bǔ)充了大量的企業(yè)級功能，并逐漸將這些功能貢獻(xiàn)給上游Kubernetes社區(qū)，此時，Kubernetes和OpenShift共同成長。隨著納入CoreOS優(yōu)秀基因的OpenShift的發(fā)布，OpenShift的功能特性和健壯性大勝往昔，并進(jìn)一步推動Kubernetes社區(qū)的發(fā)展。所以說，OpenShift和Kubernetes是相互推動、相互促進(jìn)的。接下來，我們具體看一下OpenShift對Kubernetes的一些關(guān)鍵性增強(qiáng)。

圖2-3　Kubernetes社區(qū)各公司代碼提交量分析

1.穩(wěn)定性的提升

Kubernetes是一個開源項(xiàng)目，面向容器調(diào)度；OpenShift是企業(yè)級軟件，面向企業(yè)PaaS平臺。OpenShift除了包含Kubernetes，還包含很多其他企業(yè)級組件，如認(rèn)證集成、日志監(jiān)控等。

OpenShift提供企業(yè)版和社區(qū)版，紅帽訂閱客戶可以使用企業(yè)版并獲得OpenShift企業(yè)級支持。Kubernetes有很多發(fā)行版，但由于它是一個社區(qū)開源項(xiàng)目，如果遇到技術(shù)問題，主要依靠社區(qū)或外部專家來解決。

Kubernetes每年發(fā)布4個版本，OpenShift通常使用次新版本的Kubernetes為最新版本產(chǎn)品的組件，這樣保證客戶企業(yè)級PaaS產(chǎn)品的穩(wěn)定性。

2.OpenShift實(shí)現(xiàn)了一個集群承載多租戶和多應(yīng)用

企業(yè)客戶通常需要PaaS集群具備租戶隔離能力，以支持多應(yīng)用和多租戶。多租戶是Kubernetes社區(qū)中一個備受爭議的話題，也是當(dāng)時Kubernetes早期版本所欠缺的。

為解決這個問題，紅帽在許多關(guān)鍵領(lǐng)域投入了大量資源。紅帽推動了Kubernetes RBAC和資源限制Quota的開發(fā)，以便多個租戶可以共享一個Kubernetes集群，并可以做資源限制。紅帽推動了基于Kubernetes角色的訪問控制（RBAC）的開發(fā)，以便可以為用戶分配具有不同權(quán)限級別的角色。2015年發(fā)布的OpenShift 3.0（基于Kubernetes 1.0）就已經(jīng)提供了RBAC的功能；而Kubernetes直到1.6版本才正式提供RBAC功能。當(dāng)年沒有RBAC、Quota這些功能的Kubernetes是無法滿足企業(yè)客戶的需求的。

3.OpenShift實(shí)現(xiàn)了應(yīng)用程序的簡單和安全部署

Kubernetes為應(yīng)用程序提供了諸如Pod、Service和Controller等功能組件，但在Kubernetes 1.0中部署應(yīng)用程序并實(shí)現(xiàn)應(yīng)用程序版本管理并不是一件簡單的事情。紅帽在OpenShift 3.0（基于Kubernetes 1.0）中開發(fā)了DeploymentConfig，以提供參數(shù)化部署輸入、執(zhí)行滾動部署、啟用回滾到先前部署狀態(tài)，以及通過觸發(fā)器驅(qū)動自動部署（BuildConfig執(zhí)行完畢觸發(fā)DeploymentConfig）。紅帽O(jiān)penShift DeploymentConfig中許多功能最終將成為Kubernetes Deployments功能集的一部分，目前OpenShift也完全支持Kubernetes Deployments。

企業(yè)客戶需要更多安全工具來處理正在部署的應(yīng)用程序。容器生態(tài)系統(tǒng)在容器鏡像掃描、簽名等解決方案方面已經(jīng)走過了漫長的道路。但是，開發(fā)人員仍在尋找和部署缺乏任何來源且可能不太安全的鏡像。Kubernetes通過Pod安全策略來提升安全性。例如我們可以設(shè)置Pod以非root用戶方式運(yùn)行。Pod安全策略是Kubernetes中的較新的功能，這也是受OpenShift SCC（安全上下文約束）的啟發(fā)。

為了真正實(shí)現(xiàn)容器鏡像的安全，紅帽致力于消除單一廠商控制的容器鏡像格式和運(yùn)行時（即Docker）。紅帽為Kubernetes開發(fā)了CRI-O，這是一個輕量級、穩(wěn)定且更安全的容器運(yùn)行時，基于OCI規(guī)范并通過Kubernetes CRI集成。目前已經(jīng)在OpenShift中正式發(fā)布。

4.OpenShift幫助Kubernetes運(yùn)行更多類型的應(yīng)用負(fù)載

Kubernetes本身適合無狀態(tài)的應(yīng)用運(yùn)行。但如果企業(yè)中大量有狀態(tài)的應(yīng)用都無法運(yùn)行在Kubernetes上的話，Kubernetes的使用場景終將有限。有狀態(tài)應(yīng)用在Kubernetes上運(yùn)行的最基本要求就是數(shù)據(jù)持久化。為此，紅帽創(chuàng)建了OpenShift存儲Scrum團(tuán)隊(duì)來專注此領(lǐng)域，并為上游的Kubernetes存儲卷插件做出貢獻(xiàn)，為這些有狀態(tài)服務(wù)啟用不同的存儲后端。隨后，紅帽推動了動態(tài)存儲配置的誕生，并推出了OpenShift Container Storage等創(chuàng)新解決方案。紅帽還參與了Kubernetes容器存儲接口（CSI）開源項(xiàng)目，以實(shí)現(xiàn)Pod與后端存儲的松耦合。

5.OpenShift實(shí)現(xiàn)應(yīng)用的快速訪問

Kubernetes 1.0中沒有Ingress的概念，因此將入站流量路由到Kubernetes Pod和Service是一項(xiàng)非常復(fù)雜、需要手工配置的任務(wù)。在OpenShift 3.0中，紅帽開發(fā)了Router，以提供入口請求的自動負(fù)載平衡。Router是現(xiàn)在Kubernetes Ingress控制器的前身，當(dāng)然，OpenShift也支持Kubernetes Ingress。

Kubernetes本身不包括SDN和虛擬網(wǎng)絡(luò)隔離，而OpenShift包括集成了OVS的SDN，并實(shí)現(xiàn)虛擬網(wǎng)絡(luò)隔離。此外，紅帽還幫助推動了Kubernetes容器網(wǎng)絡(luò)接口開發(fā)，為Kubernetes集群提供了豐富的第三方SDN插件生態(tài)系統(tǒng)。目前，OpenShift的OVS支持Network Policy模式，其網(wǎng)絡(luò)隔離性更強(qiáng)，而且默認(rèn)使用Network Policy模式，極大提升了容器的網(wǎng)絡(luò)安全。

6.OpenShift實(shí)現(xiàn)了容器鏡像的便捷管理

OpenShift使用ImageStreams管理容器鏡像。一個ImageStream是一類應(yīng)用鏡像的集合，而ImageStreams Tag則指向?qū)嶋H的鏡像。

對于一個已經(jīng)有的鏡像，如Docker.io上的Docker Image，如果想在OpenShift中使用Image，則可以通過將Image導(dǎo)入ImageStream中來使用。需要注意的是，我們在將Image導(dǎo)入ImageStream的時候，可以加上--scheduled=true參數(shù)，它的作用是當(dāng)創(chuàng)建好ImageStream以后，ImageStream會定期檢查鏡像庫的更新，然后保持指向最新的Image。

在DeploymentConfig中使用ImageStream時，我們可以設(shè)置一個Trigger，當(dāng)新鏡像出現(xiàn)或鏡像的Tag發(fā)生變化，Trigger會觸發(fā)自動化部署。這個功能可以幫助我們在沒有CI/CD配置的前提下實(shí)現(xiàn)新鏡像的自動部署。

通過使用ImageStream，我們實(shí)現(xiàn)了容器鏡像構(gòu)建、部署與鏡像倉庫的松耦合。

在介紹OpenShift對Kubernetes的增強(qiáng)以后，接下來介紹OpenShift對Kubernetes生態(tài)的延伸。