我司目前是自研的PaaS系統，基於k8s編排，集成docker環境，加上網格，Consul，nginx等。
Openshift是一個完整的雲應用平台，里面很多的概念是一樣的。
文章轉自 https://www.jianshu.com/p/a4712351142d
Openshift是一個開源容器雲平台，是一個基於主流的容器技術Docker和K8s構建的雲平台。Openshift底層以Docker作為容器引擎驅動，以K8s作為容器編排引擎組件，並提供了開發語言，中間件，DevOps自動化流程工具和web console用戶界面等元素，提供了一套完整的基於容器的應用雲平台。
Red Hat是Openshift的最大貢獻者。
Openshift包括社區版和企業版
社區版： Openshift Origin
企業版： Openshift Online/Openshift Enterprise
【重要概念】
system:admin為默認的集群管理員，擁有最高的權限。該用戶沒有密碼，登陸依賴於證書密鑰。
Service Account 是 Openshift 中專門供程序和組件使用的賬號。不同的用戶或組關聯不同的角色，同時關聯不同的SCC（security context constriant）安全上下文
【架構】
自底而上包括幾個層次：基礎架構層，容器引擎層，容器編排層，PaaS服務層，界面及工具層。
基礎架構層：為Openshift平台的運行提供基礎的運行環境。Openshift支持運行在物理機，虛擬機（kvm,vmware,virtual box等），公有雲（阿里雲，AWS等），私有雲，混合雲上。
容器引擎層：以當前主流的Docker作為容器引擎。
容器編排層：以Google的k8s進行容器編排。
PaaS服務層：容器雲平台的最終目的是為上層應用服務提供支持，提高開發，測試，部署，運維的速度和效率。用戶在Openshift雲平台上可以快速的獲取和部署一個數據庫，緩存等。
界面及工具層：Openshift提供了多種用戶的接入渠道：Web控制台，命令行，RestFul接口等
【核心組件】
1. Master節點
主控節點。集群內的管理組件都運行在Master節點上。Master節點負責集群的配置管理，維護集群的狀態。Master節點運行的服務組件：
API Server：負責提供Web console和RESTful API。集群內所有節點都會訪問API Server，更新節點的狀態及其上的容器狀態。
數據源（Data store）：集群內所有狀態信息都會存儲在后端的一個etcd的分布式數據庫中。
調度控制器（Scheduler）：負責按用戶輸入的要求尋找合適的計算節點。
復制控制器（Replication Controller）：負責監控當前容器實例的數量和用戶部署指定的數量是否匹配，若有容器異常退出，復制控制器發現實際數少於部署定義數，從而觸發部署新的實例。
2. Node節點
計算節點。接收Master節點的指令，運行和維護Docker容器。Master節點也可以是Node節點，只是在一般環境中，其運行容器的功能是關閉的。
3. Project：在k8s中使用命名空間來分隔資源。同一個命名空間中，某一個對象的名稱在其分類中必須唯一，但在不同命名空間中的對象則可以同名。Openshift集成了k8s命名空間的概念，而且在其上定義了Project對象的概念，每一個Project會和一個namespace相關聯。
4. Pod：在Openshift中的容器都會Pod包裹，即容器都運行在Pod內部，一個Pod可以運行一個或多個容器，絕大多少情況下，一個Pod內部運行一個容器。
5. Service：由於容器是一個非持久化的對象，所有對容器的修改再容器銷毀后都會丟失，而且每個容器的IP地址會不斷變化。k8s提供了Service組件，當部署某個應用時，會創建一個Service對象，該對象與一個或多個Pod關聯，同時每個Service分配一個相對恆定的IP，通過訪問該IP及相應的端口，請求就會轉發到對應Pod端口。除了可通過IP，也可以通過域名訪問Service，格式為：..svc.cluster.local
6. Router和Route：Service提供了一個通往后端Pod集群的穩定入口，但是Service的IP地址只是集群內部的節點和容器可見。外部需通過Router（路由器）來轉發。Router組件是Openshift集群中一個重要的組件，它是外界訪問集群內容器應用的入口。用戶可以創建Route（路由規則）對象，一個Route會與一個Service關聯，並綁定一個域名。Route規則被Router加載。當集群外部的請求通過指定域名訪問應用時，域名被解析並指向Router所在的計算機節點上，Router獲取該請求，然后根據Route規則定義轉發給與這個域名對應的Service后端所關聯的Pod容器實例。上述轉發流程類似於nginx。Router負責將集群外的請求轉發到集群的容器，Service則負責把來自集群內部的請求轉發到指定的容器中。
7. Persistent Storage：容器默認是非持久化的，所有的修改在容器銷毀時都會丟失。Docker提供了持久化卷掛載的能力，Openshift除了提供持久化卷掛載的能力，還提供了一種持久化供給模型即PV（Persistent Volume）和PVC（Persistent Volume Claim）。在PV和PVC模型中，集群管理員會創建大量不同大小和不同特性的PV。用戶在部署應用時顯示的聲明對持久化的需求，創建PVC，在PVC中定義所需要的存儲大小，訪問方式。Openshift集群會自動尋找符合要求的PV與PVC自動對接。
8. Registry：Openshift內部的鏡像倉庫，主要用於存放內置的S2I構建流程所產生的鏡像。
9. S2I：Source to Image，負責將應用源碼構建成鏡像。
步驟：
1）用戶輸入源代碼倉庫的地址
2）選擇S2I構建的基礎鏡像
3）觸發構建
4）S2I構建執行器從指定的源碼倉庫地址下載代碼
5）S2I構建執行器實例化Builder鏡像，並將代碼注入到Builder鏡像
6）S2I構建執行器按照預定義的邏輯執行源代碼的編譯，構建
7）生成新的鏡像
8）S2I構建執行器將新鏡像Push到Registry
9）更新相關的Image Stream信息
【核心流程】
1）創建應用：用戶通過web控制台或oc命令創建應用，Openshift平台根據用戶輸入的源碼地址和Builder鏡像，生成構建配置Builder config和部署配置Deployment config，Service，Route等。
2）觸發構建
3）實例化構建：平台根據Builder config實例化Builder對象，下載代碼，並將代碼注入到Builder對象，執行編譯，構建
4）生成新鏡像並Push到Registry
5）更新相關的Image Stream信息
6）觸發部署：當Image Stream更新后，觸發平台部署鏡像
7）實例化鏡像部署：平台根據Deployment config實例化部署，生成Deploy對象
8）生成Replication Controller
9）部署容器：通過Replication Controller，平台將pod及容器部署到各個節點上
10）用戶訪問：用戶通過瀏覽器訪問Route對象中定義的應用域名
11）請求處理並返回：請求到達Router組件后，通過Route轉發給相關聯的Service，最終到對應的容器實例。
參考：開源容器雲Openshift