如何利用K8S全面擁抱微服務(wù)架構(gòu)？

K8S是第一個將“一切以服務(wù)為中心，一切圍繞服務(wù)運轉(zhuǎn)”作為指導(dǎo)思想的創(chuàng)新型產(chǎn)品，它的功能和架構(gòu)設(shè)計自始至終都遵循了這一指導(dǎo)思想，構(gòu)建在K8S上的系統(tǒng)不僅可以獨立運行在物理機、虛擬機集群或者企業(yè)私有云上，也可以被托管在公有云中。

微服務(wù)架構(gòu)的核心是將一個巨大的單體應(yīng)用拆分為很多小的互相連接的微服務(wù)，一個微服務(wù)背后可能有多個實例副本在支撐。單體應(yīng)用微服務(wù)化以后，服務(wù)之間必然會有依賴關(guān)系，在發(fā)布時，若每個服務(wù)都單獨啟動會非常痛苦，簡單地說包括一些登錄服務(wù)、支付服務(wù)，若想一次全部啟動，此時必不可少要用到編排的動作。

K8S完美地解決了調(diào)度，負載均衡，集群管理、有狀態(tài)數(shù)據(jù)的管理等微服務(wù)面臨的問題，成為企業(yè)微服務(wù)容器化的首選解決方案。使用K8S就是在全面擁抱微服務(wù)架構(gòu)。

在社區(qū)不久前的線上活動交流中，圍繞金融行業(yè)基于K8S的容器云的微服務(wù)解決方案、金融行業(yè)微服務(wù)架構(gòu)設(shè)計、容器云整體設(shè)計架構(gòu)等方面的問題進行了充分的討論，得到了多位社區(qū)專家的支持。大家針對K8S容器云和微服務(wù)結(jié)合相關(guān)的問題，體現(xiàn)出了高度的參與熱情。在此，對大家關(guān)注的問題以及針對這些問題各位專家的觀點總結(jié)如下：

一、K8S容器云部署實踐篇

Q1:現(xiàn)階段容器云部署框架是什么？

A1:

? 在DMZ和內(nèi)網(wǎng)分別部署彼此獨立的2套Openshift，分別為內(nèi)網(wǎng)和DMZ區(qū)兩個網(wǎng)段，兩套環(huán)境彼此隔離。

? DMZ區(qū)的Openshift部署對外發(fā)布的應(yīng)用，負責處理外網(wǎng)的訪問

? 內(nèi)網(wǎng)的Openshift部署針對內(nèi)網(wǎng)的應(yīng)用，僅負責處理內(nèi)網(wǎng)的訪問

-權(quán)限管理

對于企業(yè)級的應(yīng)用平臺來說，會有來自企業(yè)內(nèi)外不同角色的用戶，所以靈活的、細粒度的、可擴展的權(quán)限管理是必不可少的。OCP從設(shè)計初期就考慮到企業(yè)級用戶的需求，所以在平臺內(nèi)部集成了標準化的認證服務(wù)器，并且定義了詳細的權(quán)限策略和角色。

1. 認證：

OCP平臺的用戶是基于對OCP API的調(diào)用權(quán)限來定義的，由于OCP所有的操作都是基于API的，也就說用戶可以是一個開發(fā)人員或者管理員，可以和OCP進行交互。OCP內(nèi)置了一個基于OAuth的通用身份認證規(guī)范的服務(wù)器。這個OAuth服務(wù)器可以通過多種不同類型的認證源對用戶進行認證。

2. 鑒權(quán)：

權(quán)策略決定了一個用戶是否具有對某個對象的操作權(quán)限。管理員可以設(shè)置不同規(guī)則和角色，可以對用戶或者用戶組賦予一定的角色，角色包含了一系列的操作規(guī)則。

除了傳統(tǒng)的認證和鑒權(quán)功能，OCP還提供了針對pod的細粒度權(quán)限控SCC（security context constraints），可以限制pod具備何種類型的權(quán)限，比如容器是否可以運行在特權(quán)模式下、是否可以掛在宿主機的目錄、是否可以使用宿主機的端口、是否可以以root用戶運行等。

-多租戶管理

租戶是指多組不同的應(yīng)用或者用戶同時運行在一個基礎(chǔ)資源池之上，實現(xiàn)軟件、硬件資源的共享，為了安全需求，平臺需要提供資源隔離的能力。

在OCP中，project是一個進行租戶隔離的概念，它來源于kubernetes的namespace，并對其進行了功能的擴展。利用Project，OCP平臺從多個層面提供了多租戶的支持。

1. 權(quán)限控制。通過OCP平臺細粒度的權(quán)限管理機制，管理員可以對不同的用戶和組設(shè)置不同project的權(quán)限，不同用戶登錄以后只能操作和管理特定的project

2. 網(wǎng)絡(luò)隔離。OCP平臺使用openvswitch來管理內(nèi)部的容器網(wǎng)絡(luò)，提供兩種類型的網(wǎng)絡(luò)模式，一種是集群范圍內(nèi)互通的平面網(wǎng)絡(luò)，另一種是project級別隔離的網(wǎng)絡(luò)。每個project都有一個虛擬網(wǎng)絡(luò)ID（VNID），不同VNID的流量被openvswitch自動隔離。所以不同項目之間的服務(wù)在網(wǎng)絡(luò)層不能互通。

3. Router隔離。Router是OCP平臺一個重要軟件資源，它提供了外部請求導(dǎo)入OCP集群內(nèi)部的能力。OCP提供了Router分組的功能，不同的project可以使用獨立的Router，不互相干擾，這樣就避免了由于某些應(yīng)用流量過大時對其他應(yīng)用造成干擾。

物理資源池隔離。在多租戶的環(huán)境中，為了提高資源的利用率一般情況下物理資源池是共享的，但是有些用戶也會提供獨占資源池的需求。針對這種類型的需求，OCP平臺利用nodeSelector的功能可以將基礎(chǔ)設(shè)施資源池劃分給特定的project獨享，實現(xiàn)從物理層面的隔離。

-日志和監(jiān)控

（1）傳統(tǒng)應(yīng)用日志

有別于當前流行的容器應(yīng)用，的傳統(tǒng)應(yīng)用同時一個中間件會運行多個應(yīng)用，且應(yīng)用通過log4j等機制保存在文件中方便查看和排錯。因為容器運行的特性，對于這部分的日志我們需要持久化到外置存儲中。

日志的分類如下：

? 中間件日志

? dump文件

? 應(yīng)用日志

日志保存在計算節(jié)點上掛載的NFS存儲。為了規(guī)范和方便查找。日志將會按OCP平臺中的namespace建立目錄，進行劃分。

（2）新應(yīng)用日志

