摘要：執(zhí)行容器內(nèi)部運行的執(zhí)行工作作為容器的執(zhí)行驅(qū)動，負(fù)責(zé)創(chuàng)建容器運行命名空間，負(fù)責(zé)容器資源使用的統(tǒng)計與限制，負(fù)責(zé)容器內(nèi)部進(jìn)程的真正運行等。典型的在啟動后，首先將設(shè)置為進(jìn)行一系列檢查然后將其切換為供用戶使用。

在https://segmentfault.com/a/11... 容器，隔離，云的概述。這篇對其中用途廣泛的docker,k8s做詳細(xì)介紹，并給出云搭建的生態(tài)環(huán)境體系。

容器發(fā)展，詳見上面提到的文章

典型圖：VM與container對比，差異在于OS

缺點

隔離性相比KVM之類的虛擬化方案還是有些欠缺，所有container公用一部分的運行庫
網(wǎng)絡(luò)管理相對簡單，主要是基于namespace隔離
cgroup的cpu和cpuset提供的cpu功能相比KVM的等虛擬化方案相比難以度量(所以dotcloud主要是安內(nèi)存收費)
docker對disk的管理比較有限（disk quota）
container隨著用戶進(jìn)程的停止而銷毀，container中的log等用戶數(shù)據(jù)不便收集   

優(yōu)點：

輕量級的特點，其啟動快，而且docker能夠只加載每個container變化的部分，這樣資源占用小
docker不只是容器，高級容器引擎，應(yīng)用部署平臺，應(yīng)用鏡像商店

Image 一個包含運行環(huán)境的只讀 模板

Container 鏡像的運行態(tài)，docker利 用容器運行應(yīng)用

Registry 存儲容器鏡像的倉庫

Dockerfile 包含構(gòu)建鏡像一系列命令 和參數(shù)的腳本

Docker Daemon 可以認(rèn)為是通過 Docker Server 模塊接受 Docker Client 的請求，并在 Engine 中處理請求，然后根據(jù)請求類型，創(chuàng)建出指定的 Job 并運行。 Docker Daemon 運行在 Docker host 上，負(fù)責(zé)創(chuàng)建、運行、監(jiān)控容器，構(gòu)建、存儲鏡像。

job運行過程的作用有以下幾種可能：
向 Docker Registry 獲取鏡像
通過 graphdriver 執(zhí)行容器鏡像的本地化操作
啟動容器

graph
Graph在Docker架構(gòu)中扮演已下載容器鏡像的保管者，以及已下載容器鏡像之間關(guān)系的記錄者。
一方面，Graph存儲著本地具有版本信息的文件系統(tǒng)鏡像，另一方面也通過GraphDB記錄著所有文件系統(tǒng)鏡像彼此之間的關(guān)系。
GraphDB是一個構(gòu)建在SQLite之上的小型圖數(shù)據(jù)庫，實現(xiàn)了節(jié)點的命名以及節(jié)點之間關(guān)聯(lián)關(guān)系的記錄。它僅僅實現(xiàn)了大多數(shù)圖數(shù)據(jù)庫所擁有的一個小的子集，但是提供了簡單的接口表示節(jié)點之間的關(guān)系。
Graph的本地目錄中，關(guān)于每一個的容器鏡像，具體存儲的信息有：該容器鏡像的元數(shù)據(jù)，容器鏡像的大小信息，以及該容器鏡像所代表的具體rootfs。

networkdriver 執(zhí)行容器網(wǎng)絡(luò)環(huán)境的配置
networkdriver的用途是完成Docker容器網(wǎng)絡(luò)環(huán)境的配置，其中包括Docker啟動時為Docker環(huán)境創(chuàng)建網(wǎng)橋；Docker容器創(chuàng)建時為其創(chuàng)建專屬虛擬網(wǎng)卡設(shè)備；以及為Docker容器分配IP、端口并與宿主機(jī)做端口映射，設(shè)置容器防火墻策略等。

