Kubernetes 開源以來，受到了越來越多企業及開發者的青睞，隨著 Kubernetes 社區及各大廠商的不斷改進發展，Kuberentes 有望成為容器管理領域的領導者。

今天和大家分享的內容就是青雲QingCloud 推出的容器雲服務以及基於 Kubernetes 的應用與實踐。

亂花漸欲迷人眼，容器太多怎麼選

容器技術目前的市場現狀是一家獨大、百花齊放。容器的解決方案非常多，以 Docker 為首佔據了大部分的市場，此外還有各種解決方案如 Rocket、Mesos Universal container、LXC、Hyper Container 等。

各種容器的實現，容器的外延非常廣範，用戶選型時經常會迷惑，應該選擇什麼？大家討論的時候容易產生分歧，因為大家都在說容器，但各自的角度不同，表達的具體內容也完全不一樣。

總結來看容器有兩個視角，一是資源，二是應用。

一是從資源隔離的角度。容器技術經常被拿來跟虛擬化技術作對比，從技術角度來說，容器是一種跟 VM 類似的資源隔離技術，它比 VM 的資源損耗小，但隔離性和安全性不如 VM ，等等。

二是從應用封裝的角度。Docker 之所以興起，原因在於其重點關注應用的標準化，而不是資源的隔離。Docker 的鏡像機制提供了一種更高級的通用的應用製品包，也就是大家說的集裝箱能力。原來各種操作系統或編程語言都有各自己的製品機制，各自的依賴管理，製品庫都不相同。應用從源碼打包，分發到製品庫，再部署到服務器，很難抽象出一種通用的流程和機制。

而有了 Docker 的鏡像以及鏡像倉庫標準之後，這個流程終於可以標準化了。同時 Docker 將進程的管理，比如啟動停止也標準化了。類似杯子、筐、集裝箱都是容器，它們的共同特點是能把雜物打包，標準化，方便運輸和定價。在此之上，容器可以做更高級的邏輯分裝和調度。

柳暗花明又一村，青雲方案解你愁

從資源視角和應用視角分析一下青雲QingCloud 提供的容器解決方案。

一是容器主機。

就資源視角來說，用戶希望 VM 能像 Docker 一樣，可對標準進程進行封裝，使得 VM 也是一個完整的操作系統。為延續用戶對 VM 的操作體驗，青雲QingCloud 在統一的 IaaS 平臺上同時支持 VM（Virtual Machine 虛擬主機）與 CM（Container Machine 容器主機），使得用戶對虛擬化的部署習慣得以沿襲，同時還可享受容器資源輕量隔離的特點。

一是應用服務。

就資源視角來說，用戶希望 VM 能像 Docker 一樣，可對標準進程進行封裝，使得 VM 也是一個完整的操作系統。為延續用戶對 VM 的操作體驗，青雲QingCloud 在統一的 IaaS 平臺上同時支持 VM（Virtual Machine 虛擬主機）與 CM（Container Machine 容器主機），使得用戶對虛擬化的部署習慣得以沿襲，同時還可享受容器資源輕量隔離的特點。

一是應用服務。

就應用視角來說，青雲QingCloud 支持容器編排系統，體現在三方面：

• 一是 AppCenter 應用支持 Docker 鏡像；

• 二是容器編排系統可以作為一個應用放在 AppCenter 上；

• 三是容器可以在 VM 之上部署集群，Mesos、Kubernetes、Swarm 也可以作為雲應用放在 AppCenter 之上，讓用戶可以自主選擇。現在有已經有合作伙伴把自己的容器編排系統放在 AppCenter 上。QingCloud 目前也提供 Kubernetes 應用作為容器編排系統給用戶使用。

為什麼是 Kubernetes ?

為什麼是 Kubernetes？我們做一個選擇時，總有各種選擇的理由。選擇 Kubernetes 主要從這幾個方面來看。

一是 Kubernetes 本身部署困難

這不僅僅是 Kubernetes 本身的複雜性帶來的困難，還因為眾所周知的原因，國外某著名公司的服務在國內都無法訪問，這可能是很多人試用 Kubernetes 的第一道坎。

二是微服務的需求

微服務和容器，是當前服務架構領域最熱門的技術。如果不談微服務，都會感覺自己過時了。它的敏捷交付、伸縮等優勢我不再多說，但微服務架構給我們帶來最大的挑戰是如何管理這麼多服務。

原來人工編排的方式難以管理這麼多微服務。如果你能管理，說明你的微服務不夠多，拆分的還不夠細、或是規模還不夠大。在這種情況下，Kubernetes 本身提供的對服務規範的定義、Deployment 的滾動升級，以及 DNS 服務發現的支持，都非常好的支持了微服務，這是我們選擇它的另一個理由。

三是與雲互補

IaaS 更關注於資源層面，而 Kubernetes 更關注應用層面，所以這兩者的結合是互補的結果。

目前 QingCloud 已經支持用戶一鍵部署 Kubernetes 集群，不僅解決了用戶很大的痛點，同時也驗證了 AppCenter 支持應用的廣泛性。

Kubernetes 服務背後的五個難題

接下來將會從容器調度系統的網絡、數據本地存儲的讀取、容器平臺與負載均衡器集成、實現 Kubernetes 應用的彈性伸縮能力以及集成服務五個方面跟大家介紹青雲的 Kubernetes 應用，分享我們整個過程中做的事情，也讓大家更容易在我們平臺上使用 Kubernetes。

網絡