應(yīng)對分布式環(huán)境下日志分散的解決辦法是收集日志，將其集中到一個地方。收集到的海量日志需要經(jīng)過結(jié)構(gòu)化處理，進而交給需要的人員分析，挖掘日志的價值信息。同時不同的人員對日志的需求是不一樣的，運營人員關(guān)注訪問日志，運維人員關(guān)注系統(tǒng)日志，開發(fā)人員關(guān)注應(yīng)用日志。這樣就需要有一種足夠開放、靈活的方法讓所有關(guān)心日志的人在日志收集過程中對其定義、分割、過濾、索引、查詢。

OpenShift使用EFK來實現(xiàn)日志管理平臺。該管理平臺具備以下能力：

?? 日志采集，將日志集中在一起

?? 索引日志內(nèi)容，快速返回查詢結(jié)果

?? 具有伸縮性，在各個環(huán)節(jié)都能夠擴容

強大的圖形查詢工具、報表產(chǎn)出工具

EFK是Elasticsearch(以下簡寫為ES)+ Fluentd+Kibana的簡稱。ES負責數(shù)據(jù)的存儲和索引，F(xiàn)luentd負責數(shù)據(jù)的調(diào)整、過濾、傳輸，Kibana負責數(shù)據(jù)的展示。

Fluentd無論在性能上，還是在功能上都表現(xiàn)突出，尤其在收集容器日志領(lǐng)域更是獨樹一幟，成為眾多PAAS平臺日志收集的標準方案。

（3）監(jiān)控

PaaS平臺的監(jiān)控包括系統(tǒng)監(jiān)控、容器監(jiān)控等。監(jiān)控流程由信息收集、信息匯總和信息展示等幾個部分組成。

在Openshift中默認使用kubenetes的監(jiān)控信息收集機制，在每個節(jié)點上部署cadvisor的代理，負責收集容器級別的監(jiān)控信息。然后將所有信息匯總到heapster，heapster后臺的數(shù)據(jù)持久化平臺是Cassandra。最后由hawkular從Cassandra獲取信息進行統(tǒng)一的展示。

1. 組件說明

Openshift的監(jiān)控組件，用于對pod運行狀態(tài)的CPU、內(nèi)存、網(wǎng)絡(luò)進行實時監(jiān)控，和Kubernetes使用的監(jiān)控技術(shù)棧一樣，包括三個部分：

HEAPSTER

用于監(jiān)控數(shù)據(jù)的采集

https://github.com/kubernetes/heapster

HAWKULAR METRICS

屬于開源監(jiān)控解決方案Hawkular，基于JSON格式管理、展示監(jiān)控數(shù)據(jù)

http://www.hawkular.org/

CASSANDRA

Apache Cassandra是一個開源的分布式數(shù)據(jù)庫，專門用于處理大數(shù)據(jù)量業(yè)務(wù)

http://cassandra.apache.org/

-DMZ區(qū)計算節(jié)點

在DMZ區(qū)應(yīng)用部署遵循以下策略：

? 已有應(yīng)用遷移至容器云平臺時的資源申請按現(xiàn)有配置設(shè)置，申請的服務(wù)器將僅供該使用

? 如果需要橫向擴展，也僅在已分配的計算節(jié)點上，如果資源不足，應(yīng)用項目組可再申請新的計算資源

? 本期項目中，XXX部署在DMZ區(qū)平臺上，使用2個計算節(jié)點；XXX部署在內(nèi)網(wǎng)平臺上，使用2個計算節(jié)點

? 在實施時需要為相應(yīng)的計算節(jié)點標記標簽，使應(yīng)用部署時部署到指定的計算節(jié)點上。

例如在DMZ網(wǎng)段對XXX應(yīng)用所使用的2臺計算節(jié)點打上標簽

在部署XXX應(yīng)用使，nodeSelector需要指明使用的節(jié)點的標簽為XXX=XXX。

-傳統(tǒng)應(yīng)用訪問策略

? Openshift產(chǎn)品推薦通過NodePort類型的Service為某個應(yīng)用對外暴露一個服務(wù)端口。NodePort類型的Service會在集群中的所有節(jié)點上監(jiān)聽一個特定的端口，訪問任意一個計算機節(jié)點的端口，即可訪問內(nèi)部容器中的服務(wù)。在集群的所有節(jié)點的這個端口都會預(yù)留給該應(yīng)用所用。

? 在F5 VS的Pool Member中配置所有節(jié)點，通過Keepalived來實現(xiàn)HA

? 應(yīng)用系統(tǒng)和用戶不用改變現(xiàn)有的訪問方式

-應(yīng)用訪問及防火墻

內(nèi)網(wǎng)計算節(jié)點可以直接訪問數(shù)據(jù)庫

DMZ區(qū)計算節(jié)點訪問數(shù)據(jù)庫有2種方案：

? 計算節(jié)點直接通過內(nèi)網(wǎng)防火墻訪問該應(yīng)用數(shù)據(jù)庫

內(nèi)網(wǎng)防火墻僅開通應(yīng)用所在節(jié)點訪問內(nèi)部數(shù)據(jù)庫的端口，例如本期項目，xxx應(yīng)用僅使用2個節(jié)點，則防火墻僅開通這2個節(jié)點訪問xxx數(shù)據(jù)庫的權(quán)限

? 計算節(jié)點經(jīng)Outbound 路由通過內(nèi)網(wǎng)防火墻訪問內(nèi)網(wǎng)數(shù)據(jù)o

這oOutbound路由在Openshift中稱之為Egress Routero

因此，內(nèi)網(wǎng)防火墻僅開通應(yīng)用所在節(jié)點訪問內(nèi)部數(shù)據(jù)庫的端口，例如，應(yīng)用A僅通過路由節(jié)點A和B訪問內(nèi)部數(shù)據(jù)庫，則防火墻僅開通這2個節(jié)點訪問A數(shù)據(jù)庫的權(quán)限

Q2: 容器平臺建設(shè)過程中，如何利用好已有云平臺，從技術(shù)、架構(gòu)等層次，需要注意哪些事項？

A2:

容器跑在物理機上，還是跑在云平臺虛機上，這是個值得討論的話題。

對于公有云而言，毫無疑問，肯定是跑在云主機上的。那么，有的客戶在上線容器微服務(wù)之前，已經(jīng)有了自己的私有云平臺，那么這個時候是購買一堆物理機來另起爐灶，還是基于已有云平臺快速部署，這就值得斟酌了。

其實也沒什么好糾結(jié)的，無非就是一個問題:性能！

跑在物理機上，性能肯定是最佳的，但是你真的需要所謂的性能嗎？測過沒有，是否真的只有物理機才能滿足你的容器微服務(wù)應(yīng)用，根據(jù)我的經(jīng)驗，以金融行業(yè)來說，大部分用戶物理機資源常年處于低負荷狀態(tài)！以性能為借口，惡意拉動GDP，就是耍流氓啊！

如果你決定跑在已有云平臺上，那么，你要考慮的問題如下：

1、充分利用LaC（Infrastructure as Code）實現(xiàn)自動化編排部署，這是云平臺最大的優(yōu)勢（比如openstack中的heat），也是裸機集群最大的劣勢；

