講師介紹

基於Kubernetes的容器雲

容器雲最主要的功能是以應用為中心，幫助使用者把所有的應用以容器的形式在分散式裡面跑起來，最後把應用以服務的形式呈現給使用者。容器雲裡有兩個關鍵點，一是容器編排，二是資源排程。

容器編排就是我們期望能把一些微服務通過容器編排來幫助使用者組建一個比較龐大的系統，而資源排程在容器雲這種大規模分散式環境是必須的，需要一個比較好的排程平臺來提升系統的資源利用率以及根據使用者的資源請求幫助使用者來調配資源。

我們IBM的BlueDock就是這樣一個容器雲平臺，主要基於Kubernetes實現了容器的編排和資源排程，並預設使用Mesos作為底層的資源管理器，但如果使用者沒有執行多個framework的需求，可不使用Mesos。

為什麼是Kubernetes和Mesos

為什麼選擇Kubernetes和Mesos作為容器雲的基礎平臺？在專案啟動前，我們對當前流行的容器社群做了很多調研，主要是Docker、Mesos和Kubernetes社群。

我們先看一下Docker，Docker社群主要由Docker公司把控，雖然是開源的，但其實Docker社群相對來說不是很開放，因為Docker公司有基於Docker的所有產品，包括Docker的公有云、私有云Docker Data Center等等。這樣就導致了其他公司如果想基於Docker創業的話會比較困難，因為難以與Docker公司競爭。

而Mesos社群則更開放一些，主要原因是Mesosphere在基於Mesos研發了DC/OS，正在積極尋找一些合作者來推動DC/OS在企業的落地。同時Mesosphere也期望更多的公司、更多的人加入到這個社群，增加Mesos的影響力。所以這個社群相對Docker來說更開放一些，而且Mesos已經有很多落地的案例，在剛結束的MesosCon Asia上，我們可以看到國內其實有很多骨灰級的Mesos使用者，但這些使用者過於低調，沒有及時將自己的經驗分享出來，所以也希望這些使用者或已在生產使用Mesos的使用者能及時為大家分享一些經驗，促進Mesos生態的發展。

相比起來，Kubernetes社群是最開放、最活躍、最多元化的，雖然Kubernetes是Google開源的，但Google沒有任何一個產品是基於Kubernetes的。這樣就給了大家很公平的機會，基本上每個人、每個公司都可以基於Kubernetes開發自己的產品。但Kubernetes目前欠缺的是一些落地的案例，另外其支援的叢集規模大小也需要提升。

我曾試著把容器的這幾個社群和我們以前做虛擬化的社群做過一些對比，不知道合不合適，Docker可以類比到VMWare，Mesos可以類比到Citrix，Kubernetes可以類比到KVM。大家可以在調研選型或者使用的時候，根據自己的需求選擇合適的技術。

另外一個問題，大家應該可以看到Mesos和Kubernetes都在提供除了Docker之外的容器管理能力，Mesos花了很多時間去做Unified Container這個專案，目的就是即使沒有Docker Daemon，使用者也可執行Docker容器，同時使用Unified Container，還可執行其他容器，例如AppC、OCI等；Kubernetes也在整合Rkt給使用者除了Docker之外的另一種選擇。

整體架構

以上是我們容器雲的總體概覽，最左邊是我們很熟悉的雲平臺的最重要的三層，IaaS、PaaS、SaaS，我們的BlueDock主要是提供PaaS的功能，是基於Kubernetes和Mesos（可選）來研發的。但如果我們建容器雲的話，只有這兩個是遠遠不夠的，因為容器雲裡還有很多其他的功能，所以我們圍繞著Kubernetes和Mesos，在上面加了很多企業級的東西，包括應用商店，資源排程的改進策略，應用、伺服器的雙層擴充套件，多租戶管理，映象管理，統一介面等等。

應用商店：最主要的功能是把使用者常用的一些應用做成模板，類似手機上的App Store，使用者可以很方便地通過應用市場來對應用進行部署，同時BlueDock還支援對不同版本的應用在同一個應用商店進行管理。我們還支援使用者對應用市場進行定製，這樣就可以讓使用者把一些自己常用的應用上傳到應用商店，供其它使用者使用。

資源排程的改進策略：因為容器的使用是一種高密度計算，對資源排程的要求很高，尤其是一些資源的搶佔策略等等，這部分是原生的Kubernetes和Mesos都沒有的功能，IBM對這塊功能做了很大的改進，為容器雲加入了資源搶佔的功能。

