今天和大家分享的內容就是青云QingCloud 推出的容器云服務(wù)以及基于 Kubernetes 的應用與實(shí)踐。
亂花漸欲迷人眼，容器太多怎么選
容器技術(shù)目前的市場(chǎng)現狀是一家獨大、百花齊放。容器的解決方案非常多，以 Docker 為首占據了大部分的市場(chǎng)，此外還有各種解決方案如 Rocket、Mesos Universal container、LXC、Hyper Container 等。
各種容器的實(shí)現，容器的外延非常廣范，用戶(hù)選型時(shí)經(jīng)常會(huì )迷惑，應該選擇什么？大家討論的時(shí)候容易產(chǎn)生分歧，因為大家都在說(shuō)容器，但各自的角度不同，表達的具體內容也完全不一樣。
總結來(lái)看容器有兩個(gè)視角，一是資源，二是應用。
一是從資源隔離的角度。容器技術(shù)經(jīng)常被拿來(lái)跟虛擬化技術(shù)作對比，從技術(shù)角度來(lái)說(shuō)，容器是一種跟 VM 類(lèi)似的資源隔離技術(shù)，它比 VM 的資源損耗小，但隔離性和安全性不如 VM ，等等。
二是從應用封裝的角度。Docker 之所以興起，原因在于其重點(diǎn)關(guān)注應用的標準化，而不是資源的隔離。Docker 的鏡像機制提供了一種更高級的通用的應用制品包，也就是大家說(shuō)的集裝箱能力。原來(lái)各種操作系統或編程語(yǔ)言都有各自己的制品機制，各自的依賴(lài)管理，制品庫都不相同。應用從源碼打包，分發(fā)到制品庫，再部署到服務(wù)器，很難抽象出一種通用的流程和機制。
而有了 Docker 的鏡像以及鏡像倉庫標準之后，這個(gè)流程終于可以標準化了。同時(shí) Docker 將進(jìn)程的管理，比如啟動(dòng)停止也標準化了。類(lèi)似杯子、筐、集裝箱都是容器，它們的共同特點(diǎn)是能把雜物打包，標準化，方便運輸和定價(jià)。在此之上，容器可以做更高級的邏輯分裝和調度。
柳暗花明又一村，青云方案解你愁
從資源視角和應用視角分析一下青云QingCloud 提供的容器解決方案。
一是容器主機。
就資源視角來(lái)說(shuō)，用戶(hù)希望 VM 能像 Docker 一樣，可對標準進(jìn)程進(jìn)行封裝，使得 VM 也是一個(gè)完整的操作系統。為延續用戶(hù)對 VM 的操作體驗，青云QingCloud 在統一的 IaaS 平臺上同時(shí)支持 VM（Virtual Machine 虛擬主機）與 CM（Container Machine 容器主機），使得用戶(hù)對虛擬化的部署習慣得以沿襲，同時(shí)還可享受容器資源輕量隔離的特點(diǎn)。
一是應用服務(wù)。
就應用視角來(lái)說(shuō)，青云QingCloud 支持容器編排系統，體現在三方面：
- 一是 AppCenter 應用支持 Docker 鏡像；
- 二是容器編排系統可以作為一個(gè)應用放在 AppCenter 上；
- 三是容器可以在 VM 之上部署集群，Mesos、Kubernetes、Swarm 也可以作為云應用放在 AppCenter 之上，讓用戶(hù)可以自主選擇。現在有已經(jīng)有合作伙伴把自己的容器編排系統放在 AppCenter 上。QingCloud 目前也提供 Kubernetes 應用作為容器編排系統給用戶(hù)使用。
為什么是 Kubernetes ?
為什么是 Kubernetes？我們做一個(gè)選擇時(shí)，總有各種選擇的理由。選擇 Kubernetes 主要從這幾個(gè)方面來(lái)看。
一是 Kubernetes 本身部署困難
這不僅僅是 Kubernetes 本身的復雜性帶來(lái)的困難，還因為眾所周知的原因，國外某著(zhù)名公司的服務(wù)在國內都無(wú)法訪(fǎng)問(wèn)，這可能是很多人試用 Kubernetes 的第一道坎。
二是微服務(wù)的需求
微服務(wù)和容器，是當前服務(wù)架構領(lǐng)域最熱門(mén)的技術(shù)。如果不談微服務(wù)，都會(huì )感覺(jué)自己過(guò)時(shí)了。它的敏捷交付、伸縮等優(yōu)勢我不再多說(shuō)，但微服務(wù)架構給我們帶來(lái)最大的挑戰是如何管理這么多服務(wù)。
原來(lái)人工編排的方式難以管理這么多微服務(wù)。如果你能管理，說(shuō)明你的微服務(wù)不夠多，拆分的還不夠細、或是規模還不夠大。在這種情況下，Kubernetes 本身提供的對服務(wù)規范的定義、Deployment 的滾動(dòng)升級，以及 DNS 服務(wù)發(fā)現的支持，都非常好的支持了微服務(wù)，這是我們選擇它的另一個(gè)理由。
三是與云互補
IaaS 更關(guān)注于資源層面，而 Kubernetes 更關(guān)注應用層面，所以這兩者的結合是互補的結果。
目前 QingCloud 已經(jīng)支持用戶(hù)一鍵部署 Kubernetes 集群，不僅解決了用戶(hù)很大的痛點(diǎn)，同時(shí)也驗證了 AppCenter 支持應用的廣泛性。
Kubernetes 服務(wù)背后的五個(gè)難題
接下來(lái)將會(huì )從容器調度系統的網(wǎng)絡(luò )、數據本地存儲的讀取、容器平臺與負載均衡器集成、實(shí)現 Kubernetes 應用的彈性伸縮能力以及集成服務(wù)五個(gè)方面跟大家介紹青云的 Kubernetes 應用，分享我們整個(gè)過(guò)程中做的事情，也讓大家更容易在我們平臺上使用 Kubernetes。
網(wǎng)絡(luò )
首先是網(wǎng)絡(luò )。這應該是除部署外，大家使用 Kubernetes 時(shí)遇到的第二個(gè)檻。因為 Kubernetes 本身沒(méi)有提供網(wǎng)絡(luò )解決方案，它將這部分讓渡給云平臺或社區去解決。
這樣用戶(hù)使用時(shí)會(huì )面臨在眾多社區解決方案中進(jìn)行選型，我們可以回顧一下。Docker 為了解決應用的網(wǎng)絡(luò )端口沖突，給每個(gè)容器分配了一個(gè) IP。當我們的容器只和本主機容器互通時(shí)，這沒(méi)有問(wèn)題，但我們想通過(guò)調度系統把多臺主機的容器連接在一起，就會(huì )遇到網(wǎng)絡(luò )問(wèn)題。
這時(shí)我們實(shí)際上是需要有一層 SDN 來(lái)解決問(wèn)題，大多開(kāi)源容器網(wǎng)絡(luò )的解決方案，基本是比較簡(jiǎn)易的 SDN。然后我們把這層網(wǎng)絡(luò )方案部署到云時(shí)會(huì )發(fā)現，在云之上已經(jīng)有了一層 SDN。這樣在 SDN 上再做一層 SDN，性能損耗會(huì )非常大。
我們的容器主機在 SDN 優(yōu)化下只有 10% 左右的損耗，我們的虛擬主機可能有 25% 多一點(diǎn)的損耗。但是在 SDN 上再做一次 Overlay，我們會(huì )把 75% 的性能都損耗掉。
所以，我們想既然 IaaS 有 SDN，為什么不能把它穿透上來(lái)，直接提供給容器使用？這就是青云的容器網(wǎng)絡(luò )方案，叫做 SDN Passthrough，也就是容器可以和虛擬主機共享一層網(wǎng)絡(luò )。我們基于 Kubernetes CNI 標準做了一個(gè)插件，并且在 GitHub 上進(jìn)行了開(kāi)源，如果大家想部署 Kubernetes 的時(shí)候，也可以使用。
存儲
解決網(wǎng)絡(luò )后，服務(wù)已經(jīng)可以跑起來(lái)了。但是我們想在容器里保存數據，就遇到存儲的問(wèn)題。
用過(guò) Docker 的人可能都知道，使用 Docker 存儲文件時(shí)，我們會(huì )映射主機目錄到 Docker 容器里，然后把文件存在主機目錄上。
但當我們在容器上面架一層調度系統后，調度系統會(huì )有各種各樣的原因將容器遷移到其他主機上，而這種存儲方案是無(wú)法支持遷移的。所以 Kubernetes 推出了自己的 Presistent Volume 標準。
但如 NFS、Ceph 等這分布式存儲系統，他們最大的問(wèn)題是依賴(lài)于網(wǎng)絡(luò )，因此穩定性和性能會(huì )有一點(diǎn)問(wèn)題。所以，我們把 IaaS 的存儲硬盤(pán)映射成 Kubernetes 的持久化存儲卷，當容器在我們的主機之間遷移，我們的存儲卷也可以跟著(zhù)遷移，解決容器狀態(tài)數據存儲遷移的問(wèn)題。
目前已經(jīng)支持性能盤(pán)和容量盤(pán)，未來(lái)也會(huì )支持 NeonSAN 分布式存儲系統。當然，有人會(huì )問(wèn)，如果我們用了青云的 Kubernetes，會(huì )不會(huì )導致我的應用本身遷移遇到問(wèn)題，會(huì )不會(huì )綁定在上面，導致我無(wú)法在不同的 Kubernetes 發(fā)行版之間遷移。這個(gè) Kubernetes 本身考慮到了，它提供的是存儲卷聲明的方式，也就是在 Image 中只是聲明依賴(lài)多少存儲，這個(gè)存儲由誰(shuí)來(lái)提供，應用不用關(guān)心，整個(gè)都是完全透明化的方式。
負載均衡
Kubernetes 本身的負載均衡器提供了一種插件，讓云服務(wù)商實(shí)現插件和 IaaS 層整合。因為最終用戶(hù)暴露的時(shí)候需要一個(gè)公網(wǎng) IP，這個(gè)實(shí)現和各云廠(chǎng)商的服務(wù)是息息相關(guān)的，而 Kubernetes 自己比較難直接提供這樣的服務(wù)，所以它就提供插件讓云服務(wù)商去實(shí)現。
但是云廠(chǎng)商的負載均衡器只能感知到節點(diǎn)主機這一層，對主機里面的容器是無(wú)感的，所以大多數情況下只能把 Kubernetes 集群下所有的節點(diǎn)都掛載到 LoadBalancer之后。前面講到 Service 時(shí)說(shuō)到，Kubernetes 為每一個(gè) Service 都在所有主機上監聽(tīng)一個(gè)隨機的端口，也就是 NodePort，這個(gè)請求會(huì )轉發(fā)到主機的隨機端口上，由隨機端口轉發(fā)到 ClusterIP 上，再由 ClusterIP 轉發(fā)到后面的容器，可以看出，這樣就多了幾層轉發(fā)。
如果負載均衡器能感知到容器的網(wǎng)絡(luò )，就可以直接透傳請求到容器中。我們的負載均衡器后面直接掛在的是容器網(wǎng)卡，這樣就省去了幾層轉發(fā)。同時(shí)我們的支持公網(wǎng)和私網(wǎng)兩種 Load Balancer。因為一般不可能把所有的服務(wù)遷到 Kubernetes，有一部分遷進(jìn)去了，有一部分服務(wù)可能在外面。這種情況下外部服務(wù)訪(fǎng)問(wèn)不了 Kubernetes Service 的 Cluster IP 和 DNS ，這個(gè)時(shí)候需要私網(wǎng)的 Load Balancer 去轉發(fā)這種請求。
彈性伸縮
Kubernetes 提供了本身一種機制，通過(guò)相應命令可自動(dòng)增加 Pod 的節點(diǎn)數。但光有這一層伸縮是不夠的，部署 Kubernetes 集群的時(shí)候，節點(diǎn)數是提前規劃好的。當自動(dòng)伸縮使Kubernetes容量達到上限的時(shí)候，就無(wú)法伸縮了。這個(gè)時(shí)候集群本身需要有自動(dòng)伸縮的功能，當前只有谷歌云實(shí)現了集群的伸縮能力。
當 Kubernetes 集群的資源不夠了，它會(huì )觸發(fā)一個(gè)事件，IaaS 層監聽(tīng)這個(gè)事件，收到事件請求之后增加集群的節點(diǎn)。這樣就實(shí)現了業(yè)務(wù)應用層的自動(dòng)伸縮以及 Kubernetes 資源池的伸縮。
集成服務(wù)
Kubernetes 本身提供一種擴展機制，可以把一些服務(wù)內置在里面。
我們現在主要內置了 DNS，主要用于微服務(wù)的應用發(fā)現。如果沒(méi)有這種 DNS 服務(wù)發(fā)現，應用配置文件會(huì )跟具體資源相關(guān)聯(lián)，比如數據庫 IP，當我們的應用從不同環(huán)境遷移時(shí)，比如從測試環(huán)境遷移到生產(chǎn)環(huán)境，我們的配置是就會(huì )是異構的。而有 DNS 機制，配置文件就可以完全保持一致。
另外一個(gè)是 Kubernetes 本身的一個(gè) Dashboard，還有日志與監控服務(wù)。這個(gè)服務(wù)從日志監控數據收集、存儲、展示是一體化的，應用無(wú)須關(guān)心這些事情。