2、網(wǎng)絡(luò)性能。在IaaS層上面跑容器，網(wǎng)絡(luò)是個需要認真考慮的問題，calico最佳，但是基礎(chǔ)設(shè)施改動大，不是所有客戶都能接收，flannel+hostgw是個不做選擇，原則就是盡量防止二次封裝疊加，致使網(wǎng)絡(luò)性能下降過多。

3、架構(gòu)上具備后續(xù)擴展性，這里指的不僅僅是scale-out擴展，更是功能上的向后擴展，比如隨著微服務(wù)不多擴大，網(wǎng)絡(luò)負載不斷增加，后續(xù)你可能會打算使用service mesh，那么前期就靠考慮清楚兼容性問題

4、最后，也是最樸素的一點，簡單、好用、高可用原則，不要為了高大上而“高大上”，搞得自己完全hold不住，得不償失，一個好的平臺選型就是成功的80%

除此之外

1.需要看已有云平臺提供了哪些功能或接口可以供 容器平臺使用，比如CMDB、比如權(quán)限管理、比如應(yīng)用或者中間件配置等

2.應(yīng)用 以 容器方式和傳統(tǒng)方式 的部署方式和流程 看是否可以抽象統(tǒng)一化，不管是升級回滾擴容等，在運維層面行為一致就能利用已有平臺但是自己要實現(xiàn)底層與編排系統(tǒng)的對接

Q3: K8S集群如何實現(xiàn)集群安全？雙向認證or簡單認證？

A3:

Kubernets系統(tǒng)提供了三種認證方式：CA認證、Token認證和Base認證。安全功能是一把雙刃劍，它保護系統(tǒng)不被攻擊，但是也帶來額外的性能損耗。集群內(nèi)的各組件訪問API Server時，由于它們與API Server同時處于同一局域網(wǎng)內(nèi)，所以建議用非安全的方式訪問API Server，效率更高。

-雙向認證配置

雙向認證方式是最為嚴格和安全的集群安全配置方式，主要配置流程如下：

1）生成根證書、API Server服務(wù)端證書、服務(wù)端私鑰、各個組件所用的客戶端證書和客戶端私鑰。

2）修改Kubernetts各個服務(wù)進程的啟動參數(shù)，啟用雙向認證模式。

-簡單認證配置

除了雙向認證方式，Kubernets也提供了基于Token和HTTP Base的簡單認證方式。通信方仍然采用HTTPS，但不使用數(shù)字證書。

采用基于Token和HTTP Base的簡單認證方式時，API Server對外暴露HTTPS端口，客戶端提供Token或用戶名、密碼來完成認證過程。

不僅僅是API層面，還有每個節(jié)點kubelet和應(yīng)用運行時的安全，可以看下這里

https://kubernetes.io/docs/tasks/administer-cluster/securing-a-cluster/

K8S的認證相對來說還是個比較復(fù)雜的過程，如下這篇文章，詳細介紹了K8S中的認證及其原理：

https://www.kubernetes.org.cn/4061.html

Q4: K8S在容器云上的負載均衡策略和總體思想是什么？

A4:

高可用主要分為如下幾個：

-外部鏡像倉庫高可用

外部鏡像倉庫獨立于OCP平臺之外，用于存儲平臺構(gòu)建過程中所使用的系統(tǒng)組件鏡像。因為外部無法直接訪問OCP平臺的內(nèi)部鏡像倉庫，所以由QA環(huán)境CD推送到生產(chǎn)環(huán)境的鏡像也是先復(fù)制到外部鏡像倉庫，再由平臺導(dǎo)入至內(nèi)部鏡像倉庫。

為了保證外部鏡像倉庫的高可用， 使用了2臺服務(wù)器，前端使用F5進行負載均衡，所有的請求均發(fā)至F5的虛擬地址，由F5進行轉(zhuǎn)發(fā)。后端鏡像倉庫通過掛載NFS共享存儲。

-master主控節(jié)點高可用

Openshift的Master主控節(jié)點承擔了集群的管理工作

-計算節(jié)點（容器應(yīng)用）高可用

計算節(jié)點高可用指計算節(jié)點上運行的容器應(yīng)用的高可用。一個計算節(jié)點異常停機后，其上的容器將會被逐步遷移到其他節(jié)點上，從而保證了高可用。

同時可以通過標簽的方式來管理計算節(jié)點，在不同的計算節(jié)點劃分為不同的可用區(qū)或組。在部署應(yīng)用時，使用節(jié)點選擇器將應(yīng)用部署至帶有指定標簽的目標計算節(jié)點上。為了保證高可用，標簽組合的目標計算節(jié)點數(shù)要大于1。這樣可以避免一臺目標節(jié)點宕機后，調(diào)度器還能找到滿足條件的計算節(jié)點進行容器部署。

-應(yīng)用高可用

基于軟件（HAproxy）負載均衡服務(wù)，容器服務(wù)彈性伸縮時無需人工對負載均衡設(shè)備進行配置干預(yù)，即可保證容器化應(yīng)用的持續(xù)、正常訪問；可通過圖形界面自定義負載均衡會話保持策略。

由于平臺內(nèi)部通過軟件定義網(wǎng)絡(luò)為每個應(yīng)用容器分配了IP地址，而此地址是內(nèi)網(wǎng)地址，因此外部客戶無法直接訪問到該地址，所以平臺使用路由器轉(zhuǎn)發(fā)外部的流量到集群內(nèi)部具體的應(yīng)用容器上，如果應(yīng)用有多個容器實例，路由器也可實現(xiàn)負載均衡的功能。路由器會動態(tài)的檢測平臺的元數(shù)據(jù)倉庫，當有新的應(yīng)用部署或者應(yīng)用實例發(fā)生變化時，路由器會自動根據(jù)變化更新路由信息，從而實現(xiàn)動態(tài)負載均衡的能力。

簡單一點來說，就是內(nèi)部服務(wù)的動態(tài)發(fā)現(xiàn)、負載均衡、高可用和外部訪問的路由；

通過service，解耦動態(tài)變化的IP地址，POD可以隨意關(guān)停，IP可以任意變，只要DNS正常，服務(wù)訪問不受影響，但是這里面你的隨時保證有個可用的POD,這個時候你就得需要LB了，或者說LB干的就是這個事情。

內(nèi)部服務(wù)之間訪問通過service解決了，那么外部訪問集群內(nèi)服務(wù)，則通過router即是解決，外網(wǎng)訪問要不要負載均衡，大規(guī)模高并發(fā)情況下是肯定的，當然，外部負載均衡通常需要用戶自己搞定了，F(xiàn)5或者開源的HAproxy都行！

Q5: 多租戶在kubernets/openshift的實現(xiàn)和管理？

A5:

租戶是指多組不同的應(yīng)用或者用戶同時運行在一個基礎(chǔ)資源池之上，實現(xiàn)軟件、硬件資源的共享，為了安全需求，平臺需要提供資源隔離的能力。

在OCP中，project是一個進行租戶隔離的概念，它來源于kubernetes的namespace，并對其進行了功能的擴展。利用Project，OCP平臺從多個層面提供了多租戶的支持。

1. 權(quán)限控制。通過OCP平臺細粒度的權(quán)限管理機制，管理員可以對不同的用戶和組設(shè)置不同project的權(quán)限，不同用戶登錄以后只能操作和管理特定的project

2. 網(wǎng)絡(luò)隔離。OCP平臺使用openvswitch來管理內(nèi)部的容器網(wǎng)絡(luò)，提供兩種類型的網(wǎng)絡(luò)模式，一種是集群范圍內(nèi)互通的平面網(wǎng)絡(luò)，另一種是project級別隔離的網(wǎng)絡(luò)。每個project都有一個虛擬網(wǎng)絡(luò)ID（VNID），不同VNID的流量被openvswitch自動隔離。所以不同項目之間的服務(wù)在網(wǎng)絡(luò)層不能互通。

3. Router隔離。Router是OCP平臺一個重要軟件資源，它提供了外部請求導(dǎo)入OCP集群內(nèi)部的能力。OCP提供了Router分組的功能，不同的project可以使用獨立的Router，不互相干擾，這樣就避免了由于某些應(yīng)用流量過大時對其他應(yīng)用造成干擾。

物理資源池隔離。在多租戶的環(huán)境中，為了提高資源的利用率一般情況下物理資源池是共享的，但是有些用戶也會提供獨占資源池的需求。針對這種類型的需求，OCP平臺利用nodeSelector的功能可以將基礎(chǔ)設(shè)施資源池劃分給特定的project獨享，實現(xiàn)從物理層面的隔離。

openshift里面對多租戶問題有比較好的解決方案，openshift默認使用OVS來實現(xiàn)SDN，高級安裝里面默認使用ovs-subnet SDN插件，網(wǎng)絡(luò)實現(xiàn)類似于flat網(wǎng)絡(luò)，因此要實現(xiàn)多租戶可以在安裝過程中設(shè)置參數(shù)：

os_sdn_network_plugin_name='redhat/openshift-ovs-multitenant'

這樣openshift將使用ovs-multitenant多租戶插件，實現(xiàn)租戶之間的安全隔離，另外，在openshift的多租戶和容器中心化日志實現(xiàn)中，每個租戶都只能查看屬于自己項目的日志，這個確實有亮點的！

除了OVS插件，openshift是完全支持CNI標準的，因此，是要是符合CNI標準的三方SDN插件，都是可以在openshift中使用的，目前支持的SDN插件有：

1、Cisco Contiv；

2、Juniper Contrail；

3、Nokia Nuage；

4、Tigera Calico ；

5、VMware NSX-T ；

另外，openshift是支持部署在物理機、虛擬機、公有云和私有云上的，可能有些用戶會利用已有的公有云或私有云來部署。這個時候，如果使用OVS插件，你OpenShift中的SDN可能出現(xiàn)overlay on overlay的情況，此借助三方SDN插件是個不錯的選擇，比如flannel+hostgw在性能上肯定就優(yōu)于默認的ovs-multitenant。

Q6: elasticsearch在K8S中部署？

A6

不論是IaaS還是PaaS，手工部署ELK都是不推薦的，通過ansible可以自動實現(xiàn)，至于如何實現(xiàn)，可以參考redhat文檔：

https://docs.openshift.org/3.9/install_config/aggregate_logging.html

至于說分布式存儲、本地存儲還是集中存儲，這個沒有既定答案，都是可以參考行業(yè)實現(xiàn)，比如Redhat就是參考對象

不建議elasticsearch采用分布式存儲，日志亮大情況下如果是分布式存儲es寫會是瓶頸。

根據(jù)你的描述，應(yīng)該是有兩個方面的問題：

1）es的后端存儲的選擇

2）Pod的創(chuàng)建

問題一：

分布式，本地，集中存儲不管是在傳統(tǒng)環(huán)境，還是在容器的環(huán)境中，都有使用。目前對于數(shù)據(jù)庫應(yīng)用，我們看到還是傳統(tǒng)存儲-集中存儲，占了絕大多數(shù)的市場。

分布式存儲，隨著云計算的興起，誕生的一種存儲架構(gòu)。它的優(yōu)勢很明顯，無中心節(jié)點，彈性伸縮，適合云應(yīng)用，等等。傳統(tǒng)的廠商，netapp，emc，ibm，hp都有分布式存儲，都是基于其傳統(tǒng)的技術(shù)；新興的開源分布式存儲ceph，已經(jīng)成為分布式存儲的領(lǐng)軍技術(shù)，有redhat，suse，xsky，聯(lián)想，華三等。

分布式存儲的劣勢主要是，還處于發(fā)展階段，技術(shù)有待成熟，有待市場的接受。本地存儲，一般使用的應(yīng)該比較少。主要是數(shù)據(jù)復(fù)制同步方面的問題。

集中存儲，目前用的最多的，不管是FCSAN還是IPSAN，其穩(wěn)定性和安全性都是能夠滿足要求的。但是，在性價比，可擴展性方面都存在很大的問題。

問題二：

K8S的所有的流程都不是手動完成的，都是基于自動化完成?？梢允褂胏hef/ansible/puppt等工具完成。

Q7: K8S集群中的各受管節(jié)點以及其中的容器如何做監(jiān)控？

A7:

kubernetes已成為各大公司親睞的容器編排工具，各種私有云公有云平臺基于它構(gòu)建，其監(jiān)控解決方案目前有三種：

（1）heapster+influxDB

（2）heapster+hawkular

（3）prometheus

prometheus作為一個時間序列數(shù)據(jù)收集，處理，存儲的服務(wù)，能夠監(jiān)控的對象必須直接或間接提供prometheus認可的數(shù)據(jù)模型，通過http api的形式發(fā)出來。我們知道cAdvisor支持prometheus,同樣，包含了cAdivisor的kubelet也支持prometheus。每個節(jié)點都提供了供prometheus調(diào)用的api。

prometheus支持k8s

prometheus獲取監(jiān)控端點的方式有很多，其中就包括k8s，prometheu會通過調(diào)用master的apiserver獲取到節(jié)點信息，然后去調(diào)取每個節(jié)點的數(shù)據(jù)。

k8s節(jié)點的kubelet服務(wù)自帶cadvisor用來收集各節(jié)點容器相關(guān)監(jiān)控信息，然后通過heapster收集，這樣在dashboard上可以看到容器使用CPU和Memory。

為了長期監(jiān)控，可以采用prometheus監(jiān)控方案nodeExporter收集主機監(jiān)控信息cadvisor收集容器監(jiān)控信息

