摘要：在的的首次會(huì)議慶祝了其新功能版本的發(fā)布?？梢砸赃@三種方式暴露出來(lái)內(nèi)部外部和負(fù)載均衡。比如，可能會(huì)通過(guò)一個(gè)彈性負(fù)載均衡器接收流量，或者通過(guò)谷歌的負(fù)載均衡器接收。這個(gè)功能令第三方負(fù)載均衡器整合到。負(fù)起了接管發(fā)現(xiàn)任務(wù)和微服務(wù)負(fù)載均衡器的重任。

隨著容器逐漸受到企業(yè)的注意，焦點(diǎn)慢慢被轉(zhuǎn)移到了容器編排工具上。復(fù)雜的工作負(fù)載在生產(chǎn)過(guò)程中需要成熟地被調(diào)度，編排，彈性擴(kuò)容和管理工具。有了Docker，管理運(yùn)行在主機(jī)操作系統(tǒng)上的容器以及它的生命周期變得十分容易了。因?yàn)槿萜骰墓ぷ髫?fù)載運(yùn)行在多個(gè)主機(jī)上，我們需要一些工具在上面管理單個(gè)的容器和單個(gè)的主機(jī)。

Docker數(shù)據(jù)中心，也就是Mesosphere DC／OS和Kubernetes起重要作用的地方。他們可以讓開(kāi)發(fā)者和操作者處理多個(gè)機(jī)器就如同處理跑在集群上的單個(gè)機(jī)器一樣。開(kāi)發(fā)運(yùn)維組人員通過(guò)應(yīng)用程序編程接口（API），命令行接口（CLI）或者專(zhuān)業(yè)工具來(lái)提交工作到容器編排引擎（COE），這個(gè)引擎負(fù)責(zé)管理應(yīng)用程序的生命周期。

COE的集群化版本作為CaaS來(lái)交付，容器作為一種服務(wù)。CaaS的例子包括谷歌GCE，RackSpace的Carina，亞馬遜EC2 容器服務(wù)，Azure容器服務(wù)和Joyent Triton。

Kubernetes，作為一個(gè)開(kāi)源集群管理工具和容器編排引擎，是谷歌內(nèi)部數(shù)據(jù)中心管理工具Borg的簡(jiǎn)化版本。在2015的KubeCon(Kubernetes的首次會(huì)議)慶祝了其新功能1.1版本的發(fā)布。

我寫(xiě)了一篇用Hadoop的商業(yè)實(shí)現(xiàn)來(lái)對(duì)比COE市場(chǎng)格局的文章。有很多初創(chuàng)公司和成立的平臺(tái)在為COE嘗試捕捉企業(yè)市場(chǎng)。Kubernetes脫穎而出，歸功于它來(lái)自谷歌網(wǎng)絡(luò)級(jí)的工作負(fù)載運(yùn)行經(jīng)驗(yàn)的成熟性?；谖业膫€(gè)人經(jīng)驗(yàn)，我在嘗試著調(diào)出可以令Kubernetes為容器標(biāo)準(zhǔn)化的功能。

容器和微服務(wù)有一個(gè)獨(dú)特的屬性——他們一次只運(yùn)行一個(gè)進(jìn)程，有且僅有一個(gè)。虛擬機(jī)運(yùn)行在全棧LAMP應(yīng)用程序上是司空見(jiàn)慣的事，但是同樣的應(yīng)用程序不得不被分裂成至少兩個(gè)容器——一個(gè)用PHP運(yùn)行Apache，另外一個(gè)運(yùn)行MySQL。如果將Memcached和Redis扔到堆棧里，他們同樣需要運(yùn)行在分別的容器中。

