我們?yōu)槭裁词褂萌萜鳎?/p>

我們?yōu)槭裁词褂锰摂M機（云主機）硕舆？ 為什么使用物理機咽笼？ 這一系列的問題并沒有一個統(tǒng)一的標(biāo)準(zhǔn)答案招刨。因為以上幾類技術(shù)棧都有自身最適用的場景，在最佳實踐之下灵份，它們分別都是不可替代的仁堪。 原本沒有虛擬機，所有類型的業(yè)務(wù)應(yīng)用都直接跑在物理主機上面填渠，計算資源和存儲資源都難于增減弦聂，要么就是一直不夠用，要么就一直是把過剩的資源浪費掉氛什，所以后來我們看到大家越來越多得使用虛擬機（或云主機）莺葫，物理機的使用場景被極大地壓縮到了像數(shù)據(jù)庫系統(tǒng)這樣的特殊類型應(yīng)用上面。

原本也沒有容器屉更，我們把大部分的業(yè)務(wù)應(yīng)用跑在虛擬機（或云主機）上面徙融，把少部分特殊類型的應(yīng)用仍然跑在物理主機上面。但現(xiàn)在所有的虛擬機技術(shù)方案瑰谜，都無法回避兩個主要的問題，一個問題是虛擬化Hypervisor管理軟件本身的資源消耗與磁盤IO性能降低树绩，另一個是虛擬機仍然還是一個獨立的操作系統(tǒng)萨脑，對很多類型的業(yè)務(wù)應(yīng)用來說都顯得太重了，導(dǎo)致我們在處理虛擬機的擴(kuò)縮容與配置管理工作時效率低下饺饭。所以渤早，我們后來發(fā)現(xiàn)了容器的好處，所有業(yè)務(wù)應(yīng)用可以直接運行在物理主機的操作系統(tǒng)之上瘫俊，可以直接讀寫磁盤鹊杖，應(yīng)用之間通過計算悴灵、存儲和網(wǎng)絡(luò)資源的命名空間進(jìn)行隔離，為每個應(yīng)用形成一個邏輯上獨立的“容器操作系統(tǒng)”骂蓖。除此之外积瞒，容器技術(shù)還有以下優(yōu)點：簡化部署、多環(huán)境支持登下、快速啟動茫孔、服務(wù)編排、易于遷移被芳。

容器技術(shù)的一些缺點：仍然不能做到徹底的安全隔離缰贝，技術(shù)棧復(fù)雜度飚升，尤其是在應(yīng)用了容器集群技術(shù)之后畔濒。所以如果只是小規(guī)模的使用剩晴，做實驗或測試是可以的，上生產(chǎn)環(huán)境需要三思而后行侵状。

容器與容器集群技術(shù)的演進(jìn)

容器技術(shù)的演進(jìn)路線

注：上圖取自《容器技術(shù)及其應(yīng)用白皮書[v1.0]》

容器集群技術(shù)的演進(jìn)

上圖描述了容器技術(shù)的演進(jìn)赞弥，此后的近三年來的容器技術(shù)演進(jìn)發(fā)展為主要是以容器集群技術(shù)為中心，如下所示壹将。

器的運行原理與基本組件

Docker容器主要基于以下三個關(guān)鍵技術(shù)實現(xiàn)的：– Namespaces – Cgroups技術(shù) – Image鏡像

容器引擎容器引擎（Engine）或者容器運行時（Runtime）是容器系統(tǒng)的核心嗤攻，也是很多人使用“容器”這個詞語的指代對象。容器引擎能夠創(chuàng)建和運行容器诽俯，而容器的定義一般是以文本方式保存的妇菱，比如 Dockerfile。