execdriver 執(zhí)行容器內(nèi)部運行的執(zhí)行工作
execdriver作為Docker容器的執(zhí)行驅(qū)動，負(fù)責(zé)創(chuàng)建容器運行命名空間，負(fù)責(zé)容器資源使用的統(tǒng)計與限制，負(fù)責(zé)容器內(nèi)部進(jìn)程的真正運行等。在execdriver的實現(xiàn)過程中，原先可以使用LXC驅(qū)動調(diào)用LXC的接口，來操縱容器的配置以及生命周期，而現(xiàn)在execdriver默認(rèn)使用native驅(qū)動，不依賴于LXC。具體體現(xiàn)在Daemon啟動過程中加載的ExecDriverflag參數(shù)，該參數(shù)在配置文件已經(jīng)被設(shè)為"native"。這可以認(rèn)為是Docker在1.2版本上一個很大的改變，或者說Docker實現(xiàn)跨平臺的一個先兆

libcontainer
Docker架構(gòu)中一個使用Go語言設(shè)計實現(xiàn)的庫，設(shè)計初衷是希望該庫可以不依靠任何依賴，直接訪問內(nèi)核中與容器相關(guān)的API。
正是由于libcontainer的存在，Docker可以直接調(diào)用libcontainer，而最終操縱容器的namespace、cgroups、apparmor、網(wǎng)絡(luò)設(shè)備以及防火墻規(guī)則等。這一系列操作的完成都不需要依賴LXC或者其他包。
libcontainer提供了一整套標(biāo)準(zhǔn)的接口來滿足上層對容器管理的需求。

docker run過程
(1) Docker Client接受docker run命令，解析完請求以及收集完請求參數(shù)之后，發(fā)送一個HTTP請求給Docker Server，HTTP請求方法為POST，請求URL為/containers/create? +xxx;
(2) Docker Server接受以上HTTP請求，并交給mux.Router，mux.Router通過URL以及請求方法來確定執(zhí)行該請求的具體handler；
(3) mux.Router將請求路由分發(fā)至相應(yīng)的handler，具體為PostContainersCreate；
(4) 在PostImageCreate這個handler之中，一個名為"create"的job被創(chuàng)建，并開始讓該job運行；
(5) 名為"create"的job在運行過程中，執(zhí)行Container.Create操作，該操作需要獲取容器鏡像來為Docker容器創(chuàng)建rootfs，即調(diào)用graphdriver；
(6) graphdriver從Graph中獲取創(chuàng)建Docker容器rootfs所需要的所有的鏡像；
(7) graphdriver將rootfs所有鏡像，加載安裝至Docker容器指定的文件目錄下；
(8) 若以上操作全部正常執(zhí)行，沒有返回錯誤或異常，則Docker Client收到Docker Server返回狀態(tài)之后，發(fā)起第二次HTTP請求。請求方法為"POST"，請求URL為"/containers/"+container_ID+"/start"；
(9) Docker Server接受以上HTTP請求，并交給mux.Router，mux.Router通過URL以及請求方法來確定執(zhí)行該請求的具體handler；
(10) mux.Router將請求路由分發(fā)至相應(yīng)的handler，具體為PostContainersStart；
(11) 在PostContainersStart這個handler之中，名為"start"的job被創(chuàng)建，并開始執(zhí)行；
(12) 名為"start"的job執(zhí)行完初步的配置工作后，開始配置與創(chuàng)建網(wǎng)絡(luò)環(huán)境，調(diào)用networkdriver；
(13) networkdriver需要為指定的Docker容器創(chuàng)建網(wǎng)絡(luò)接口設(shè)備，并為其分配IP，port，以及設(shè)置防火墻規(guī)則，相應(yīng)的操作轉(zhuǎn)交至libcontainer中的netlink包來完成；
(14) netlink完成Docker容器的網(wǎng)絡(luò)環(huán)境配置與創(chuàng)建；
(15) 返回至名為"start"的job，執(zhí)行完一些輔助性操作后，job開始執(zhí)行用戶指令，調(diào)用execdriver；
(16) execdriver被調(diào)用，初始化Docker容器內(nèi)部的運行環(huán)境，如命名空間，資源控制與隔離，以及用戶命令的執(zhí)行，相應(yīng)的操作轉(zhuǎn)交至libcontainer來完成；
(17) libcontainer被調(diào)用，完成Docker容器內(nèi)部的運行環(huán)境初始化，并最終執(zhí)行用戶要求啟動的命令。