首先是網絡。這應該是除部署外，大家使用 Kubernetes 時遇到的第二個檻。因為 Kubernetes 本身沒有提供網絡解決方案，它將這部分讓渡給雲平臺或社區去解決。

這樣用戶使用時會面臨在眾多社區解決方案中進行選型，我們可以回顧一下。Docker 為了解決應用的網絡端口衝突，給每個容器分配了一個 IP。當我們的容器只和本主機容器互通時，這沒有問題，但我們想通過調度系統把多臺主機的容器連接在一起，就會遇到網絡問題。

這時我們實際上是需要有一層 SDN 來解決問題，大多開源容器網絡的解決方案，基本是比較簡易的 SDN。然後我們把這層網絡方案部署到雲時會發現，在雲之上已經有了一層 SDN。這樣在 SDN 上再做一層 SDN，性能損耗會非常大。

我們的容器主機在 SDN 優化下只有 10% 左右的損耗，我們的虛擬主機可能有 25% 多一點的損耗。但是在 SDN 上再做一次 Overlay，我們會把 75% 的性能都損耗掉。

所以，我們想既然 IaaS 有 SDN，為什麼不能把它穿透上來，直接提供給容器使用？這就是青雲的容器網絡方案，叫做 SDN Passthrough，也就是容器可以和虛擬主機共享一層網絡。我們基於 Kubernetes CNI 標準做了一個插件，並且在 GitHub 上進行了開源，如果大家想部署 Kubernetes 的時候，也可以使用。

存儲

解決網絡後，服務已經可以跑起來了。但是我們想在容器裡保存數據，就遇到存儲的問題。

用過 Docker 的人可能都知道，使用 Docker 存儲文件時，我們會映射主機目錄到 Docker 容器裡，然後把文件存在主機目錄上。

但當我們在容器上面架一層調度系統後，調度系統會有各種各樣的原因將容器遷移到其他主機上，而這種存儲方案是無法支持遷移的。所以 Kubernetes 推出了自己的 Presistent Volume 標準。

但如 NFS、Ceph 等這分佈式存儲系統，他們最大的問題是依賴於網絡，因此穩定性和性能會有一點問題。所以，我們把 IaaS 的存儲硬盤映射成 Kubernetes 的持久化存儲卷，當容器在我們的主機之間遷移，我們的存儲卷也可以跟著遷移，解決容器狀態數據存儲遷移的問題。

目前已經支持性能盤和容量盤，未來也會支持 NeonSAN 分佈式存儲系統。當然，有人會問，如果我們用了青雲的 Kubernetes，會不會導致我的應用本身遷移遇到問題，會不會綁定在上面，導致我無法在不同的 Kubernetes 發行版之間遷移。這個 Kubernetes 本身考慮到了，它提供的是存儲卷聲明的方式，也就是在 Image 中只是聲明依賴多少存儲，這個存儲由誰來提供，應用不用關心，整個都是完全透明化的方式。

負載均衡

Kubernetes 本身的負載均衡器提供了一種插件，讓雲服務商實現插件和 IaaS 層整合。因為最終用戶暴露的時候需要一個公網 IP，這個實現和各雲廠商的服務是息息相關的，而 Kubernetes 自己比較難直接提供這樣的服務，所以它就提供插件讓雲服務商去實現。

但是雲廠商的負載均衡器只能感知到節點主機這一層，對主機裡面的容器是無感的，所以大多數情況下只能把 Kubernetes 集群下所有的節點都掛載到 LoadBalancer之後。前面講到 Service 時說到，Kubernetes 為每一個 Service 都在所有主機上監聽一個隨機的端口，也就是 NodePort，這個請求會轉發到主機的隨機端口上，由隨機端口轉發到 ClusterIP 上，再由 ClusterIP 轉發到後面的容器，可以看出，這樣就多了幾層轉發。

如果負載均衡器能感知到容器的網絡，就可以直接透傳請求到容器中。我們的負載均衡器後面直接掛在的是容器網卡，這樣就省去了幾層轉發。同時我們的支持公網和私網兩種 Load Balancer。因為一般不可能把所有的服務遷到 Kubernetes，有一部分遷進去了，有一部分服務可能在外面。這種情況下外部服務訪問不了 Kubernetes Service 的 Cluster IP 和 DNS ，這個時候需要私網的 Load Balancer 去轉發這種請求。

彈性伸縮

Kubernetes 提供了本身一種機制，通過相應命令可自動增加 Pod 的節點數。但光有這一層伸縮是不夠的，部署 Kubernetes 集群的時候，節點數是提前規劃好的。當自動伸縮使Kubernetes容量達到上限的時候，就無法伸縮了。這個時候集群本身需要有自動伸縮的功能，當前只有谷歌雲實現了集群的伸縮能力。

當 Kubernetes 集群的資源不夠了，它會觸發一個事件，IaaS 層監聽這個事件，收到事件請求之後增加集群的節點。這樣就實現了業務應用層的自動伸縮以及 Kubernetes 資源池的伸縮。

集成服務

Kubernetes 本身提供一種擴展機制，可以把一些服務內置在裡面。

我們現在主要內置了 DNS，主要用於微服務的應用發現。如果沒有這種 DNS 服務發現，應用配置文件會跟具體資源相關聯，比如數據庫 IP，當我們的應用從不同環境遷移時，比如從測試環境遷移到生產環境，我們的配置是就會是異構的。而有 DNS 機制，配置文件就可以完全保持一致。

另外一個是 Kubernetes 本身的一個 Dashboard，還有日誌與監控服務。這個服務從日誌監控數據收集、存儲、展示是一體化的，應用無須關心這些事情。