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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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