1、進(jìn)程命名空間：每個命名空間獨立維護(hù)自己的進(jìn)程號，父子關(guān)系結(jié)構(gòu)，子空間的進(jìn)程對父空間是可見的，新fork出的進(jìn)程 在父命名空間和子命名空間都會生成一個進(jìn)程號
?2、網(wǎng)絡(luò)命名空間：實現(xiàn)網(wǎng)絡(luò)隔離 完全獨立的網(wǎng)絡(luò)協(xié)議視圖，包括網(wǎng)絡(luò)設(shè)備接口、IPV4 IPV6協(xié)議棧，路由表，防火墻規(guī)則，sockers等，采用虛擬網(wǎng)絡(luò)設(shè)備，將容器中的虛擬網(wǎng)卡綁定在本地主機(jī)的docker0的網(wǎng)橋上
?3、ipc命名空間 進(jìn)程間交互，信號量、消息隊列，和共享內(nèi)存，同一個IPC空間的可以交互，不同的不可以
?4、掛載命名空間 類似chroot, 將一個進(jìn)程放到一個特定的目錄執(zhí)行。允許不同命名空間的進(jìn)程看到的文件結(jié)構(gòu)不同，文件目錄被隔離 chroot(PATH)這個function必須具有 root的身份才能執(zhí)行，執(zhí)行后會將根目錄切換到PATH 所指定的地方。
5、 UTS命名空間 UNIX Time-sharing System 允許每個容器擁有獨立的主機(jī)名和域名，默認(rèn)主機(jī)名為容器ID
?6、用戶命名空間 每個容器可以有不同的用戶和組id，可以在容器內(nèi)使用特定的內(nèi)部用戶執(zhí)行程序。每個容器都有root賬號

1.cpu,io,mem等等:cgroups
2.網(wǎng)卡
docker創(chuàng)建容器的過程：
? ? ?1、創(chuàng)建一對虛擬接口 veth pair ，分別放在本地主機(jī)和新容器的命名空間中
? ? ?2、本地主機(jī)一端的虛擬接口 連接到默認(rèn)的docker0網(wǎng)橋上，或指定網(wǎng)橋，并具有一個veth開頭的唯一名字
? ? ?3、容器一端的虛擬接口，放到新的容器中，修改名字為eth0，只在容器中可見
? ? ?4、從網(wǎng)橋可用地址中 分配一個空閑的給 eth0，（172.17.0.2/16) 并設(shè)置默認(rèn)路由網(wǎng)卡為 docker0的ip （172.17.42.1/16）

Veth pair 是一對虛擬網(wǎng)卡，從一張veth網(wǎng)卡發(fā)出的數(shù)據(jù)包可以直接到達(dá)它的peer veth,兩者之間存在著虛擬鏈路。不同網(wǎng)絡(luò)命名空間之間交互
Veth 網(wǎng)卡和常規(guī)的以太網(wǎng)區(qū)別僅在于xmit接口：將數(shù)據(jù)發(fā)送到其peer,觸發(fā)peer的Rx 過程。
3.disk/network quota
雖然cgroup提供IOPS之類的限制機(jī)制，但是從限制用戶能使用的磁盤大小和網(wǎng)絡(luò)帶寬上還是非常有限的。
Disk/network的quota現(xiàn)在有兩種思路:
1).通過docker run -v命令將外部存儲mount到container的目錄下，quota從Host方向限制，在device mapper driver中更采用實際的device因此更好控制。
2).通過使用disk quota來限制AUFS的可操作文件大小。維護(hù)一個UID池，每次創(chuàng)建container都從中取一個user name， 在container里和Host上用這個username創(chuàng)建用戶，在Host上用set quota限制該username的UID的disk. 網(wǎng)絡(luò)上由于docker采用veth的方式，可以采用tc來控制host上的veth的設(shè)備。

