K8S是第一個將“一切以服務為中心，一切圍繞服務運轉”作為指導思想的創新型產品，它的功能和架構設計自始至終都遵循了這一指導思想，構建在K8S上的系統不僅可以獨立運行在物理機、虛擬機集群或者企業私有云上，也可以被托管在公有云中。

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

K8S完美地解決了調度，負載均衡，集群管理、有狀態數據的管理等微服務面臨的問題，成為企業微服務容器化的首選解決方案。使用K8S就是在全面擁抱微服務架構。

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

一、K8S容器云部署實踐篇

Q1:現階段容器云部署框架是什么？

A1:

? 在DMZ和內網分別部署彼此獨立的2套Openshift，分別為內網和DMZ區兩個網段，兩套環境彼此隔離。

? DMZ區的Openshift部署對外發布的應用，負責處理外網的訪問

? 內網的Openshift部署針對內網的應用，僅負責處理內網的訪問

-權限管理

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

1. 認證：

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

2. 鑒權：

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

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

-多租戶管理

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

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

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

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

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

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

-日志和監控

（1）傳統應用日志

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

日志的分類如下：

? 中間件日志

? dump文件

? 應用日志

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

（2）新應用日志

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

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

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

?? 索引日志內容，快速返回查詢結果

?? 具有伸縮性，在各個環節都能夠擴容

強大的圖形查詢工具、報表產出工具

EFK是Elasticsearch(以下簡寫為ES)+ Fluentd+Kibana的簡稱。ES負責數據的存儲和索引，Fluentd負責數據的調整、過濾、傳輸，Kibana負責數據的展示。

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

（3）監控

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

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

1. 組件說明

Openshift的監控組件，用于對pod運行狀態的CPU、內存、網絡進行實時監控，和Kubernetes使用的監控技術棧一樣，包括三個部分：

HEAPSTER

用于監控數據的采集

https://github.com/kubernetes/heapster

HAWKULAR METRICS

屬于開源監控解決方案Hawkular，基于JSON格式管理、展示監控數據

http://www.hawkular.org/

CASSANDRA

Apache Cassandra是一個開源的分布式數據庫，專門用于處理大數據量業務

http://cassandra.apache.org/

-DMZ區計算節點

在DMZ區應用部署遵循以下策略：

? 已有應用遷移至容器云平臺時的資源申請按現有配置設置，申請的服務器將僅供該使用

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

? 本期項目中，XXX部署在DMZ區平臺上，使用2個計算節點；XXX部署在內網平臺上，使用2個計算節點

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

例如在DMZ網段對XXX應用所使用的2臺計算節點打上標簽

在部署XXX應用使，nodeSelector需要指明使用的節點的標簽為XXX=XXX。

-傳統應用訪問策略

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

? 在F5 VS的Pool Member中配置所有節點，通過Keepalived來實現HA

? 應用系統和用戶不用改變現有的訪問方式

-應用訪問及防火墻

內網計算節點可以直接訪問數據庫

DMZ區計算節點訪問數據庫有2種方案：

? 計算節點直接通過內網防火墻訪問該應用數據庫

內網防火墻僅開通應用所在節點訪問內部數據庫的端口，例如本期項目，xxx應用僅使用2個節點，則防火墻僅開通這2個節點訪問xxx數據庫的權限

? 計算節點經Outbound 路由通過內網防火墻訪問內網數據o

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

因此，內網防火墻僅開通應用所在節點訪問內部數據庫的端口，例如，應用A僅通過路由節點A和B訪問內部數據庫，則防火墻僅開通這2個節點訪問A數據庫的權限

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

A2:

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

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

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

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

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

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

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

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

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

除此之外

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

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

Q3: K8S集群如何實現集群安全？雙向認證or簡單認證？

A3:

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

-雙向認證配置

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

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

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

-簡單認證配置

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

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

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

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

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

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

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

A4:

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

-外部鏡像倉庫高可用