Docker Engine ：目前最流行的容器引擎暴区，也是業(yè)界的事實標(biāo)準(zhǔn)闯团。Rkt：CoreOS 團(tuán)隊推出的容器引擎，有著更加簡單的架構(gòu)仙粱，一直作為 Docker 的直接競爭對手存在房交，是 kubernetes 調(diào)度系統(tǒng)支持的容器引擎之一。containerd：這個新的Daemon是對Docker內(nèi)部組件的一個重構(gòu)以便支持OCI規(guī)范伐割，containerd 主要職責(zé)是鏡像管理（鏡像候味、元信息等）、容器執(zhí)行（調(diào)用最終運行時組件執(zhí)行）隔心，向上為 Docker Daemon 提供了 gRPC 接口白群，向下通過 containerd-shim 結(jié)合 runC，使得引擎可以獨立升級硬霍。docker-shim：shim 通過調(diào)用 containerd 啟動 docker 容器帜慢，所以每啟動一個容器都會起一個新的docker-shim進(jìn)程。docker-shim是通過指定的三個參數(shù)：容器id，boundle目錄和運行時（默認(rèn)為runC）來調(diào)用runC的api創(chuàng)建一個容器粱玲。runC ：是 Docker 按照開放容器格式標(biāo)準(zhǔn)（OCF, Open Container Format）制定的一種具體實現(xiàn)躬柬，實現(xiàn)了容器啟停、資源隔離等功能抽减，所以是可以不用通過 docker 引擎直接使用runC運行一個容器的允青。也支持通過改變參數(shù)配置，選擇使用其他的容器運行時實現(xiàn)胯甩。RunC可以說是各大CaaS廠商間合縱連橫昧廷、相互妥協(xié)的結(jié)果，注：RunC在各個CaaS廠商的推動下在生產(chǎn)環(huán)境得到廣泛的應(yīng)用偎箫。Kubernetes目前基本只支持RunC容器木柬，對于Docker超出其容器抽象層之外的功能，一概不支持淹办。同樣眉枕，Mesos也通過其Unified Containerizer只支持RunC容器，目前還支持Docker怜森，但是未來的規(guī)劃是只支持Unified Containerizer速挑。CF也通過Garden只支持RunC，不支持Docker超出RunC之前的功能副硅。

為什么在容器的啟動或運行過程中需要一個 docker-containerd-shim 進(jìn)程呢姥宝？其目的有如下幾點： – 它允許容器運行時(即 runC)在啟動容器之后退出，簡單說就是不必為每個容器一直運行一個容器運行時(runC) – 即使在 containerd 和 dockerd 都掛掉的情況下恐疲，容器的標(biāo)準(zhǔn) IO 和其它的文件描述符也都是可用的 – 向 containerd 報告容器的退出狀態(tài)

rkt與containerd的區(qū)別是什么腊满？一個主要的不同之處是，rkt作為一個無守護(hù)進(jìn)程的工具（daemonless tool）培己，可以用來在生產(chǎn)環(huán)境中碳蛋，集成和執(zhí)行那些特別的有關(guān)鍵用途的容器。舉個例子省咨，CoreOS Container Linux使用rkt來以一個容器鏡像的方式執(zhí)行Kubernetes的agent肃弟，即kublet。更多的例子包括在Kubernetes生態(tài)環(huán)境中零蓉，使用rkt來用一種容器化的方式掛載volume笤受。這也意味著rkt能被集成進(jìn)并和Linux的init系統(tǒng)一起使用，因為rkt自己并不是一個init系統(tǒng)敌蜂。kubernets支持容器進(jìn)行部署感论，其所支持的容器不只是僅僅局限于docker，CoreOS的rkt也是容器玩家之一紊册，雖然跟docker比起來還是明顯處于絕對下風(fēng)，但有競爭總要好過沒有。

容器編排和管理系統(tǒng)

容器是很輕量化的技術(shù)囊陡，相對于物理機和虛機而言芳绩，這意味著在等量資源的基礎(chǔ)上能創(chuàng)建出更多的容器實例出來。一旦面對著分布在多臺主機上且擁有數(shù)百套容器的大規(guī)模應(yīng)用程序時撞反，傳統(tǒng)的或單機的容器管理解決方案就會變得力不從心妥色。另一方面，由于為微服務(wù)提供了越來越完善的原生支持遏片，在一個容器集群中的容器粒度越來越小嘹害、數(shù)量越來越多。在這種情況下吮便，容器或微服務(wù)都需要接受管理并有序接入外部環(huán)境笔呀，從而實現(xiàn)調(diào)度、負(fù)載均衡以及分配等任務(wù)髓需。 簡單而高效地管理快速增漲的容器實例许师，自然成了一個容器編排系統(tǒng)的主要任務(wù)。

容器集群管理工具能在一組服務(wù)器上管理多容器組合成的應(yīng)用僚匆，每個應(yīng)用集群在容器編排工具看來是一個部署或管理實體微渠，容器集群管理工具全方位為應(yīng)用集群實現(xiàn)自動化，包括應(yīng)用實例部署咧擂、應(yīng)用更新逞盆、健康檢查、彈性伸縮松申、自動容錯等等云芦。?容器編排和管理系統(tǒng)的分層結(jié)構(gòu)圖

