【導(dǎo)讀】地完成了任務(wù)書中規(guī)定的內(nèi)容，不弄虛作假，不抄襲別人的工作內(nèi)容。貢獻(xiàn)的個(gè)人和集體均已在文中注明。本人承擔(dān)相應(yīng)的法律責(zé)任。4．本人完全了解學(xué)校關(guān)于保存、使用畢業(yè)設(shè)計(jì)（論文）的規(guī)定，校保留畢業(yè)設(shè)計(jì)（論文）的復(fù)印件和電子版本，允許被查閱和借閱；以公布其中的全部或部分內(nèi)容。并開發(fā)了Kuberes用來搭建了一個(gè)集群管控程序。本文就其的主要部件的。解除了集群管理程序和Docker程序的耦合。了整個(gè)系統(tǒng)的一致性。同時(shí)，為互聯(lián)網(wǎng)與Pod之間增加了一層訪問中間控制層，解決了傳統(tǒng)軟件服務(wù)發(fā)現(xiàn)和流量負(fù)載均衡的問題。但是，對(duì)于DNS的支持并未。達(dá)到理想的程度。最后，利用自建的機(jī)制解決了服務(wù)的動(dòng)態(tài)擴(kuò)容難題，為快速部。署服務(wù)提供了一個(gè)簡(jiǎn)單而可行的方案。.容器VS虛擬機(jī)——商用為主.........

　　

