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

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

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

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

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

一、K8S容器云部署實(shí)踐篇

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

A1:

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

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

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

-權(quán)限管理

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

1. 認(rèn)證：

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

2. 鑒權(quán)：

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

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

-多租戶管理

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

在OCP中，project是一個(gè)進(jìn)行租戶隔離的概念，它來(lái)源于kubernetes的namespace，并對(duì)其進(jìn)行了功能的擴(kuò)展。利用Project，OCP平臺(tái)從多個(gè)層面提供了多租戶的支持。

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

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

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

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

-日志和監(jiān)控

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

有別于當(dāng)前流行的容器應(yīng)用，的傳統(tǒng)應(yīng)用同時(shí)一個(gè)中間件會(huì)運(yùn)行多個(gè)應(yīng)用，且應(yīng)用通過(guò)log4j等機(jī)制保存在文件中方便查看和排錯(cuò)。因?yàn)槿萜鬟\(yùn)行的特性，對(duì)于這部分的日志我們需要持久化到外置存儲(chǔ)中。

日志的分類如下：

? 中間件日志

? dump文件

? 應(yīng)用日志

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

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

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

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

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

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

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

強(qiáng)大的圖形查詢工具、報(bào)表產(chǎn)出工具

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

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

（3）監(jiān)控

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

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

1. 組件說(shuō)明

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

HEAPSTER

用于監(jiān)控?cái)?shù)據(jù)的采集

https://github.com/kubernetes/heapster

HAWKULAR METRICS

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

http://www.hawkular.org/

CASSANDRA

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

http://cassandra.apache.org/

-DMZ區(qū)計(jì)算節(jié)點(diǎn)

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

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

? 如果需要橫向擴(kuò)展，也僅在已分配的計(jì)算節(jié)點(diǎn)上，如果資源不足，應(yīng)用項(xiàng)目組可再申請(qǐng)新的計(jì)算資源

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

? 在實(shí)施時(shí)需要為相應(yīng)的計(jì)算節(jié)點(diǎn)標(biāo)記標(biāo)簽，使應(yīng)用部署時(shí)部署到指定的計(jì)算節(jié)點(diǎn)上。

例如在DMZ網(wǎng)段對(duì)XXX應(yīng)用所使用的2臺(tái)計(jì)算節(jié)點(diǎn)打上標(biāo)簽

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

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

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

? 在F5 VS的Pool Member中配置所有節(jié)點(diǎn)，通過(guò)Keepalived來(lái)實(shí)現(xiàn)HA

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

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

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

DMZ區(qū)計(jì)算節(jié)點(diǎn)訪問(wèn)數(shù)據(jù)庫(kù)有2種方案：

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

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

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

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

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

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

A2:

容器跑在物理機(jī)上，還是跑在云平臺(tái)虛機(jī)上，這是個(gè)值得討論的話題。

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

其實(shí)也沒(méi)什么好糾結(jié)的，無(wú)非就是一個(gè)問(wèn)題:性能！

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

如果你決定跑在已有云平臺(tái)上，那么，你要考慮的問(wèn)題如下：

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

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

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

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

除此之外

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

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

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

A3:

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

-雙向認(rèn)證配置

雙向認(rèn)證方式是最為嚴(yán)格和安全的集群安全配置方式，主要配置流程如下：

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

2）修改Kubernetts各個(gè)服務(wù)進(jìn)程的啟動(dòng)參數(shù)，啟用雙向認(rèn)證模式。

-簡(jiǎn)單認(rèn)證配置

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

采用基于Token和HTTP Base的簡(jiǎn)單認(rèn)證方式時(shí)，API Server對(duì)外暴露HTTPS端口，客戶端提供Token或用戶名、密碼來(lái)完成認(rèn)證過(guò)程。

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

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

K8S的認(rèn)證相對(duì)來(lái)說(shuō)還是個(gè)比較復(fù)雜的過(guò)程，如下這篇文章，詳細(xì)介紹了K8S中的認(rèn)證及其原理：

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

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

A4:

高可用主要分為如下幾個(gè)：

-外部鏡像倉(cāng)庫(kù)高可用

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

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

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

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

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

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

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

-應(yīng)用高可用

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

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

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

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

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

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

A5:

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

在OCP中，project是一個(gè)進(jìn)行租戶隔離的概念，它來(lái)源于kubernetes的namespace，并對(duì)其進(jìn)行了功能的擴(kuò)展。利用Project，OCP平臺(tái)從多個(gè)層面提供了多租戶的支持。

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

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

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

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

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

os_sdn_network_plugin_name='redhat/openshift-ovs-multitenant'

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

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

1、Cisco Contiv；

2、Juniper Contrail；

3、Nokia Nuage；

4、Tigera Calico ；

5、VMware NSX-T ；

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

Q6: elasticsearch在K8S中部署？

A6

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

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

至于說(shuō)分布式存儲(chǔ)、本地存儲(chǔ)還是集中存儲(chǔ)，這個(gè)沒(méi)有既定答案，都是可以參考行業(yè)實(shí)現(xiàn)，比如Redhat就是參考對(duì)象