k8s中需要給kubelet配合kube-reserved和system-reserved相關(guān)參數(shù)給系統(tǒng)預(yù)留內(nèi)存

監(jiān)控領(lǐng)域，無非就是E*K，heapster、influxDB、heapster、hawkular、prometheus、grafana這些東西了，就目前來看，prometheus應(yīng)該是最具前景的監(jiān)控工具，在openshift 3.12里面，heapster將由prometheus替換，未來應(yīng)該是prometheus的天下吧！

二、微服務(wù)部署piapian

Q1: 微服務(wù)架構(gòu)按照什么細粒度拆分？

A1：

既然理解微服務(wù)是用來重構(gòu)業(yè)務(wù)應(yīng)用的，這個問題就很簡單，以業(yè)務(wù)應(yīng)用為核心，構(gòu)建業(yè)務(wù)服務(wù)。忘掉，重構(gòu)！

業(yè)務(wù)服務(wù)需要數(shù)據(jù)服務(wù)、計算服務(wù)、搜索服務(wù)、算法服務(wù)……以及基本的日志、監(jiān)控、配置、注冊發(fā)現(xiàn)、網(wǎng)關(guān)、任務(wù)調(diào)度等組件。

至于數(shù)據(jù)服務(wù)怎么實現(xiàn)，看你團隊能力。這才涉及數(shù)據(jù)分拆，模型重構(gòu)。

服務(wù)通信可以考慮事件驅(qū)動機制，也是后期業(yè)務(wù)數(shù)據(jù)處理，態(tài)勢感知，智能風控，智能營銷，智能運維等的基礎(chǔ)。

感覺這是個沒有標準答案的問題，如何拆？按什么套路來拆？問答這兩個問題的基礎(chǔ)一定要十分熟悉你的業(yè)務(wù)邏輯才行。微服務(wù)這東西，尤其是那種已經(jīng)運行多年的老系統(tǒng)，一不小心就能拆出問題。

如果對云計算，對OpenStack有了解，建議以O(shè)penStack中的Kolla項目為微服務(wù)入門學習對象，Kolla干的事情就是把OpenStack服務(wù)拆分成微服務(wù)的形式跑在容器中，OpenStack號稱全球最大開源Python項目，由幾十個開源子項目組成，如果能把這樣復(fù)雜的集群項目都拆分成微服務(wù)，那么一定會得到很多別人給不了的心得體會。

這里以O(shè)penStack為例，Kolla這個項目對OpenStack的拆分，大概如下：

1、先按服務(wù)功能劃分，得到粗粒度，如計算服務(wù)、網(wǎng)絡(luò)服務(wù)、存儲服務(wù)，這些租粒度模塊通常會共享同一個base鏡像，這個base鏡像中預(yù)置了服務(wù)模塊的共性依賴；

2、基于服務(wù)模塊的“原子性”拆分，如把計算服務(wù)Nova拆分為noav-api、nova-scheduler、nova-compoute、nova-libvirt等等，所謂原子性拆分，就是拆分到不能再往下拆為止，原子拆分后通常就是彼此獨立的單進程了，也可以把他們稱為是葉子節(jié)點了，他們的鏡像都是針對自己依賴的“個人”鏡像，不能被其他進程共享了。

如果從鏡像的角度來看，大概是這樣：

父鏡像：centos-base

一級子鏡像：centos-openstack-base

二級子鏡像：centos-nova-base

葉子節(jié)點鏡像：centos-nova-api

這幾個鏡像的繼承關(guān)系是這樣的：centos-base->centos-openstack-base->centos-nova-base->centos-nova-api

以上只是舉個例子供參考，建議深入了解下Kolla這個項目，對于微服務(wù)的拆分就會更有底氣些！

先將系統(tǒng)模塊化 解耦，別的微服務(wù)還是一體都只是部署的問題。 常見的耦合方式有 邏輯耦合 功能耦合 時間耦合等， 感覺從碼農(nóng)的角度來分析解決耦合是基于微服務(wù)還是soa化的最大區(qū)別。 soa化的系統(tǒng)更多的是業(yè)務(wù)系統(tǒng)，領(lǐng)域模型級別的。 在分布式系統(tǒng)中遠遠不夠需要考慮性能，安全，事務(wù)等，最起碼的cap原則還是要把控的。 碼農(nóng)解耦的角度有 接口化，動靜分離（查詢和修改等），元數(shù)據(jù)抽取等等，更多的是代碼上，設(shè)計模式上的真功夫 。 很多架構(gòu)的估計沒這個水平， 只看大象不看大腿。需要明確：

1、充分分析拆分的目的是什么，需要解決什么問題。

2、是否具備微服務(wù)技術(shù)能力，是否已選型好相應(yīng)的技術(shù)框架，技術(shù)變化對企業(yè)有什么影響。

3、是否有完善的運維設(shè)施保障，比如快速配置、基礎(chǔ)監(jiān)控、快速部署等能力。

Q2: svn環(huán)境下實現(xiàn)CI/CD？

A2：

svn可以使用hook(post commit)的方式來實現(xiàn)，但是需要編寫hook腳本，靈活度存在問題；

這在svn-repo的粒度較細的情況下還可行，如何一個大的repo，管理起來較復(fù)雜，不建議使用；

建議使用jenkins 輪詢scm的方式觸發(fā)pipeline/job

能不能實現(xiàn)CI/CD與SVN無關(guān)，關(guān)鍵是你如何構(gòu)建pipeline，微服務(wù)理念下大致這樣：

gitlab/svn->Jenkins->build images->push images->docker-registry->pull images->containers

Q3: K8S DNS服務(wù)配置如何實現(xiàn)微服務(wù)的發(fā)布？

A3：

配置k8s dns

DNS (domain name system),提供域名解析服務(wù)，解決了難于記憶的IP地址問題，以更人性可讀可記憶可標識的方式映射對應(yīng)IP地址。

Cluster DNS擴展插件用于支持k8s集群系統(tǒng)中各服務(wù)之間發(fā)現(xiàn)與調(diào)用。

組件：

?SkyDNS 提供DNS解析服務(wù)

?Etcd 存儲DNS信息

?Kube2sky 監(jiān)聽kubernetes，當有Service創(chuàng)建時，生成相應(yīng)的記錄到SkyDNS。

如訪問外部DNS，可以設(shè)置external_dns 到configmap實現(xiàn)

Q4: 請問在K8S中部署數(shù)據(jù)庫現(xiàn)在有好的解決方案了么？

A4：

銀聯(lián)搞了一個基于容器的DBaaS，是供應(yīng)商做的，這里是ppt可以參考，主要點:SAN 和 SR-IOV

Q5: K8S目前是否有可視化的服務(wù)編排組件

A5：

