今天在聽架構課程時候，聽到了多臺機器，我們使用docker來進行部署服務，使用K8S叢集管理。
那麼本人就突然有疑問，多臺主機，一個主機一個docker嗎？效能如何分配？比如cpu 記憶體 磁碟空間等。
答案是：一臺電腦，一個docker執行。
具體參考如下。
如果你對我的觀點有疑問，可以聯絡我。
docker注意點
大家需要注意，Docker本身並不是容器，它是建立容器的工具，是應用容器引擎。
想要搞懂Docker，其實看它的兩句口號就行。
第一句，是“Build, Ship and Run”。
k8s 注意點
就在Docker容器技術被炒得熱火朝天之時，大家發現，如果想要將Docker應用於具體的業務實現，是存在困難的——編排、管理和排程等各個方面，都不容易。於是，人們迫切需要一套管理系統，對Docker及容器進行更高階更靈活的管理。
就在這個時候，K8S出現了。
K8S，就是基於容器的叢集管理平臺，它的全稱，是kubernetes。
Kubernetes 這個單詞來自於希臘語，含義是舵手或領航員。K8S是它的縮寫，用“8”字替代了“ubernete”這8個字元。
Docker容器CPU、memory資源限制
背景
在使用 docker 執行容器時，預設的情況下，docker沒有對容器進行硬體資源的限制，當一臺主機上執行幾百個容器，這些容器雖然互相隔離，但是底層卻使用著相同的 CPU、記憶體和磁碟資源。如果不對容器使用的資源進行限制，那麼容器之間會互相影響，小的來說會導致容器資源使用不公平；大的來說，可能會導致主機和叢集資源耗盡，服務完全不可用。
docker 作為容器的管理者，自然提供了控制容器資源的功能。正如使用核心的 namespace 來做容器之間的隔離，docker 也是通過核心的 cgroups 來做容器的資源限制；包括CPU、記憶體、磁碟三大方面，基本覆蓋了常見的資源配額和使用量控制。
Docker記憶體控制OOME在linxu系統上，如果核心探測到當前宿主機已經沒有可用記憶體使用，那麼會丟擲一個OOME(Out Of Memory Exception:記憶體異常 )，並且會開啟killing去殺掉一些程式。
一旦發生OOME，任何程式都有可能被殺死，包括docker daemon在內，為此，docker特地調整了docker daemon的OOM_Odj優先順序，以免他被殺掉，但容器的優先順序並未被調整。經過系統內部複製的計算後，每個系統程式都會有一個OOM_Score得分，OOM_Odj越高，得分越高，（在docker run的時候可以調整OOM_Odj）得分最高的優先被kill掉，當然，也可以指定一些特定的重要的容器禁止被OMM殺掉，在啟動容器時使用 –oom-kill-disable=true指定。
cgroup簡介
cgroup是Control Groups的縮寫，是Linux 核心提供的一種可以限制、記錄、隔離程式組所使用的物理資源(如 cpu、memory、磁碟IO等等) 的機制，被LXC、docker等很多專案用於實現程式資源控制。cgroup將任意程式進行分組化管理的 Linux 核心功能。cgroup本身是提供將程式進行分組化管理的功能和介面的基礎結構，I/O 或記憶體的分配控制等具體的資源管理功能是通過這個功能來實現的。這些具體的資源管理功能稱為cgroup子系統，有以下幾大子系統實現：
- blkio：設定限制每個塊裝置的輸入輸出控制。例如:磁碟，光碟以及usb等等。
- cpu：使用排程程式為cgroup任務提供cpu的訪問。 cpuacct：產生cgroup任務的cpu資源報告。
- cpuset：如果是多核心的cpu，這個子系統會為cgroup任務分配單獨的cpu和記憶體。
- devices：允許或拒絕cgroup任務對裝置的訪問。
- freezer：暫停和恢復cgroup任務。
- memory：設定每個cgroup的記憶體限制以及產生記憶體資源報告。
- net_cls：標記每個網路包以供cgroup方便使用。
- ns：名稱空間子系統。
- perf_event：增加了對每group的監測跟蹤的能力，即可以監測屬於某個特定的group的所有執行緒以及執行在特定CPU上的執行緒。
目前docker只是用了其中一部分子系統，實現對資源配額和使用的控制。
記憶體限制
Docker 提供的記憶體限制功能有以下幾點：
容器能使用的記憶體和交換分割槽大小。
容器的核心記憶體大小。
容器虛擬記憶體的交換行為。
容器記憶體的軟性限制。
是否殺死佔用過多記憶體的容器。
容器被殺死的優先順序
一般情況下，達到記憶體限制的容器過段時間後就會被系統殺死。
詳細的省略了
CPU 限制
概述
Docker 的資源限制和隔離完全基於 Linux cgroups。對 CPU 資源的限制方式也和 cgroups 相同。Docker 提供的 CPU 資源限制選項可以在多核系統上限制容器能利用哪些 vCPU。而對容器最多能使用的 CPU 時間有兩種限制方式：一是有多個 CPU 密集型的容器競爭 CPU 時，設定各個容器能使用的 CPU 時間相對比例。二是以絕對的方式設定容器在每個排程週期內最多能使用的 CPU 時間。
磁碟IO配額控制
相對於CPU和記憶體的配額控制，docker對磁碟IO的控制相對不成熟，大多數都必須在有宿主機裝置的情況下使用。主要包括以下引數：
- –device-read-bps：限制此裝置上的讀速度（bytes per second），單位可以是kb、mb或者gb。
- –device-read-iops：通過每秒讀IO次數來限制指定裝置的讀速度。
- –device-write-bps ：限制此裝置上的寫速度（bytes per second），單位可以是kb、mb或者gb。
- –device-write-iops：通過每秒寫IO次數來限制指定裝置的寫速度。
- –blkio-weight：容器預設磁碟IO的加權值，有效值範圍為10-100。
- –blkio-weight-device： 針對特定裝置的IO加權控制。其格式為DEVICE_NAME:WEIGHT
儲存配額控制的相關引數，可以參考Red Hat文件中blkio這一章，瞭解它們的詳細作用。
容器空間大小限制
在docker使用devicemapper作為儲存驅動時，預設每個容器和映象的最大大小為10G。如果需要調整，可以在daemon啟動引數中，使用dm.basesize來指定，但需要注意的是，修改這個值，不僅僅需要重啟docker daemon服務，還會導致宿主機上的所有本地映象和容器都被清理掉。
使用aufs或者overlay等其他儲存驅動時，沒有這個限制。
本作品採用《CC 協議》，轉載必須註明作者和本文連結
