考慮大家的知識背景有所不同，在介紹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 的範圍，以及節點的數量。
可以看出，在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工具以及分散式應用。
採用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的服務採用統一的命名標準，從而更加方便不同平臺之間的服務發現與通訊。
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與其它的服務。
在網路方面，DC/OS網路支援Host，Bridge以及VXLAN三種樣式，使用者可以規劃多個VXLAN網路從而隔離不同型別的應用。
目前為止，Kubernetes僅能使用DC/OS 的VXLAN樣式，每個Kubelet與其所在的DC/OS Agent共享VTEP IP，執行在Kubernetes上的容器若跨主機通訊需要VXLAN網路封裝。
所以最佳的建議是使用者為Kubernetes規劃一個單獨的VXLAN網路，而對於其它型別的服務，則可以使用Host或Bridge樣式的網路，也可以使用與Kubernetes不同的VXLAN網路。
儲存方面的規劃取決於實際業務需求，DC/OS支援多種型別的儲存，如包本地臨時儲存、本地持久化儲存、分散式共享儲存以及集中儲存，多種儲存也可以同時使用。在儲存規劃方面，Kubernetes 的儲存使用不依賴於DC/OS，使用者完全可以按照Kubernetes的標準來為執行在Kubernetes上的應用靈活地選取儲存。
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上看未來在效能和安全上會有很多新的提升。
本次培訓內容包括：Docker基礎、容器技術、Docker映象、資料共享與持久化、Docker三駕馬車、Docker實踐、Kubernetes基礎、Pod基礎與進階、常用物件操作、服務發現、Helm、Kubernetes核心元件原理分析、Kubernetes服務質量保證、排程詳解與應用場景、網路、基於Kubernetes的CI/CD、基於Kubernetes的配置管理等，點選瞭解具體培訓內容。
長按二維碼向我轉賬
![]()
受蘋果公司新規定影響，微信 iOS 版的贊賞功能被關閉，可透過二維碼轉賬支援公眾號。
知識星球
