1 故事開始

隨著消費者購買力的不斷提升，用戶擁有越來越多的電子快消品。小李預計在未來五年內(nèi)，二手電子快消品市場將會迅速擴張。小李覺得這是一個創(chuàng)業(yè)的好機會，于是找到了我和幾個志同道合的小伙伴開始了創(chuàng)業(yè)，決定做一個叫“XX”的平臺。

2 故事發(fā)展

旗魚一開始是一個 all in one 的 Java 應用，部署在一臺物理機上，隨著業(yè)務的發(fā)展，發(fā)現(xiàn)機器已經(jīng)快扛不住了，就趕緊對服務器的規(guī)格做了升級，從 64C256G 一路升到了 160C1920G，雖然成本高了點，但是系統(tǒng)至少沒出問題。

業(yè)務發(fā)展了一年后，160C1920G 也扛不住了，不得不進行服務化拆分、分布式改造了。為了解決分布式改造過程中的各種問題，引入了一系列的中間件，類似 hsf、tddl、tair、diamond、metaq 這些，在艱難的業(yè)務架構(gòu)改造后，我們成功的把 all in one 的 Java 應用拆分成了多個小應用，重走了一遍阿里當年中間件發(fā)展和去 IOE 的道路。

分布式改完了后，我們管理的服務器又多起來了，不同批次的服務器，硬件規(guī)格、操作系統(tǒng)版本等等都不盡相同，于是應用運行和運維的各種問題就出來了。

還好有虛擬機技術(shù)，把底層各種硬件和軟件的差異，通過虛擬化技術(shù)都給屏蔽掉啦，雖然硬件不同，但是對于應用來說，看到的都是一樣的啦，但是虛擬化又產(chǎn)生了很大的性能開銷。

嗯，不如使用類似 docker 的技術(shù)，比如 podman，因為容器技術(shù)在屏蔽底層差異的同時，也沒有明顯的性能影響，真是一個好東西。而且基于容器鏡像的業(yè)務交付，使得 CI/CD 的運作也非常的容易啦~

隨著容器數(shù)量的增長，又不得不面對新的難題，就是大量的容器如何調(diào)度與通信？畢竟隨著業(yè)務發(fā)展，公司規(guī)模日益增長，線上運行著幾千個容器，并且按照現(xiàn)在的業(yè)務發(fā)展趨勢，馬上就要破萬了。

不行，我們一定要做一個系統(tǒng)，這個系統(tǒng)能夠自動的管理服務器（比如是不是健康啊，剩下多少內(nèi)存和 CPU 可以使用啊等等）、然后根據(jù)容器聲明所需的 CPU 和 memory 選擇最優(yōu)的服務器進行容器的創(chuàng)建，并且還要能夠控制容器和容器之間的通信（比如說某個部門的內(nèi)部服務，當然不希望其他部門的容器也能夠訪問）。

我們給這個系統(tǒng)取一個名字，就叫做容器編排系統(tǒng)吧。

3 容器編排系統(tǒng)

那么問題來了，面對一堆的服務器，我們要怎么實現(xiàn)一個容器編排系統(tǒng)呢？

先假設已經(jīng)實現(xiàn)了這個編排系統(tǒng)，那么服務器就會有一部分會用來運行這個編排系統(tǒng)，剩下的服務器用來運行業(yè)務容器，我們將運行編排系統(tǒng)的服務器叫做 master 節(jié)點，把運行業(yè)務容器的服務器叫做 worker 節(jié)點。

既然 master 節(jié)點負責管理服務器集群，那它就必須要提供出相關(guān)的管理接口，一個是方便運維管理員對集群進行相關(guān)的操作，另一個就是負責和 worker 節(jié)點進行交互，比如進行資源的分配、網(wǎng)絡的管理等。

我們把 master 上提供管理接口的組件稱為 kube apiserver，對應的還需要兩個用于和 api server 交互的客戶端，一個是提供給集群的運維管理員使用的，我們稱為 kubectl；一個是提供給 worker 節(jié)點使用的，我們稱為 kubelet。