K8S目前最大的弊端，有點類似OpenStack的早期，使用起來太復(fù)雜了，一款好的產(chǎn)品如果僅是功能強大，但是不便于使用，對用戶而言，他就不是真正意義上的好產(chǎn)品。目前，K8S中好像也沒什么可視化編排組件，滿世界的YAML讓人眼花繚亂。我的理解，單純的K8S使用是很難構(gòu)建一套平臺出來的，要構(gòu)建一套自動化編排平臺，應(yīng)該是以K8S為kernel，集成外圍諸多生態(tài)圈軟件，這樣才能實現(xiàn)滿足終端用戶要求的自動化調(diào)度、編排、CI/CD平臺。這就好比單純使用Linux內(nèi)核來自己構(gòu)建系統(tǒng)的，都是極為熟悉內(nèi)核的大牛一樣，如果內(nèi)核外面沒有很多tools、utilities供你使用，普通用戶是沒法使用Linux系統(tǒng)的。從這個角度來看，Openshift就是容器微服務(wù)時代的“Linux”。K8S可以去研究，但是如果是拿來使用的話，還是OpenShift吧！

可以根據(jù)應(yīng)用類型指定對應(yīng)的yaml模板，通過制作前端頁面調(diào)用k8s api動態(tài)更新資源描述并使其生效，至于拖拽組合功能在前端做設(shè)計(招專業(yè)前端啊)對應(yīng)到后端需要調(diào)用哪些api

類似于是想要一個類似于openstack 的heat工具，或者vmware的blueprint的工具。目前，為了適應(yīng)快速的業(yè)務(wù)需求，微服務(wù)架構(gòu)已經(jīng)逐漸成為主流，微服務(wù)架構(gòu)的應(yīng)用需要有非常好的服務(wù)編排支持，k8s中的核心要素Service便提供了一套簡化的服務(wù)代理和發(fā)現(xiàn)機制，天然適應(yīng)微服務(wù)架構(gòu)，任何應(yīng)用都可以非常輕易地運行在k8s中而無須對架構(gòu)進行改動；

k8s分配給Service一個固定IP，這是一個虛擬IP(也稱為ClusterIP)，并不是一個真實存在的IP，而是由k8s虛擬出來的。虛擬IP的范圍通過k8s API Server的啟動參數(shù) --service-cluster-ip-range=19.254.0.0/16配置;虛擬IP屬于k8s內(nèi)部的虛擬網(wǎng)絡(luò)，外部是尋址不到的。在k8s系統(tǒng)中，實際上是由k8s Proxy組件負責實現(xiàn)虛擬IP路由和轉(zhuǎn)發(fā)的，所以k8s Node中都必須運行了k8s Proxy，從而在容器覆蓋網(wǎng)絡(luò)之上又實現(xiàn)了k8s層級的虛擬轉(zhuǎn)發(fā)網(wǎng)絡(luò)。

服務(wù)代理：

在邏輯層面上，Service被認為是真實應(yīng)用的抽象，每一個Service關(guān)聯(lián)著一系列的Pod。在物理層面上，Service有事真實應(yīng)用的代理服務(wù)器，對外表現(xiàn)為一個單一訪問入口，通過k8s Proxy轉(zhuǎn)發(fā)請求到Service關(guān)聯(lián)的Pod。

Service同樣是根據(jù)Label Selector來刷選Pod進行關(guān)聯(lián)的，實際上k8s在Service和Pod之間通過Endpoint銜接，Endpoints同Service關(guān)聯(lián)的Pod；相對應(yīng)，可以認為是Service的服務(wù)代理后端，k8s會根據(jù)Service關(guān)聯(lián)到Pod的PodIP信息組合成一個Endpoints。

Service不僅可以代理Pod，還可以代理任意其他后端，比如運行在k8s外部的服務(wù)。加速現(xiàn)在要使用一個Service代理外部MySQL服務(wù)，不用設(shè)置Service的Label Selector。

微服務(wù)化應(yīng)用的每一個組件都以Service進行抽象，組件與組件之間只需要訪問Service即可以互相通信，而無須感知組件的集群變化。這就是服務(wù)發(fā)現(xiàn)；

--service發(fā)布

k8s提供了NodePort Service、 LoadBalancer Service和Ingress可以發(fā)布Service；

NodePort Service

NodePort Service是類型為NodePort的Service， k8s除了會分配給NodePort Service一個內(nèi)部的虛擬IP，另外會在每一個Node上暴露端口NodePort，外部網(wǎng)絡(luò)可以通過[NodeIP]:[NodePort]訪問到Service。

LoadBalancer Service (需要底層云平臺支持創(chuàng)建負載均衡器,比如GCE)

LoadBalancer Service是類型為LoadBalancer的Service，它是建立在NodePort Service集群基礎(chǔ)上的，k8s會分配給LoadBalancer；Service一個內(nèi)部的虛擬IP，并且暴露NodePort。除此之外，k8s請求底層云平臺創(chuàng)建一個負載均衡器，將每個Node作為后端，負載均衡器將轉(zhuǎn)發(fā)請求到[NodeIP]:[NodePort]。

Q6: service mesh和spring cloud的優(yōu)缺點

A6

2018年以前，扛起微服務(wù)大旗的，可能是Spring Cloud。Service Mesh作為一種非侵入式API的框架。比侵入式的Spring Cloud，雖然還在處于成長期，但是應(yīng)該更有前景。

關(guān)于service mesh的定義，通常以Buoyant 公司的 CEO Willian Morgan 在其文章 WHAT’S A SERVICE MESH? AND WHY DO I NEED ONE? 中對 Service Mesh的定義為參考：

A service mesh is a dedicated infrastructure layer for handling service-to-service communication. It’s responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud native application. In practice, the service mesh is typically implemented as an array of lightweight network proxies that are deployed alongside application code, without the application needing to be aware.

就行業(yè)而言，Docker和Kubernetes解決的了服務(wù)部署的問題，但是運行時的問題還未解決，而這正是Service Mesh的用武之地。Service Mesh的核心是提供統(tǒng)一的、全局的方法來控制和測量應(yīng)用程序或服務(wù)之間的所有請求流量(用數(shù)據(jù)中心的話說，就是“east-west”流量)。對于采用了微服務(wù)的公司來說，這種請求流量在運行時行為中扮演著關(guān)鍵角色。因為服務(wù)通過響應(yīng)傳入請求和發(fā)出傳出請求來工作，所以請求流成為應(yīng)用程序在運行時行為的關(guān)鍵決定因素。因此，標準化流量管理成為標準化應(yīng)用程序運行時的工具。

通過提供api來分析和操作此流量，Service Mesh為跨組織的運行時操作提供了標準化的機制——包括確?？煽啃?、安全性和可見性的方法。與任何好的基礎(chǔ)架構(gòu)層一樣，Service Mesh采用的是獨立于服務(wù)的構(gòu)建方式。

請參考：https://developers.redhat.com/blog/2016/12/09/spring-cloud-for-microservices-compared-to-kubernetes/

Q7: dubbo，zookeeper環(huán)境下，K8S的問題？

A7：

遇到過的問題