REDHAT實現(xiàn)AFUS的driver(RHEL DEVIDE MAPPER)

功能 采用AUFS作為docker的container的文件系統(tǒng)，能夠提供如下好處:
1）節(jié)省存儲空間 - 多個container可以共享base image存儲
2）快速部署 - 如果要部署多個container，base image可以避免多次拷貝
3）內(nèi)存更省 - 因為多個container共享base image, 以及OS的disk緩存機(jī)制，多個container中的進(jìn)程命中緩存內(nèi)容的幾率大大增加
4）升級更方便 - 相比于 copy-on-write 類型的FS，base-image也是可以掛載為可writeable的，可以通過更新base image而一次性更新其之上的container
5）允許在不更改base-image的同時修改其目錄中的文件 - 所有寫操作都發(fā)生在最上層的writeable層中，這樣可以大大增加base image能共享的文件內(nèi)容。
以上5條 1-3 條可以通過 copy-on-write 的FS實現(xiàn), 4可以利用其他的union mount方式實現(xiàn), 5只有AUFS實現(xiàn)的很好。這也是為什么Docker一開始就建立在AUFS之上。

AUFS工作過程：
1.啟動：bootfs+rootfs
bootfs (boot file system) 主要包含 bootloader 和 kernel, bootloader主要是引導(dǎo)加載kernel, 當(dāng)boot成功后 kernel 被加載到內(nèi)存中后 bootfs就被umount了。
rootfs (root file system) 包含的就是典型 Linux 系統(tǒng)中的 /dev, /proc,/bin, /etc 等標(biāo)準(zhǔn)目錄和文件。
2.典型的Linux在啟動后，首先將 rootfs 設(shè)置為 readonly, 進(jìn)行一系列檢查, 然后將其切換為 "readwrite" 供用戶使用。在Docker中，初始化時也是將 rootfs 以readonly方式加載并檢查，然而接下來利用 union mount 的方式將一個 readwrite 文件系統(tǒng)掛載在 readonly 的rootfs之上，并且允許再次將下層的 FS(file system) 設(shè)定為readonly 并且向上疊加, 這樣一組readonly和一個writeable的結(jié)構(gòu)構(gòu)成一個container的運行時態(tài), 每一個FS被稱作一個FS層。
3.得益于AUFS的特性, 每一個對readonly層文件/目錄的修改都只會存在于上層的writeable層中。這樣由于不存在競爭, 多個container可以共享readonly的layer。 所以docker將readonly的層稱作 "image" - 對于container而言整個rootfs都是read-write的，但事實上所有的修改都寫入最上層的writeable層中, image不保存用戶狀態(tài)，可以用于模板、重建和復(fù)制。

用戶每次向Git服務(wù)器的push提交都會通知給Jenkins(基于Java開發(fā)的一種持續(xù)集成工具)，Jenkins觸發(fā)build。Maven(是一個采用Java編寫的開源項目管理工具，我們最常用的就是該工具的構(gòu)建功能)構(gòu)建所有的相關(guān)代碼，包括Docker鏡像。
Maven會把完成的鏡像推送到私有的Registry保存
最后Jenkins會觸發(fā)Docker Registry pull下載鏡像到宿主機(jī)本地，并自動啟動應(yīng)用容器。

k8s是一個容器集群管理系統(tǒng)，其提供應(yīng)用部署、維護(hù)、 擴(kuò)展機(jī)制等功能，利用 Kubernetes 能方便地管理跨機(jī)器運行容器化的應(yīng)用。其架構(gòu)圖如下：

Labels 是用于區(qū)分 Pod、Service、Replication Controller 的 key/value 鍵值對

