本篇本意是介紹hadoop的部署資源隔離和調(diào)度方案yarn。順便介紹了容器和容器集群管理。
說(shuō)回yarn隔離分為cpu和內(nèi)存，cpu基于cgroups,內(nèi)存自行實(shí)現(xiàn)計(jì)算ru_maxrss。還對(duì)比了k8n的隔離，它內(nèi)存和cpu都基于cgroups。在調(diào)度方面介紹了yarn的兩種調(diào)度機(jī)制Capacity Scheduler和Fair Scheduler。
整體：https://segmentfault.com/a/11...

yarn是hadoop的資源隔離和調(diào)度
運(yùn)行在YARN上帶來(lái)的好處 ：

一個(gè)集群部署多個(gè)版本
計(jì)算資源按需伸縮
不同負(fù)載應(yīng)用混搭，集群利用率高
共享底層存儲(chǔ)，避免數(shù)據(jù)跨集群遷移

兩層資源調(diào)度

RM
負(fù)責(zé)AM的創(chuàng)建和從AM接收分配請(qǐng)求分配，有調(diào)度器（上述的調(diào)度算法插件式放這兒），ASM（分配AM）

AM
負(fù)責(zé)計(jì)算分配量（每個(gè)容器大小，要多少個(gè)容器）/監(jiān)控/容錯(cuò)，一個(gè)容器運(yùn)行一個(gè)任務(wù)，AM可以要多個(gè)分配給自己內(nèi)部任務(wù)。

1.到RM申請(qǐng)，在一個(gè)Container（只是一個(gè)java對(duì)象，虛擬的，指定資源大小，啟動(dòng)時(shí)是運(yùn)行task的bin文件等）中啟動(dòng)AM
包含異步的分配資源，暫存在緩沖區(qū)，等待AM來(lái)取
2.AM RPC取資源并與NM通信
AM領(lǐng)取資源后分配任務(wù)不是yarn事情，用戶自行實(shí)現(xiàn)
3.包含各種狀態(tài)同步，比如7,持續(xù)的nm到rm.

目前只能實(shí)現(xiàn)cpu和內(nèi)存的隔離
基于cgroups
linux/kernel/cgroup,包含子系統(tǒng)：cpu,io,mmemory,net等

內(nèi)核中的代碼在kennel下。
用戶使用：通過(guò)文件系統(tǒng)配置（內(nèi)核給用戶提供的方法）
VFS 文件：ext2,ext3磁盤(pán)，socket,cgroups 。操作系統(tǒng)實(shí)現(xiàn)后可以通過(guò)mount掛載到cgroups文件系統(tǒng)
vi /etc/cgconfig.conf。/sys/fs/cgroup/cpuset中配置即可
對(duì)于內(nèi)存并沒(méi)有直接用cgroups
內(nèi)存隔離：線程監(jiān)控進(jìn)程內(nèi)存量，不是超過(guò)立刻殺死，有個(gè)生命期

jvm不足以：每個(gè)任務(wù)不僅有java進(jìn)程，reduce用C++

不能單純的cgroups內(nèi)存樹(shù)直接配置
Linux中所有的進(jìn)程都是通過(guò)fork()復(fù)制來(lái)實(shí)現(xiàn)的，而為了減少創(chuàng)建進(jìn)程帶來(lái)的堆棧消耗和性能影響，Linux使用了寫(xiě)時(shí)復(fù)制機(jī)制來(lái)快速創(chuàng)建進(jìn)程。也就是說(shuō)，一個(gè)子進(jìn)程剛剛產(chǎn)生時(shí)，它的堆?？臻g和父進(jìn)程是完全一致的，那么從一開(kāi)始它就擁有和父進(jìn)程同樣的ru_maxrss，如果父進(jìn)程的ru_maxrss比較大，那么由于rusage計(jì)算值取最大值，就算在觸發(fā)寫(xiě)時(shí)復(fù)制后，子進(jìn)程使用的實(shí)際最大駐留集大小被更新，我們獲得的也還是父進(jìn)程的那個(gè)值，也就是說(shuō)我們永遠(yuǎn)拿不到子進(jìn)程真實(shí)使用的內(nèi)存。
Java創(chuàng)建子進(jìn)程時(shí)采用了“fork() + exec()”的方案，子進(jìn)程啟動(dòng)瞬間，它的內(nèi)存使用量與父進(jìn)程是一致的，exec系函數(shù)，這個(gè)系別的函數(shù)通過(guò)將當(dāng)前進(jìn)程的使用權(quán)轉(zhuǎn)交給另一個(gè)程序，這時(shí)候進(jìn)程原有的所有運(yùn)行堆棧等數(shù)據(jù)將全部被銷毀，因此ru_maxrss也會(huì)被清零計(jì)算,然后子進(jìn)程的內(nèi)存會(huì)恢復(fù)正常；也就是說(shuō)，Container（子進(jìn)程）的創(chuàng)建過(guò)程中可能會(huì)出現(xiàn)內(nèi)存使用量超過(guò)預(yù)先定義的上限值的情況（取決于父進(jìn)程，也就是NodeManager的內(nèi)存使用量）；此時(shí)，如果使用Cgroup進(jìn)行內(nèi)存資源隔離，這個(gè)Container就可能會(huì)被“kill”。
雖然我們已經(jīng)可以獲得各個(gè)Container進(jìn)程樹(shù)的內(nèi)存（物理內(nèi)存、虛擬內(nèi)存）使用量，但是我們不能僅憑進(jìn)程樹(shù)的內(nèi)存使用量（物理內(nèi)存、虛擬內(nèi)存）是否超過(guò)上限值就決定是否“殺死”一個(gè)Container，因?yàn)椤白舆M(jìn)程”的內(nèi)存使用量是有“波動(dòng)”的，為了避免“誤殺”的情況出現(xiàn)，Hadoop賦予每個(gè)進(jìn)程“年齡”屬性，并規(guī)定剛啟動(dòng)進(jìn)程的年齡是1，MonitoringThread線程每更新一次，各個(gè)進(jìn)程的年齡加一，在此基礎(chǔ)上，選擇被“殺死”的Container的標(biāo)準(zhǔn)如下：如果一個(gè)Contaier對(duì)應(yīng)的進(jìn)程樹(shù)中所有進(jìn)程（年齡大于0）總內(nèi)存（物理內(nèi)存或虛擬內(nèi)存）使用量超過(guò)上限值的兩倍；或者所有年齡大于1的進(jìn)程總內(nèi)存（物理內(nèi)存或虛擬內(nèi)存）使用量超過(guò)上限值，則認(rèn)為該Container使用內(nèi)存超量，可以被“殺死”。（注意：這里的Container泛指Container進(jìn)程樹(shù)）
fork/exec/線程/進(jìn)程在另一篇：xx

