摘要：去年換工作后，開始真正在生產(chǎn)環(huán)境中接觸容器與。今天想先談談，我理解的容器是什么，以及為什么它們能火起來。一個容器鏡像的實質就是程序進程加所有運行時環(huán)境及配置依賴的集合。這里再談談我理解的。而，就是目前的容器編排的平臺的事實標準了。

去年換工作后，開始真正在生產(chǎn)環(huán)境中接觸容器與Kubernetes。邊惡補相關知識的同時，也想把學到的內容和自己的理解整理出來。學習的途徑包括k8s官方文檔、書籍、極客時間專欄及網(wǎng)上各種博文。所涉及一些摘抄或描述，大多用自己的理解來組織語言，也就不一一注明出處了。

Kubernetes(簡稱K8S)與容器技術，可以說是近幾年最火熱的技術之一。提起K8S，大家都知道是google開源的容器編排工具。今天想先談談，我理解的容器、K8S是什么，以及為什么它們能火起來。

既然說K8S是一個容器編排的工具，那么要搞清楚K8S是什么，首先得搞清楚，容器是什么，以及為什么要用容器技術。

形象的來說，一個linux容器，實際就是一個進程，還是個被系統(tǒng)欺騙的進程。為什么這么說呢？一個運行在容器里的進程，主要有以下特點：

它被宿主機操作系統(tǒng)隔離了，它看不到宿主機上的其他進程，以為自己就是pid為1的進程

它被宿主機操作系統(tǒng)限制了硬件資源，它能使用的cpu、內存等硬件資源只是宿主機的一部分

在被宿主機操作系統(tǒng)限制了存儲空間，讓這個進程認為宿主機的某個目錄就是系統(tǒng)根目錄

這幾個欺騙進程的技術，就是是容器技術的三板斧，用于資源隔離的namespace，用于資源限制的cgroup,以及用于偽裝進程根目錄的rootfs。這三種技術，都是是早已存在于linux中的，只是docker公司比較創(chuàng)新的把這三種技術整合在一起，并且，提出了容器鏡像及鏡像倉庫等概念，把這個進程及相關的依賴環(huán)境都一起打包成可分發(fā)及重復使用的鏡像文件，方便容器能在不同機器之間移植。這樣，在任何地方，只要能運行docker，就能把容器鏡像跑成一個包含這應用進程及相關依賴環(huán)境的容器實例。

這里用利用K8S官方文檔的圖，簡單說下生產(chǎn)中的場景，看看容器技術能解決什么問題。

左圖是傳統(tǒng)的物理機部署應用方式的方式，可以看到除了一個應用的運行，除了程序本身，離不開應用配置、庫、等等依賴環(huán)境。通常情況下，一個應用的上線，要經(jīng)歷開發(fā)環(huán)境、pre環(huán)境、beta環(huán)境、灰度測試、生產(chǎn)環(huán)境等等不同的基礎環(huán)境。開發(fā)的同學在開發(fā)環(huán)境跑通了代碼，到其他環(huán)境運行時，由于各環(huán)境依賴、配置、安全需求不同，可能會出現(xiàn)各種問題。運維的同學忙著在不同的環(huán)境中統(tǒng)一依賴。不同應用各種語言，各種應用的特殊依賴需求，也造成了CI/CD邏輯復雜，難以統(tǒng)一。

右圖是用了容器技術之后的場景。一個容器鏡像的實質就是程序進程加所有運行時環(huán)境及配置、依賴的集合。只要各個環(huán)境的底層能兼容docker，就能實現(xiàn)所有環(huán)境部署的一致性。開發(fā)同學不用關心生產(chǎn)環(huán)境和開發(fā)環(huán)境的差異可能會導致應用運行問題，運維同學部署一個應用，只要確保容器鏡像能正常運行就好。CI/CD的自動化也相對容易實現(xiàn)很多。從而極大增加開發(fā)效率、應用迭代效率及節(jié)省了運維工作量。