容器編排和管理系統(tǒng)界的主要選手– Kubernetes：Google 開源的容器管理系統(tǒng)，起源于內(nèi)部歷史悠久的 Borg 系統(tǒng)攻臀。因為其豐富的功能被多家公司使用焕数，其發(fā)展路線注重規(guī)范的標(biāo)準(zhǔn)化和廠商“中立”，支持底層不同的容器運行時和引擎（比如 Rkt）刨啸，逐漸解除對 Docker 的依賴堡赔。Kubernetes的核心是如何解決自動部署，擴(kuò)展和管理容器化（containerized）應(yīng)用程序设联。目前該項目在github上Star數(shù)量為43k善已。 – Docker Swarm： 在 Docker 1.2 版本后將 Swarm 集成在了 Docker 引擎中。用戶能夠輕松快速搭建出來 docker 容器集群离例，幾乎完全兼容 docker API 的特性换团。目前該項目在github上Star數(shù)量為5.3k。 – Mesosphere Marathon：Apache Mesos 的調(diào)度框架目標(biāo)是成為數(shù)據(jù)中心的操作系統(tǒng)宫蛆，完全接管數(shù)據(jù)中心的管理工作艘包。Mesos理念是數(shù)據(jù)中心操作系統(tǒng)（DCOS）的猛，為了解決IaaS層的網(wǎng)絡(luò)、計算和存儲問題想虎，所以Mesos的核心是解決物理資源層的問題卦尊。Marathon是為Mesosphere DC/OS和Apache Mesos設(shè)計的容器編排平臺。目前該項目在github上Star數(shù)量為3.7k舌厨。

注：國內(nèi)外有很多公司在從事基于上面三個基礎(chǔ)技術(shù)平臺的創(chuàng)新創(chuàng)業(yè)岂却，為企業(yè)提供增值服務(wù)，其中做得不錯的如Rancher裙椭，其產(chǎn)品可以同時兼容 kubernetes躏哩、mesos 和 swarm 集群系統(tǒng)，此外還有很多商用解決方案揉燃，如OpenShift扫尺。

中國市場的表現(xiàn)在中國市場，2017 年 6 月 Kubernetes 中國社區(qū) K8SMeetup 曾組織了國內(nèi)首個針對中國容器開發(fā)者和企業(yè)用戶的調(diào)研你雌。近 100 個受訪用戶和企業(yè)中給我們帶來了關(guān)于 Kubernetes 在中國落地狀況的一手調(diào)查資料顯示： – 在容器編排工具中器联，Kubernetes占據(jù)了70%市場份額，此外是Mesos約11%婿崭，Swarm不足7%； – 在中國受訪企業(yè)用戶中氓栈，Kubernetes 平臺上運行的應(yīng)用類型非常廣泛渣磷，幾乎包括了除hadoop大數(shù)據(jù)技術(shù)棧以外的各種類型應(yīng)用； – 中國受訪企業(yè)運行 Kubernetes 的底層環(huán)境分布顯示授瘦，29%的客戶使用裸機直接運行容器集群醋界，而在包括OpenStack、VMWare提完、阿里云和騰訊云在內(nèi)的泛云平臺上運行容器集群服務(wù)的客戶占到了60%形纺；

關(guān)于CNCF基金會

主要的容器技術(shù)廠商（包括 Docker、CoreOS徒欣、Google逐样、Mesosphere、RedHat 等）成立了 Cloud Native Computing Foundation (CNCF) 打肝。?CNCF對云原生的定義是：– 云原生技術(shù)幫助公司和機構(gòu)在公有云脂新、私有云和混合云等新型動態(tài)環(huán)境中，構(gòu)建和運行可彈性擴(kuò)展的應(yīng)用粗梭。云原生的代表技術(shù)包括容器争便、服務(wù)網(wǎng)格、微服務(wù)断医、不可變基礎(chǔ)設(shè)施和聲明式API滞乙。 – 這些技術(shù)能夠構(gòu)建容錯性好奏纪、易于管理和便于觀察的松耦合系統(tǒng)。結(jié)合可靠的自動化手段酷宵，云原生技術(shù)可以使開發(fā)者輕松地對系統(tǒng)進(jìn)行頻繁并可預(yù)測的重大變更亥贸。 – 云原生計算基金會（CNCF）致力于培育和維護(hù)一個廠商中立的開源生態(tài)系統(tǒng)，來推廣云原生技術(shù)浇垦。我們通過將最前沿的模式普惠，讓這些創(chuàng)新為大眾所用荣挨。