應用、伺服器的雙層擴充套件：這個我們可以理解為是一種聯動擴充套件。當用戶的應用因為負載的變化在擴充套件的時候，如果發現底層的伺服器不夠了，那應用就沒辦法去擴充套件了。這時我們的容器雲就會和底層的OpenStack互動，通過OpenStack去申請一些新的伺服器加入到容器雲中，實現了容器雲平臺和用於應用的聯動擴充套件。我們的容器雲可以和多個不同的雲平臺整合，實現聯動擴充套件的功能。

多租戶管理：這塊主要是和OpenStack Keystone整合來對租戶進行管理，同時將Keystone的Project對映為Kubernetes的namespace。另外一個是我們還通過和Keystone整合實現了層級的租戶管理。按照這種層級的租戶管理，一個很大的優勢是可以按照層級的結構來對資源做事先的定義，這樣的話就可以和企業的組織架構就可以很好的匹配起來，便於企業內部的資源分配。

映象管理：這個服務主要是對映象進行管理，然後我們也調研了很多開源的對映象管理的軟體，例如Harbor，但是Harbor功能太多了，裡面不單單有映象管理的功能，還有對使用者，租戶管理的功能，許可權控制等等，裡邊很多功能和我們的容器雲是重複的，所以我們最終決定我們沒有用這個專案，而是參考Harbor自己開發了一個新的服務來對映象進行管理。

日誌管理：主要是通過ELK來實現。

持續整合：主要是通過Kubernetes Jenkins外掛來實現的。這個外掛的優勢是在資源分配時，Jenkins根據任務屬性自動建立臨時Docker容器，並作為slave節點加入Jenkins叢集，實現資源的分配；另外在任務執行結束後，Jenkins自動刪除相關節點，並銷燬相關Docker容器，實現資源的釋放；整個資源分配和資源釋放過程對使用者來說是透明的，使用者只需要建立好任務就可以了，不需要操作節點；對於Jenkins來說，slave節點（容器）是臨時的，任務一結束就會銷燬。為了實現資料持久化，需要和一些分散式的儲存整合，例如Ceph、Glusterfs等等。

統一的UI：對所有的服務進行操作，包括可以對UI對服務對映象進行管理，對應用市場進行管理等等。

如何實現self-healing

上圖是BlueDock中使用Kubernetes+Mesos的方案元件圖。BlueDock中的所有元件，都是通過container來部署的。用container的一個最大的優勢就是安裝部署升級是很簡單的，同時不會修改物理伺服器的一些配置，對物理伺服器不會有任何改動。我們現在的BlueDock，只需要一個通過一個“docker run”命令，就可以很方便在上百臺伺服器上把容器雲跑起來，我們做過一些測試，如果要去部署五百臺左右的伺服器，我們可以在十分鐘以內把整個容器雲集群安裝部署完成。

在圖中的最下邊用不同顏色的方框表示出了BlueDock中不同元件的管理方式。其中有三個比較重要的概念：Static pod、DaemonSet和Deployment。

Static pod是在特定節點上由kubelet守護程式直接管理的，Kubernetes APIServer不會對其進行管理。 它沒有關聯任何Relication Controller，kubelet守護程序來負責對Static pod的監控，並在static pod crash時重新啟動它。 Static pod始終繫結到一個kubelet守護程式，並且始終在同一節點上執行。

DaemonSet可以確保所有（或一些）節點始終執行某個pod的副本。 當節點新增到叢集時，DaemonSet可以保證自動在新新增的節點建立pod；如果節點被刪除後，這些pod也會相應的被DaemonSet刪除。

Deployment是kubernetes 1.2的一個新引入的概念，它包含著對Pod和將要代替Replication Controller的Replica Set的描述。

BlueDock主要通過Static Pod、DaemonSet和Deployment來對主要元件進行管理，這三個功能可以通過Kubernetes自身的功能保證BlueDock self-healing的功能，某些Pod crash後，Static Pod、DaemonSet和Deployment可以保證其會被重啟，從而保證系統的高可用。

基本流程是通過ansible呼叫docker-py通過docker container的形式在master節點啟動kubelet，在master節點的kubelet服務啟動後，就會以static pod的形式建立master節點的一些元件，例如k8sm-apiserver、k8sm-scheduler等等，當master節點的所有元件啟動完畢後，開始通過docker-py在不同的worker上啟動mesos agent，當整個BlueDock叢集開始執行後，再通過DaemonSet的形式啟動一些BlueDock的add-on的一些元件服務，例如日誌管理、網路管理等等。