說到這里，不得不說下容器與傳統(tǒng)意義的虛擬機間的對比。其實二者都可以理解為虛擬化，它們最本質的區(qū)別是，容器是操作系統(tǒng)層級的虛擬化，而虛擬機是硬件層級的虛擬化。參看下圖。

由于虛擬機多了一層Guest OS，需要宿主機額外的性能開銷進行硬件虛擬化，同時因為是完整的操作系統(tǒng)，虛擬機鏡像一般動輒大幾G，很難在各環(huán)境間快速傳播，hypervisor層相對Docker Engine也比較重。再看docker容器，實質就是宿主機上跑的一個進程，只不過通過docker與其他進程隔離開來。簡單的說，敏捷和高效，是容器相比虛擬機最大的優(yōu)勢，當然也有劣勢，由于容器只是操作系統(tǒng)級別的隔離，不同容器間隔離的不夠徹底。

簡單說完了docker的理解，那么Kubernetes又是什么，它解決了哪些問題呢，為啥現(xiàn)在提容器技術必提k8s呢。這里再談談我理解的Why K8S。

回到實際的場景來，假如你已經(jīng)開始用docker鏡像來打包應用，可以方便的進行分發(fā)和部署，不用去考慮不同環(huán)境的差異。但是不是還感覺還少了點什么？

因為正常的實際業(yè)務系統(tǒng)，不是應用能部署，能運行起來就完事了，還要考慮應用容器的訪問、水平伸縮、監(jiān)控、安全、備份、容災等等因素。而對于一個完整的業(yè)務系統(tǒng)來說，也不是單個應用就能搞定的，還要考慮的是各應用間的關系，及應用運行的形態(tài)。比如一個web業(yè)務，可能需要web服務器、緩存系統(tǒng)、數(shù)據(jù)庫等多個應用。容器化部署后，它們可能部署在不同宿主機的不同容器中，相互間的訪問要怎么實現(xiàn)，這就涉及到容器間訪問關系的處理。再比如，有個優(yōu)化緩存的應用也跑在容器里，只需要定期運行容器實例執(zhí)行優(yōu)化任務，執(zhí)行完畢就終止容器，這就需要處理不同容器應用的運行形態(tài)問題。類似上述這些對容器應用及容器間關系進行管理，就是所謂的容器編排及調度。而Kubernetes，就是目前的容器編排的平臺的事實標準了。

那么，具體來說，K8S到底能做哪些事呢。

在官方文檔中，對K8S功能的描述如下

Kubernetes 滿足了生產(chǎn)中運行應用程序的許多常見的需求，例如：
Pod提供了一種復合的應用容器模型,
掛載外部存儲,
Secret管理,
應用健康檢查,
副本應用實例,
橫向自動擴縮容,
服務發(fā)現(xiàn),
負載均衡,
滾動更新,
資源監(jiān)測,
日志采集和存儲,
支持自檢和調試,
認證和鑒權.

從這些功能介紹可以看出，K8S已很類似一個云平臺了，可以完全能滿足生產(chǎn)級別的容器應用管理需求。下面是一張最簡單的K8S系統(tǒng)示意圖：

K8S集群由一個主節(jié)點（master節(jié)點）及多個工作節(jié)點（node節(jié)點）構成，開發(fā)者提交應用容器鏡像，并將鏡像運行的數(shù)量、方法等通過描述文件提交給K8S master節(jié)點，K8S master節(jié)點或根據(jù)集群整體情況，將應用按照需求部署在工作節(jié)點中。對于開發(fā)者來說，利用K8S可以方便的部署程序，不用關心基礎設施，而對于運維人員來說，工作重心從維護具體應用，轉變?yōu)榫S護K8S集群。而且，不管是開發(fā)者還是運維人員，都不用關心應用具體部署在哪個節(jié)點，K8S會自動判斷搞定一切。相比于傳統(tǒng)的應用部署方式，有沒有覺得K8S很棒棒？