下圖是截止2018.11的CNCF部分云原生項目列表：

云原生以容器為核心技術(shù)男韧，分為運行時（Runtime）和 Orchestration 兩層，Runtime 負(fù)責(zé)容器的計算默垄、存儲此虑、網(wǎng)絡(luò)；Orchestration 負(fù)責(zé)容器集群的調(diào)度口锭、服務(wù)發(fā)現(xiàn)和資源管理朦前。注：上圖只截取了原圖的核心組件部分，完整圖表詳見https://landscape.cncf.io/images/landscape.png

Kubernetes的核心組件

Kubernetes的核心組件示意圖

etcd是Kubernetes的存儲狀態(tài)的分布式數(shù)據(jù)庫鹃操，采用raft協(xié)議作為一致性算法（raft協(xié)議原理可參見一個動畫演示http://thesecretlivesofdata.com/raft/）韭寸。API Server組件主要提供認(rèn)證與授權(quán)、運行一組準(zhǔn)入控制器以及管理API版本等功能荆隘，通過REST API向外提供服務(wù)恩伺，允許各類組件創(chuàng)建、讀取椰拒、寫入晶渠、更新和監(jiān)視資源（Pod, Deployment, Service等）。Scheduler組件燃观，根據(jù)集群資源和狀態(tài)選擇合適的節(jié)點用于創(chuàng)建Pod褒脯。Controller Manager組件，實現(xiàn)ReplicaSet的行為缆毁。Kubelet組件番川，負(fù)責(zé)監(jiān)視綁定到其所在節(jié)點的一組Pod，并且能實時返回這些Pod的運行狀態(tài)积锅。創(chuàng)建Pod的整個流程時序圖

容器網(wǎng)絡(luò)

容器的大規(guī)模使用爽彤，也對網(wǎng)絡(luò)提供了更高的要求。網(wǎng)絡(luò)的不靈活也是很多企業(yè)的短板缚陷，目前也有很多公司和項目在嘗試解決這些問題适篙，希望提出容器時代的網(wǎng)絡(luò)方案。 Docker采用插件化的網(wǎng)絡(luò)模式箫爷，默認(rèn)提供bridge嚷节、host聂儒、none、overlay硫痰、macvlan和Network plugins這幾種網(wǎng)絡(luò)模式衩婚，運行容器時可以通過–network參數(shù)設(shè)置具體使用那一種模式。

– bridge：這是Docker默認(rèn)的網(wǎng)絡(luò)驅(qū)動效斑，此模式會為每一個容器分配Network Namespace和設(shè)置IP等非春，并將容器連接到一個虛擬網(wǎng)橋上。如果未指定網(wǎng)絡(luò)驅(qū)動缓屠，這默認(rèn)使用此驅(qū)動奇昙。 – host：此網(wǎng)絡(luò)驅(qū)動直接使用宿主機的網(wǎng)絡(luò)。

– none：此驅(qū)動不構(gòu)造網(wǎng)絡(luò)環(huán)境敌完。采用了none 網(wǎng)絡(luò)驅(qū)動储耐，那么就只能使用loopback網(wǎng)絡(luò)設(shè)備，容器只能使用127.0.0.1的本機網(wǎng)絡(luò)滨溉。

– overlay：此網(wǎng)絡(luò)驅(qū)動可以使多個Docker daemons連接在一起什湘，并能夠使用swarm服務(wù)之間進(jìn)行通訊。也可以使用overlay網(wǎng)絡(luò)進(jìn)行swarm服務(wù)和容器之間晦攒、容器之間進(jìn)行通訊闽撤，

– macvlan：此網(wǎng)絡(luò)允許為容器指定一個MAC地址，允許容器作為網(wǎng)絡(luò)中的物理設(shè)備勤家，這樣Docker daemon就可以通過MAC地址進(jìn)行訪問的路由腹尖。對于希望直接連接網(wǎng)絡(luò)網(wǎng)絡(luò)的遺留應(yīng)用，這種網(wǎng)絡(luò)驅(qū)動有時可能是最好的選擇伐脖。

– Network plugins：可以安裝和使用第三方的網(wǎng)絡(luò)插件热幔。可以在Docker Store或第三方供應(yīng)商處獲取這些插件讼庇。

在默認(rèn)情況绎巨，Docker使用bridge網(wǎng)絡(luò)模式。

