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

Kubernetes on DC/OS最佳實踐

考慮大家的知識背景有所不同,在介紹Kubernetes on DC/OS的原理與技術實現之前,我覺得還是有必要先簡單地介紹一下Mesos,DC/OS以及Kubernetes之間的關係與區別。
準確的說Mesos與Kubernetes的定位不同,因此不可以簡單橫向的進行比較。

如圖所示,Mesos的定位是分佈式資源管理框架,Mesos集群由Mesos Master與Mesos Agent組成,Mesos Master與Mesos Agent安裝在通用的Linux操作系統之上,不久的將來,也將會很好地支持Power Linux和Windows。
Mesos Master可以將Mesos Agent的資源進行統一管理,並將Mesos Agent的資源以offer的方式上報給Framework,這些Framework包括Marathon(用於實現容器的管理與調度),Chronos(用於實現任務的管理與調度),第三方應用的Framework,如Spark、Kafka、HDFS、Cassandra等,還有今天我們要分享的Kubernetes。
運行在Mesos之上的Framework需要按照Mesos的接口或者SDK來編寫,除了Mesos支持的Certified Framework以及Community Framework之外,用戶也可以根據自己的需求來編寫Framework,關於Mesos SDK的詳情可參考:https://mesosphere.github.io/dcos-commons/developer-guide/。
可以看出,與容器編排平臺Kubernetes不同的是,Mesos其定位是分佈式資源管理框架,它僅負責將資料中心的計算資源、儲存資源、網絡資源以及GPU資源等進行細粒度的拆分,然後將資源提供給上層的Framework來使用,也就是我們常說的二次調度,Framework聚焦在應用本身的調度,而Mesos則僅聚焦在基礎資源的調度。
以上便是Meoss的簡單介紹,接下來我們再簡單說說DC/OS,DC/OS核心基於Mesos實現,但是除了Mesos之外,還包括了Marathon,Metronom,Mesos-DNS,Spartan等三十多個組件,這些組件互相集成、共同協作。目前DC/OS包括兩個版本,一個是開源的版本,由Mesosphere以及社區共同維護,另一個是企業版本,由Mesosphere發行並提供服務。
通過使用DC/OS,用戶可以以容器的方式運行傳統長應用,任務型應用,分佈式應用以及微服務,因此個人認為,將DC/OS與Kubernetes進行比較比將Mesos與Kubernetes進行比較更加合理。
對於Kubernetes,想必大家都很瞭解,在此我不做過多贅述。用一段話總結他們的關係,就是DC/OS核心基於Mesos實現,它和容器編排平臺Kubernetes在容器管理上有很多相似的功能,但是應用範圍和定位比Kubernetes更廣泛。
與眾多Framework類似,Kubernetes可以作為一種服務運行在DC/OS平臺之上,而接下來我要和大家分享的就是Kubernetes運行在DC/OS的技術實現和關鍵功能。

如圖所示,與其它服務類似,在DC/OS下,Kubernetes是通過服務的方式運行在DC/OS平臺之上,用戶可以在DC/OS的服務目錄中搜索到Kubernetes服務,單擊圖標對關鍵的引數進行配置後一鍵完成Kubernetes平臺的部署。

Kubernetes on DC/OS整體的部署流程描述如下:
1、DC/OS中的Marathon會接受Mesos的資源offer,然後將Kubernetes的Framework通過容器的方式部署在Mesos Agent節點上。
2、當Kubernetes的Framework容器運行之後,會與Mesos進行註冊,然後接受Mesos資源offer,按照順序完成Kubernetes各組件的部署。
Kubernetes Framework本身不包括與Kubernetes有關的任何組件,它的作用就是接收Mesos的資源offfer,並按照既定的順序和策略完成Kubernetes組件的部署與管理。
為了更好的說明運行原理,我對一些關鍵操作進行了截圖。
首先,用戶在DC/OS上部署Kuberntes之前,需要在界面上輸入相關的引數。
輸入Kubernetes的服務名稱和一些元資料信息。
輸入 Kubernetes CLUSTER IP 的範圍,以及節點的數量。
輸入etcd服務的配置信息。
輸入scheduler的配置信息。
輸入Apiserver的配置信息。

輸入kubeproxy的配置信息。