1.可以占用空閑資源 Capacity Scheduler DefaultResourceCalculator(哪個(gè)用得少分哪個(gè)),drf
2.平均分配 Fair Scheduler 支持fair,fifo,drf

二者都從根開(kāi)始選擇隊(duì)列，應(yīng)用，容器，分配資源（遞歸直到葉子容器）。每次選擇時(shí)依據(jù)不同。

Capacity Scheduler
在 Capacity Scheduler 中，在比較資源占用率時(shí)，不同的資源比較器對(duì)資源定義是不一樣的。默認(rèn)的是 DefaultResourceCalculator，它只考慮內(nèi)存資源。另外一種是 DominantResourceCalculator，采用了 DRF 比較算法，同時(shí)考慮內(nèi)存和 cpu 兩種資源
DRF:每次計(jì)算資源分配占用，最大的。選擇最大中最小的分配資源

考慮一個(gè)有9個(gè)cpu和18GB的系統(tǒng)，有兩個(gè)用戶：用戶A的每個(gè)任務(wù)都請(qǐng)求（1CPU，4GB）資源；用戶B的每個(gè)任務(wù)都請(qǐng)求（3CPU，1GB）資源。最終A分配3份，B分配兩份

Fair Scheduler
fair比較：
若 s2緊需資源，s1 不緊需資源，把資源給 s2
若 s1、s2 都緊需資源，把資源給 minShareRatio 更小的，minShareRatio1 = 已使用內(nèi)存/ 最小資源保證
若 s1、s2 都不緊需資源， 把資源給 useToWeightRatio 更小的, useToWeightRatio = 已使用內(nèi)存 / 權(quán)重

namespace技術(shù)用來(lái)進(jìn)行做進(jìn)程間的隔離，linux namespace包括：mount namespace, uts namespace, ipc namespace, pid namespace, network namespace, user namespace六種，用于將mount點(diǎn)、UTS(hostname, domain name)、IPC資源、進(jìn)程、網(wǎng)絡(luò)、用戶等六種資源做到進(jìn)程級(jí)別的隔離。容器作為一個(gè)普通的進(jìn)程，使用namespace技術(shù)作隔離。

pivot_root根文件系統(tǒng)切換。mount –bind /etc /tmp/test/etc方式允許從任何其他位置訪問(wèn)任何文件或目錄，但是其他用戶仍然能看到這些mount點(diǎn)，而mount namespace可以做到mount點(diǎn)在各個(gè)進(jìn)程之間隔離。盡管如此，目前沒(méi)有對(duì)文件/目錄做進(jìn)程間隔離的namespace，所以有必要制作根文件系統(tǒng)再采用pivot_root命令在容器內(nèi)替換為這個(gè)根文件系統(tǒng)（注：chroot只是在指定的根文件系統(tǒng)下運(yùn)行命令）。

cgroups技術(shù)用來(lái)做資源限制，這些資源包括CPU、內(nèi)存、存儲(chǔ)、網(wǎng)絡(luò)等。

AUFS文件系統(tǒng)采用CoW寫(xiě)時(shí)復(fù)制技術(shù)將多個(gè)文件系統(tǒng)聯(lián)合到一個(gè)掛載點(diǎn)，這樣可以為容器實(shí)現(xiàn)一個(gè)只讀的base鏡像加一個(gè)可寫(xiě)的鏡像，從而縮小鏡像的體積。

