歡迎光臨
每天分享高質量文章

基於K8S的容器雲平臺如何部署微服務?

來源: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 –


    赞(0)

    分享創造快樂