這個(gè)模式使得配置發(fā)生了變化。例如，緩存容器應(yīng)該跟網(wǎng)頁(yè)容器緊密相關(guān)。當(dāng)網(wǎng)頁(yè)層通過(guò)運(yùn)行額外的容器擴(kuò)容，緩存容器也需要被擴(kuò)容。當(dāng)request到一個(gè)網(wǎng)頁(yè)容器的時(shí)候，就會(huì)在相應(yīng)的容器緩存里檢查數(shù)據(jù)設(shè)置；如果沒(méi)有找到的話，數(shù)據(jù)庫(kù)查詢就被放到MySQL里了。這個(gè)設(shè)計(jì)被一起調(diào)用來(lái)配對(duì)網(wǎng)頁(yè)和緩存容器，然后將他們一起存在本地主機(jī)上。

在Kubernetes中pod就是可以輕松地給多個(gè)當(dāng)作單個(gè)部署單元的容器貼上標(biāo)簽。他們?cè)谕粋€(gè)主機(jī)上協(xié)作，分享同一個(gè)資源，比如說(shuō)網(wǎng)絡(luò)、存儲(chǔ)系統(tǒng)和節(jié)點(diǎn)存儲(chǔ)。每個(gè)pod得到一個(gè)pod組里面所有容器共享的專(zhuān)用IP地址。到那時(shí)也并非完全如此——每個(gè)運(yùn)行在同一個(gè)pod里面的容器都有著相同的主機(jī)名字，所以他們可以被定為為一個(gè)單元。

當(dāng)一個(gè)pod被擴(kuò)容的時(shí)候，所有在里面的容器被擴(kuò)容為一個(gè)組。這個(gè)設(shè)計(jì)彌補(bǔ)了虛擬化應(yīng)用和容器化應(yīng)用之間的不同。然而當(dāng)保留每個(gè)容器運(yùn)行一個(gè)進(jìn)程的時(shí)候，我們可以輕松地將容器歸到一個(gè)組，使之作為一個(gè)單元。所以，一個(gè)pod在微服務(wù)和Kubernetes的情況下就是一個(gè)新的虛擬機(jī)。即使只有一個(gè)容器需要被配置，它也要按照作為一個(gè)pod來(lái)打包。

Pods管理開(kāi)發(fā)和部署之間的分離問(wèn)題。當(dāng)開(kāi)發(fā)人員注意于他們的代碼的時(shí)候，操作人員來(lái)決定什么進(jìn)入pod。他們組裝相關(guān)的容器，然后通過(guò)pod的定義來(lái)縫合他們。這就有了最終可移植性，因?yàn)樵谶@里容器沒(méi)有進(jìn)行特別打包。簡(jiǎn)單地放這里，一個(gè)pod就是多個(gè)容器鏡像一起管理的密鑰清單。

如果Kubernetes是新的操作系統(tǒng)，那么一個(gè)pod就是一個(gè)新的進(jìn)程。隨著他們變得更加普及，我們會(huì)看到開(kāi)發(fā)運(yùn)維人員將pod密鑰清單轉(zhuǎn)換為多個(gè)容器鏡像。Helm，來(lái)自Deis的制造商，是一個(gè)用作Kubernetes pods市場(chǎng)的服務(wù)的例子。

整體服務(wù)和微服務(wù)之間的一個(gè)重要的差別就是相關(guān)性被發(fā)現(xiàn)的方式。整體指的可能就是一個(gè)專(zhuān)門(mén)IP地址或者一個(gè)DNS分錄，微服務(wù)調(diào)用它之前不得不去發(fā)現(xiàn)相關(guān)性。因?yàn)槿萜骱蚿ods可能會(huì)搬遷到任何節(jié)點(diǎn)。每次一個(gè)容器或者一個(gè)pod復(fù)活，它就會(huì)得到一個(gè)新的IP地址。這樣的話跟蹤端點(diǎn)就變得相當(dāng)難。開(kāi)發(fā)者不得不在發(fā)現(xiàn)后端查詢services，比如etcd，Consul，ZooKeeper或者Sky DNS。這要求代碼級(jí)別的修改來(lái)讓?xiě)?yīng)用程序正確地運(yùn)行。

Kubernetes內(nèi)置服務(wù)發(fā)現(xiàn)功能十分出眾。Kubernetes里面的Services為pods一貫保持定義完善的端點(diǎn)。這些端點(diǎn)仍然是一樣的，即使當(dāng)pods被迫遷移到其它節(jié)點(diǎn)，或者是復(fù)活的時(shí)候也都是一樣的。