1.如果k8s上的應(yīng)用僅僅是consumer，應(yīng)該是沒問題的，不管provider是在k8s集群內(nèi)部還是外部

2.如果k8s上的應(yīng)用是provider，注冊到zk時是容器地址，這時如果consumer如果在集群內(nèi)部容器方式運行是能訪問到provider的，如果consumer在集群外部，那就訪問不到，也就是你說的情況吧。

這個時候需要做一些路由策略: 設(shè)置consumer所在網(wǎng)段到k8s內(nèi)部網(wǎng)段下一跳為k8s集群內(nèi)部某一個節(jié)點即可，我們在騰訊云和阿里云上就是這么做的，VPC內(nèi)非K8S節(jié)點也可以直通K8S集群內(nèi)部overlay網(wǎng)絡(luò)IP地址

通過api gateway來暴露需要對外的API。gateway不僅可以打通網(wǎng)絡(luò)，還可以隱藏內(nèi)部api，方便api治理

三、金融行業(yè)容器云微服務(wù)實踐篇

Q1: 金融行業(yè)的微服務(wù)架構(gòu)一般是怎樣的，案例有哪些？

A1：

-微服務(wù)(Microservices Architecture)是一種架構(gòu)風格，一個大型復(fù)雜軟件應(yīng)用由一個或多個微服務(wù)組成。系統(tǒng)中的各個微服務(wù)可被獨立部署，各個微服務(wù)之間是松耦合的。每個微服務(wù)僅關(guān)注于完成一件任務(wù)并很好地完成該任務(wù)。微服務(wù)是指開發(fā)一個單個 小型的但有業(yè)務(wù)功能的服務(wù)，每個服務(wù)都有自己的處理和輕量通訊機制，可以部署在單個或多個服務(wù)器上。微服務(wù)也指一種種松耦合的、有一定的有界上下文的面向服務(wù)架構(gòu)。也就是說，如果每個服務(wù)都要同時修改，那么它們就不是微服務(wù)，因為它們緊耦合在一起；如果你需要掌握一個服務(wù)太多的上下文場景使用條件，那么它就是一個有上下文邊界的服務(wù)。

-微服務(wù)架構(gòu)的優(yōu)點：

每個微服務(wù)都很小，這樣能聚焦一個指定的業(yè)務(wù)功能或業(yè)務(wù)需求。

微服務(wù)能夠被小團隊單獨開發(fā)，這個小團隊是2到5人的開發(fā)人員組成。

微服務(wù)是松耦合的，是有功能意義的服務(wù)，無論是在開發(fā)階段或部署階段都是獨立的。

微服務(wù)能使用不同的語言開發(fā)。

微服務(wù)易于被一個開發(fā)人員理解，修改和維護，這樣小團隊能夠更關(guān)注自己的工作成果。無需通過合作才能體現(xiàn)價值。

微服務(wù)允許你利用融合最新技術(shù)。

微服務(wù)只是業(yè)務(wù)邏輯的代碼，不會和HTML,CSS 或其他界面組件混合。

-微服務(wù)架構(gòu)的缺點：

微服務(wù)架構(gòu)可能帶來過多的操作。

需要DevOps技巧。

可能雙倍的努力。

分布式系統(tǒng)可能復(fù)雜難以管理。

因為分布部署跟蹤問題難。

當服務(wù)數(shù)量增加，管理復(fù)雜性增加。

-微服務(wù)適合哪種情況：

當需要支持桌面，web，移動智能電視，可穿戴時都是可以的。

甚至將來可能不知道但需要支持的某種環(huán)境。

未來的規(guī)劃，將以產(chǎn)業(yè)鏈延伸、客戶導(dǎo)向及互聯(lián)網(wǎng)+為戰(zhàn)略發(fā)展方向，需要BI分析、業(yè)務(wù)動態(tài)擴展、以及敏捷的產(chǎn)品與服務(wù)對接和裝配的能力支撐，基于以上的技術(shù)要求，優(yōu)化建設(shè)支撐企業(yè)業(yè)務(wù)及應(yīng)用運營的基礎(chǔ)設(shè)施，結(jié)合基礎(chǔ)資源現(xiàn)狀，建立云計算技術(shù)能力，形成快速響應(yīng)，可持續(xù)發(fā)展的下一代數(shù)據(jù)中心。

對比傳統(tǒng)方案，容器云的方案，將在對微服務(wù)架構(gòu)的支持、業(yè)務(wù)彈性擴容、自動化部署、產(chǎn)品快速上線、敏捷/迭代、全面系統(tǒng)監(jiān)控等方面對IT部門帶來全方位的提升。

目前金融行業(yè)案例：

銀行：中國銀聯(lián)，工商銀行，浦發(fā)銀行、梅州客商銀行等；

保險：太平洋保險，平安保險、中國人壽、大地保險、眾安保險；

證券：海通證券

Q2: 部署在K8S上的微服務(wù)，如何實現(xiàn)有狀態(tài)和無狀態(tài)服務(wù)對于存儲的要求？

A2：

容器的特性決定了容器本身是非持久化的，容器被刪除，其上的數(shù)據(jù)也一并刪除。而其上承載的應(yīng)用分為有狀態(tài)和無狀態(tài)。容器更傾向于無狀態(tài)化應(yīng)用，可水平擴展的，但并不意味所有的應(yīng)用都是無狀態(tài)的，特別是銀行的應(yīng)用，一些服務(wù)的狀態(tài)需要保存比如日志等相關(guān)信息，因此需要持久化存儲。容器存儲大致有三種存儲方案：

（1）原生云存儲方案：按照純粹的原生云的設(shè)計模式，持久化數(shù)據(jù)并不是存儲在容器中，而是作為后端服務(wù)，例如對象存儲和數(shù)據(jù)庫即服務(wù)。這個方案可以確保容器和它們的數(shù)據(jù)持久化支持服務(wù)松耦合，同時也不需要那些會限制擴展的依賴。

（2）把容器作為虛擬機：利用容器帶來的便攜性的優(yōu)點，一些用戶將容器作為輕量虛擬機來使用。如果便攜性是遷移到容器的原因之一，那么采用容器替代虛擬機來安裝遺留應(yīng)用是這種便攜性的反模式。由于大卷中存儲數(shù)據(jù)是緊耦合在容器上，便攜性難以實現(xiàn)。

（3）容器持久化數(shù)據(jù)卷：在容器中運行的應(yīng)用，應(yīng)用真正需要保存的數(shù)據(jù)，可以寫入持久化的Volume數(shù)據(jù)卷。在這個方案中，持久層產(chǎn)生價值，不是通過彈性，而是通過靈活可編程，例如通過設(shè)計的API來擴展存儲。這個方案結(jié)合了持久層和或純云原生設(shè)計模式。

