知識星球
來源:talkwithtrend
ID:talkwithtrend
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，就是耍流氓啊！
如果你決定跑在已有雲平臺上，那麼，你要考慮的問題如下：
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容器的執行平臺中。現有的各種儲存可以透過簡單的驅動程式封裝，從而實現和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也許才是很多人需要尋找的東西！
本文由社群專家顧文俊根據線上交流活動中的問答整理，由多位社群專家和會員貢獻分享。
顧文俊，目前就職於中國大地保險集團資訊科技部。2008年南京郵電大學電路與系統專業研究生畢業，主要從事通訊、IT、雲端計算、分散式儲存相關領域的研發、售前顧問等。目前，就職於中國大地保險集團資訊科技部，負責大地保險核心業務的雲端計算基礎架構解決方案相關工作。
《Linux雲端計算及運維架構師高薪實戰班》2018年11月26日即將開課中，120天衝擊Linux運維年薪30萬，改變速約~~~~
*宣告：推送內容及圖片來源於網路，部分內容會有所改動，版權歸原作者所有，如來源資訊有誤或侵犯權益，請聯絡我們刪除或授權事宜。
– END –