外部鏡像倉庫獨立于OCP平臺之外，用于存儲平臺構建過程中所使用的系統組件鏡像。因為外部無法直接訪問OCP平臺的內部鏡像倉庫，所以由QA環境CD推送到生產環境的鏡像也是先復制到外部鏡像倉庫，再由平臺導入至內部鏡像倉庫。

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

-master主控節點高可用

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

-計算節點（容器應用）高可用

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

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

-應用高可用

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

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

簡單一點來說，就是內部服務的動態發現、負載均衡、高可用和外部訪問的路由；

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

內部服務之間訪問通過service解決了，那么外部訪問集群內服務，則通過router即是解決，外網訪問要不要負載均衡，大規模高并發情況下是肯定的，當然，外部負載均衡通常需要用戶自己搞定了，F5或者開源的HAproxy都行！

Q5: 多租戶在kubernets/openshift的實現和管理？

A5:

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

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

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

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

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

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

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

os_sdn_network_plugin_name='redhat/openshift-ovs-multitenant'

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

除了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可能出現overlay on overlay的情況，此借助三方SDN插件是個不錯的選擇，比如flannel+hostgw在性能上肯定就優于默認的ovs-multitenant。

Q6: elasticsearch在K8S中部署？

A6

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

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

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

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

根據你的描述，應該是有兩個方面的問題：

1）es的后端存儲的選擇

2）Pod的創建

問題一：

分布式，本地，集中存儲不管是在傳統環境，還是在容器的環境中，都有使用。目前對于數據庫應用，我們看到還是傳統存儲-集中存儲，占了絕大多數的市場。

分布式存儲，隨著云計算的興起，誕生的一種存儲架構。它的優勢很明顯，無中心節點，彈性伸縮，適合云應用，等等。傳統的廠商，netapp，emc，ibm，hp都有分布式存儲，都是基于其傳統的技術；新興的開源分布式存儲ceph，已經成為分布式存儲的領軍技術，有redhat，suse，xsky，聯想，華三等。

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

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

問題二：

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

Q7: K8S集群中的各受管節點以及其中的容器如何做監控？

A7:

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

（1）heapster+influxDB

（2）heapster+hawkular

（3）prometheus

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

prometheus支持k8s

prometheus獲取監控端點的方式有很多，其中就包括k8s，prometheu會通過調用master的apiserver獲取到節點信息，然后去調取每個節點的數據。

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

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

k8s中需要給kubelet配合kube-reserved和system-reserved相關參數給系統預留內存

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

二、微服務部署piapian

Q1: 微服務架構按照什么細粒度拆分？

A1：

既然理解微服務是用來重構業務應用的，這個問題就很簡單，以業務應用為核心，構建業務服務。忘掉，重構！

業務服務需要數據服務、計算服務、搜索服務、算法服務……以及基本的日志、監控、配置、注冊發現、網關、任務調度等組件。

至于數據服務怎么實現，看你團隊能力。這才涉及數據分拆，模型重構。

服務通信可以考慮事件驅動機制，也是后期業務數據處理，態勢感知，智能風控，智能營銷，智能運維等的基礎。

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

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

這里以OpenStack為例，Kolla這個項目對OpenStack的拆分，大概如下：

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

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

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

父鏡像：centos-base

一級子鏡像：centos-openstack-base

二級子鏡像：centos-nova-base

葉子節點鏡像：centos-nova-api

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

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

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

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

2、是否具備微服務技術能力，是否已選型好相應的技術框架，技術變化對企業有什么影響。

3、是否有完善的運維設施保障，比如快速配置、基礎監控、快速部署等能力。

Q2: svn環境下實現CI/CD？

A2：

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

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

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

能不能實現CI/CD與SVN無關，關鍵是你如何構建pipeline，微服務理念下大致這樣：

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

Q3: K8S DNS服務配置如何實現微服務的發布？

A3：