Docker發(fā)布了容器卷插件規(guī)范，允許第三方廠商的數(shù)據(jù)卷在Docker引擎中提供數(shù)據(jù)服務(wù)。這種機制意味著外置存儲可以超過容器的生命周期而獨立存在。而且各種存儲設(shè)備只要滿足接口API標準，就可接入Docker容器的運行平臺中。現(xiàn)有的各種存儲可以通過簡單的驅(qū)動程序封裝，從而實現(xiàn)和Docker容器的對接?？梢哉f，驅(qū)動程序?qū)崿F(xiàn)了和容器引擎的北向接口，底層則調(diào)用后端存儲的功能完成數(shù)據(jù)存取等任務(wù)。目前已經(jīng)實現(xiàn)的Docker Volume Plugin中，后端存儲包括常見的NFS，GlusterFS和塊設(shè)備等。

K8S中的持久性存儲主要還是通過PV、PVC和StorageClass來實現(xiàn)。

對于無狀態(tài)服務(wù)，存儲可能是不必要的，但是對于由狀態(tài)服務(wù)，需要各種類型的存儲來保持狀態(tài)。在K8S中，PV提供存儲資源，PVC使用存儲資源，二者是供應(yīng)者和消費者的關(guān)系，那么服務(wù)是如何把數(shù)據(jù)存儲到PV上的呢？

我們知道K8S中服務(wù)運行在POD中，因此在POD的YAML定義文件中，就需要定義PVC，并指定要關(guān)聯(lián)的PVC名稱，然后PVC會根據(jù)自身的YAML文件定義綁定合適的PV，流程就是：POD->PVC->PV,當然，這是靜態(tài)供給方式，靜態(tài)供給的特定就是先有PV再有PVC。

對于動態(tài)供給方式，就需要定義storageclass，并在存儲類的YAML文件中聲明存儲卷供應(yīng)者，如aws-ebs、ceph-rbd和cinder等，當POD需要存儲的時候，再動態(tài)創(chuàng)建PV，其特點就是先PVC再PV；

當然，存儲這塊本身有很多需要考慮的地方，最佳答案還是官網(wǎng)

https://kubernetes.io/docs/concepts/storage/persistent-volumes/

這里有兩個擴閱讀，關(guān)于容器原生存儲：

https://www.linuxfoundation.org/press-release/opensds-aruba-release-unifies-sds-control-for-kubernetes-and-openstack/

https://github.com/openebs/openebs

Q3: kubernets如何Devops實現(xiàn)持續(xù)部署發(fā)布測試全流程？

A3：

使用原生kubernets實現(xiàn)CI/CD最大的弊端，就是你需要自己搞定Jenkins、Registry，以及外圍的ELK監(jiān)控、grafana等等東西，單是部署這些都要花費大量時間。

Openshift已經(jīng)集成Jenkins，自帶內(nèi)部registry，支持pipeline，用戶需要做的就是搭建自己的Gitlab或者SVN用以存放自己的源代碼，Openshift社區(qū)在Jenkins中實現(xiàn)了很多openshift插件，使得你在Jenkins和openshift之間可以實現(xiàn)互動關(guān)聯(lián)操作，同時openshift提供了私有鏡像倉庫，可以將編譯后的docker鏡像存儲在openshift內(nèi)部registry中，然后在開發(fā)、測試和生產(chǎn)環(huán)境都可從這個registry中抓取鏡像部署，開發(fā)、測試和生產(chǎn)環(huán)境之間在Jenkins中通過openshift插件進行觸發(fā)，完美解決構(gòu)建pipeline實現(xiàn)CI/CD。所以，完全沒別要自己搞k8s+Jenkins，openshift已經(jīng)提供了一站式解決方案。還是那句話，與其悶頭搞K8S，不如直接上openshift！

kubernetes需要整合Jenkins、Harbor、Gitlab還有日志管理、監(jiān)控管理等等的其他組件，看需要，來實現(xiàn)持續(xù)部署持續(xù)發(fā)布的全流程。

GitLab主要負責開發(fā)代碼的存放管理。

Jenkins是一個持續(xù)集成持續(xù)發(fā)布引擎，使用jenkins感覺它太重了，不太適合容器，當然也可以選擇其他的。

Harbor就是私有鏡像倉庫了，新版Harbor提供了鏡像安全掃描等功能，當然也可以使用其他的，如registry。

完成DevOps的話需要整合這些進行一些平臺化的開發(fā)，這樣才會有比較好的交互體驗。也可以直接使用Jenkins

Q4:微服務(wù)的編排K8S提供了很多yaml文件，但這其實用戶體驗并不好，有什么圖形編排的解決思路么？以及怎樣用微服務(wù)的理念打造企業(yè)中臺（SOA）？

A4：

SOA面向服務(wù)架構(gòu)，它可以根據(jù)需求通過網(wǎng)絡(luò)對松散耦合的粗粒度應(yīng)用組件進行分布式部署、組合和使用。服務(wù)層是SOA的基礎(chǔ)，可以直接被應(yīng)用調(diào)用，從而有效控制系統(tǒng)中與軟件代理交互的人為依賴性。

大多數(shù)初次接觸YAML的人都會覺得這類文檔模板體驗極差，感覺太反人類了，各種對齊、格式，一不小心就語法報錯，通常又不能準確定位錯誤點，對新手來說，這種YAML文本確實很頭疼，但是又沒法，K8S里面盡是YAML，奈何？？？？

即使真有圖形編排解決思路，感覺也是換湯不換藥。

解決問題的根本辦法，通常就是釜底抽薪。目前，已有大牛發(fā)起noYAML運動，雖然還未成氣候，但是至少說明確實有很多人不喜歡YAML，而且在使用實際行動來不喜歡。

細數(shù)YAML“十宗罪”：

https://arp242.net/weblog/yaml_probably_not_so_great_after_all.html

https://news.ycombinator.com/item?id=17358103

如果希望在K8S上運行微服務(wù)，那么有必要了解一些云原生編程語言，如：

Pulumi（https://www.pulumi.com/）

Ballerina（https://ballerina.io/）

對于終端用戶而言，或許平臺才是你最終需要的。設(shè)想你有一個平臺引擎，這個平臺引擎集成了Docker及其調(diào)度引擎K8S，然后你只需要編寫業(yè)務(wù)邏輯代碼，然后鏡像封裝、容器部署調(diào)度全部交由平臺處理，當然這個過程中各種YAML文件也由平臺自動生成，何樂而不為？

那問題就是：有沒有這樣的平臺？

以前就有，但是確實不怎么好用，但是OpenShift V3出來之后，個人認為它就是我們要找的平臺。作為終端用戶，我個人并不建議直接搞K8S，對K8S有些概念術(shù)語上的理解，就可直接上OpenShift V3。K8s和Docker僅是Openshift的kernel，除此之外，OpenShift還集成了很多應(yīng)用程序編譯、部署、交付和生命周期管理的生態(tài)圈軟件，因此，比起硬上K8S，OpenShift也許才是很多人需要尋找的東西！