DO280介绍红帽OPENSHIFT容器平台--管理OpenShift与课外补充
🎹 個(gè)人簡(jiǎn)介：大家好，我是 金魚哥，CSDN運(yùn)維領(lǐng)域新星創(chuàng)作者，華為云·云享專家，阿里云社區(qū)·專家博主
📚個(gè)人資質(zhì)：CCNA、HCNP、CSNA（網(wǎng)絡(luò)分析師），軟考初級(jí)、中級(jí)網(wǎng)絡(luò)工程師、RHCSA、RHCE、RHCA、RHCI、ITIL😜
💬格言：努力不一定成功，但要想成功就必須努力🔥
🎈支持我：可點(diǎn)贊👍、可收藏??、可留言📝
文章目錄
- 📜管理OpenShift
- 📑OpenShift項(xiàng)目及應(yīng)用
- 📑使用Source-to-image構(gòu)建映像
- 📑管理OpenShift資源
- 📜OpenShift網(wǎng)絡(luò)
- 📑OpenShift網(wǎng)絡(luò)概述
- 📜OpenShift持久性存儲(chǔ)
- 📑永久存儲(chǔ)
- 📜OpenShift高可用
- 📑OpenShift高可用概述
- 📜Image Streams
- 📑Image Streams
- 摘自網(wǎng)上資料（摘自陳沙克老師的博客）
- 📜虛擬化和容器–開源發(fā)展相似歷程（2017-10-25）
- 📑虛擬化
- 技術(shù)
- 抽象層
- 管理引擎
- 產(chǎn)品化
- 📑容器
- 技術(shù)
- 抽象層
- 管理引擎
- 產(chǎn)品化
- 📜OpenShift介紹（2017-10-19）
- 📑容器和Docker
- 📑編排和kubernetes
- 📑PaaS和OpenShift
- 📑OpenShift版本
- 📑OpenShift介紹
- 📑OpenShift對(duì)手
- 📑PaaS和IaaS關(guān)系
- 📜OpenShift圖解（2017-11-9）
- 📑部署架構(gòu)圖
- 📑What isOpenShift
- 📑Roadmap
- 📑流程
- 📑Compare
- 📑Architecture
- 📜OpenStack和Kubernetes相似的地方（2018-9-10）
- 📑看不到對(duì)手
- 📑基金會(huì)管理
- 📑架構(gòu)
- 📑部署
- 💡總結(jié)
📜管理OpenShift
📑OpenShift項(xiàng)目及應(yīng)用
除了Kubernetes的資源(如pods和services)之外，OpenShift還管理projects和users。一個(gè)projects對(duì)Kubernetes資源進(jìn)行分組，以便用戶可以使用訪問權(quán)限。還可以為projects分配配額，從而限制了已定義的pod、volumes、services和其他資源。
OpenShift中沒有application的概念，OpenShift client提供了一個(gè)new-app命令。此命令在projects中創(chuàng)建資源，但它們都不是應(yīng)用程序資源。這個(gè)命令是為標(biāo)準(zhǔn)開發(fā)人員工作流配置帶有公共資源
的proiect的快捷方式。OpenShift使用lables(標(biāo)簽)對(duì)集群中的資源進(jìn)行分類。默認(rèn)情況下，OpenShift使用app標(biāo)簽將相關(guān)資源分組到應(yīng)用程序中。
📑使用Source-to-image構(gòu)建映像
OpenShift允許開發(fā)人員使用標(biāo)準(zhǔn)源代碼管理倉(cāng)庫(kù)(SCM)和集成開發(fā)環(huán)境(ide)來發(fā)布應(yīng)用。
OpenShift中的source-to-lmage (S2I) 流程從SCM倉(cāng)庫(kù)中提取代碼，自動(dòng)判斷所需的runtime，基于runtime啟動(dòng)一個(gè)pod，在pod中編譯應(yīng)用。
當(dāng)編譯成功時(shí)，將在runtime image中添加層并形成新的image，推送進(jìn)入OpenShift internal registry倉(cāng)庫(kù)，接著基于這個(gè)image將創(chuàng)建新的pod，運(yùn)行應(yīng)用程序。
S2I可被視為已經(jīng)內(nèi)置到OpenShift中的完整的CI/CD管道。
CI/CD有不同的形式，根據(jù)具體場(chǎng)景表現(xiàn)不同。例如，可以使用外部CI工具(如Jenkins)啟動(dòng)構(gòu)建并運(yùn)行測(cè)試，然后將新構(gòu)建的映像標(biāo)記為成功或失敗，將其推送到QA或生產(chǎn)。
📑管理OpenShift資源
OpenShift資源定義,如image、container、pod、service、builder、template等，都存儲(chǔ)在Etcd中，可以由OpenShift CLI, web控制臺(tái)或REST API進(jìn)行管理。
OpenShift的資源可通過JSON或YAML文件查看，并且在類似Git或版本控制的SCM中共享。OpenShift甚至可以直接從外部SCM檢索這些資源定義。
大多數(shù)OpenShift操作不需要實(shí)時(shí)響應(yīng)，OpenShift命令和APIs通常創(chuàng)建或修改存儲(chǔ)在Etcd中的資源描述。Etcd然后通知OpenShift控制器，OpenShift控制器會(huì)就更改警告這些資源。
這些控制器采取行動(dòng)，以便使得資源的最終態(tài)反應(yīng)達(dá)到更改效果。例如，如果創(chuàng)建了一個(gè)新的pod資源，Kubernetes將在node上調(diào)度并啟動(dòng)該pod，使用pod資源確定要使用哪個(gè)映像、要公開哪個(gè)端口，等等。或者一個(gè)模板被更改，從而指定應(yīng)該有更多的pod來處理負(fù)載，OpenShift會(huì)安排額外的pod(副本)來滿足更新后的模板定義。
**注意：**雖然Docker和Kubernetes是OpenShift的底層，但是必須主要使用OpenShift CLi和OpenShift APls來管理應(yīng)用程序和基礎(chǔ)設(shè)施。OpenShift增加了額外的安全和自動(dòng)化功能，當(dāng)直接使用Docker或Kubernetes命令和APls時(shí)，這些功能必須手動(dòng)配置，或者根本不可用。因此強(qiáng)烈建議不要使用docker或Kubernetes的命令直接管理應(yīng)用。
📜OpenShift網(wǎng)絡(luò)
📑OpenShift網(wǎng)絡(luò)概述
Docker網(wǎng)絡(luò)相對(duì)簡(jiǎn)單，Docker創(chuàng)建一個(gè)虛擬內(nèi)核橋接器（docker0網(wǎng)卡），并將每個(gè)容器網(wǎng)絡(luò)接口連接到它。Docker本身沒有提供允許一個(gè)主機(jī)上的pod連接到另一個(gè)主機(jī)上的pod的方法。Docker也沒有提供向應(yīng)用程序分配公共固定IP地址的方法，以便外部用戶可以訪問它。
但Kubernetes提供service和route資源來管理pods之間的網(wǎng)絡(luò)，以及從外部到pods的路由流量。service在不同pods之間提供負(fù)載均衡用于接收網(wǎng)絡(luò)請(qǐng)求，同時(shí)為service的所有客戶機(jī)(通常是其他
pods)提供一個(gè)內(nèi)部IP地址。container和pods不需要知道其他pods在哪里，它們只連接到service。route為service提供一個(gè)固定的惟一DNS名稱，使其對(duì)OpenShift集群之外的客戶端可見。
Kubernetes service和route資源需要外部（功能）插件支持。service需要軟件定義的網(wǎng)絡(luò)(SDN)，它將在不同主機(jī)上的pod之間提供通信，route需要轉(zhuǎn)發(fā)或重定向來自外部客戶端的包到服務(wù)內(nèi)部IP。OpenShift提供了一個(gè)基于Open vSwitch的SDN，路由由分布式HAProxy farm提供。
📜OpenShift持久性存儲(chǔ)
📑永久存儲(chǔ)
pod可以在一個(gè)節(jié)點(diǎn)上停止，并隨時(shí)在另一個(gè)節(jié)點(diǎn)上重新啟動(dòng)。同時(shí)pod的默認(rèn)存儲(chǔ)是臨時(shí)存儲(chǔ)，通過對(duì)于類似數(shù)據(jù)庫(kù)需要永久保存數(shù)據(jù)的應(yīng)用不適合。
Kubernetes為管理容器的外部持久存儲(chǔ)提供了一個(gè)框架。Kubernetes提供了PersistentVolume資源，它可以在本地或網(wǎng)絡(luò)中定義存儲(chǔ)。pod資源可以使用PersistentVolumeClaim資源來訪問對(duì)應(yīng)的持久存儲(chǔ)卷。
Kubernetes還指定了一個(gè)PersistentVolume資源是否可以在pod之間共享，或者每個(gè)pod是否需要具有獨(dú)占訪問權(quán)的自己PersistentVolume。當(dāng)pod移動(dòng)到另一個(gè)節(jié)點(diǎn)時(shí)，它將保持與相同的PersistentVolumeClaim和PersistentVolumne資源的關(guān)聯(lián)。這意味著pod的持久存儲(chǔ)數(shù)據(jù)跟隨它，而不管它將在哪個(gè)節(jié)點(diǎn)上運(yùn)行。
OpenShift向Kubernetes提供了多種VolumeProvider，如NFS、iSCSI、FC、Gluster或OpenStack Cinder。
OpenShift還通過StorageClass資源為應(yīng)用程序提供動(dòng)態(tài)存儲(chǔ)。使用動(dòng)態(tài)存儲(chǔ)，可以選擇不同類型的后端存儲(chǔ)。后面存儲(chǔ)根據(jù)應(yīng)用程序的需要?jiǎng)澐譃椴煌摹皌iers”。例如，可以定義一個(gè)名為“fast”的存儲(chǔ)類和另一個(gè)名為“slow”的存儲(chǔ)類，前者使用更高速的后端存儲(chǔ)，后者提供普通的存儲(chǔ)。當(dāng)請(qǐng)求存儲(chǔ)時(shí)，最終用戶可以指定一個(gè)Persistentvolumeclaim，并使用一個(gè)注釋指定他們所需的StorageClass。
📜OpenShift高可用
📑OpenShift高可用概述
OpenShift平臺(tái)集群的高可用性(HA)有兩個(gè)不同的方面：OpenShift基礎(chǔ)設(shè)施本身的HA(即主機(jī))；以及在OpenShift集群中運(yùn)行的應(yīng)用程序的HA。
默認(rèn)情況下，OpenShift為master提供了完全支持的本機(jī)HA機(jī)制。
對(duì)于應(yīng)用程序或“pods”，如果pod因任何原因丟失，Kubernetes將調(diào)度另一個(gè)副本，將其連接到服務(wù)層和持久存儲(chǔ)。如果整個(gè)節(jié)點(diǎn)丟失，Kubernetes會(huì)為它所有的pod安排替換節(jié)點(diǎn)，最終所有的應(yīng)用程序都會(huì)重新可用。pod中的應(yīng)用程序負(fù)責(zé)它們自己的狀態(tài)，因此它們需要自己維護(hù)應(yīng)用程序狀態(tài)(如HTTP會(huì)話復(fù)制或數(shù)據(jù)庫(kù)復(fù)制)。
📜Image Streams
📑Image Streams
要在OpenShift中創(chuàng)建一個(gè)新的應(yīng)用程序，除了應(yīng)用程序源代碼之外，還需要一個(gè)base image(S2I builder image)。如果源代碼或image任何一個(gè)更新，就會(huì)生成一個(gè)新的image，并且基于此新image創(chuàng)建新的pod，同時(shí)替換舊的pod。
即當(dāng)應(yīng)用程序代碼發(fā)生更改時(shí)，容器鏡像需要更新，但如果構(gòu)建器鏡像發(fā)生更改，則部署的pod也需
要更新。
Image Streams包括由tag標(biāo)識(shí)的大量的image。應(yīng)用程序是針對(duì)Image Streams構(gòu)建的。Image Streams可用于在創(chuàng)建新image時(shí)自動(dòng)執(zhí)行操作。構(gòu)建和部署可以監(jiān)視Image Streams，以便在添加新image時(shí)接收通知，并分別執(zhí)行構(gòu)建或部署。
OpenShift默認(rèn)情況下提供了幾個(gè)Image Streams，包括許多流行的runtime和frameworks。Image Streams tag是指向Image Streams中的image的別名。通常縮寫為istag。它包含一個(gè)image歷史記錄，表示為tag曾經(jīng)指向的所有images的堆棧。每當(dāng)使用特定的istag標(biāo)記一個(gè)新的或現(xiàn)有的image時(shí)，它都會(huì)被放在歷史堆棧的第一個(gè)位置(標(biāo)記為latest)。之前tag再次指向舊的image。同時(shí)允許簡(jiǎn)單的回滾，使標(biāo)簽再次指向舊的image。
摘自網(wǎng)上資料（摘自陳沙克老師的博客）
感謝陳沙克（可自行百度一下，大神級(jí)人物，九州云副總裁）老師的文章分享讓我們能夠?qū)W習(xí)得更多。
📜虛擬化和容器–開源發(fā)展相似歷程（2017-10-25）
其實(shí)回顧一下虛擬化和容器的發(fā)展歷程，很大程度是驚人相似。我這里其實(shí)肯定不是很嚴(yán)謹(jǐn)?shù)拿枋觥H僅是大概介紹一下過程。
📑虛擬化
技術(shù)
商業(yè)的虛擬化技術(shù)其實(shí)也不少。開源的的也是一樣。著名的就是Xen和KVM兩家。
Xen
KVM
Xen是2003年發(fā)布。KVM進(jìn)入linux內(nèi)核，真正第一個(gè)操作系統(tǒng)支持，當(dāng)時(shí)據(jù)說是：ubuntu 8.04，也就是2008年，當(dāng)時(shí)的KVM，還是一個(gè)玩具。
2010年，紅帽發(fā)布RHEL 6.0，KVM算是正式進(jìn)入主流。當(dāng)時(shí)全球虛擬化，公有云，基本都是Xen的天下。
經(jīng)過了5年的PK，現(xiàn)在已經(jīng)是KVM獨(dú)大。目前AWS，阿里云，已經(jīng)全面轉(zhuǎn)向KVM。
Xen的沒落，很多原因，其中一個(gè)，就是intel搞了一套cpu虛擬化的東西，幫助kvm勝出。
KVM的想法其實(shí)應(yīng)該是2006年，為了對(duì)抗Xen，intel，紅帽，IBM，聯(lián)手搞出一個(gè)KVM，放到內(nèi)核里。
抽象層
那么多虛擬化引擎，那么肯定有人想到要做一個(gè)統(tǒng)一管理工具，這樣可以管理多個(gè)。這樣Libvirt就出現(xiàn)了。
Libvirt最擅長(zhǎng)管理KVM，不過其實(shí)別的都是可以管理。
管理引擎
虛擬化的技術(shù)，其實(shí)需要有管理工具，那么他的管理工具有哪些呢
- OpenStack
- CloudStack
- Eucalptus
- OpenNebula
其實(shí)還要很多，這些管理工具，當(dāng)時(shí)是能管理Xen和Kvm，也有專門針對(duì)某個(gè)虛擬化的管理工具
Xen Server，專門管理Xen
Ovirt，專門管理KVM
這些工具，從2008年，一直pk到2014年，終于分出的高低。最后是OpenStack+KVM勝出。
管理引擎，也是通過抽象層，Libvirt去管理KVM的。
產(chǎn)品化
其實(shí)就是針對(duì)管理引擎的產(chǎn)品化。你需要把管理引擎包裝出來，加上很多輔助的工具，讓用戶用的很爽。
紅帽TrippleO
Mirantis的Fuel
Kolla
其實(shí)Ubuntu和Suse，都有他們的產(chǎn)品。
Mirantis的Fuel和Suse的Crowbar，大概是2014年出現(xiàn)，到現(xiàn)在也經(jīng)歷了3年多。從我的角度，最終就是Kolla徹底勝出，毫無(wú)懸念啊。
OpenStack的創(chuàng)業(yè)公司，目前還能有口飯吃，其實(shí)是要謝謝紅帽。紅帽因?yàn)樵贠penStack上的策略有所失誤，導(dǎo)致沒能在OpenStack一統(tǒng)天下。要記住啊，
當(dāng)年kolla項(xiàng)目可是TrippleO的一個(gè)子項(xiàng)目，
Kolla項(xiàng)目的創(chuàng)始人，也是紅帽的工程師，
ansible，Ceph都是紅帽自家產(chǎn)品啊，
Cobbler，也是Ansible公司的人在維護(hù)。
libvirt，qemu，kvm都是紅帽的
📑容器
技術(shù)
容器的技術(shù)，起源很早，我最早接觸是OpenVZ，這個(gè)讓國(guó)內(nèi)很多賣虛擬機(jī)掙錢的軟件。對(duì)于開源，流行的容器來說
LXC
Docker
LXD
RTK
Clean container
LXC，國(guó)內(nèi)互聯(lián)網(wǎng)2010年就開始使用。不過目前最流行的是Docker，
Docker從2013年發(fā)布到現(xiàn)在，其實(shí)發(fā)展速度很快，很多廠商都來不及響應(yīng)，這個(gè)東西就成為主流。這個(gè)時(shí)候，intel又想重施故技，搞一個(gè)和cpu有關(guān)的容器技術(shù)，所謂的Clean Container。
不過這次由于Docker發(fā)展過于迅速，intel這次搞容器，完全是自己玩，不像當(dāng)年和紅帽勾搭在一起。所以很難在市場(chǎng)立足。
抽象層
和虛擬化其實(shí)一樣道理，底層那么多容器技術(shù)，如何方便管理呢。
CRI Interface, Container RunTime Interface，就出現(xiàn)了，做了一層抽象后，各個(gè)廠商就可以和平共處。
管理引擎
對(duì)于容器來說，也叫編排引擎，這個(gè)大家就比較熟悉3大編排引擎
K8S
Swarm
Messos
K8S是從2014年7月份推出，到2017年7月份，基本上是完勝。廠商紛紛投降。K8s+Docker和虛擬化也是一樣，目前K8s，是通過CRI，去管理Docker。
產(chǎn)品化
用戶要用起來，要把k8s，或者messos用起來，那么還是需要做很多工作。業(yè)界最著名的產(chǎn)品就是
OpenShift
Racher
國(guó)內(nèi)的很多容器公司，k8s公司，其實(shí)都是在做類似的工作，在K8s上增加自己定制，形成自己的產(chǎn)品。包括現(xiàn)在CloudFountry，都號(hào)稱要支持K8s。背后的故事也很多，Racher當(dāng)時(shí)號(hào)稱要管理3個(gè)引擎，k8s，swarm和messos，最新的2.0的版本，就只管理K8s。
還是紅帽厲害，2014年K8s發(fā)布，馬上轉(zhuǎn)方向，全面發(fā)力K8s，包裝自己的OpenShift產(chǎn)品。當(dāng)紅帽已經(jīng)做出勢(shì)頭的時(shí)候，那是無(wú)人能敵的。這種K8s的產(chǎn)品化，基本也是毫無(wú)懸念，OpenShift勝出。
📜OpenShift介紹（2017-10-19）
現(xiàn)在開始搞PaaS平臺(tái)，那么OpenShift就必須研究一下，這里寫篇文章，把我過去一個(gè)月的理解，整理一下。
以前都是搞OpenStack，IaaS層面，發(fā)現(xiàn)對(duì)PaaS層面，了解不多。不過幸好當(dāng)時(shí)搞Kolla，把OpenStack容器化，對(duì)我現(xiàn)在理解PaaS，還是有很大的幫助。
📑容器和Docker
其實(shí)這個(gè)對(duì)我來說，還是比較熟悉，可以說的清楚。市場(chǎng)上的容器，基本都是Docker，有很多其他容器廠商，不過目前看來還是很難和Docker來PK。
那么對(duì)于軟件行業(yè)來說，我自己是深刻體會(huì)Docker帶來的變化。是一個(gè)革命性的應(yīng)用。Docker從2013年發(fā)布，到現(xiàn)在已經(jīng)五年，已經(jīng)進(jìn)入比較穩(wěn)定的階段。
📑編排和kubernetes
編排，這個(gè)詞，對(duì)于不是開發(fā)人員來說，還是不好理解。其實(shí)就是當(dāng)你的應(yīng)用放到容器里的時(shí)候，容器的啟動(dòng)順序是有要求的。那么這個(gè)時(shí)候就需要用編排。
對(duì)容器的編排，其實(shí)很多工具可以實(shí)現(xiàn)。對(duì)于OpenStack容器化項(xiàng)目kolla來說。ansible目前是編排工具，其實(shí)也挺好。這主要一個(gè)原因就是在規(guī)模不大，容量數(shù)量不多，環(huán)境不復(fù)雜的情況下，ansible編排，是可以滿足需求的。
對(duì)編排一個(gè)需求，就是一個(gè)服務(wù)如果掛掉，編排工具可以自動(dòng)啟動(dòng)，壓力大的時(shí)候，會(huì)橫向擴(kuò)容。不過在OpenStack的場(chǎng)景下，無(wú)狀態(tài)的服務(wù)，從來都不是瓶頸，nova api，服務(wù)我用了OpenStack那么久，沒遇到過掛掉的。
對(duì)于有狀態(tài)的服務(wù)，其實(shí)編排工具是無(wú)法實(shí)現(xiàn)所謂的橫向擴(kuò)容。例如數(shù)據(jù)庫(kù)和消息隊(duì)列。
編排工具，目前最大的玩家，就是k8s。基本所有廠商都用它。
那么k8s和paas是什么關(guān)系。經(jīng)常在會(huì)議上，很多講座，就把k8s當(dāng)成PaaS來介紹。
K8S是一個(gè)容器編排工具，要實(shí)現(xiàn)PaaS的功能，其實(shí)還需要在上面做很多工作，監(jiān)控，日志，CI，CD等。那么這些工具，你可以自己組合，結(jié)合自己的公司的需求，搞出一套PaaS平臺(tái)。
📑PaaS和OpenShift
真正意義上的PaaS，其實(shí)就是業(yè)界兩家：
- vmware 的CloudFoundry
- 紅帽的OpenShift
2015年的時(shí)候，這兩家的PaaS，都是ruby開發(fā)，思路基本都是一樣，江湖傳聞，兩位項(xiàng)目創(chuàng)始人酒吧喝完酒，各自搞了一個(gè)項(xiàng)目。不過在市場(chǎng)上，CloudFoundry聲音是比較大的。遠(yuǎn)超過紅帽。
2015年的時(shí)候，華為，IBM，HP的所謂PaaS平臺(tái)，都是基于CloudFoundry來修改的。
K8s，2014年7月份發(fā)布第一個(gè)版本，2015年七月份，發(fā)布1.0的產(chǎn)品，那么這個(gè)時(shí)候紅帽看到的機(jī)會(huì)，也是在這個(gè)時(shí)候，業(yè)界的風(fēng)向發(fā)生的改變，紅帽，華為，IBM，把底層都改成K8S。
2015年，紅帽推出基于k8s的OpenShift。
Openshift 3.0的產(chǎn)品，就全面轉(zhuǎn)向K8S。可以這樣理解，以前的代碼全部扔掉，重新來過一次。很神奇的事情，2016年，紅帽就宣布OpenShift掙大錢。同時(shí)也加大投入。
OpenShift對(duì)紅帽有多么重要呢？已經(jīng)成為的第二大收入來源。第一大肯定是操作系統(tǒng)。
那么新版的OpenShift和以前的OpenShift有啥區(qū)別呢？
其實(shí)以前的PaaS平臺(tái)一個(gè)通病，就是要把應(yīng)用放到PaaS上，你是必須對(duì)代碼進(jìn)行修改才行。例如大家可能以前也去紅帽的OpenShift官網(wǎng)測(cè)試過一個(gè)wordpress的實(shí)驗(yàn)，這個(gè)wordpress，是要經(jīng)過代碼修改的。一旦進(jìn)行了update更新，就肯定會(huì)掛掉。
現(xiàn)在的OpenShift，不需要你做任何的代碼修改，就可以放上去PaaS平臺(tái)，所以肯定也是能update。
CloudFoundry，剛剛也對(duì)外宣布，底層也要支持K8s，不過已經(jīng)晚了。紅帽的勢(shì)頭已經(jīng)起來。你就完全沒有機(jī)會(huì)了。
我和朋友開玩笑說：紅帽的OpenStack勢(shì)頭沒做起來，導(dǎo)致OpenStack廠商還能有口飯吃。紅帽的PaaS平臺(tái)，K8s已經(jīng)勢(shì)頭起來了，別的廠商，其實(shí)已經(jīng)空間不大了。
📑OpenShift版本
紅帽的一貫風(fēng)格，都是開源版本，商業(yè)版本，命名也不一樣。從上面圖其實(shí)就可以看出來，也讓用戶感覺很混亂。
到了OpenShift 3.6的版本，集成的K8s 1.6的版本，版本就清晰很多
開源版本：OpenShift Origin 3.6
商業(yè)版本：OpenShift 3.6
我的理解，代碼都是一樣，就是一個(gè)商業(yè)支持的區(qū)別。
從紅帽的發(fā)布OpenShift版本可以看出，基本是一年4個(gè)版本，緊跟K8S。目前K8S最新版本是1.8。落后2個(gè)版本。
k8s 1.5的版本是2016年12月23日，紅帽的OpenShift 3.5，是2017年4月份發(fā)布
K8s 1.6的版本是2017年3月22日發(fā)布的，紅帽的OpenShift 3.6是2017年7月底。紅帽需要4個(gè)月時(shí)間發(fā)布一個(gè)版本。
https://www.kubernetes.org.cn/1353.html
2017年12月13日 k8s v1.9.0正式版本發(fā)布！
Kubernetes 1.1的版本是，2015年11月9日發(fā)布。
📑OpenShift介紹
很多人說紅帽的OpenShift就是一個(gè)K8S，其實(shí)這是一個(gè)不算太正確的理解。OpenShift，目前的版本，可以理解成一個(gè)真正意義上的PaaS。
紅帽在K8S上封裝了一層，你基本上已經(jīng)用不上K8S的命令。上面提供紅帽的UI，集成了日志，監(jiān)控，鏡像倉(cāng)庫(kù)等功能。也集成的CI，CD。
比如你希望在K8s跑一個(gè)mysql的群集，Redis的群集，那么這些都是需要廠商做很多工作才能實(shí)現(xiàn)，紅帽提供全套的服務(wù)。
📑OpenShift對(duì)手
很多廠商基于K8S做出自己的PaaS平臺(tái)，例如IBM的Bluemix。但是真正能產(chǎn)品化的，也就
OpenShift和Racher。
目前市場(chǎng)上OpenShift肯定是領(lǐng)先的。紅帽的開源優(yōu)勢(shì)發(fā)揮出來。
📑PaaS和IaaS關(guān)系
大家可以受那張圖的影響，認(rèn)為PaaS必須跑在IaaS上。那么其實(shí)兩者可以沒任何關(guān)系，也是可以密切聯(lián)系。
紅帽的OpenShift，基本支持所有的平臺(tái)，物理機(jī)器的部署，OpenStack里部署，和虛擬機(jī)里部署。
目前OpenShift的部署，是通過Ansible來實(shí)現(xiàn)，非常方便。
IaaS平臺(tái)上，很多組件可以是PaaS通過軟件提供，也可以是IaaS提供，例如負(fù)載均衡，DNS服務(wù)，Nas服務(wù)，如果Iaas平臺(tái)提供這些服務(wù)，那么跑PaaS平臺(tái)，OpenShift，就更加方便可靠。
對(duì)于實(shí)際的PaaS應(yīng)用來說，微服務(wù)用到有狀態(tài)的服務(wù)，例如數(shù)據(jù)庫(kù)，mysql，redis。目前業(yè)界都是推薦直接使用IaaS平臺(tái)的，目前在PaaS層跑有狀態(tài)的應(yīng)用，業(yè)界的測(cè)試還是不夠的。
📜OpenShift圖解（2017-11-9）
📑部署架構(gòu)圖
📑What isOpenShift
📑Roadmap
📑流程
developer provides git repo
Developer chooses image from grgistry
layer is applied to image
layer is added back to registry
image is scheduled and deployed
Developer can declare webhooks
updated image is added back to the registry
New Images is depoyed as rooling update
📑Compare
📑Architecture
📜OpenStack和Kubernetes相似的地方（2018-9-10）
我也算是折騰了一年的OpenShift，OpenShift，就是Kubernetes的一個(gè)發(fā)行版，我的感覺，其實(shí)他們相似的地方還是很多，對(duì)我的改變并沒有想象那么大。
下面總結(jié)一下他們的相同的地方
📑看不到對(duì)手
無(wú)論是OpenStack還是kubernetes，都是在重圍中殺出來，一騎絕塵，根本看不到對(duì)手。
OpenStack干掉CloudStack，Eucalyptus，OpenNebula。
Kubernetes，干掉swam ，messos
都是壓倒性的優(yōu)勢(shì)勝出。
區(qū)別就在于，OpenStack勝出以后，就迷失了方向，往自己不擅長(zhǎng)的邊緣計(jì)算，最終只能是一條不歸路。
K8s勝出后，社區(qū)的想法還是很多，還保持1年4個(gè)版本的迭代。
一個(gè)是python最大的開源項(xiàng)目，一個(gè)是Go語(yǔ)言最大的開源項(xiàng)目。
📑基金會(huì)管理
OpenStack專門成立基金會(huì)管理，不過基金會(huì)不涉及技術(shù)方向，技術(shù)方向有專門的TC，技術(shù)委員會(huì)管理，當(dāng)big tent，大帳篷策略后，TC的用途也就不大，而且TC混日子的人也多了。
OpenStack官方目前有60多個(gè)項(xiàng)目，其實(shí)大部分都是僵尸項(xiàng)目，停留在實(shí)驗(yàn)室階段，根本就沒生產(chǎn)使用案例。真的能用的項(xiàng)目，應(yīng)該不超過15個(gè)。
k8s，其實(shí)也歸屬CNCF基金會(huì)。吸取OpenStack基金會(huì)的教訓(xùn)。對(duì)項(xiàng)目是加入，孵化，畢業(yè)，有了嚴(yán)格的流程。這個(gè)可以很好避免。
OpenStack技術(shù)設(shè)計(jì)的時(shí)候，很糾結(jié)規(guī)模優(yōu)先還是功能優(yōu)先。公有云為主，還是私有云為主。這個(gè)也導(dǎo)致一直無(wú)法明確。
我的理解，K8s的功能，逐步的玩企業(yè)級(jí)發(fā)展。無(wú)論是用k8s支持有狀態(tài)的應(yīng)用，還是讓k8s管理vm，方向都非常明確。
📑架構(gòu)
看完OpenStack的架構(gòu)演變過程，再看k8s，感覺相似的地方很多的。
- Nova==CRI-O
- cinder=CSI
- Neutron=CNI
計(jì)算，存儲(chǔ)，網(wǎng)絡(luò)，都搞一個(gè)，無(wú)論是OpenStack，還是k8s，基本都是一樣的玩法，讓廠商都能參與進(jìn)來。
目前k8s上沒有統(tǒng)一的身份認(rèn)證，就沒有keystone，k8s上，沒提供鏡像倉(cāng)庫(kù)，就沒有g(shù)lance。
事實(shí)上也是有一堆的應(yīng)用，對(duì)于OpenStack組件
- keystone+ldap=keycloak+ldap
- glance=Quay or harbor
📑部署
大家都感覺OpenStack很復(fù)雜，如果和k8s比起來，其實(shí)算是簡(jiǎn)單的。k8s的部署，單單是一個(gè)雙向的證書，都能讓你折騰一個(gè)半天。
但是用戶一般感覺k8s比較簡(jiǎn)單，一個(gè)原因，就是k8s自己做的部署管理工具比較成熟。目前紅帽的OpenShift，已經(jīng)采用全容器化的部署方案部署OpenShift，并且容器的管理，也是在Openshift上，真的比較完善。升級(jí)的問題，也就變得很簡(jiǎn)單。
OpenStack目前部署方案的方向也是容器化部署，不過還無(wú)法實(shí)現(xiàn)用k8s來管理，只能通過ansible來管理。
對(duì)我來說，
- kolla-ansible 部署OpenStack
- openshift-ansible 部署OpenShift
都是通過ansible來實(shí)現(xiàn)。
💡總結(jié)
RHCA認(rèn)證需要經(jīng)歷5門的學(xué)習(xí)與考試，還是需要花不少時(shí)間去學(xué)習(xí)與備考的，好好加油，可以噶🤪。
以上就是【金魚哥】對(duì) 第一章 介紹紅帽O(jiān)PENSHIFT容器平臺(tái)–管理OpenShift與課外補(bǔ)充 的簡(jiǎn)述和講解。希望能對(duì)看到此文章的小伙伴有所幫助。
💾紅帽認(rèn)證專欄系列：
RHCSA專欄：戲說 RHCSA 認(rèn)證
RHCE專欄：戲說 RHCE 認(rèn)證
此文章收錄在RHCA專欄：RHCA 回憶錄
如果這篇【文章】有幫助到你，希望可以給【金魚哥】點(diǎn)個(gè)贊👍，創(chuàng)作不易，相比官方的陳述，我更喜歡用【通俗易懂】的文筆去講解每一個(gè)知識(shí)點(diǎn)。
如果有對(duì)【運(yùn)維技術(shù)】感興趣，也歡迎關(guān)注?????? 【金魚哥】??????，我將會(huì)給你帶來巨大的【收獲與驚喜】💕💕！
總結(jié)
以上是生活随笔為你收集整理的DO280介绍红帽OPENSHIFT容器平台--管理OpenShift与课外补充的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 【Lingo】lingo使用
- 下一篇： 吴恩达深度学习课程第五章第二周编程作业(