摘要：執行容器內部運行的執行工作作為容器的執行驅動，負責創建容器運行命名空間，負責容器資源使用的統計與限制，負責容器內部進程的真正運行等。典型的在啟動后，首先將設置為進行一系列檢查然后將其切換為供用戶使用。

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

容器發展，詳見上面提到的文章

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

缺點

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

優點：

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

Image 一個包含運行環境的只讀 模板

Container 鏡像的運行態，docker利 用容器運行應用

Registry 存儲容器鏡像的倉庫

Dockerfile 包含構建鏡像一系列命令 和參數的腳本

Docker Daemon 可以認為是通過 Docker Server 模塊接受 Docker Client 的請求，并在 Engine 中處理請求，然后根據請求類型，創建出指定的 Job 并運行。 Docker Daemon 運行在 Docker host 上，負責創建、運行、監控容器，構建、存儲鏡像。

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

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

networkdriver 執行容器網絡環境的配置
networkdriver的用途是完成Docker容器網絡環境的配置，其中包括Docker啟動時為Docker環境創建網橋；Docker容器創建時為其創建專屬虛擬網卡設備；以及為Docker容器分配IP、端口并與宿主機做端口映射，設置容器防火墻策略等。

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

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

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

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

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

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

REDHAT實現AFUS的driver(RHEL DEVIDE MAPPER)

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

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

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

k8s是一個容器集群管理系統，其提供應用部署、維護、 擴展機制等功能，利用 Kubernetes 能方便地管理跨機器運行容器化的應用。其架構圖如下：

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

master 包含Replication Controller，API Server

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

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

Minion Registry 負責跟蹤 Kubernetes 集群中有多少 Minion(Host)：可以對 Minion Registry Create、Get、List、Delete
Pod Registry 負責跟蹤 Kubernetes 集群中有多少 Pod 在運行，以及這些 Pod 跟 Minion 是如何的映射關系，對 Pod 進行 Create、Get、List、Update、Delete 操作。
……
Endpoints Registry 負責收集 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 收集和分析當前 Kubernetes 集群中所有 Minion 節點的資源 (內存、CPU) 負載情況，然后依此分發新建的 Pod 到 Kubernetes 集群中可用的節點

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

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

交互：

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

公司云架構圖：

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

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

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

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

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

物理網絡
容器ip2直接到物理機（ip1,ip2=》mac1。物理機再轉發給ip

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

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

外網：為每個創建了eth1可以連接外網。其過程和bridge的docker0訪問外網一樣
host內部 br0還是直接endpoint連接著，另外加了一個vxlan設備，與其他host連接

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

Linux vxlan 創建一個 UDP Socket，默認在 8472 端口監聽。
接收到 vxlan 包后，解包，然后根據其中的 vxlan ID 將它轉給某個 vxlan interface，然后再通過它所連接的 linux bridge 轉給虛機。
Linux vxlan 在收到虛機發來的數據包后，將其封裝為多播 UDP 包，從網卡發出。