容器網(wǎng)絡(luò)模型（CNM）

CNM在2015年由Docker引入蠕啄，CNM有IP 地址管理（IPAM）和網(wǎng)絡(luò)插件功能场勤。IPAM插件可以創(chuàng)建IP地址池并分配再来，刪除和釋放容器IP个粱。網(wǎng)絡(luò)插件API用于創(chuàng)建/刪除網(wǎng)絡(luò)茅信，并從網(wǎng)絡(luò)中添加/刪除容器笼平。

容器網(wǎng)絡(luò)接口（CNI）

CNI誕生于2015年4月，由CoreOS公司推出夺饲，CNI是容器中的網(wǎng)絡(luò)系統(tǒng)插件胡陪，它使得類似Kubernetes之類的管理平臺更容易的支持IPAM件舵、SDN或者其它網(wǎng)絡(luò)方案骚秦。CNI實現(xiàn)的基本思想為：Contianer runtime在創(chuàng)建容器時她倘，先創(chuàng)建好network namespace璧微，這在實際操作過程中，首先創(chuàng)建出來的容器是Pause容器硬梁。之后調(diào)用CNI插件為這個netns配置網(wǎng)絡(luò)前硫，最后在啟動容器內(nèi)的進(jìn)程。

CNI Plugin負(fù)責(zé)為容器配置網(wǎng)絡(luò)荧止，包括兩個基本接口： – 配置網(wǎng)絡(luò)：AddNetwork(net NetworkConfig, rt RuntimeConf) (types.Result, error) – 清理網(wǎng)絡(luò)：DelNetwork(net NetworkConfig, rt RuntimeConf) error

每個CNI插件只需實現(xiàn)兩種基本操作：創(chuàng)建網(wǎng)絡(luò)的ADD操作屹电，和刪除網(wǎng)絡(luò)的DEL操作（以及一個可選的VERSION查看版本操作）。所以CNI的實現(xiàn)確實非常簡單罩息，把復(fù)雜的邏輯交給具體的Network Plugin實現(xiàn)嗤详。

Kubernetes CNI 插件

Flannel：CoreOS 開源的網(wǎng)絡(luò)方案，為 kubernetes 設(shè)計瓷炮，它的功能是讓集群中的不同節(jié)點主機創(chuàng)建的Docker容器都具有全集群唯一的虛擬IP地址。Flannel的底層通信協(xié)議的可選余地有很多递宅，比如UDP娘香、VXlan、AWS VPC等等办龄，不同協(xié)議實現(xiàn)下的網(wǎng)絡(luò)通信效率相差較多烘绽，默認(rèn)為使用UDP協(xié)議，部署和管理簡單俐填。目前為止安接，還不支持k8s的Network Policy。Calico：一個純?nèi)龑拥木W(wǎng)絡(luò)解決方案英融，使用 BGP 協(xié)議進(jìn)行路由盏檐，可以集成到 openstack 和 docker。Calico節(jié)點組網(wǎng)可以直接利用數(shù)據(jù)中心的網(wǎng)絡(luò)結(jié)構(gòu)（無論是L2或者L3）驶悟，不需要額外的NAT胡野，隧道或者Overlay Network，網(wǎng)絡(luò)通信性能好痕鳍。Calico基于iptables還提供了豐富而靈活的網(wǎng)絡(luò)Policy硫豆，保證通過各個節(jié)點上的ACLs來提供Workload的多租戶隔離、安全組以及其他可達(dá)性限制等功能笼呆。如果企業(yè)生產(chǎn)環(huán)境可以開啟BGP協(xié)議熊响，可以考慮calico bgp方案。不過在現(xiàn)實中的網(wǎng)絡(luò)并不總是支持BGP路由的诗赌，因此Calico也設(shè)計了一種IPIP模式汗茄，使用Overlay的方式來傳輸數(shù)據(jù)。Weave Net：weaveworks 給出的網(wǎng)絡(luò)的方案境肾，使用 vxlan 技術(shù)通過Overlay網(wǎng)絡(luò)實現(xiàn)的剔难， 支持網(wǎng)絡(luò)的隔離和安全胆屿，安裝和使用都比較簡單。Contiv: 思科開源偶宫，兼容CNI模型以及CNM模型非迹，支持 VXLAN 和 VLAN 方案，配置較復(fù)雜纯趋。支持Tenant憎兽，支持租戶隔離，支持多種網(wǎng)絡(luò)模式（L2吵冒、L3纯命、overlay、cisco sdn solution）痹栖。Contiv帶來的方便是用戶可以根據(jù)容器實例IP直接進(jìn)行訪問亿汞。Canal：基于 Flannel 和 Calico 提供 Kubernetes Pod 之間網(wǎng)絡(luò)防火墻的項目。Cilium：利用 Linux 原生技術(shù)提供的網(wǎng)絡(luò)方案揪阿，支持 L7 和 L3疗我、L4 層的訪問策略。Romana：Panic Networks 推出的網(wǎng)絡(luò)開源方案南捂，基于 L3 實現(xiàn)的網(wǎng)絡(luò)連通吴裤，因此沒有 Overlay 網(wǎng)絡(luò)帶來的性能損耗，但是只能通過 IP 網(wǎng)段規(guī)劃來實現(xiàn)租戶劃分溺健。從理論上說麦牺，這些CNI工具的網(wǎng)絡(luò)速度應(yīng)該可以分為3個速度等級。 最快的是Romana鞭缭、Gateway模式的Flannel剖膳、BGP模式的Calico。 次一級的是IPIP模式的Calico缚去、Swarm的Overlay網(wǎng)絡(luò)潮秘、VxLan模式的Flannel、Fastpath模式的Weave易结。 * 最慢的是UDP模式的Flannel枕荞、Sleeve模式的Weave。