那 master 又是怎么知道各個 worker 上的資源消耗和容器的運行情況的呢？這個簡單，我們可以通過 worker 上的 kubelet 周期性的主動上報節(jié)點資源和容器運行的情況，然后 master 將這個數(shù)據(jù)存儲下來，后面就可以用來做調(diào)度和容器的管理使用了。

至于數(shù)據(jù)怎么存儲，我們可以寫文件、寫 db 等等，不過有一個開源的存儲系統(tǒng)叫 etcd，滿足數(shù)據(jù)一致性和高可用的要求，同時安裝簡單、性能又好，我們就選 etcd 吧。

現(xiàn)在我們已經(jīng)有了所有 worker 節(jié)點和容器運行的數(shù)據(jù)，我們可以做的事情就非常多了。比如前面所說的，我們使用用戶中心 2.0 版本的鏡像創(chuàng)建了 1000 個容器，其中有5個容器都是運行在 A worker 節(jié)點上，如果 A 這個節(jié)點突然出現(xiàn)了硬件故障，導致節(jié)點不可用了，這個時候 master 就要將 A 從可用 worker 節(jié)點中摘除掉，并且還需要把原先運行在這個節(jié)點上的 5 個用戶中心 2.0 的容器重新調(diào)度到其他可用的 worker 節(jié)點上，使得用戶中心 2.0 的容器數(shù)量能夠重新恢復到 1000 個，并且還需要對相關(guān)的容器進行網(wǎng)絡通信配置的調(diào)整，使得容器間的通信還是正常的。

我們把這一系列的組件稱為控制器，比如節(jié)點控制器、副本控制器、端點控制器等等，并且為這些控制器提供一個統(tǒng)一的運行組件，稱為控制器管理器（kube-controller-manager）。

那 master 又該如何實現(xiàn)和管理容器間的網(wǎng)絡通信呢？首先每個容器肯定需要有一個唯一的 ip 地址，通過這個 ip 地址就可以互相通信了，但是彼此通信的容器有可能運行在不同的 worker 節(jié)點上，這就涉及到 worker 節(jié)點間的網(wǎng)絡通信，因此每個 worker 節(jié)點還需要有一個唯一的 ip 地址，但是容器間通信都是通過容器 ip 進行的，容器并不感知 worker 節(jié)點的 ip 地址，因此在 worker 節(jié)點上需要有容器 ip 的路由轉(zhuǎn)發(fā)信息，我們可以通過 iptables、ipvs 等技術(shù)來實現(xiàn)。

那如果容器 ip 變化了，或者容器數(shù)量變化了，這個時候相關(guān)的 iptables、ipvs 的配置就需要跟著進行調(diào)整，所以在 worker 節(jié)點上我們需要一個專門負責監(jiān)聽并調(diào)整路由轉(zhuǎn)發(fā)配置的組件，我們把這個組件稱為 kube proxy（此處為了便于理解，就不展開引入 Service 的內(nèi)容了）。

我們已經(jīng)解決了容器間的網(wǎng)絡通信，但是在我們編碼的時候，我們希望的是通過域名或者 vip 等方式來調(diào)用一個服務，而不是通過一個可能隨時會變化的容器 ip。因此我們需要在容器 ip 之上在封裝出一個 Service 的概念，這個 Service 可以是一個集群的 vip，也可以是一個集群的域名，為此我們還需要一個集群內(nèi)部的 DNS 域名解析服務。

另外雖然我們已經(jīng)有了 kubectl，可以很愉快的和 master 進行交互了，但是如果有一個 web 的管理界面，這肯定是一個更好的事情。此處之外，我們可能還希望看到容器的資源信息、整個集群相關(guān)組件的運行日志等等。

像 DNS、web 管理界面、容器資源信息、集群日志，這些可以改善我們使用體驗的組件，我們統(tǒng)稱為插件。

至此，我們已經(jīng)成功構(gòu)建了一個容器編排系統(tǒng)，我們來簡單總結(jié)下上面提到的各個組成部分：

Master 組件：kube-apiserver、kube-scheduler、etcd、kube-controller-manager

Node 組件：kubelet、kube-proxy

插件：DNS、用戶界面 Web UI、容器資源監(jiān)控、集群日志

審核編輯：黃飛