日誌管理主要是通過DaemonSet的形式啟動了Filebeat，來蒐集每個worker的容器日誌資訊。網路管理主要是通過DaemonSet在每個worker節點啟動了Calico node的container，這個container裡面包含了Bird路由管理、Felix協議等。其它還有一些元件通過Deployment來管理，例如用於對log進行過濾的logstash，用於對Network Policy進行管理的calico congtroller等等。

上圖是BlueDock沒有Mesos的部署方式，基本和帶有Mesos的部署模式是一樣的，全部都是通過容器來對所有元件進行管理，同時可以self-healing。在這裡主要想強調的是，BlueDock對k8s-scheduler做了很大的改進，支援資源的搶佔，智慧回收的策略。因為一臺伺服器上可以啟動成百上千個容器，所以在這種高密度計算中，對資源的排程策略要求很高。BlueDock通過和IBM Platform的EGO整合，實現了資源的搶佔和智慧回收的策略。

上圖是BlueDock的一個簡單的改進的資源借入借出的一個例子。現在有兩個tenant，T1和T2，都獨佔8個資源，但是我們看到在T1和T2之間有個虛線，這個虛線表示T2可以從T1借入4個資源。所以當T1和T2去申請資源的時候，T1要4個，T2要12個，那T1可以直接拿到他獨佔的4個資源，T2要12個，但是他只獨佔8個資源，所以他會先拿到自己獨佔的這8個資源。

拿完之後，T2發現，他可以再從T1借4個，所以當T2從T1借完4個後，T1和T2的資源請求都得到了滿足，同時系統的資源使用率也達到了100％，所以這個是我們通過資源借入借出實現的提升資源利用率的一個例子。另外，如果T1的請求再提升的話，T1可以把借給T2的資源再搶佔回來，保證T1的SLA。

上圖是BlueDock的兩種不同的安裝模式：包含和不包含Mesos，這個可以在使用者對BlueDock安裝的時候，通過“—enable-mesos”來控制。當BlueDock安裝完成後，這兩種模式會有統一的GUI介面，終端使用者不會感知Mesos的存在，唯一的區別就是如果使用了Mesos，可以通過BlueDock管理Mesos的Framework。

BlueDock的Auth主要是通過Keystone實現了一個Kubernetes OpenID的provider，方便與其它第三方的應用整合實現單點登入的功能。同時利用了Kubernetes的RBAC的功能，可以定義細粒度的許可權控制。另外在和Keystone的整合過程中，BlueDock將Kubernetes的namespace對映為Keystone的project，這樣的話，可以藉助keystone來對Kubernetes的使用者和namespace來統一管理。

在BlueDock叢集中的每個節點上執行一個Filebeat的容器，收集容器的日誌傳送給到LogStash來進行過濾，然後統一儲存到ElasticSearch叢集中，使用者可以通過Kibana檢視任意Node、Namespace、Service、Pod和容器的資料。在BlueDock中，ElasticSearch是作為DaemonSet在所有管理節點啟動的。

應用管理主要通過Kubernetes Helm來管理，Helm是官方Kubernetes的一部分，主要用來進行軟體包的管理。Helm的一個很重要的概念是Charts，表示可以安裝並組成的預配置Kubernetes資源包。Helm採用客戶端機伺服器模式。伺服器部分被稱為tiller，同時包括你執行Kubernetes叢集。客戶端部分被稱為helm，安裝在本地的開發系統上。

在BlueDock中，為了讓BlueDock的UI能直接呼叫Helm的API，我們通過Helm的Client實現了Helm的Rest API，這樣可通過BlueDock的UI來呼叫Helm的Rest API實現對Kubernetes應用包的管理。同時在BlueDock中將Rest API、Helm Client和Tiller通過一個Kubernetes Deployment進行管理部署，這樣可通過Kubernetes自身來對Helm的所有元件進行管理。

注：IBM釋出了BlueDock的開源版本，可以下載來玩一下。BlueDock安裝的Docker映象可從這裡下載：https://hub.docker.com/r/ibmcom/cfc-installer/ ，一個“docker run”命令可幫助安裝整個叢集。如果在安裝時有任何問題，可到slack channel尋求幫助，具體資訊可參考：https://www.ibm.com/developerworks/community/wikis/home?lang=zh#!/wiki/W1559b1be149d_43b0_881e_9783f38faaff