Why Kubernetes ，我所理解的docker與k8s

---

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

---

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

Why Docker

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

形象的來講，一個linux容器，實際就是一個進程，仍是個被系統欺騙的進程。爲何這麼說呢？一個運行在容器裏的進程，主要有如下特色：

• 它被宿主機操做系統隔離了，它看不到宿主機上的其餘進程，覺得本身就是pid爲1的進程
• 它被宿主機操做系統限制了硬件資源，它能使用的cpu、內存等硬件資源只是宿主機的一部分
• 在被宿主機操做系統限制了存儲空間，讓這個進程認爲宿主機的某個目錄就是系統根目錄

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

這裏用利用K8S官方文檔的圖，簡單說下生產中的場景，看看容器技術能解決什麼問題。

左圖是傳統的物理機部署應用方式的方式，能夠看到除了一個應用的運行，除了程序自己，離不開應用配置、庫、等等依賴環境。一般狀況下，一個應用的上線，要經歷開發環境、pre環境、beta環境、灰度測試、生產環境等等不一樣的基礎環境。開發的同窗在開發環境跑通了代碼，到其餘環境運行時，因爲各環境依賴、配置、安全需求不一樣，可能會出現各類問題。運維的同窗忙着在不一樣的環境中統一依賴。不一樣應用各類語言，各類應用的特殊依賴需求，也形成了CI/CD邏輯複雜，難以統一。

右圖是用了容器技術以後的場景。一個容器鏡像的實質就是程序進程加全部運行時環境及配置、依賴的集合。只要各個環境的底層能兼容docker，就能實現全部環境部署的一致性。開發同窗不用關心生產環境和開發環境的差別可能會致使應用運行問題，運維同窗部署一個應用，只要確保容器鏡像能正常運行就好。CI/CD的自動化也相對容易實現不少。從而極大增長開發效率、應用迭代效率及節省了運維工做量。

說到這裏，不得不說下容器與傳統意義的虛擬機間的對比。其實兩者均可以理解爲虛擬化，它們最本質的區別是，容器是操做系統層級的虛擬化，而虛擬機是硬件層級的虛擬化。參看下圖。

因爲虛擬機多了一層Guest OS，須要宿主機額外的性能開銷進行硬件虛擬化，同時由於是完整的操做系統，虛擬機鏡像通常動輒大幾G，很難在各環境間快速傳播，hypervisor層相對Docker Engine也比較重。再看docker容器，實質就是宿主機上跑的一個進程，只不過經過docker與其餘進程隔離開來。簡單的說，敏捷和高效，是容器相比虛擬機最大的優點，固然也有劣勢，因爲容器只是操做系統級別的隔離，不一樣容器間隔離的不夠完全。

Why Kubernetes

簡單說完了docker的理解，那麼Kubernetes又是什麼，它解決了哪些問題呢，爲啥如今提容器技術必提k8s呢。這裏再談談我理解的Why K8S。

回到實際的場景來，假如你已經開始用docker鏡像來打包應用，能夠方便的進行分發和部署，不用去考慮不一樣環境的差別。可是不是還感受還少了點什麼？

由於正常的實際業務系統，不是應用能部署，能運行起來就完事了，還要考慮應用容器的訪問、水平伸縮、監控、安全、備份、容災等等因素。而對於一個完整的業務系統來講，也不是單個應用就能搞定的，還要考慮的是各應用間的關係，及應用運行的形態。好比一個web業務，可能須要web服務器、緩存系統、數據庫等多個應用。容器化部署後，它們可能部署在不一樣宿主機的不一樣容器中，相互間的訪問要怎麼實現，這就涉及到容器間訪問關係的處理。再好比，有個優化緩存的應用也跑在容器裏，只須要按期運行容器實例執行優化任務，執行完畢就終止容器，這就須要處理不一樣容器應用的運行形態問題。相似上述這些對容器應用及容器間關係進行管理，就是所謂的容器編排及調度。而Kubernetes，就是目前的容器編排的平臺的事實標準了。

那麼，具體來講，K8S到底能作哪些事呢。

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

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

從這些功能介紹能夠看出，K8S已很相似一個雲平臺了，能夠徹底能知足生產級別的容器應用管理需求。下面是一張最簡單的K8S系統示意圖：

