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