做爲一名容器時代的程序員相信你已經或多或少接觸過Docker，但同時你也會發現Docker雖然流行了多年，但以前卻不多有公司直接將線上應用經過Docker容器進行大規模地部署。但最近三年，你會發現幾乎絕大多數有條件的公司都已經在使用Kubernetes部署和發佈本身的線上業務了。對一名普通開發人員來講，這一切可能發生得太快，以致於你尚未搞清楚它是怎麼發生的，也會疑惑Docker和Kubernetes之間究竟是個什麼關係。
android
在今天的內容中，咱們從Kubernetes的系統架構及容器編排核心概念兩個方面來簡單聊一聊這個問題，但願能幫助到你更好地理解Docker和Kubernetes之間因果關係。程序員
Kubernetes介紹
web
在具體介紹Kubernetes以前不得再也不提一下Docker，若是你用過Docker部署過程序，那麼你必定會很是享受它帶給你的絲滑體驗，而聯想到在此以前發佈一個程序須要寫各類腳本、進行各類環境匹配的糟糕體驗，那麼相信你的這種感受會更增強烈。
數據庫
而Docker之因此能作到這一點，就在於它以「Docker鏡像」的方式一舉解決了應用打包和發佈這一困擾業界多年的技術難題，而且大大下降了普通開發人員運維部署應用的門檻。正是由於解決了應用打包這個根本性的問題，才使得Docker很快就被廣大開發/運維人員所接受，迅速成爲煊赫一時的技術，並在必定時間內引領了容器化技術發展的浪潮。後端
那麼Docker這麼好用爲何還會出現Kubernetes呢？事實是Docker做爲單一的容器技術工具並不能很好地定義容器的「組織方式」和「管理規範」，難以獨立地支撐起生產級大規模容器化部署的要求。所以容器技術的發展就迅速走向了以Kubernetes爲表明的「容器編排」的技術路線，而這也是爲何Docker容器沒有直接在生產環境中大規模部署的關鍵緣由。api
上面咱們提到了「容器編排」的概念，瞭解到相對於Docker單一容器技術而言，Kubernetes容器編排技術能夠很好地實現大規模容器的組織和管理，從而使容器技術實現了從「容器」到「容器雲」的飛躍！那麼Kubernetes技術是從何而來？而又真正解決了什麼問題呢？微信
從背景上說，Kubernetes是由Google與RedHat公司共同主導的開源「容器編排」項目，它起源於Google公司的Borg系統。因此它在超大規模集羣管理方面的經驗要明顯優於其餘容器編排技術，加上Kubernetes在社區管理方面的民主化，使得它很快戰勝了Docker公司推出的容器編排解決方案(Compose+Swarm)，從而成爲了容器編排領域事實上的標準。cookie
而在功能上Kubernetes是一種綜合的基於容器構建分佈式系統的基礎架構環境，它不只可以實現基本的拉取用戶鏡像、運行容器，還能夠提供路由網關、水平擴展、監控、備份、災難恢復等一系列運維能力，而更重要的是Kubernetes能夠按照用戶的意願和整個系統的規則，高度自動化的處理好容器之間的各類關係實現「編排」能力。
網絡
此外Kubernetes的出現也從新定義了微服務架構的技術方向，目前一般所說的「雲原生」及「Service Mesh(服務網格)」等概念，很大程度上也是依賴於Kubernetes所提供的基礎能力。因爲篇幅和做者知識水平有限，這裏就不展開去聊了，感興趣的讀者能夠參考其餘專業書籍或技術資料。架構
Kubernetes總體系統架構
前面咱們簡單介紹了Kubernetes的起源和背景，接下來看看Kubernetes的總體系統架構，以下圖所示：
如上圖所示，Kubernetes在架構上主要由Master和Node兩種類型的節點組成，這兩種節點分別對應着控制節點和計算節點。其中Master即控制節點，是整個Kubernetes集羣的大腦，主要負責編排、管理和調度用戶提交的做業，並能根據集羣系統資源的總體使用狀況將做業任務自動分發到可用Node計算節點。具體看Master節點主要由三個緊密協做的獨立組件組合而成，它們分別是：
kube-apiserver：是Kubernetes集羣API服務的入口，主要提供資源訪問操做、認證、受權、訪問控制及API註冊和發現等功能機制。
kube-scheduler：負責Kubernetes的資源調度，能按照預約的調度策略將Pod調度到相應的機器上。
kube-controller-manager：負責容器編排及Kubernetes集羣狀態的維護，例如故障檢測、自動擴展、滾動更新等。
須要說明的是，上述組件在工做狀態下還會產生許多須要進行持久化的數據，這些數據會經過kube-apiserver處理後統一保存到Etcd存儲服務中。因此從這個角度看kube-apiserver不只是外部訪問Kubernetes集羣的入口，也是維護整個Kubernetes集羣狀態的信息中樞。
而在Kubernetes計算節點中，除了上述3個系統組件外，其餘基本與Master節點相同，而其中最核心的部分就是kubelet組件。它的核心功能具以下：
經過CRI(Container Runtime Interface)遠程接口同容器運行時（如Docker）進行交互，對容器生命週期進行維護。其中CRI接口會定義了容器運行時的各項核心操做，例如啓動容器所需的命令及參數等。
經過GRPC協議同Device Plugin插件交互，實現Kubernetes對宿主機物理設備的管理。
此外kubelet另外一個重要的功能則是經過CNI（Container Networking Interface）來調用網絡插件爲容器配置網絡，以及經過CSI（Container Storage Interface）和存儲插件交互爲容器配置持久化存儲。
在Kubernetes中kubelet會經過CRI接口同容器運行時進行交互，而容器運行時則經過叫作OCI容器運行時規範與底層Linux操做系統進行交互(涉及對Namespace、Cgroups等資源的操做，具體能夠了解下Docker的技術原理)。須要強調的是，這裏所說的容器運行時並不只僅指Docker，而是全部實現了CRI接口規範的容器項目均可以做爲Kubernetes的容器運行時存在。這是由於Kubernetes從設計之初就沒有把Docker做爲整個架構的核心，而只是將其做爲最底層的一個容器運行時來實現。
但這並非說Kubernetes就徹底拋棄Docker了，要知道Docker最大的成功並非它的容器運行時技術，而是它定義的「容器鏡像」開創性地解決了困擾業界多年的應用打包難題，因此雖然Kubernetes並不徹底依賴於Docker的容器運行時技術，但容器鏡像的定義標準倒是全部容器技術都繞不開的存在。
何況從Kubernetes架構設計上看，Kubernetes並無打算重複造輪子而對已有的容器技術進行替代，它更關注的是對運行在大規模集羣中的各類任務根據其關係進行做業編排及管理，因此任何實現了CRI、CNI、CSI等協議標準的容器技術均可以無縫地與Kubernetes集成。從這個角度看，Docker與Kubernetes的關係並非替代的關係，而是平臺與組件的關係，Kubernetes能夠利用現有的Docker容器運行時技術，但卻並不徹底依賴Docker。而這也正是Kubernetes爲何被稱做容器編排技術而不只僅只是容器技術的緣由。
Kubernetes容器編排概述
咱們說處理任務之間的各類關係，實現容器編排是Kubernetes的核心技術能力，也是其大規模流行的關鍵緣由。那麼容器編排究竟是個什麼概念？在Kubernetes中是如何實現容器編排的呢？
其實所謂容器編排，通俗點舉例就是若是兩個應用調用關係比較緊密，那麼咱們但願運行時將它們部署在同一臺機器上，從而提高服務之間的通訊效率。而可以支持自動將具備此類關係的應用，以容器的方式部署在同一臺機器上的技術就是容器編排。
固然，這裏所說的緊密關係只是一種形象的說法，實際的技術場景中這種緊密關係能夠被劃分爲不少類型，例如Web應用與數據庫之間的訪問關係、負載均衡和它後端服務之間的代理關係、門戶應用與受權組件之間的調用關係等。
而對於Kubernetes來講，這樣的關係描述顯然仍是過於具體，由於Kubernetes的設計目標不只僅是可以處理前面提到的全部類型的關係，還要可以支持將來可能出現的更多種類的關係。這就要求Kubernetes要從更宏觀地角度來定義任務之間的各類關係，而且能爲未來支持更多種類的關係留有餘地。
具體來講，Kubernetes是對容器間的訪問進行了分類，若是這些應用之間須要很是頻繁的交互和訪問，或者它們之間存在直接經過本地文件進行信息交換的狀況，那麼在Kubernetes中能夠將這些容器劃分爲一個「Pod」,而Pod中的容器將共享同一個Network Namespace、同一組數據卷，從而實現高效率通訊。
Pod是Kubernetes中最基礎的編排對象，是Kubernetes最小的調度單元，也是Kubernetes實現容器編排的載體，其本質上是一組共享了某些系統資源的容器集合。在Kubernetes中圍繞Pod能夠延伸出其餘核心概念，具體以下圖所示：
如上圖所示，在Kubernetes中Pod解決了容器間緊密協做（即編排）的問題，而Pod要實現一次啓動多個Pod副本就須要Deployment這個Pod多實例管理器；而有了這樣一組Pod後，咱們又須要經過一個固定網絡地址以負載均衡的方式訪問它，因而又有了Service。
而根據不一樣的編排場景Pod又衍生出描述一次性運行任務的Job編排對象、描述每一個宿主機上必須且只能運行一個副本的守護進程服務DaemonSet、描述定義任務的CronJob編排對象、以及針對有狀態應用的StatefulSet等多種編排對象。而這些編排對象正是Kubernetes定義容器間關係和形態的主要方法。
關於這些具體編排對象的介紹及應用場景，後面我將在本公衆號的《Devops技術專欄》中陸續給你們介紹到，感興趣的朋友能夠點贊+關注！
—————END—————
本文分享自微信公衆號 - 無敵碼農（jiangqiaodege）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。