master 包含Replication Controller，API Server

Replication Controller：
會確保 Kubernetes 集群中指定的 pod 副本 (replicas) 在運行， 即使在節(jié)點出錯時。通過修改 Replication Controller 的副本 (replicas) 數(shù)量來水平擴(kuò)展或者縮小運行的pods，一個一個地替換pods來 rolling updates 服務(wù)，labels維度的Multiple release tracks

API Server 的主要聲明，包括 Pod Registry、Controller Registry、Service Registry、Endpoint Registry、Minion Registry、Binding Registry、RESTStorage 以及 Client

Minion Registry 負(fù)責(zé)跟蹤 Kubernetes 集群中有多少 Minion(Host)：可以對 Minion Registry Create、Get、List、Delete
Pod Registry 負(fù)責(zé)跟蹤 Kubernetes 集群中有多少 Pod 在運行，以及這些 Pod 跟 Minion 是如何的映射關(guān)系，對 Pod 進(jìn)行 Create、Get、List、Update、Delete 操作。
……
Endpoints Registry 負(fù)責(zé)收集 Service 的 endpoint，比如 Name："mysql"，Endpoints: ["10.10.1.1:1909"，"10.10.2.2:8834"]，Create、Get、List、Update、Delete 以及 watch
Binding Registry 綁定的 Pod 被綁定到一個 host
Scheduler 收集和分析當(dāng)前 Kubernetes 集群中所有 Minion 節(jié)點的資源 (內(nèi)存、CPU) 負(fù)載情況，然后依此分發(fā)新建的 Pod 到 Kubernetes 集群中可用的節(jié)點

Kubelet
是 Kubernetes 集群中每個 Minion 和 Master API Server 的連接點，Kubelet 運行在每個 Minion 上，是 Master API Server 和 Minion 之間的橋梁，接收 Master API Server 分配給它的 commands 和 work，與持久性鍵值存儲 etcd、file、server 和 http 進(jìn)行交互，讀取配置信息。Kubelet 的主要工作是管理 Pod 和容器的生命周期，其包括 Docker Client、Root Directory、Pod Workers、Etcd Client、Cadvisor Client 以及 Health Checker 組件

Proxy
是為了解決外部網(wǎng)絡(luò)能夠訪問跨機(jī)器集群中容器提供的應(yīng)用服務(wù)而設(shè)計的，從上圖 3-3 可知 Proxy 服務(wù)也運行在每個 Minion 上。Proxy 提供 TCP/UDP sockets 的 proxy，每創(chuàng)建一種 Service，Proxy 主要從 etcd 獲取 Services 和 Endpoints 的配置信息，或者也可以從 file 獲取，然后根據(jù)配置信息在 Minion 上啟動一個 Proxy 的進(jìn)程并監(jiān)聽相應(yīng)的服務(wù)端口，當(dāng)外部請求發(fā)生時，Proxy 會根據(jù) Load Balancer 將請求分發(fā)到后端正確的容器處理。

交互：

http://tiewei.github.io/cloud...

公司云架構(gòu)圖：

靜態(tài)容器
固定可訪問IP,不能動態(tài)漂移，容器中無代碼，擴(kuò)容較快，輕量虛擬機(jī)，支持共享卷/塊設(shè)備，日志收集與物理機(jī)一樣。

有狀態(tài)容器
k8s的statefulstes模型，可以較好彈性伸縮，可以動態(tài)漂移，有代碼，擴(kuò)容很快，支持共享卷/塊設(shè)備（帶云盤），固定ip。適用于對程序數(shù)據(jù)有持久化需求的服務(wù)。

無狀態(tài)容器
k8s的deployment模型，開箱即用，可以動態(tài)漂移，急速擴(kuò)容，彈性伸縮極好，只支持共享卷（ceph這種網(wǎng)絡(luò)分布式磁盤），日志遠(yuǎn)程收集，容器名和ip不固定，適用于無狀態(tài)微服務(wù)。只支持云平臺變更（直接的上線系統(tǒng)不行），不掛載云盤

