Kubernetes方法有哪些

這篇文章主要講解了“Kubernetes方法有哪些”，文中的講解內(nèi)容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“Kubernetes方法有哪些”吧！

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

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

COE的集群化版本作為CaaS來交付，容器作為一種服務。CaaS的例子包括谷歌GCE，RackSpace的Carina，亞馬遜EC2 容器服務，Azure容器服務和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)絡級的工作負載運行經(jīng)驗的成熟性。基于我的個人經(jīng)驗，我在嘗試著調(diào)出可以令Kubernetes為容器標準化的功能。

PODs：新虛擬機

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

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

如果Kubernetes是新的操作系統(tǒng)，那么pod就是新的進程

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

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

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

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

Service：可輕松發(fā)現(xiàn)的端點

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

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

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

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

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

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

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

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

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

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

感謝各位的閱讀，以上就是“Kubernetes方法有哪些”的內(nèi)容了，經(jīng)過本文的學習后，相信大家對Kubernetes方法有哪些這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關(guān)知識點的文章，歡迎關(guān)注！