在容器編排這個概念出現(xiàn)的時候，Kubernetes并不是唯一的一個容器編排工具，主流的工具還有Docker公司原生的swarm和Apache基金會的mesos，為什么K8S能笑到最后，成為容器編排的事實標準呢？我理解K8S對比它們有兩個最大不同點：（這里不對swarm和mesos做詳細介紹了，實際也確實沒怎么玩過）

K8S對容器又做了一層抽象，也就是POD。
不同于與其他兩個工具，K8S管理的原子對象，其實并不是容器，而是POD。按照官方文檔的定義，一個POD，是由一個或多個共享存儲及網(wǎng)絡的容器，以及描述怎么運行這些容器的集合，所以，POD實際是一個抽象的概念。k8s對容器的所有操作，比如動態(tài)伸縮、監(jiān)控等，實際上都是對pod的管理。那這層抽象的好處是什么呢？
上面有提到過，容器實質就是被特殊處理的進程。想像一個web業(yè)務，web應用進程輸出的日志需要被大數(shù)據(jù)agent進程處理。這個業(yè)務如果想容器化，通常有兩個做法。一是分別起來兩個容器，掛載宿主機同一個目錄來存放日志。另一種是起一個操作系統(tǒng)級別的容器或supervisord容器作為enterpoint，來管理web服務和agent進程。前一種方式，這個兩個容器就被框在這臺宿主機上了，要實現(xiàn)業(yè)務實例橫向擴縮容，要考慮兩個容器的運行情況和存儲掛載，邏輯比較復雜。后一種方式，你要為每個容器再額外開一個supervisord進程，更重要的是，由于entrypoint是supervisord進程，web應用和大數(shù)據(jù)agent對docker來說，都是不可見的。即使nginx出錯頻繁重啟，只要supervisord還活著，Docker就認為這個容器是正常的。

我們再來看看，使用了pod這個概念以后，有什么變化。一個pod里面同時起了web服務進程和大數(shù)據(jù)agent兩個容器實例，首先，pod里的容器實例是共享存儲和網(wǎng)絡namespace的，也就是說，這兩進程的存儲數(shù)據(jù)是直接共享的，不需要額外的掛載動作。其次，這個pod是作為一個整體被k8s管理著的，k8s會監(jiān)控pod里每個容器的狀態(tài)，并根據(jù)策略在有問題時進行自動干預。從這個意義上說，pod才更類似傳統(tǒng)的虛擬機。

聲明式API
第二點也是比較重要的方面，是K8S的聲明式api(貌似swarm的新版也支持了，同樣沒玩過就不細說了)。什么是聲明式API呢，可以參考上面系統(tǒng)圖中的描述文件。比如要我需要集群中跑10個web服務容器，傳統(tǒng)的命令式API是一步步調用命令構建出容器。而使用聲明式api，只要告訴K8S我要10個web容器，K8S就會自動將web集群實例數(shù)維持在10個，并且，在某個pod出問題退出時，K8S會自動重新拉起新pod，使集群始終保持10個pod實例在跑。這就使得管理集群變得很簡單，只要通過配置文件描述出希望的集群狀態(tài)，而不用去關注中間的實現(xiàn)過程。

最后，總結一下：
Why Dokcer： 用容器技術跑應用，相比原來的物理機及虛擬機更高效、輕量、省資源，同時大大方便了不同環(huán)境下的應用部署及分發(fā)。
Why Kubernetes：生產(chǎn)集群光跑容器還不夠，還要對容器應用作為一個業(yè)務系統(tǒng)集群進行編排及管理，而K8S的一些優(yōu)勢使得它成為目前容器集群編排管理工具的事實標準。

最后的最后再多提一點，實際上，容器技術不止Docker公司一家在做，Kubernetes也不是只能管理Docker容器。只是，無論從市場份額、應用性還是開發(fā)社區(qū)的熱度來說，它們都是目前容器技術最主流的解決方案，就生產(chǎn)環(huán)境來說，目前基本沒有必要去考慮其他的容器技術了。