Flannel

UDP封包使用了Flannel自定義的一種包頭協(xié)議搞动，數(shù)據(jù)是在Linux的用戶態(tài)進(jìn)行封包和解包的躏精，因此當(dāng)數(shù)據(jù)進(jìn)入主機后，需要經(jīng)歷兩次內(nèi)核態(tài)到用戶態(tài)的轉(zhuǎn)換鹦肿。網(wǎng)絡(luò)通信效率低且存在不可靠的因素矗烛。VxLAN封包采用的是內(nèi)置在Linux內(nèi)核里的標(biāo)準(zhǔn)協(xié)議，因此雖然它的封包結(jié)構(gòu)比UDP模式復(fù)雜，但由于所有數(shù)據(jù)裝瞭吃、解包過程均在內(nèi)核中完成碌嘀，實際的傳輸速度要比UDP模式快許多。Vxlan方案在做大規(guī)模應(yīng)用時復(fù)雜度會提升歪架，故障定位分析復(fù)雜股冗。Flannel的Gateway模式與Calico速度相當(dāng)，甚至理論上還要快一點和蚪。Flannel的Host-Gateway模式止状，在這種模式下，F(xiàn)lannel通過在各個節(jié)點上的Agent進(jìn)程攒霹，將容器網(wǎng)絡(luò)的路由信息刷到主機的路由表上怯疤，這樣一來所有的主機就都有整個容器網(wǎng)絡(luò)的路由數(shù)據(jù)了。Host-Gateway的方式?jīng)]有引入像Overlay中的額外裝包解包操作催束，完全是普通的網(wǎng)絡(luò)路由機制集峦，它的效率與虛擬機直接的通信相差無幾。Host-Gateway的模式就只能用于二層直接可達(dá)的網(wǎng)絡(luò)抠刺，由于廣播風(fēng)暴的問題少梁，這種網(wǎng)絡(luò)通常是比較小規(guī)模的。路由網(wǎng)絡(luò)對現(xiàn)有網(wǎng)絡(luò)設(shè)備影響比較大矫付，路由器的路由表有空間限制，一般是兩三萬條第焰，而容器的大部分應(yīng)用場景是運行微服務(wù)买优，數(shù)量集很大。Flannel網(wǎng)絡(luò)通信原理示意圖

各CNI網(wǎng)絡(luò)插件的功能對比：

容器存儲

因為容器存活時間很短的特點挺举，容器的狀態(tài)（存儲的數(shù)據(jù)）必須獨立于容器的生命周期杀赢，也因為此，容器的存儲變得非常重要湘纵。 – Ceph：分布式存儲系統(tǒng)脂崔，同時支持塊存儲、文件存儲和對象存儲梧喷，發(fā)展時間很久砌左，穩(wěn)定性也得到了驗證。之前在 OpenStack 社區(qū)被廣泛使用铺敌，目前在容器社區(qū)也是很好的選項汇歹。 – GlusterFS：RedHat 旗下的產(chǎn)品，部署簡單偿凭，擴(kuò)展性強产弹。 – 商業(yè)存儲：DELL EMC，NetApp等 – CSI（Container Storage Interface）：定義云應(yīng)用調(diào)度平臺和各種存儲服務(wù)接口的項目弯囊，核心的目標(biāo)就是存儲 provider 只需要編寫一個 driver痰哨，就能集成到任何的容器平臺上胶果。 – Rook：基于 Ceph 作為后臺存儲技術(shù)，深度集成到 Kubernetes 容器平臺的容器項目斤斧，因為選擇了 Ceph 和 Kubernetes 這兩個都很熱門的技術(shù)早抠，并且提供自動部署、管理折欠、擴(kuò)展贝或、升級、遷移锐秦、災(zāi)備和監(jiān)控等功能

