【文章內(nèi)容簡(jiǎn)介】 是其實(shí)底層還是用的容器技術(shù)（當(dāng)然不可能是 Docker）。國內(nèi)，完全基于 Docker 的 CasS 公司 DaoCloud 也于前日正式對(duì)外提供服務(wù)。 . 容器 VS 虛擬機(jī) —— 商用為主 虛擬機(jī)技術(shù)，從最開始的分時(shí)系統(tǒng)，到后來的各種 VM 的亂戰(zhàn)到 Xen 的統(tǒng)一服務(wù)器端江湖 [6]，直到現(xiàn)在 KVM 流行?！?現(xiàn)在都是 KVM[7]，如果新一點(diǎn)的，就玩 Container 了。 ”計(jì)算機(jī)世界分為兩條線，計(jì)算和存儲(chǔ)，虛擬化屬于計(jì)算這條線，而虛擬化又分為兩條，硬件虛擬化和軟件虛擬化，硬件虛擬化從 IBM 時(shí)代就開始了。 1999 年，一個(gè)叫 VMware Workstation 的公司流行了一段時(shí)間，這個(gè)公司就是現(xiàn)在的虛擬化巨頭 VMware。但是前幾年被賣給 EMC 了，現(xiàn)在連 EMC 都自身難保。 相較之，容器技術(shù)的概念也被提出很久了，根據(jù)國外的研究成果 [8]，之所以一致未曾實(shí)現(xiàn)，主要原因還是因?yàn)槿萜骷夹g(shù)的不成熟。因?yàn)槭沁M(jìn)程級(jí)別虛擬化，其隔離系統(tǒng)總不會(huì)像硬件級(jí)別虛擬化一樣密不透風(fēng)， Linux Kernel 上關(guān)于 LXC的 Security Announce 有五十多個(gè)，但是沒人敢去修，因?yàn)檫@個(gè)東西是牽一發(fā)而動(dòng)全身的。從 IBM 360 到 VMware 的流行，國外花了近二十年時(shí)間才讓硬件虛長(zhǎng)春理工大學(xué)本科畢業(yè)設(shè)計(jì) 3 擬化技術(shù)變得為商業(yè)所接受。同樣的，容器技術(shù)要走進(jìn)真正的商用還需要很長(zhǎng)的一段路 [9]。 微服務(wù)化 云計(jì)算在當(dāng)計(jì)算機(jī)科 學(xué)高度發(fā)展的今天已經(jīng)越來越多參與了我們正常的生產(chǎn)生活。同時(shí)，提供云計(jì)算服務(wù)的廠商也如雨后春筍般冒了出來。與傳統(tǒng)的 IT產(chǎn)業(yè)公司不同的是，云計(jì)算時(shí)代的互聯(lián)網(wǎng)公司，作為云計(jì)算服務(wù)的提供者，越來越扮演著幕后的角色。典型的云計(jì)算時(shí)代，當(dāng)你打開手機(jī)，點(diǎn)開某個(gè)門戶網(wǎng)站，瀏覽一段視頻，與人溝通交流，這一切的一切都是由巨量的服務(wù)支撐起來的。同樣的，每一個(gè)服務(wù)都盡量做到輕量，簡(jiǎn)單。這也正是 UNIX 的設(shè)計(jì)哲學(xué) 1，這樣的服務(wù)被稱之為 ―微服務(wù) ‖。 將服務(wù)拆散開，以鏈接、 api、轉(zhuǎn)發(fā)、負(fù)載均衡等方式對(duì)外提供，在提供商這里，拆小了業(yè)務(wù)邏 輯，將原先生產(chǎn)一條飛機(jī)的難度降低到了生產(chǎn)一顆螺絲釘上去。對(duì)于開發(fā)者和消費(fèi)者，微服務(wù)提供了更多的可能和更強(qiáng)大的兼容性。 然而，拋開了完整的系統(tǒng)，而轉(zhuǎn)向微服務(wù)的我們，該如何保證微服務(wù)的穩(wěn)定和高可用呢？ 云計(jì)算就像一個(gè)池子，服務(wù)就像池子里的水，正常情況下，服務(wù)從提供商手里流出，保障其基礎(chǔ)設(shè)施的運(yùn)轉(zhuǎn)良好。但是當(dāng)你的池子不夠大呢？擴(kuò)容？是個(gè)好辦法。但是這需要時(shí)間和成本的開銷，而且運(yùn)維反應(yīng)速度慢和快也是衡量一個(gè)公司服務(wù)能力的重要標(biāo)準(zhǔn)。因此，在云計(jì)算時(shí)代，無論企業(yè)還是個(gè)人，都需要一個(gè)輕便，易于部署，快速遷移，快速啟動(dòng)的環(huán)境設(shè)置技術(shù)來支持服務(wù)啟用、備份、容災(zāi)、遷移。 這個(gè)技術(shù)，就是 Docker。 Docker 是一個(gè)容器管理程序，由 Golang 編寫，采用 LXC 做 BackEnd，提供了容器的快速啟動(dòng)，快速部署，版本控制等方法。 Docker 就像一個(gè)集裝箱，把服務(wù)需要的環(huán)境都封裝在里面，想用的時(shí)候直接拿集裝箱走并使用就可以。省去了很多無用而且緩慢的部署腳本，并且，其 image 的概念的提出，為冷備 Docker 提供了一個(gè)簡(jiǎn)單而且方便的途徑。國內(nèi)目前已經(jīng)有學(xué)者開始對(duì)微服務(wù)化的可行性做了研究，并且， Docker 也開始和傳統(tǒng)的云計(jì)算平臺(tái)結(jié)合 [10]產(chǎn)生了奇妙的變化。 主要研究?jī)?nèi)容 本文主要進(jìn)行了如下的研究： 1 kISS:keep it simple amp。 stupid 長(zhǎng)春理工大學(xué)本科畢業(yè)設(shè)計(jì) 4 （ 1） 對(duì) Kuberes 的設(shè)計(jì)和架構(gòu)進(jìn)行深度解析，分析各個(gè)組件的設(shè)計(jì)目的和具體實(shí) 現(xiàn) （ 2） 提供一個(gè)簡(jiǎn)單、易用的自動(dòng)化部署、持續(xù)集成、滾動(dòng)升級(jí)、灰度、多版本追蹤發(fā)布方案。讓 Docker 能夠更加簡(jiǎn)單的在生產(chǎn)環(huán)境中應(yīng)用。 （ 3） 提供一個(gè)可靠的橫向擴(kuò)展架構(gòu)，搭建一個(gè)無狀態(tài)易擴(kuò)展的高可用服務(wù)器集群，自動(dòng)實(shí)現(xiàn)負(fù)載均衡和動(dòng)態(tài)擴(kuò)容。 （ 4） 研究虛網(wǎng)絡(luò)和 SDN 網(wǎng)絡(luò)的設(shè)計(jì)模型，并對(duì)其進(jìn)行分析。以及在 Kuberes 中的應(yīng)用和實(shí)戰(zhàn)。 （ 5） 研究集群一致算法 Raft[11]，分析 Kuberes 的集群的一致性。 論文組織結(jié)構(gòu) 本次論文共分三個(gè)大部分：總體設(shè)計(jì)、細(xì)節(jié)設(shè)計(jì)、實(shí)戰(zhàn)部署。 其中，第 1 章 ~第 2 章，主要講述的是 Kuberes 系統(tǒng)的架構(gòu)和設(shè)計(jì)，以及一些特化的概念。 第 3 章 ~第 5 章是 Kuberes 系統(tǒng)的詳細(xì)設(shè)計(jì)和技術(shù)細(xì)節(jié)。本部分從 Master節(jié)點(diǎn)開始，逐步分析 Kuberes 系統(tǒng)設(shè)計(jì)實(shí)踐中出現(xiàn)的問題，并提出自己的解決方案。展示其各個(gè)組件的實(shí)現(xiàn)細(xì)節(jié)和技術(shù)上的缺陷。 第 6 章是 Kuberes 的實(shí)戰(zhàn)部署，在一臺(tái) Ubuntu 主機(jī)上搭建單節(jié)點(diǎn)的 Kuberes 集群，并檢測(cè)其安裝結(jié)果。長(zhǎng)春理工大學(xué)本科畢業(yè)設(shè)計(jì) 5 第 2 章 總體設(shè)計(jì) 功能設(shè)計(jì) 本系統(tǒng)名叫 Kuberes，是 Google 公司推出的一款類似于 B2的開源的容器管理程序。其總體設(shè)計(jì)圖圖 2 1： API ServerETCD 集群Controller ManagerScheduler核心交換機(jī)Minion 集群 圖 2 1 Kuberes 網(wǎng)絡(luò)圖 對(duì)于 Kuberes，其詳細(xì)組件圖如圖 2 2： Minion 節(jié)點(diǎn)組件 在每個(gè)對(duì)外提供服務(wù)的節(jié)點(diǎn)（對(duì)于整個(gè)集群來說，這些節(jié)點(diǎn)可以稱之為 minion）上， Kuberes 有如下組件： kubelet：管理 Docker 本身，與 BackEnd 通訊的程序，其本身就是一個(gè)守護(hù)進(jìn)程，伴隨著 Docker 一起啟動(dòng)。 2 B 是 Google 公司內(nèi)部使用的服務(wù)部署和動(dòng)態(tài)遷移程序，未開源 長(zhǎng)春理工大學(xué)本科畢業(yè)設(shè)計(jì) 6 kubeProxy：代理程序，對(duì)外提供 Docker 機(jī)器上的服務(wù)的網(wǎng)絡(luò)轉(zhuǎn)發(fā)，對(duì)內(nèi)則進(jìn)行端口映射和隧道壓縮，將網(wǎng)絡(luò)流轉(zhuǎn)發(fā)致各個(gè)可用的服務(wù)容器上。 圖 2 2 Kuberes 組件圖 Master 節(jié)點(diǎn)組件 對(duì)于 master 節(jié)點(diǎn)，共有三個(gè)主要組件： kubeapiserver : 本組件是 Kuberes 系統(tǒng)的主要組件，對(duì)外， apiserver 提供開放的端口，即，提供服務(wù)；對(duì)內(nèi)， apiserver 維持一個(gè)對(duì)于 ETCD 系統(tǒng)的 RESTful 持久化 對(duì)象，以便于同步集群的信息。對(duì)整個(gè)集群，他是集群控制的入口，提供一個(gè) RESTful 的 api 來對(duì)集群進(jìn)行控制。 kubescheduler: Kuberes 的調(diào)度程序，負(fù)責(zé)調(diào)度整個(gè)集群的資源，為部署容器提供自動(dòng)化的執(zhí)行方案 3。 kubecontrollermanager: Kuberes 的執(zhí)行各種 controller 的程序，目前 controller 共有兩類，分別是： ? endpointcontroller ：負(fù)責(zé)關(guān)聯(lián) Kuberes 的服務(wù)和容器 4映射的正確性。 ? replicationcontroller ： 負(fù)責(zé)定義容器的數(shù)量處在正確的值，即，關(guān)閉超過數(shù)量的容器，增加因?yàn)橘Y源不足，意外宕機(jī)等原因而減少的容器的數(shù) 3 這個(gè)地方原本是 B 系統(tǒng)最精華的部分，但是限于 Google 公司機(jī)密，因此做成了一個(gè)簡(jiǎn)單的服務(wù)。 4 當(dāng)然，這里對(duì)于容器并不是 k8s 的最基本調(diào)度單位，這里所說的實(shí)際上使指的 Service 和 pod 的正確映射關(guān)系，關(guān)于 k8s 的一些基本概念，將在下一節(jié)詳細(xì)敘述 長(zhǎng)春理工大學(xué)本科畢業(yè)設(shè)計(jì) 7 量。 etcd : etcd 是一個(gè)由 Coreos 公司實(shí)現(xiàn)的簡(jiǎn)易 kv 分布式數(shù)據(jù)存儲(chǔ)系統(tǒng)，采用raft 算法保證集群一致性。 Kuberes 用它來實(shí)現(xiàn)了一個(gè) global index 系統(tǒng)，從而達(dá)到全局的一致性保證。這里面主要存儲(chǔ)的是 Kuberes 系統(tǒng)的所有 Label。 基本概念 Pod Pod，是 Kuberes 的一個(gè)基本的調(diào)度單位，一個(gè) Pod 對(duì)應(yīng)的一組 Docker Container 構(gòu)成的容器組，在同一個(gè) Pod 里， Docker Volume 可以共享的掛載在同Pod 中的所有 Docker Container 中。如下圖 2 3。 在邏輯上， Pod 的提出結(jié)束了自己管理 Docker 容器的分立的狀態(tài)， Pod 建立了一個(gè)“邏輯虛擬機(jī) ‖的模型，在這個(gè)虛擬機(jī)里，每個(gè) Docker 的 Container 相當(dāng)于傳統(tǒng)虛擬機(jī)的一個(gè)進(jìn)程。而共享的 Volume 則構(gòu)成了進(jìn)程之間共同訪問的文件資源。與正常的 Docker Container 一樣， Pod 的生命周期，相對(duì)于整個(gè)集群來說是不持久的。 同時(shí)， Pod 給 Kuberes 提供了一個(gè)程序上的解耦，因?yàn)?Kuberes 底層是面向容器的，但不一定是只支持 Docker 的。因此，為了與 Docker 解除綁定，也為了能定義一個(gè)更準(zhǔn)確的邏輯模型， Kuberes 啟用了 Pod 的概念。 在 Pod 被引入之前，我曾經(jīng)嘗試過在一個(gè) Docker Container 同時(shí)啟用多個(gè)應(yīng)用。但是后來發(fā)現(xiàn)這樣做有其固有的缺陷： （ 1） 多個(gè)應(yīng)用同時(shí)部署在一個(gè) Docker Container 之中，會(huì)增加不必要的軟件的依賴，每當(dāng)其中某個(gè)依賴的軟件進(jìn)行變更的時(shí)候，便不得不重建整個(gè) Docker Container。而當(dāng) Docker Container 的數(shù)量、大小達(dá)到一定規(guī)模的時(shí)候，這樣做無疑會(huì)帶來巨量的系統(tǒng)負(fù)擔(dān)。 （ 2） 用戶不必運(yùn)行自己的進(jìn)程管理程序，多個(gè)進(jìn)程之間也無需考慮進(jìn)程信號(hào)量或退出碼擴(kuò)散等問題。 （ 3） 將多個(gè)應(yīng)用部署到同一個(gè)容器之中，將不可避免的加重容器，這里所說的加重是從啟動(dòng)時(shí)間、監(jiān)控難度、調(diào)度難度等多個(gè)方面來考量的。 長(zhǎng)春理工大學(xué)本科畢業(yè)設(shè)計(jì) 8 R e d is M a s t e r C o n t a in e r 1 R e d is S la v e C o n t a in e r 1P o d 1V o lu m e r e d is 圖 2 3 Pod 結(jié)構(gòu)圖 而引入 Pod 帶來的了兩點(diǎn)顯著的改善： （ 1） 資源共享和容器通信 Pod 的引入將多個(gè)不同的為多個(gè) Docker Container 之間劃分了一個(gè)界限，同一個(gè) Pod 內(nèi)部的容器共享同樣的 work namespace、 IP 已經(jīng)端口資源，能通過UDS 進(jìn)行通信。在這樣一個(gè)扁平化的虛網(wǎng)絡(luò)里，每一個(gè) Pod 都有擁有其獨(dú)立的 IP 地址，通過該 IP 地址， Pod 之內(nèi)的容器就能正常的與其他 Minion、邏輯虛擬機(jī)、或者容器進(jìn)行直接通信。 同樣的，共享存儲(chǔ)卷（ Volume）的存在，方便了同一個(gè) Pod 之內(nèi)的各個(gè)容器進(jìn)行共享數(shù)據(jù)，以及避免了數(shù)據(jù)在容器的重建重啟等過程中的丟失，保證 了數(shù)據(jù)的一致性和安全性。 （ 2） 易于管理 和原生的 Docker API 不同， Kuberes 對(duì)底層的 API 進(jìn)行封裝和抽象，提供了一個(gè)方便而簡(jiǎn)易的接口，基本上所有的操作都可以通過一個(gè) JSON（ YAML）文件來定義，簡(jiǎn)化了應(yīng)用部署和管理的流程。 Pod 可以看成是管理和擴(kuò)容的基本單位，這樣， Docker 容器的邏輯劃分， FateSharing5，拷貝協(xié)同，主機(jī)管理，資源共享以及依賴管理都可以自動(dòng)化處理。 作為調(diào)度的基本單位， Kuberes 保證在整個(gè)系統(tǒng)里， Pod 的數(shù)量都是恒定的，和 Pod 創(chuàng)建的時(shí)候給定的參數(shù)相同 。當(dāng)然，類似的，用戶也可以動(dòng)態(tài)的調(diào)整Pod 的數(shù)量，這個(gè)過程完全是由 Kuberes 自動(dòng)調(diào)度完成的。當(dāng)然， Pod 的生命周期相對(duì)于集群來說是短暫的。他的行為被 Replication Controller 所驅(qū)動(dòng)。那么， 5 參照 Wikipade: 長(zhǎng)春理工大學(xué)本科畢業(yè)設(shè)計(jì) 9 Pod 是何時(shí)被創(chuàng)建，銷毀，遷移是無法預(yù)測(cè)到的，每當(dāng)給 Pod 綁定一個(gè) IP 地址時(shí)候。用戶是無法確定這個(gè) IP 可以被持久的，持續(xù)的訪問。即，對(duì)應(yīng)的 IP 地址和端口是否還能存在。 為了解決這個(gè)問題， Kuberes 引入了 Services 的概念。 Service 與 Pod 相對(duì)， Service 對(duì)應(yīng)的是對(duì)外的概念。整個(gè)集群可以抽象成多個(gè)不同的服務(wù)，而每個(gè)服務(wù)則由一定數(shù)量的 Pod 組成。目前的 Kuberes 采用的是 iptables 的 nat 網(wǎng)橋轉(zhuǎn)發(fā)的功能實(shí)現(xiàn)的這個(gè)轉(zhuǎn)發(fā)。生成 kubeproxy 的數(shù)據(jù)流，連接 apiserver 和 client 上 kubeproxy 綁定的隨機(jī)端口。 對(duì)于集群的使用者來說，鏈接的就是 Kuberes 的 Service 所提供的虛擬 IP和端口，而其內(nèi)部采用輪詢或者隨機(jī)訪問的算法來平衡各個(gè) Pod 之間的壓力。 Replication Cont