不建議elasticsearch采用分布式存儲(chǔ)，日志亮大情況下如果是分布式存儲(chǔ)es寫(xiě)會(huì)是瓶頸。

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

1）es的后端存儲(chǔ)的選擇

2）Pod的創(chuàng)建

問(wèn)題一：

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

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

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

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

問(wèn)題二：

K8S的所有的流程都不是手動(dòng)完成的，都是基于自動(dòng)化完成。可以使用chef/ansible/puppt等工具完成。

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

A7:

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

（1）heapster+influxDB

（2）heapster+hawkular

（3）prometheus

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

prometheus支持k8s

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

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

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

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

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

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

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

A1：

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

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

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

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

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

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

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

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

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

如果從鏡像的角度來(lái)看，大概是這樣：

父鏡像：centos-base

一級(jí)子鏡像：centos-openstack-base

二級(jí)子鏡像：centos-nova-base

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

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

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

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

1、充分分析拆分的目的是什么，需要解決什么問(wèn)題。

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

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

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

A2：

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

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

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

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

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

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

A3：

配置k8s dns

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

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

組件：

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

?Etcd 存儲(chǔ)DNS信息

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

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

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

A4：

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

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

A5：

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

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

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

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

服務(wù)代理：

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

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

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

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

--service發(fā)布

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

NodePort Service

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

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

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

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

A6

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

關(guān)于service mesh的定義，通常以Buoyant 公司的 CEO Willian Morgan 在其文章 WHAT’S A SERVICE MESH? AND WHY DO I NEED ONE? 中對(duì) 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ù)部署的問(wèn)題，但是運(yùn)行時(shí)的問(wèn)題還未解決，而這正是Service Mesh的用武之地。Service Mesh的核心是提供統(tǒng)一的、全局的方法來(lái)控制和測(cè)量應(yīng)用程序或服務(wù)之間的所有請(qǐng)求流量(用數(shù)據(jù)中心的話說(shuō)，就是“east-west”流量)。對(duì)于采用了微服務(wù)的公司來(lái)說(shuō)，這種請(qǐng)求流量在運(yùn)行時(shí)行為中扮演著關(guān)鍵角色。因?yàn)榉?wù)通過(guò)響應(yīng)傳入請(qǐng)求和發(fā)出傳出請(qǐng)求來(lái)工作，所以請(qǐng)求流成為應(yīng)用程序在運(yùn)行時(shí)行為的關(guān)鍵決定因素。因此，標(biāo)準(zhǔn)化流量管理成為標(biāo)準(zhǔn)化應(yīng)用程序運(yùn)行時(shí)的工具。

通過(guò)提供api來(lái)分析和操作此流量，Service Mesh為跨組織的運(yùn)行時(shí)操作提供了標(biāo)準(zhǔn)化的機(jī)制——包括確保可靠性、安全性和可見(jiàn)性的方法。與任何好的基礎(chǔ)架構(gòu)層一樣，Service Mesh采用的是獨(dú)立于服務(wù)的構(gòu)建方式。

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

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

A7：

遇到過(guò)的問(wèn)題

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

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

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

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

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

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

A1：

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

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

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

微服務(wù)能夠被小團(tuán)隊(duì)單獨(dú)開(kāi)發(fā)，這個(gè)小團(tuán)隊(duì)是2到5人的開(kāi)發(fā)人員組成。

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

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

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

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

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

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

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

需要DevOps技巧。

可能雙倍的努力。

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

因?yàn)榉植疾渴鸶檰?wèn)題難。

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

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

當(dāng)需要支持桌面，web，移動(dòng)智能電視，可穿戴時(shí)都是可以的。

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

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

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

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

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

保險(xiǎn)：太平洋保險(xiǎn)，平安保險(xiǎn)、中國(guó)人壽、大地保險(xiǎn)、眾安保險(xiǎn)；

證券：海通證券

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

A2：

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

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

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

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

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

K8S中的持久性存儲(chǔ)主要還是通過(guò)PV、PVC和StorageClass來(lái)實(shí)現(xiàn)。

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

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

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

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

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

這里有兩個(gè)擴(kuò)閱讀，關(guān)于容器原生存儲(chǔ)：

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

https://github.com/openebs/openebs

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

A3：

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

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

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

GitLab主要負(fù)責(zé)開(kāi)發(fā)代碼的存放管理。

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

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

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

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

A4：

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

大多數(shù)初次接觸YAML的人都會(huì)覺(jué)得這類文檔模板體驗(yàn)極差，感覺(jué)太反人類了，各種對(duì)齊、格式，一不小心就語(yǔ)法報(bào)錯(cuò)，通常又不能準(zhǔn)確定位錯(cuò)誤點(diǎn)，對(duì)新手來(lái)說(shuō)，這種YAML文本確實(shí)很頭疼，但是又沒(méi)法，K8S里面盡是YAML，奈何？？？？

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

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

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

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

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

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

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

Ballerina（https://ballerina.io/）

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

那問(wèn)題就是：有沒(méi)有這樣的平臺(tái)？

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