今天和大家分享的內(nèi)容就是青云QingCloud 推出的容器云服務以及基于 Kubernetes 的應用與實踐。

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

　　各種容器的實現(xiàn)，容器的外延非常廣范，用戶選型時經(jīng)常會迷惑，應該選擇什么？大家討論的時候容易產(chǎn)生分歧，因為大家都在說容器，但各自的角度不同，表達的具體內(nèi)容也完全不一樣。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　這時我們實際上是需要有一層 SDN 來解決問題，大多開源容器網(wǎng)絡的解決方案，基本是比較簡易的 SDN。然后我們把這層網(wǎng)絡方案部署到云時會發(fā)現(xiàn)，在云之上已經(jīng)有了一層 SDN。這樣在 SDN 上再做一層 SDN，性能損耗會非常大。

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

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

　　解決網(wǎng)絡后，服務已經(jīng)可以跑起來了。但是我們想在容器里保存數(shù)據(jù)，就遇到存儲的問題。

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

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

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

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

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

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

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

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

　　當 Kubernetes 集群的資源不夠了，它會觸發(fā)一個事件，IaaS 層監(jiān)聽這個事件，收到事件請求之后增加集群的節(jié)點。這樣就實現(xiàn)了業(yè)務應用層的自動伸縮以及 Kubernetes 資源池的伸縮。

　　Kubernetes 本身提供一種擴展機制，可以把一些服務內(nèi)置在里面。

　　我們現(xiàn)在主要內(nèi)置了 DNS，主要用于微服務的應用發(fā)現(xiàn)。如果沒有這種 DNS 服務發(fā)現(xiàn)，應用配置文件會跟具體資源相關聯(lián)，比如數(shù)據(jù)庫 IP，當我們的應用從不同環(huán)境遷移時，比如從測試環(huán)境遷移到生產(chǎn)環(huán)境，我們的配置是就會是異構的。而有 DNS 機制，配置文件就可以完全保持一致。

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