多個(gè)pods運(yùn)行在一個(gè)集群的多個(gè)節(jié)點(diǎn)上面，會(huì)被暴露為一個(gè)service。這是微服務(wù)的基本構(gòu)件塊。Service密鑰清單擁有定義和將多個(gè)運(yùn)行為微服務(wù)的pods歸到一個(gè)組的正確標(biāo)簽和選擇器。

例如，所有的Apache網(wǎng)頁(yè)服務(wù)器pods運(yùn)行在集群的任意一個(gè)節(jié)點(diǎn)上，集群匹配了“frontend”節(jié)點(diǎn)，這個(gè)網(wǎng)頁(yè)服務(wù)器會(huì)成為service的一部分。會(huì)帶來(lái)多個(gè)運(yùn)行在集群上一個(gè)端點(diǎn)下的pods的抽象層。這個(gè)service有一個(gè)IP地址和端口組合，當(dāng)然，還有一個(gè)名字。使用者可以根據(jù)IP地址或者service的名字指向service。這個(gè)能力使得它將遺留的應(yīng)用程序移植到容器中十分靈活。

如果多個(gè)容器分享同一個(gè)端點(diǎn)，他們?nèi)绾尉鶆蚪邮芡ㄐ?？這就是負(fù)載均衡性能服務(wù)流進(jìn)來(lái)的地方。這個(gè)功能是Kubernetes和其它COE的關(guān)鍵區(qū)別點(diǎn)。Kubernetes有一個(gè)輕量級(jí)內(nèi)部負(fù)載均衡器，可以路由流量到所有參與服務(wù)的pods。

Service可以以這三種方式暴露出來(lái)：內(nèi)部、外部和負(fù)載均衡。

內(nèi)部：比如數(shù)據(jù)庫(kù)和緩存端點(diǎn)的一定的服務(wù)，不需要被暴露。他們只被其它內(nèi)部pods使用到應(yīng)用程序。這些服務(wù)通過(guò)一個(gè)只在集群中可進(jìn)入的IP地址被暴露，但是沒(méi)有到暴露到外部世界。Kubernetes通過(guò)暴露一個(gè)端點(diǎn)來(lái)隱藏敏感服務(wù)，這個(gè)端點(diǎn)對(duì)于內(nèi)部依賴是可用的。這個(gè)功能通過(guò)隱藏私有pods帶來(lái)一個(gè)額外的安全層。

外部：Service運(yùn)行網(wǎng)頁(yè)服務(wù)器或者公開(kāi)可訪問(wèn)的pods，這些通過(guò)一個(gè)外部端點(diǎn)被暴露出來(lái)。這些端點(diǎn)通過(guò)特定端口在每個(gè)節(jié)點(diǎn)上是可得的。

負(fù)載均衡器：在云提供商提供一個(gè)外部負(fù)載均衡的場(chǎng)景下，service可被連接到那里。比如，pods可能會(huì)通過(guò)一個(gè)彈性負(fù)載均衡器（ELB）接收流量，或者通過(guò)谷歌GCE的HTTP負(fù)載均衡器接收。這個(gè)功能令第三方負(fù)載均衡器整合到Kubernetes service。

Kubernetes負(fù)起了接管發(fā)現(xiàn)任務(wù)和微服務(wù)負(fù)載均衡器的重任。它將陷在底層基礎(chǔ)設(shè)施中處理復(fù)雜的管道的開(kāi)發(fā)運(yùn)維人員解救了出來(lái)。開(kāi)發(fā)人員也可以使用主機(jī)名或者環(huán)境變量的標(biāo)準(zhǔn)管理來(lái)將注意力集中在他們的代碼上，而不需要擔(dān)心額外的代碼（比如注冊(cè)和發(fā)現(xiàn)服務(wù)的）。

(轉(zhuǎn)載請(qǐng)先聯(lián)系我們，尊重知識(shí)產(chǎn)權(quán)人人有責(zé)：）