可以看出,在Kubernetes on DC/OS場景下,Kubernetes的管理組件採用了模塊化拆分,與常規方案不同的是,etcd, Kube-api, Kube-scheduler以及 Kube-controller等組件沒有通過二進制的方式集中部署在一臺或多台管理節點上,而是通過容器的方式分佈式的運行在Mesos的Agent之上。
如下圖所示,用戶在輸入完相關的引數後,Kubernetes Framework會按照etcd, Kube-api, Kube-controller 以及Kube-scheduler的順序依次完成Kubernetes 各組件的部署,若用戶啟用了HA樣式,那麼每個組件容器實體部署的數量為3個,DC/OS中的Minuteman以及Mesos-DNS組件會為服務提供VIP和域名服務,從而實現服務之間的發現與通信。此功能類似於Kubernetes中的CLUSTER IP和Kube-dns。

在完成Kubernetes管理組件的創建後,Framework會繼續創建Kubelet,Kubelet 是通過容器的方式運行的,這一點也與通用的方案不太一樣。在通用方案中,每個Kubernetes節點安裝在一臺物理服務器或者一臺虛擬機上,每個Kubernetes節點主要包括Kubelet與Kube-proxy組件。
但是在Kubernetes on DC/OS 場景下,Kubelet、Kube-proxy、CoreDNS分別運行在不同的三個UCR容器上(UCR容器是Mesos支持的另外一種容器運行時),Kubelet、Kube-proxy與CoreDNS會一起創建,也就是用戶每新增一個Kubernetes節點,就會有Kubelet、Kube-proxy、CoreDNS三個容器同時創建。到目前為止,每個Mesos Agent上僅支持運行一個Kubelet、Kube-proxy以及CoreDNS。
Kubelet成功創建後,Framework會繼續運行一些短任務,這些任務的主要作用是在Kubelet節點上創建Kube add-on組件。
這些短任務也是通過容器的方式運行,由Framework創建,但是與Kubernetes服務不同的是,這些任務運行結束後,就會被自動kill掉。

當Kubernetes服務完成安裝後,用戶可以單擊Proxy的圖標,訪問Kubernetes的Dashboard,如下圖所示。

若用戶希望增加kubelet節點,可以隨時調整node數量,之後Framework再不影響既有平臺的同時,完成新的資源擴充,如下圖所示。