Kubernetes支持的存儲類型

awsElasticBlockStoreazureDiskazureFilecephfsconfigMapcsidownwardAPIemptyDirfc (fibre channel)flockergcePersistentDiskgitRepo (deprecated)glusterfshostPathiscsilocalnfspersistentVolumeClaimprojectedportworxVolumequobyterbdscaleIOsecretstorageosvsphereVolumeKubernetes以in-tree plugin的形式來對接不同的存儲系統(tǒng)咪奖，滿足用戶可以根據(jù)自己業(yè)務(wù)的需要使用這些插件給容器提供存儲服務(wù)。同時兼容用戶使用FlexVolume和CSI定制化插件酱床。

一般來說羊赵，Kubernetes中Pod通過如下三種方式來訪問存儲資源： – 直接訪問 – 靜態(tài)provision – 動態(tài)provision（使用StorageClass動態(tài)創(chuàng)建PV）

服務(wù)發(fā)現(xiàn)

容器和微服務(wù)的結(jié)合創(chuàng)造了另外的熱潮，也讓服務(wù)發(fā)現(xiàn)成功了熱門名詞扇谣∶两荩可以輕松擴(kuò)展微服務(wù)的同時，也要有工具來實現(xiàn)服務(wù)之間相互發(fā)現(xiàn)的需求罐寨。 DNS 服務(wù)器監(jiān)視著創(chuàng)建新 Service 的 Kubernetes API靡挥，從而為每一個 Service 創(chuàng)建一組 DNS 記錄。 如果整個集群的 DNS 一直被啟用鸯绿，那么所有的 Pod應(yīng)該能夠自動對 Service 進(jìn)行名稱解析跋破。在技術(shù)實現(xiàn)上是通過kubernetes api監(jiān)視Service資源的變化，并根據(jù)Service的信息生成DNS記錄寫入到etcd中瓶蝴。dns為集群中的Pod提供DNS查詢服務(wù)毒返，而DNS記錄則從etcd中讀取。 – kube-dns：kube-dns是Kubernetes中的一個內(nèi)置插件舷手，目前作為一個獨立的開源項目維護(hù)拧簸。Kubernetes DNS pod 中包括 3 個容器：kube-dns，sidecar男窟，dnsmasq – CoreDNS：CoreDNS是一套靈活且可擴(kuò)展的權(quán)威DNS服務(wù)器盆赤，作為CNCF中的托管的一個項目，自k8s 1.11 版本起被正式作為集群DNS附加選項蝎宇，且在用戶使用kubeadm時默認(rèn)生效弟劲。提供更好的可靠性、靈活性和安全性姥芥，可以選擇使用CoreDNS替換Kubernetes插件kube-dns兔乞。

狀態(tài)數(shù)據(jù)存儲

目前主要有三種工具，大部分的容器管理系統(tǒng)也都是同時可以支持這三種工具。 – etcd：CoreOS 開源的分布式 key-value 存儲庸追，通過 HTTP/HTTPS 協(xié)議提供服務(wù)霍骄。etcd 只是一個 key-value 存儲，默認(rèn)不支持服務(wù)發(fā)現(xiàn)淡溯，需要三方工具來集成读整。kubernetes 默認(rèn)使用 etcd 作為存儲。 – ZooKeeper：Hadoop 的一個子項目咱娶，本來是作為 Hadoop 集群管理的數(shù)據(jù)存儲米间，目前也被應(yīng)用到容器領(lǐng)域，開發(fā)語言是 Java膘侮。 – Consul：HashiCorp 開發(fā)的分布式服務(wù)發(fā)現(xiàn)和配置管理工具

這些工具的主要作用就是保證這個集群的動態(tài)信息能統(tǒng)一保存屈糊，并保證一致性，這樣每個節(jié)點和容器就能正確地獲取到集群當(dāng)前的信息琼了。

