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

yarn是hadoop的資源隔離和調度
運行在YARN上帶來的好處 ：

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

兩層資源調度

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

AM
負責計算分配量（每個容器大小，要多少個容器）/監(jiān)控/容錯，一個容器運行一個任務，AM可以要多個分配給自己內部任務。

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

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

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

jvm不足以：每個任務不僅有java進程，reduce用C++

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

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

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

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

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

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

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

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

cgroups技術用來做資源限制，這些資源包括CPU、內存、存儲、網(wǎng)絡等。

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

在hadoop的yarn部署中，容器只是個資源單位的虛擬（沒有移植的概念，是在機器上運行執(zhí)行文件進程限制資源）

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

虛擬機（獨立系統(tǒng)，通過hypervisor把硬件頁指向vm，hypercall調用負責vm和下層硬件調用,所以硬件可以共享，但是隔離性更好，lxc因為一個操作系統(tǒng)很難做到硬件完全隔離）

LXC(與虛擬機比不需要多帶帶操作系統(tǒng)，共享的更多就更節(jié)省，是docker的基礎）
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（沒有調度分配集群管理）；多了https://stackoverflow.com/que...：應用容器，鏡像，AUFS可以跨機器/甚至平臺移植,增量更改,應用自動部署），rkt（有了k8s之后docker的技術壁壘變低，k8s可以集成任何容器，只要他支持）?？梢赃\行在虛擬機上

從第一版的JobTracker 單進程的資源分配，源于hadoop。

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

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

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

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

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

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

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

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