配置k8s dns

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

Cluster DNS擴展插件用于支持k8s集群系統中各服務之間發現與調用。

組件：

?SkyDNS 提供DNS解析服務

?Etcd 存儲DNS信息

?Kube2sky 監聽kubernetes，當有Service創建時，生成相應的記錄到SkyDNS。

如訪問外部DNS，可以設置external_dns 到configmap實現

Q4: 請問在K8S中部署數據庫現在有好的解決方案了么？

A4：

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

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

A5：

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

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

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

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

服務代理：

在邏輯層面上，Service被認為是真實應用的抽象，每一個Service關聯著一系列的Pod。在物理層面上，Service有事真實應用的代理服務器，對外表現為一個單一訪問入口，通過k8s Proxy轉發請求到Service關聯的Pod。

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

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

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

--service發布

k8s提供了NodePort Service、 LoadBalancer Service和Ingress可以發布Service；

NodePort Service

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

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

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

Q6: service mesh和spring cloud的優缺點

A6

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

關于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.

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

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

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

Q7: dubbo，zookeeper環境下，K8S的問題？

A7：

遇到過的問題

1.如果k8s上的應用僅僅是consumer，應該是沒問題的，不管provider是在k8s集群內部還是外部

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

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

通過api gateway來暴露需要對外的API。gateway不僅可以打通網絡，還可以隱藏內部api，方便api治理

三、金融行業容器云微服務實踐篇

Q1: 金融行業的微服務架構一般是怎樣的，案例有哪些？

A1：

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

-微服務架構的優點：

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

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

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

微服務能使用不同的語言開發。

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

微服務允許你利用融合最新技術。

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

-微服務架構的缺點：

微服務架構可能帶來過多的操作。

需要DevOps技巧。

可能雙倍的努力。

分布式系統可能復雜難以管理。

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

當服務數量增加，管理復雜性增加。

-微服務適合哪種情況：

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

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

未來的規劃，將以產業鏈延伸、客戶導向及互聯網+為戰略發展方向，需要BI分析、業務動態擴展、以及敏捷的產品與服務對接和裝配的能力支撐，基于以上的技術要求，優化建設支撐企業業務及應用運營的基礎設施，結合基礎資源現狀，建立云計算技術能力，形成快速響應，可持續發展的下一代數據中心。

對比傳統方案，容器云的方案，將在對微服務架構的支持、業務彈性擴容、自動化部署、產品快速上線、敏捷/迭代、全面系統監控等方面對IT部門帶來全方位的提升。

目前金融行業案例：

銀行：中國銀聯，工商銀行，浦發銀行、梅州客商銀行等；

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

證券：海通證券

Q2: 部署在K8S上的微服務，如何實現有狀態和無狀態服務對于存儲的要求？

A2：

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

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

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

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

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

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

對于無狀態服務，存儲可能是不必要的，但是對于由狀態服務，需要各種類型的存儲來保持狀態。在K8S中，PV提供存儲資源，PVC使用存儲資源，二者是供應者和消費者的關系，那么服務是如何把數據存儲到PV上的呢？

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

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

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

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

這里有兩個擴閱讀，關于容器原生存儲：

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

https://github.com/openebs/openebs

Q3: kubernets如何Devops實現持續部署發布測試全流程？

A3：

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

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

kubernetes需要整合Jenkins、Harbor、Gitlab還有日志管理、監控管理等等的其他組件，看需要，來實現持續部署持續發布的全流程。

GitLab主要負責開發代碼的存放管理。

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

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

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

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

A4：

SOA面向服務架構，它可以根據需求通過網絡對松散耦合的粗粒度應用組件進行分布式部署、組合和使用。服務層是SOA的基礎，可以直接被應用調用，從而有效控制系統中與軟件代理交互的人為依賴性。

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

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

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

細數YAML“十宗罪”：

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

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

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

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

Ballerina（https://ballerina.io/）

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

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

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