K8S集羣由一個主節點（master節點）及多個工做節點（node節點）構成，開發者提交應用容器鏡像，並將鏡像運行的數量、方法等經過描述文件提交給K8S master節點，K8S master節點或根據集羣總體狀況，將應用按照需求部署在工做節點中。對於開發者來講，利用K8S能夠方便的部署程序，不用關心基礎設施，而對於運維人員來講，工做重心從維護具體應用，轉變爲維護K8S集羣。並且，不論是開發者仍是運維人員，都不用關心應用具體部署在哪一個節點，K8S會自動判斷搞定一切。相比於傳統的應用部署方式，有沒有以爲K8S很棒棒？

在容器編排這個概念出現的時候，Kubernetes並非惟一的一個容器編排工具，主流的工具還有Docker公司原生的swarm和Apache基金會的mesos，爲何K8S能笑到最後，成爲容器編排的事實標準呢？我理解K8S對比它們有兩個最大不一樣點：（這裏不對swarm和mesos作詳細介紹了，實際也確實沒怎麼玩過）

1. K8S對容器又作了一層抽象，也就是POD。
   不一樣於與其餘兩個工具，K8S管理的原子對象，其實並非容器，而是POD。按照官方文檔的定義，一個POD，是由一個或多個共享存儲及網絡的容器，以及描述怎麼運行這些容器的集合，因此，POD實際是一個抽象的概念。k8s對容器的全部操做，好比動態伸縮、監控等，實際上都是對pod的管理。那這層抽象的好處是什麼呢？
   上面有提到過，容器實質就是被特殊處理的進程。想像一個web業務，web應用進程輸出的日誌須要被大數據agent進程處理。這個業務若是想容器化，一般有兩個作法。一是分別起來兩個容器，掛載宿主機同一個目錄來存放日誌。另外一種是起一個操做系統級別的容器或supervisord容器做爲enterpoint，來管理web服務和agent進程。前一種方式，這個兩個容器就被框在這臺宿主機上了，要實現業務實例橫向擴縮容，要考慮兩個容器的運行狀況和存儲掛載，邏輯比較複雜。後一種方式，你要爲每一個容器再額外開一個supervisord進程，更重要的是，因爲entrypoint是supervisord進程，web應用和大數據agent對docker來講，都是不可見的。即便nginx出錯頻繁重啓，只要supervisord還活着，Docker就認爲這個容器是正常的。

   咱們再來看看，使用了pod這個概念之後，有什麼變化。一個pod裏面同時起了web服務進程和大數據agent兩個容器實例，首先，pod裏的容器實例是共享存儲和網絡namespace的，也就是說，這兩進程的存儲數據是直接共享的，不須要額外的掛載動做。其次，這個pod是做爲一個總體被k8s管理着的，k8s會監控pod裏每一個容器的狀態，並根據策略在有問題時進行自動干預。從這個意義上說，pod才更相似傳統的虛擬機。

2. 聲明式API
   第二點也是比較重要的方面，是K8S的聲明式api(貌似swarm的新版也支持了，一樣沒玩過就不細說了)。什麼是聲明式API呢，能夠參考上面系統圖中的描述文件。好比要我須要集羣中跑10個web服務容器，傳統的命令式API是一步步調用命令構建出容器。而使用聲明式api，只要告訴K8S我要10個web容器，K8S就會自動將web集羣實例數維持在10個，而且，在某個pod出問題退出時，K8S會自動從新拉起新pod，使集羣始終保持10個pod實例在跑。這就使得管理集羣變得很簡單，只要經過配置文件描述出但願的集羣狀態，而不用去關注中間的實現過程。

最後，總結一下：
Why Dokcer： 用容器技術跑應用，相比原來的物理機及虛擬機更高效、輕量、省資源，同時大大方便了不一樣環境下的應用部署及分發。
Why Kubernetes：生產集羣光跑容器還不夠，還要對容器應用做爲一個業務系統集羣進行編排及管理，而K8S的一些優點使得它成爲目前容器集羣編排管理工具的事實標準。

最後的最後再多提一點，實際上，容器技術不止Docker公司一家在作，Kubernetes也不是隻能管理Docker容器。只是，不管從市場份額、應用性仍是開發社區的熱度來講，它們都是目前容器技術最主流的解決方案，就生產環境來講，目前基本沒有必要去考慮其餘的容器技術了。