在hadoop的yarn部署中，容器只是個(gè)資源單位的虛擬（沒(méi)有移植的概念，是在機(jī)器上運(yùn)行執(zhí)行文件進(jìn)程限制資源）

最初版本的chroot（目錄隔離）

虛擬機(jī)（獨(dú)立系統(tǒng)，通過(guò)hypervisor把硬件頁(yè)指向vm，hypercall調(diào)用負(fù)責(zé)vm和下層硬件調(diào)用,所以硬件可以共享，但是隔離性更好，lxc因?yàn)橐粋€(gè)操作系統(tǒng)很難做到硬件完全隔離）

LXC(與虛擬機(jī)比不需要多帶帶操作系統(tǒng)，共享的更多就更節(jié)省，是docker的基礎(chǔ)）
Kernel namespaces (ipc, uts, mount, pid, network and user)
Apparmor and SELinux profiles
Seccomp policies
Chroots (using pivot_root)
Kernel capabilities
CGroups (control groups)

docker（基于lxc（沒(méi)有調(diào)度分配集群管理）；多了https://stackoverflow.com/que...：應(yīng)用容器，鏡像，AUFS可以跨機(jī)器/甚至平臺(tái)移植,增量更改,應(yīng)用自動(dòng)部署），rkt（有了k8s之后docker的技術(shù)壁壘變低，k8s可以集成任何容器，只要他支持）?？梢赃\(yùn)行在虛擬機(jī)上

從第一版的JobTracker 單進(jìn)程的資源分配，源于hadoop。

第二版的Borg(google,未公開(kāi)過(guò))/yarn/mesos(twitter)等雙層（單主整體負(fù)責(zé)分配，多二層負(fù)責(zé)具體監(jiān)控等，各個(gè)框架調(diào)度器并不知道整個(gè)集群資源使用情況，只是被動(dòng)的接收資源；Master僅將可用的資源推送給各個(gè)框架）

第三版的omega（google） 去中心化，集群信息共享，樂(lè)觀鎖，集群申請(qǐng)變化快性能會(huì)不好(http://dockone.io/article/1153)

以上這些本身容器是抽象調(diào)的，隔離和調(diào)度就可以實(shí)現(xiàn)這些容器的隔離和固定大小的分配?？梢院蚫ocker等容器一起用（隔離是重復(fù)的），用來(lái)調(diào)度和部署。docker是運(yùn)行時(shí)隔離和鏡像
k8s是需要針對(duì)具體容器的，重點(diǎn)在于調(diào)度部署等，可以作為docker的編排管理，也針對(duì)docker做了很多應(yīng)用。只要支持

k8s（google基于omega,開(kāi)發(fā)人員基本都是omega和Borg的）也可以隔離，功能更全容器編排與管理，容器互聯(lián)，pod組合等
所以其實(shí)可以用任何k8s,yarn來(lái)部署和控制docker資源配置。

國(guó)內(nèi)百度云，騰訊云都實(shí)現(xiàn)自己的，比如百度的matrix.類似Borg

云計(jì)算和云存儲(chǔ)的思想都是，海量分布式環(huán)境，用戶請(qǐng)求返回按需計(jì)算收費(fèi)：云計(jì)算是一種按使用量付費(fèi)的模式，這種模式提供可用的、便捷的、按需的網(wǎng)絡(luò)訪問(wèn)， 進(jìn)入可配置的計(jì)算資源共享池（資源包括網(wǎng)絡(luò)，服務(wù)器，存儲(chǔ)，應(yīng)用軟件，服務(wù)）
云計(jì)算可以認(rèn)為包括以下幾個(gè)層次的服務(wù)：基礎(chǔ)設(shè)施即服務(wù)（IaaS），平臺(tái)即服務(wù)（PaaS）和軟件即服務(wù)（SaaS）

需要分布式大量副本和不同版本控制升級(jí)等，docker為其提供了降低運(yùn)維的方式（類似其中的Iaas+升級(jí)等管理工具）；虛擬技術(shù)和容器管理為其提供了多租戶隔離和調(diào)度。
云可以使用虛擬機(jī)節(jié)約硬件，私有云可以直接使用docker和k8s即節(jié)約硬件也節(jié)省操作系統(tǒng)占用，虛擬機(jī)和docker也可以適當(dāng)超賣，docker超賣成本低，因?yàn)檫w移方便，虛擬機(jī)貌似遷移成本很高。在提供虛擬機(jī)同時(shí)也可以提供k8s+docker的服務(wù)，使

基本上完全基于cgroups。但是對(duì)于內(nèi)存/磁盤(pán)這種沒(méi)有就不行的不可壓縮資源，會(huì)再加一個(gè)閾值，防止不穩(wěn)定，能分配的會(huì)少于這個(gè)。所以k8s對(duì)于內(nèi)存的限制會(huì)在fork時(shí)誤放大沒(méi)有處理。
https://juejin.im/post/5b3d8c...