Kubernetes 和 Docker，到底什么关系？
來源 | 無敵碼農(nóng)
責編 | 寇雪芹
頭圖 | 下載于視覺中國
作為一名容器時代的程序員相信你已經(jīng)或多或少接觸過Docker，但同時你也會發(fā)現(xiàn)Docker雖然流行了多年，但之前卻很少有公司直接將線上應用通過Docker容器進行大規(guī)模地部署。但最近三年，你會發(fā)現(xiàn)幾乎絕大多數(shù)有條件的公司都已經(jīng)在使用Kubernetes部署和發(fā)布自己的線上業(yè)務了。對一名普通開發(fā)人員來說，這一切可能發(fā)生得太快，以至于你還沒有搞清楚它是怎么發(fā)生的，也會疑惑Docker和Kubernetes之間到底是個什么關系。
在今天的內(nèi)容中，我們從Kubernetes的系統(tǒng)架構(gòu)及容器編排核心概念兩個方面來簡單聊一聊這個問題，希望能幫助到你更好地理解Docker和Kubernetes之間因果關系。
Kubernetes介紹
在具體介紹Kubernetes之前不得不再提一下Docker，如果你用過Docker部署過程序，那么你一定會非常享受它帶給你的絲滑體驗，而聯(lián)想到在此之前發(fā)布一個程序需要寫各種腳本、進行各種環(huán)境匹配的糟糕體驗，那么相信你的這種感覺會更加強烈。
而Docker之所以能做到這一點，就在于它以“Docker鏡像”的方式一舉解決了應用打包和發(fā)布這一困擾業(yè)界多年的技術(shù)難題，并且大大降低了普通開發(fā)人員運維部署應用的門檻。正是因為解決了應用打包這個根本性的問題，才使得Docker很快就被廣大開發(fā)/運維人員所接受，迅速成為炙手可熱的技術(shù)，并在一定時間內(nèi)引領了容器化技術(shù)發(fā)展的浪潮。
那么Docker這么好用為什么還會出現(xiàn)Kubernetes呢？事實是Docker作為單一的容器技術(shù)工具并不能很好地定義容器的“組織方式”和“管理規(guī)范”，難以獨立地支撐起生產(chǎn)級大規(guī)模容器化部署的要求。因此容器技術(shù)的發(fā)展就迅速走向了以Kubernetes為代表的“容器編排”的技術(shù)路線，而這也是為什么Docker容器沒有直接在生產(chǎn)環(huán)境中大規(guī)模部署的關鍵原因。
上面我們提到了“容器編排”的概念，了解到相對于Docker單一容器技術(shù)而言，Kubernetes容器編排技術(shù)可以很好地實現(xiàn)大規(guī)模容器的組織和管理，從而使容器技術(shù)實現(xiàn)了從“容器”到“容器云”的飛躍！那么Kubernetes技術(shù)是從何而來？而又真正解決了什么問題呢？
從背景上說，Kubernetes是由Google與RedHat公司共同主導的開源“容器編排”項目，它起源于Google公司的Borg系統(tǒng)。所以它在超大規(guī)模集群管理方面的經(jīng)驗要明顯優(yōu)于其他容器編排技術(shù)，加上Kubernetes在社區(qū)管理方面的民主化，使得它很快打敗了Docker公司推出的容器編排解決方案(Compose+Swarm)，從而成為了容器編排領域事實上的標準。
而在功能上Kubernetes是一種綜合的基于容器構(gòu)建分布式系統(tǒng)的基礎架構(gòu)環(huán)境，它不僅能夠?qū)崿F(xiàn)基本的拉取用戶鏡像、運行容器，還可以提供路由網(wǎng)關、水平擴展、監(jiān)控、備份、災難恢復等一系列運維能力，而更重要的是Kubernetes可以按照用戶的意愿和整個系統(tǒng)的規(guī)則，高度自動化的處理好容器之間的各種關系實現(xiàn)“編排”能力。
此外Kubernetes的出現(xiàn)也重新定義了微服務架構(gòu)的技術(shù)方向，目前通常所說的“云原生”及“Service Mesh(服務網(wǎng)格)”等概念，很大程度上也是依賴于Kubernetes所提供的基礎能力。由于篇幅和作者知識水平有限，這里就不展開去聊了，感興趣的讀者可以參考其他專業(yè)書籍或技術(shù)資料。
Kubernetes整體系統(tǒng)架構(gòu)
前面我們簡單介紹了Kubernetes的起源和背景，接下來看看Kubernetes的整體系統(tǒng)架構(gòu)，如下圖所示：
如上圖所示，Kubernetes在架構(gòu)上主要由Master和Node兩種類型的節(jié)點組成，這兩種節(jié)點分別對應著控制節(jié)點和計算節(jié)點。其中Master即控制節(jié)點，是整個Kubernetes集群的大腦，主要負責編排、管理和調(diào)度用戶提交的作業(yè)，并能根據(jù)集群系統(tǒng)資源的整體使用情況將作業(yè)任務自動分發(fā)到可用Node計算節(jié)點。具體看Master節(jié)點主要由三個緊密協(xié)作的獨立組件組合而成，它們分別是：
kube-apiserver：是Kubernetes集群API服務的入口，主要提供資源訪問操作、認證、授權(quán)、訪問控制及API注冊和發(fā)現(xiàn)等功能機制。
kube-scheduler：負責Kubernetes的資源調(diào)度，能按照預定的調(diào)度策略將Pod調(diào)度到相應的機器上。
kube-controller-manager：負責容器編排及Kubernetes集群狀態(tài)的維護，例如故障檢測、自動擴展、滾動更新等。
需要說明的是，上述組件在工作狀態(tài)下還會產(chǎn)生許多需要進行持久化的數(shù)據(jù)，這些數(shù)據(jù)會通過kube-apiserver處理后統(tǒng)一保存到Etcd存儲服務中。所以從這個角度看kube-apiserver不僅是外部訪問Kubernetes集群的入口，也是維護整個Kubernetes集群狀態(tài)的信息中樞。
而在Kubernetes計算節(jié)點中，除了上述3個系統(tǒng)組件外，其他基本與Master節(jié)點相同，而其中最核心的部分就是kubelet組件。它的核心功能具如下：
通過CRI(Container Runtime Interface)遠程接口同容器運行時（如Docker）進行交互，對容器生命周期進行維護。其中CRI接口會定義了容器運行時的各項核心操作，例如啟動容器所需的命令及參數(shù)等。
通過GRPC協(xié)議同Device Plugin插件交互，實現(xiàn)Kubernetes對宿主機物理設備的管理。
此外kubelet另一個重要的功能則是通過CNI（Container Networking Interface）來調(diào)用網(wǎng)絡插件為容器配置網(wǎng)絡，以及通過CSI（Container Storage Interface）和存儲插件交互為容器配置持久化存儲。
在Kubernetes中kubelet會通過CRI接口同容器運行時進行交互，而容器運行時則通過叫做OCI容器運行時規(guī)范與底層Linux操作系統(tǒng)進行交互(涉及對Namespace、Cgroups等資源的操作，具體可以了解下Docker的技術(shù)原理)。需要強調(diào)的是，這里所說的容器運行時并不僅僅指Docker，而是所有實現(xiàn)了CRI接口規(guī)范的容器項目都可以作為Kubernetes的容器運行時存在。這是因為Kubernetes從設計之初就沒有把Docker作為整個架構(gòu)的核心，而只是將其作為最底層的一個容器運行時來實現(xiàn)。
但這并不是說Kubernetes就完全拋棄Docker了，要知道Docker最大的成功并不是它的容器運行時技術(shù)，而是它定義的“容器鏡像”開創(chuàng)性地解決了困擾業(yè)界多年的應用打包難題，所以雖然Kubernetes并不完全依賴于Docker的容器運行時技術(shù)，但容器鏡像的定義標準卻是所有容器技術(shù)都繞不開的存在。
況且從Kubernetes架構(gòu)設計上看，Kubernetes并沒有打算重復造輪子而對已有的容器技術(shù)進行替代，它更關注的是對運行在大規(guī)模集群中的各種任務根據(jù)其關系進行作業(yè)編排及管理，所以任何實現(xiàn)了CRI、CNI、CSI等協(xié)議標準的容器技術(shù)都可以無縫地與Kubernetes集成。從這個角度看，Docker與Kubernetes的關系并不是替代的關系，而是平臺與組件的關系，Kubernetes可以利用現(xiàn)有的Docker容器運行時技術(shù)，但卻并不完全依賴Docker。而這也正是Kubernetes為什么被稱作容器編排技術(shù)而不僅僅只是容器技術(shù)的原因。
Kubernetes容器編排概述
我們說處理任務之間的各種關系，實現(xiàn)容器編排是Kubernetes的核心技術(shù)能力，也是其大規(guī)模流行的關鍵原因。那么容器編排到底是個什么概念？在Kubernetes中是如何實現(xiàn)容器編排的呢？
其實所謂容器編排，通俗點舉例就是如果兩個應用調(diào)用關系比較緊密，那么我們希望運行時將它們部署在同一臺機器上，從而提升服務之間的通信效率。而能夠支持自動將具有此類關系的應用，以容器的方式部署在同一臺機器上的技術(shù)就是容器編排。
當然，這里所說的緊密關系只是一種形象的說法，實際的技術(shù)場景中這種緊密關系可以被劃分為很多類型，例如Web應用與數(shù)據(jù)庫之間的訪問關系、負載均衡和它后端服務之間的代理關系、門戶應用與授權(quán)組件之間的調(diào)用關系等。
而對于Kubernetes來說，這樣的關系描述顯然還是過于具體，因為Kubernetes的設計目標不僅僅是能夠處理前面提到的所有類型的關系，還要能夠支持未來可能出現(xiàn)的更多種類的關系。這就要求Kubernetes要從更宏觀地角度來定義任務之間的各種關系，并且能為將來支持更多種類的關系留有余地。
具體來說，Kubernetes是對容器間的訪問進行了分類，如果這些應用之間需要非常頻繁的交互和訪問，或者它們之間存在直接通過本地文件進行信息交換的情況，那么在Kubernetes中可以將這些容器劃分為一個“Pod”,而Pod中的容器將共享同一個Network Namespace、同一組數(shù)據(jù)卷，從而實現(xiàn)高效率通信。
Pod是Kubernetes中最基礎的編排對象，是Kubernetes最小的調(diào)度單元，也是Kubernetes實現(xiàn)容器編排的載體，其本質(zhì)上是一組共享了某些系統(tǒng)資源的容器集合。在Kubernetes中圍繞Pod可以延伸出其他核心概念，具體如下圖所示：
如上圖所示，在Kubernetes中Pod解決了容器間緊密協(xié)作（即編排）的問題，而Pod要實現(xiàn)一次啟動多個Pod副本就需要Deployment這個Pod多實例管理器；而有了這樣一組Pod后，我們又需要通過一個固定網(wǎng)絡地址以負載均衡的方式訪問它，于是又有了Service。
而根據(jù)不同的編排場景Pod又衍生出描述一次性運行任務的Job編排對象、描述每個宿主機上必須且只能運行一個副本的守護進程服務DaemonSet、描述定義任務的CronJob編排對象、以及針對有狀態(tài)應用的StatefulSet等多種編排對象。而這些編排對象正是Kubernetes定義容器間關系和形態(tài)的主要方法。
關于?Devops 技術(shù)的其他文章
Docker私有鏡像倉庫是什么？
上手 Docker 容器，不應該是個問題
什么魔力讓 Docker 一發(fā)不可收拾？
總結(jié)
以上是生活随笔為你收集整理的Kubernetes 和 Docker，到底什么关系？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 云原生人物志|华为云CTO张宇昕：云原生
- 下一篇： 从程序媛到微软全球 AKS 女掌门人，技