支撐大規模公用雲端的Kubernetes改進與最佳化 (1)

標籤：使用   ble   key   掛載   客戶   體系   網易   管理   過濾   

Kubernetes是設計用來實施私人容器雲的，然而容器作為公用雲端，同樣需要一個管理平台，在Swarm，Mesos，Kubernetes中，基於Kubernetes已經逐漸成為容器編排的最熱最主流的平台，網易基於Kubernetes實現了自己的容器公用雲端，在這個過程中，需要對Kubernetes進行一定的改進與最佳化。

 

架構如下：

 

 

網易開發了自己的一個Container Service平台，將OpenStack的IaaS層和Kubernetes容器層深度融合起來，從而實現一個完整的公用雲端體系。可以看出，Container Service平台會調度OpenStack的計算服務Nova來建立KVM虛擬機器，然後調用Cinder進行雲端硬碟的建立於掛載，調用Neturon進行網路的建立與串連，然後調用Kubernetes進行容器建立，還可以調用NLB掛載負載平衡器。

 

一、OpenStack架構很複雜

 

在容器平台之前，網易的IaaS層採用的是OpenStack架構。大家都說OpenStack太複雜了，如是OpenStack的一個架構圖。

 

 

OpenStack主要包括以下的模組：

• 安全認證模組keystone

• 計算虛擬化模組Nova

• 儲存虛擬化模組Cinder

• 網路虛擬化模組Neutron

• 鏡像管理模組Glance

• Object Storage Service模組Swift

 

其中每一個模組都包含很多的子模組，大部分包括api模組，調度模組，以及具體幹活的模組。

 

二、OpenStack建立虛擬機器的流程很複雜

 

OpenStack建立一個虛擬機器的流程非常複雜，這裡簡單概括一下其中的要點。

 

第一：AAA，也即我們常說的Authentication，Authorization，Account。

 

所謂的Authentication認證，就是驗證我是不是我，Authorization鑒權就是審核，雖然我是我，但是我都沒有這個權利做這個事情。

 

Authentication一般有兩種方式，一個是對稱式加密的方式，也即用一個Token，用戶端和服務端都用這個Token進行加密和解密，一個是非對稱式加密的方式，也即使用PKI，使用certificate的方式。

 

AWS也是有這兩種方式。

 

 

另外Authorization，則常用的是Role based access control。

 

有使用者，角色，租戶的概念。

 

例如AWS裡面有

 

第二： nova-api接受請求

 

在這裡可以幹兩件事情，rate limit，調用我不能太頻繁，quota，控制每個租戶最多能夠建立多少資源。

 

第三：nova-scheduler進行調度

 

調度分兩個過程，一個是Filtering，先將不符合要求的主機過濾掉，一個是weighting，剩下的根據主機的使用方式進行打分排名，選擇一台機器。

 

第四：nova-compute真正幹活的人接收到請求，調用libvirt建立虛擬機器

 

 

第五：libvirt是真正的建立虛擬機器的工具，先要下載虛擬機器鏡像

 

 

第六：libvirt開始定義KVM的啟動參數

 

第七：libvirt開始給KVM建立網路裝置

 

第八：libvirt啟動KVM，這裡一般會用到Cgroup對KVM的資源使用進行控制

 

第九：調用Cinder為虛擬機器建立儲存，後端一般用Ceph

 

想瞭解Kubernetes的人是不是看到這裡已經煩了，不是講kubernetes嗎？怎麼講了這麼多OpenStack?

 

那就再來看張圖，這個是aws建立虛擬機器的知識圖譜，是不是很多類似的概念？

 

 

很多學技術的發現技術發展實在太快，從虛擬化，到OpenStack，到Docker，到Kubernetes等，怎麼學的過來，其實深入瞭解會發現，基礎的技術非常像，包括接下來解析的Kubernetes。

 

三、Kubernetes的架構相對簡單

 

很多人喜歡Docker，以及Docker平台，就在於Docker非常簡單，沒有OpenStack這麼複雜的概念，很容易就能啟動一個nginx的demo。

 

而作為容器管理平台，Kubernetes的架構也是比較簡單的。

 

 

客戶請求進來的時候，先進入api層，相當於nova-api，首先先要進行認證和鑒權(Authentication和Authorization)，相當於keystone做的事情。

 

然後建立的對象會儲存在etcd裡面，如果是OpenStack則在資料庫裡面。

 

接著進行Scheduler，將對象調度到一台機器，相當於nova-scheduler要乾的事情。

 

然後每台機器上的kubelet是真正幹活的，發現自己被調度到了，需要在自己的機器上建立容器，相當於nova-compute。

 

kubelet建立容器的時候，先要下載容器鏡像，nova-compute也要下載虛擬機器的鏡像。

 

nova-compute要調用docker的介面建立容器，相當於nova-compute調用的libvirt建立KVM，docker真正的隔離使用的是cgroup，KVM也要用cgroup，docker還用到了namespace，KVM的網路設定也會用到namespace。

 

docker建立好了，需要給docker配置網路，配置儲存，libvirt也幹了這些事情。

 

四、kubernetes建立pod和service的過程

 

 

• 用戶端調用api介面建立pod。

• api-server將pod建立一個對象，儲存在etcd裡面。

• scheduler不斷通過api-server查看哪些pod需要調度，然後進行調度，將調度結果返回給api-server

• api-server將scheduler的調度結果寫入etcd中。

• kubelet不斷查看有沒有能夠調度到自己機器上的pod，有的話調用docker的介面建立容器。

 

 

• 用戶端調用api介面建立服務。

• api-server建立service對象寫入etcd。

• controller不斷掃描service對應的pod。

• controller調用api-server建立對應的訪問端點endpoint。

• api-server將endpoint對象寫入etcd。

• proxy不斷髮現有沒有可以放在自己上面的轉寄規則，如果有則建立socket監聽連接埠，並且建立相應的iptables規則。

 

五、kubernetes沒有什嗎？

 

Kubernetes看起來比OpenStack簡單很多，其實缺少了很多的功能。

• 沒有完善租戶管理模組，租戶隔離性不好，是否需要一個類似keystone的服務？

• 是不是需要鏡像的管理，難道不需要一個類似glance的服務？

• 鏡像儲存在哪裡，是否需要一個Object Storage Service的服務，類似swift？

• kubernetes本身不管網路，需要通過外掛程式進行，網路和SDN誰來管理？

• kubernetes本身不管儲存，需要通過外掛程式進行，大部分的儲存方案還是通過Ceph搞定。

 

然而，如果要做一個公用雲端，至少要搞定上面的部分，如果把這些都加上去，相當於基於kubernetes重造一個OpenStack了，為什麼要重複造輪子呢？所以我們選擇OpenStack和kubernetes深入融合的解決方案。

 

今天飛機晚點了，本來一天一篇的，應該昨天寫完的只好淩晨完成。

 

接下來會解析OpenStack和kubernetes融合的方案。

 

其實作為公用雲端還有更多的問題：

• 網路二次虛擬化的問題

• 公網和浮動IP的問題

• 一個Kubernetes叢集還是多個Kubernetes叢集？

• Kubernetes叢集如果做到很大規模？

• 等等等等

 

也會在接下來這個系列的文章中詳細闡述

支撐大規模公用雲端的Kubernetes改進與最佳化 (1)