健康檢查

Kubernetes提供兩種類型的健康檢查逻锐，支持進(jìn)行三種類型的探測：HTTP、Command和TCP雕薪。 – Readiness探針旨在讓Kubernetes知道您的應(yīng)用何時準(zhǔn)備好其流量服務(wù)昧诱。 Kubernetes確保Readiness探針檢測通過，然后允許服務(wù)將流量發(fā)送到Pod所袁。 如果Readiness探針開始失敗盏档，Kubernetes將停止向該容器發(fā)送流量，直到它通過燥爷。 – Liveness探針讓Kubernetes知道你的應(yīng)用程序是活著還是死了妆丘。 如果你的應(yīng)用程序還活著，那么Kubernetes就不管它了局劲。 如果你的應(yīng)用程序已經(jīng)死了，Kubernetes將刪除Pod并啟動一個新的替換它奶赠。

容器監(jiān)控

我們習(xí)慣于在兩個層次監(jiān)控：應(yīng)用以及運行它們的主機∮闾睿現(xiàn)在由于容器處在中間層，以及 Kubernetes 本身也需要監(jiān)控毅戈，因此有 4 個不同的組件需要監(jiān)控并且搜集度量信息苹丸。

1）cAdvisor + InfluxDB + Grafana：一個簡單的跨多主機的監(jiān)控系統(tǒng)Cadvisor：將數(shù)據(jù)，寫入InfluxDBInfluxDB ：時序數(shù)據(jù)庫苇经，提供數(shù)據(jù)的存儲赘理，存儲在指定的目錄下Grafana ：提供了WEB控制臺，自定義查詢指標(biāo)扇单，從InfluxDB查詢數(shù)據(jù)商模，并展示。

2）Heapster + InfluxDB + Grafana：Heapster是一個收集者，將每個Node上的cAdvisor的數(shù)據(jù)進(jìn)行匯總施流，然后導(dǎo)到InfluxDB响疚，支持從Cluster、Node瞪醋、Pod的各個層面提供詳細(xì)的資源使用情況忿晕。Heapster：在Kubernetes集群中獲取Metrics和事件數(shù)據(jù)，寫入InfluxDB银受，Heapster收集的數(shù)據(jù)比cAdvisor多践盼，而且存儲在InfluxDB的也少。InfluxDB：時序數(shù)據(jù)庫宾巍，提供數(shù)據(jù)的存儲咕幻，存儲在指定的目錄下。Grafana：提供了WEB控制臺蜀漆，自定義查詢指標(biāo)谅河，從InfluxDB查詢數(shù)據(jù)，并展示确丢。

3）Prometheus+Grafana：Prometheus是個集DB绷耍、Graph、Statistics鲜侥、Alert 于一體的監(jiān)控工具褂始。提供多維數(shù)據(jù)模型（時序列數(shù)據(jù)由metric名和一組key/value組成）和在多維度上靈活的查詢語言(PromQl)，提供了很高的寫入和查詢性能描函。對內(nèi)存占用量大崎苗，不依賴分布式存儲，單主節(jié)點工作舀寓，所以不具有高可用性胆数，支持pull/push兩種時序數(shù)據(jù)采集方式。

考慮到Prometheus在擴(kuò)展性和高可用方面的缺點互墓，在超大規(guī)模應(yīng)用時可以考察下thanos這樣的面向解決Prometheus的長時間數(shù)據(jù)存儲與服務(wù)高可用解決方案的開源項目：https://github.com/improbable-eng/thanos

容器集群的四個監(jiān)控層次

鏡像 registry

鏡像 registry 是存儲鏡像的地方必尼，可以方便地在團(tuán)隊、公司或者世界各地分享容器鏡像篡撵，也是運行容器最基本的基礎(chǔ)設(shè)施判莉。 – Docker Registry：Docker 公司提供的開源鏡像服務(wù)器，也是目前最流行的自建 registry 的方案 – Harbor：企業(yè)級的鏡像 registry育谬，提供了權(quán)限控制和圖形界面

每種對應(yīng)技術(shù)幾乎都有自己的基礎(chǔ)鏡像券盅，例如： – https://hub.docker.com/_/java/ （該鏡像仍存在，但已經(jīng)很長時間未更新） – https://hub.docker.com/_/python/ – https://hub.docker.com/_/nginx/ – https://hub.docker.com/_/alpine/ 一個常用的基礎(chǔ)鏡像Alpine Linux（體積小于5MB）