所以說在Kubernetes on DC/OS場景下,Kubernetes實際上是DC/OS平臺下的一個服務,就像Spark、Cassandra以及Kafka等服務一樣。在這種場景下,一個很大的特點就是全容器化部署,無論是Kubernetes管理服務還是Kubelet、Kube-proxy以及CoreDNS。
通過Kubernetes on DC/OS,用戶可以實現在同一套基礎設施上融合所有業務,一個DC/OS主機上不僅可以運行kubelet節點,也可以運行Nginx實體、Cassasndra Node、Kafka Broker、Jenkins Slave、Tensforflow worker、Spark task等等。
Kubelet採用了容器化方式部署,因此這裡用到了容器嵌套的技術。但是與虛擬化的嵌套不一樣的是,Kubernetes on DC/OS 嵌套的性能損耗非常小,對於CPU和記憶體來講,除了Kubelet行程消耗一些額外的資源之外,沒有操作系統層面的開銷。對於網絡,Kubelet容器與Mesos Agent共享Namespace,Pod跨主機通信通過VXLAN實現,Kubelet與DC/OS Agent共享一個VTEP IP,不存在網絡多層封裝的問題,因此也沒有額外的開銷。
以上就是Kubernetes on DC/OS的原理與實現方式,接下來我們在介紹一下Kubernetes on DC/OS的方案優勢和適用場景。
首先,通過DC/OS部署Kubernetes,用戶可以實現Kubernetes的全自動化部署、配置、升級與擴容。這種優勢在節點越多的時候體現的越明顯,用戶可以在一個小時之內部署上百個節點規模的Kubernetes,再輸入完必要的引數後,一鍵即可完成部署。
其次,通過DC/OS部署Kubernetes,用戶可以綜合地利用Mesos與Kubernetes的優勢,目前Kubernetes在容器編排領域無疑是最優秀的平臺,但其目前對分佈式應用如Kafka、Cassandra、Spark、Tensorflow等應用支持的還不夠好,而DC/OS早已支持Kafka、Cassandra、Spark、Tensorflow這些分佈式應用並得到大規模的生產驗證,所以若希望通過全融合的方式搭建一套基礎設施,該方案是比較理想的。
因此總結起來,Kubernetes on DC/OS非常適用希望構建全融合資料中心的用戶,特別是大規模、混合雲的場景。這種場景下用戶的資料中心平臺不僅僅用於承載新一代的無狀態的容器應用以及微服務,也可以同時承載傳統應用、DevOps工具以及分佈式應用。
最後我們再聊一聊方案設計。
1、業務規劃
採用Kubernetes on DC/OS的用戶,通常也需要同一個平臺上同時運行傳統業務以及分佈式應用,典型的方案是用戶使用DC/OS承載DevOps工具,分佈式應用以及傳統的應用,用Kubernetes承載一些無狀態應用或者微服務。用戶可利用DevOps工具根據實際情況將應用交付至DC/OS平臺或者Kubernetes平臺上,運行在Kubernetes上的應用可以與運行在DC/OS上的應用互相通信。
目前為止Kubernetes DNS與Mesos DNS還沒有完全實現融合,Kubernetes的服務與DC/OS的服務通信需要通過IP或者借助第三方DNS服務器實現。但是不久之後,兩者將會完全融合,因此DC/OS平臺上的服務將會與DC/OS的服務採用統一的命名標準,從而更加方便不同平臺之間的服務發現與通信。
2、節點規劃
DC/OS 部署在通用的操作系統之上,因此對底層的資源無過多限制,用戶可以選擇將節點部署在物理機上也可以選擇將節點部署在虛擬化平臺、私有雲IaaS資源或者公有雲IaaS資源上,也可以根據需求混合部署。
若希望構建多區域的混合雲,建議將DC/OS Master部署在同一區域內,例如資料中心A部署DC/OS Master 和 DC/OS Agent,資料中心B只部署DC/OS Agent,若有更多的資料中心,推薦其它資料中心也只部署DC/OS Agent。運行在DC/OS上的Framework具有區域感知功能,會根據策略靈活地將任務調度到不同的資料中心上。
DC/OS即將會支持Kubernetes多集群部署,因此建議在不同的區域上部署不同的Kubernetes集群。
而在同一物理資料中心中,Kubernetes 與 DC/OS 其它服務會融合部署,若用戶有硬體資源的隔離需求,也可通過Mesos Placement Constrain的方式將不同的服務部署在不同的物理服務器上,從而卻分Kubernetes與其它的服務。
3、網絡規劃
在網絡方面,DC/OS網絡支持Host,Bridge以及VXLAN三種樣式,用戶可以規劃多個VXLAN網絡從而隔離不同型別的應用。
目前為止,Kubernetes僅能使用DC/OS 的VXLAN樣式,每個Kubelet與其所在的DC/OS Agent共享VTEP IP,運行在Kubernetes上的容器若跨主機通信需要VXLAN網絡封裝。
所以最佳的建議是用戶為Kubernetes規劃一個單獨的VXLAN網絡,而對於其它型別的服務,則可以使用Host或Bridge樣式的網絡,也可以使用與Kubernetes不同的VXLAN網絡。
4、儲存規劃
儲存方面的規劃取決於實際業務需求,DC/OS支持多種型別的儲存,如包本地臨時儲存、本地持久化儲存、分佈式共享儲存以及集中儲存,多種儲存也可以同時使用。在儲存規劃方面,Kubernetes 的儲存使用不依賴於DC/OS,用戶完全可以按照Kubernetes的標準來為運行在Kubernetes上的應用靈活地選取儲存。


Q&A;