【正文】 d 相關(guān)的信息 Binding 寫回 API Server。 長(zhǎng)春理工大學(xué)本科畢業(yè)設(shè)計(jì) 16 第 4 章 設(shè)計(jì)實(shí)現(xiàn) Pod Pod 共有如下字段如表 4 1 所示 這其中， TypeMeta 類型是一個(gè)結(jié)構(gòu)體，是所有 REST 資源的共有屬性， Golang 通過組合的方式代替繼承，因此，這里的一個(gè)沒有名字的 TypeMeta 類型可以認(rèn)為是一種特殊的繼承方式，由 Pod 繼承自 TypeMeta。因此， TypeMeta 也可以說是一個(gè)對(duì)象的元數(shù)據(jù)。其中包括：資源類型、對(duì)象名、 namespace、 、 UUID、版本、創(chuàng)建時(shí)間、和資源對(duì)象的 API 版本等信息 。 Labels 是創(chuàng)建 Pod 時(shí)資 源文件里為 Pod 指定的 Labels 字段。 表 4 2 Pod 字段表 字段名 字段類型 字段說明 TypeMeta REST 資源共有屬性 Labels map[string]string 本 Pod 的 Labels，可以動(dòng)態(tài)的附加 DesiredState PodState 當(dāng)前 Pod 操作完成之后的狀態(tài) CurrentState PodState 當(dāng)前 Pod 的狀態(tài) NodeSelector map[string]string 是一個(gè) LabelSelector，用于選取和 Pod 對(duì)應(yīng)的 Minion DesiredState 和 CurrentState 是一對(duì)相對(duì)的狀態(tài)，是一個(gè) struct，其中包含了很多屬性， 屬性即代表了組成一個(gè) Pod 的 Volumes 和 Containers 的配置信息，該屬性的內(nèi)容與 Pod 資源文件的 est 字段內(nèi)容等價(jià)。 CurrentState 屬性則代表該 Pod 的當(dāng)前狀態(tài)，該屬性的內(nèi)容不需要用戶填入而是在系統(tǒng)運(yùn)行過程中被系統(tǒng)填充進(jìn)去的。 NodeSelector 即一個(gè) Label Selector，用于為 Pod 選取 Minion，如果需要可以在 Pod 資源文件中設(shè)置，該屬性在 kubeScheduler 調(diào)度 Pod 時(shí)會(huì)用到 。 可以在創(chuàng)建 Pod 的控制文件中聲明，其對(duì)應(yīng)表如表 4 2 所示： 其中 Containers 和 Volumes 是兩個(gè)子類列表，其中 Container 包含了一系列預(yù)定義的資源上限以及資源標(biāo)識(shí)。其中， Container 主要包括容器名、 image 名、長(zhǎng)春理工大學(xué)本科畢業(yè)設(shè)計(jì) 17 預(yù)執(zhí)行命令、工作目錄、需要掛載的 Volume 等信息。而 Volumes 是預(yù)先聲明的Volume 的字段，主要用來預(yù)申請(qǐng)這些 Volume，只有當(dāng)所有的 Volume 都可用的時(shí)候， Kuberes 才會(huì)繼續(xù)進(jìn)行調(diào)度。 表 4 3 ContainerManifest 字段表 字段 必需 值類型 含義 資源文件 備注 Version 是 string manifest 的版本號(hào) 是 目前必需是 v1beta2 的 ID 是 string Manifest 的名字 是 UUID 是 string 唯一標(biāo)示 Pod的 ID 否 只讀，由系統(tǒng)自動(dòng)填充 Containers[] 是 [Container…] 要在 Pod 里啟動(dòng)的所有容器 是 RestartPolicy 否 string Pod 的重啟策略 是 包含三種策略：Always， OnFailed， Never。默認(rèn)Always Volumes[] 否 [Volumes…] 在本 Pod 之間共享的所有 Volumes 是 DNSPolicy 否 String 定義 Pod 的 DNS 策略 是 兩種選擇： ClusterFirst 和 Default。默認(rèn) Default。 將以上內(nèi)容解析到 Kuberes 的配置文件之中，就能得到一個(gè)用來管控 Kuberes 集群中某些 Pod 的配置文件（如附錄 1)： Volume 容器的生命周期是短暫的，通常情況下，容器總是在不斷的被重啟和重新創(chuàng)建中，而當(dāng)容器退出之后，其對(duì)應(yīng)的文件系統(tǒng)也將被一同銷毀。但是，在實(shí)際的應(yīng)用中，持久化作為業(yè)務(wù)服務(wù)中重要的一環(huán)是不可或缺的。對(duì)此 Docker 提供了一個(gè)簡(jiǎn)單的方案就是 Volume 機(jī)制， Docker 稱之為：持久存儲(chǔ)卷。 其特點(diǎn)就是將宿主機(jī)的某個(gè)特殊的目錄作為掛載點(diǎn)映射到容器之中，這個(gè) Volume 并不會(huì)隨著容器的銷毀而銷毀，而是實(shí)時(shí)存儲(chǔ)到宿主機(jī)上的。同樣的我們長(zhǎng)春理工大學(xué)本科畢業(yè)設(shè)計(jì) 18 聲明一個(gè)帶 Volume 的資源文件（如附錄 2）： 首先，我們聲明了一個(gè)名叫 ‖redispersistentstorage‖的 volume，然后再名叫redis 的 container 之內(nèi)使用了這個(gè) volume。 在 Kuberes 整個(gè)系統(tǒng)中， emptyDir 的生命周期和 Pod 的生命周期是一樣的。即，大于等于任何 Pod 內(nèi)的 Container。因此，在整個(gè) Pod 的生命周期里，所有的 Container 都可掛載這個(gè) Volume，即使其中某些的 Container 意外退出，這里面的數(shù)據(jù)也不受任何影響。 與 Docker 的 Volume 不同的是， Kuberes 中的 Volume 是可以重復(fù)的、額外的綁定多個(gè) Docker Container 上的。每個(gè)容器所能看到的的文件系統(tǒng)由兩部分構(gòu)成：一是 Docker image 所自帶的文件系統(tǒng)，位于文件系統(tǒng)的最底層，另外就是互相疊加的至少零個(gè)的 Volume 作為掛載點(diǎn)。 Kuberes 支持四種不同的 Volume 的 Source 類型： EmptyDir、 HostDir、 GCEPersistentDisk、 NFS。 （ 1） EmptyDir EmptyDir 綁定到 Pod 上的時(shí)候，最開始的時(shí)候就和一個(gè)空的文件夾是一樣的，只有當(dāng) Pod 不斷的向里面寫入數(shù)據(jù)之后，才會(huì)有數(shù)據(jù)存儲(chǔ)在里面。其生命周期和 Pod 是一樣的，即，當(dāng) Pod 被移除的時(shí)候，這里的數(shù)據(jù)也將被移除，而且是永久性的刪除。由于 Container 的限制，每個(gè) Container 的存儲(chǔ)資源不能超過 20G，所以，當(dāng)運(yùn)行 I/O 密集型任務(wù)的時(shí)候臨時(shí)文件可能會(huì)很大，因此需要一個(gè)臨時(shí)文件來支持大量臨時(shí) 文件的存放。同樣的，由于其共享性， EmptyDir 類型的 Volume 可以用作臨時(shí)的數(shù)據(jù)交換文件來使用。 EmptyDir 類型的存儲(chǔ)并不能由用戶指定，而是由 Kubelet 自動(dòng)決定，默認(rèn)的情況下使用的就是 Minion 上的臨時(shí)文件夾。 （ 2） HostDir 一個(gè)規(guī)定為 HostDir 的 Volume 可以被允許訪問當(dāng)前 Minion 上的文件系統(tǒng)，即可以突破 Container 的封裝去訪問宿主機(jī)上的資源。這點(diǎn)與 Docker 提供的 Volume 系統(tǒng)是一致的。但是附加這種 Volume 的時(shí)候，要千萬保證 Pod 所訪問的資源在整個(gè)集群上都是一致的。因?yàn)?Pod 可能被很容易的遷移走，當(dāng)某個(gè) Pod 綁定到其他的 Minion 上時(shí)候，不一致的資源可能導(dǎo)致你的 Pod 意外退出。因此， HostDir 多配合著 ReadOnly 選項(xiàng)使用，即，規(guī)定這個(gè) Volume 為只讀，這樣，便將此 Volume 定義為無狀態(tài)的，可以很容易的遷移走。 （ 3） GCEPersistentDisk 在使用 GCEpersistentDIsk 之前，需要先用 GCE6的 gcloud 工具建立一塊專門的 PD(Persitent Disk)，另外也要求 Kuberes 集群必須有 GCE 環(huán)境的支持，這 6 Google Compute Engine 長(zhǎng)春理工大學(xué)本科畢業(yè)設(shè)計(jì) 19 里我們不做過多贅述。 （ 4） NFS Kuberes 的 NFS 類型的 Volume 允許容器將一個(gè)網(wǎng)絡(luò)文件系統(tǒng)動(dòng)態(tài)的掛載進(jìn) Pod 內(nèi)被多個(gè)容器共享。同時(shí)，用戶可以自己規(guī)定 NFS 的起始目錄，并且在這個(gè)目錄建立 Root Barrier，保證了 NFS 服務(wù)器上其他的數(shù)據(jù)不會(huì)被污染。 容器通信 對(duì)于一個(gè) Pod 內(nèi)的容器，為了能更簡(jiǎn)單的使其互相通信， Kuberes 專門為了每個(gè) Pod 自動(dòng)生成了一個(gè)特殊的 ―網(wǎng)絡(luò)容器 ‖，這個(gè)容器的容器名以 k8s_.*開頭。該容器負(fù)責(zé)將 Pod 內(nèi)的容器暴露端口綁定轉(zhuǎn) 發(fā)到所有 Minion 上的可端口上，甚至包括 loopback。網(wǎng)絡(luò)容器負(fù)責(zé)這個(gè)復(fù)雜的網(wǎng)絡(luò)映射過程中的一一對(duì)應(yīng)關(guān)系的維持。 Replication Controller Replication Controller（副本控制器），保證了集群中一定數(shù)量的 Pod 總是處于正常的運(yùn)行狀態(tài)。 Pod 的生命周期定義如表 4 4 所示： 表 4 5 Pod 生命周期表 狀態(tài)值 含義 pending Pod 的創(chuàng)建請(qǐng)求已經(jīng)被系統(tǒng)接受，但 Pod 內(nèi)還有一個(gè)或多個(gè)容器未啟動(dòng)。距離 Pod 創(chuàng)建成功還需要一些時(shí)間，這些時(shí)間可能包括：下載 Docker 鏡像的網(wǎng)絡(luò)傳輸時(shí)間和 Pod 的調(diào)度時(shí)間等。 running Pod 已經(jīng)被綁定到工作節(jié)點(diǎn)上，并且其內(nèi)的所有容器都已經(jīng)開始運(yùn)行了，最重要的是其中至少還要一個(gè)容器處于 running 或者啟動(dòng)過程 succeeded 所有容器均正常退出 failed 所有容器都退出，且至少有一個(gè)因出錯(cuò)而意外退出 Pod 的生命周期定義中還指出， 當(dāng)且僅當(dāng) Pod 的重啟策略 RestartPolicy = Always 時(shí)， Replication Controller 才會(huì)對(duì)該 Pod 進(jìn)行正常的管理操作（譬如：創(chuàng)建、銷毀、重啟等），而當(dāng) Pod 的重啟策略是其他類型（ OnFailure 或 Never）時(shí)， Replication Controller 就會(huì)拒絕實(shí)例化 7該 Pod。 一般情況下， Pod 被創(chuàng)建完畢后不會(huì)自動(dòng)的被銷毀。而進(jìn)行這個(gè)過程的可能 7 不實(shí)例化的意思是 ：可以啟動(dòng)這個(gè) Pod，但是不會(huì)將其加入到 Replication Controller，主要用于測(cè)試 長(zhǎng)春理工大學(xué)本科畢業(yè)設(shè)計(jì) 20 是用戶或者 Replication Controller。唯一的例外就是當(dāng) Pod 處于 succeeded 或者 failed 狀態(tài)時(shí)間過長(zhǎng)的時(shí)候，該 Pod 即被系統(tǒng)回收。如果一個(gè)節(jié)點(diǎn)因?yàn)楣收隙鴶嚅_連接， Kuberes 也會(huì)對(duì)其進(jìn)行應(yīng)用超時(shí)策略，并將這個(gè)節(jié)點(diǎn)上所有綁定的 Pod 的狀態(tài)都標(biāo)記成 failed。 RestartPolicy 和 Replication Controller 其中，重啟策略和狀態(tài)的對(duì)應(yīng)關(guān)系如圖 4 1： 另外，除了 RestartPolicy 影響著 Replication Controller 的調(diào)度之外， Minion的狀態(tài)同樣也會(huì)影響到 Replication Controller 的調(diào)度。例如： （ 1） 當(dāng) Pod 處于 Running 狀態(tài)的時(shí)候，其中一個(gè) Volume 發(fā)生了崩潰性錯(cuò)誤，這時(shí)候 Replication Controller 將： a) 殺死這個(gè) Pod 中的所有容器 b) 向系統(tǒng)輸出 failure 的 event c) Pod 被標(biāo)記為 failed 狀態(tài) d) Pod 被遷移至其他的 Minion 上繼續(xù)運(yùn)行。 （ 2） 當(dāng) Pod 處于 running 狀態(tài)時(shí)，綁定它的 Minion 與集群斷開： a) Node Controller 應(yīng)用等待策略，等待一個(gè)超時(shí)時(shí)間 b) Node Controller 標(biāo)記該 Minion 上的所有 Pod 處于 Failed 狀態(tài) c) 此 Minion 上的所有 Pod 均被遷移至其他節(jié)點(diǎn)上繼續(xù)運(yùn)行 Kuberes 系統(tǒng)在設(shè)計(jì)上是為了滿足大量機(jī)器的大規(guī)模集群，和著名的大數(shù)據(jù)計(jì)算框架 Hadoop 一樣， Kuberes 認(rèn)為節(jié)點(diǎn)失效是常態(tài)而不是意態(tài)。這就意味著，每當(dāng)節(jié)點(diǎn)失效而下線的時(shí)候， Replication Controller 的控制策略是遷移至其他節(jié)點(diǎn)繼續(xù)重新創(chuàng)建和運(yùn)行其所有容器。但是如果這個(gè) Pod 的 RestartPolicy 并不是 always 的，那么 Pod 其實(shí)是已經(jīng)被標(biāo)注為 Failed 狀態(tài)，但是卻再次進(jìn)行實(shí)例化。這也就是上文要求的， RestartPolicy 必須是 always 的，否則 Kuberes拒絕實(shí)例化它的原因。 所以，對(duì)于 Kuberes 來說，所有正式上線并納入 Replication Controller 管理的 Pod 的重啟策略都是積極的，即，除非顯式的刪除，不然這個(gè)啟動(dòng)失敗的 Pod 會(huì)一直不斷的進(jìn)行重啟和變更 Minion。這對(duì)于系統(tǒng)資源的消耗是及其巨大的，因此，用戶在啟動(dòng) Pod 的時(shí)候，必須要確定其正確無誤。 另外必須要清楚的是， Kuberes 的 Pod 所定義的 RestartPolicy 是對(duì)于其中的 Docker Container 的，而不是 Pod 本身。因此被管理重啟的也只而且只能是 Dock