小的放ceph,大的物理機(jī)映射=>網(wǎng)絡(luò)抖動全換成本地磁盤（無論日志還是數(shù)據(jù)，數(shù)據(jù)需要多帶帶遷移，兩種方案都可以）

docker的虛擬網(wǎng)絡(luò)很多種實現(xiàn)，原生或者插件，一般原生的overlay用的較多
sdn overlay網(wǎng)絡(luò) 穩(wěn)定性差（ip不受限制，因此漂移也不受限制） =》物理網(wǎng)絡(luò)（ip受限于tor[交換機(jī)]的網(wǎng)絡(luò)分配，ip只能tor切換，擴(kuò)容后資源不均衡）
流量到LB后，若采取sdn，會到sdn中心節(jié)點，虛擬ip和物理ip的映射，找到物理ip的宿主機(jī)器，宿主機(jī)器通過overlay與docker通信
若物理網(wǎng)絡(luò)，直接到docker，docker的ip就是分配的物理ip。漂移受tor的影響指的是在ip不變的情況下漂移。ip變化會導(dǎo)致日志等問題

物理網(wǎng)絡(luò)
容器ip2直接到物理機(jī)（ip1,ip2=》mac1。物理機(jī)再轉(zhuǎn)發(fā)給ip

docker虛擬網(wǎng)絡(luò)原理
1.同host：bridge的ip模式為例
創(chuàng)建虛擬網(wǎng)卡。同一網(wǎng)卡之間都可以互相通信
不同網(wǎng)卡之間即使配了ip路由也會隔離，用的iptable的drop
與外網(wǎng)：先默認(rèn)連docker0，如果網(wǎng)橋 docker0 收到來自 172.17.0.0/16 網(wǎng)段的外出包，把它交給 MASQUERADE 處理（iptable NAT）。而 MASQUERADE 的處理方式是將包的源地址替換成 host 的地址發(fā)送出去，即做了一次網(wǎng)絡(luò)地址轉(zhuǎn)換（NAT）
外網(wǎng)反向：ip:port（不同虛擬ip綁定不同端口），docker-proxy監(jiān)聽所有port,換ip1發(fā)給docker0,與ip1通信

2.跨主機(jī)overlay
Docerk overlay 網(wǎng)絡(luò)需要一個 key-value 數(shù)據(jù)庫用于保存網(wǎng)絡(luò)狀態(tài)信息，包括 Network、Endpoint、IP 等。Consul、Etcd 和 ZooKeeper 都是 Docker 支持的 key-vlaue 軟件，我們這里使用 Consul。
不同host:基于VxLAN。VxLAN 可將二層數(shù)據(jù)封裝到 UDP 進(jìn)行傳輸，VxLAN 提供與 VLAN 相同的以太網(wǎng)二層服務(wù)，但是擁有更強(qiáng)的擴(kuò)展性和靈活性。

外網(wǎng)：為每個創(chuàng)建了eth1可以連接外網(wǎng)。其過程和bridge的docker0訪問外網(wǎng)一樣
host內(nèi)部 br0還是直接endpoint連接著，另外加了一個vxlan設(shè)備，與其他host連接

VXLAN原理
vxlan在二層包上封裝vxlan header放在UDP中發(fā)到VTEP設(shè)備上解封（header中包含24位的ID，同一ID的可以互相通信）

Linux vxlan 創(chuàng)建一個 UDP Socket，默認(rèn)在 8472 端口監(jiān)聽。
接收到 vxlan 包后，解包，然后根據(jù)其中的 vxlan ID 將它轉(zhuǎn)給某個 vxlan interface，然后再通過它所連接的 linux bridge 轉(zhuǎn)給虛機(jī)。
Linux vxlan 在收到虛機(jī)發(fā)來的數(shù)據(jù)包后，將其封裝為多播 UDP 包，從網(wǎng)卡發(fā)出。