Q:目前有公司落地這套方案上生產嗎? 在AWS是否實踐過這個方案?
A:Kubernetes on DC/OS是去年九月份官方由Mesosphere支持,經過半年的迭代開發,版本已經GA。目前國外的案例較多一些,國內的中國聯通與中國石化正在嘗試使用,國內的中國聯通希望結合著Fabric8一起來使用,中石化希望用來運行微服務。目前AWS Marketplace支持DC/OS,國外很多用戶也在用AWS構建混合雲方案,Kubernetes on DC/OS屏蔽了底層,所以只要DC/OS運行在AWS上,Kubernetes就沒有問題。
Q:DC/OS全稱是什麼?物理機跑虛擬機,虛擬機跑DC/OS,DC/OS又嵌套容器會不會無止境的架構,越來越複雜?
A:全稱就是DC/OS,也稱Datacenter Operating System,資料中心操作系統。不會無止境的,UCR官方支持嵌套三十二層,但是我們容器層面一般只嵌套一層,而且容器與虛擬機最大的不同就是不會造成OS的開銷,所以多幾層嵌套問題也不大。
Q:如果同一個集群內部的其他應用沒有和Kubernetes在一個VXLAN裡面,他們如何通訊,可以通過VIP嗎?
A:需要通過負載均衡、Node port或Ingress的方式,不久之後DC/OS的服務會和Kubernetes的服務全面融合。
Q:很高興能看到關於Mesos的分享,目前發現Mesos越來越被邊緣化的趨勢,比方說Cassandra Framework已經在GitHub上標記為過時了,我的問題是DC/OS以後會是Mesos主流的部署方式嗎?用Mesos如果要使用Framework的話是不是要自己去封裝?
A:不能說被邊緣化,很多大型互聯網廠商都是低調的在使用,畢竟技術定位還是不同,而且Mesos確實在資源管理方面有其獨特的優勢。而且Cassandra雖然在GitHub上過時了,但是在Mesosphere內部從未過時,版本更新的很快,還可以無縫遷移。DC/OS的核心基於Mesos,這個不會變,但是支持Kubernetes是我們的重中之中,這個也不會變。DC/OS的Framework目前已經好幾十種,Mesosphere也在不斷地擴大生態,感興趣可以到官方Universe上查看,那裡詳細地例舉了Framework以及不同的版本號。
Q:Server Agent的高可用,以及它們任務調度和Framework上的容器調度,任務調度有關係嗎?
A:Server Agent,您是指Mesos Agent嗎?DC/OS 與VMware等虛擬化平臺在某些方面有類似的功能,比如說,若Agent節點出現故障,DC/OS上的Framework會將task自動重啟,或者在其他主機重啟,對於有狀態服務,建議使用共享儲存方案。
Q:如果同一個集群內的其他應用和Kubernetes不在一個VXLAN中,他們之間可以怎樣通訊?有什麼比較好的解決方案?
A:若DC/OS的服務與Kubernetes不在同一個VXLAN上,目前就需要使用Kubernetes的 NODE IP,Ingress或則LB,這個和開源Kubernetes使用方式一致。當前的Kubernetes內的服務還只能處在一個flat network內,但是可以集成第三方Plugin,這個和DC/OS關係不大,用戶可自行選擇。
Q:實際使用中Kafka、Elastic組件會出現集群不穩定情況,比如Kafka起三個broker,死活啟動不了三個的情況,有好的解決辦法嗎?補充,因為是Framework的方式感覺不如Docker好管理。
A:起不來的原因有很多,但是我很少遇見一直起不來,有可能是單節點資源不夠,有可能是網絡原因導致一些鏡像或artifacts fetch不下來或者是節點數量不夠,但是Framework與Docker的定位畢竟不同,也不屬於一個技術。這個我們可以私下交流,我可以幫助您解決一些部署服務的問題。
Q:既然Marathon有容器編排功能,為何要棄Marathon,而用Kubernetes,增加體系複雜性,我的問題是,這隻是為了滿足用戶偏好還是確實有設計或性能優勢?
A:沒有嫌棄不用,Kubernetes的Framework不就是Marathon創建的嗎?而且Marathon與Kubernetes的運行機制也不太一樣,各有各的優勢。只是因為Kubemetes在容器編排方面確實很優秀,而且生態很好,因此為客戶提供更多的選擇。這個絕對不是為了滿足用戶偏好,不然公司不會投入這麼多,大家每天都在群裡面討論如何優化性能,提供差異化的服務。從發佈到現在僅僅六個月,但是方便的話可以體驗一下,確實在管理和運維上有很多優勢。而且從Roadmap上看未來在性能和安全上會有很多新的提升。

Kubernetes入門與進階實戰培訓

本次培訓內容包括:Docker基礎、容器技術、Docker鏡像、資料共享與持久化、Docker三駕馬車、Docker實踐、Kubernetes基礎、Pod基礎與進階、常用物件操作、服務發現、Helm、Kubernetes核心組件原理分析、Kubernetes服務質量保證、調度詳解與應用場景、網絡、基於Kubernetes的CI/CD、基於Kubernetes的配置管理等,點擊瞭解具體培訓內容

5月11日正式上課,點擊閱讀原文鏈接即可報名。
赞(0)

分享創造快樂