Kubernetes方法有哪些

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

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

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

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

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

我寫了一篇用Hadoop的商業實現來對比COE市場格局的文章。有很多初創公司和成立的平臺在為COE嘗試捕捉企業市場。Kubernetes脫穎而出，歸功于它來自谷歌網絡級的工作負載運行經驗的成熟性。基于我的個人經驗，我在嘗試著調出可以令Kubernetes為容器標準化的功能。

PODs：新虛擬機

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

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

如果Kubernetes是新的操作系統，那么pod就是新的進程

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

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

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

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

Service：可輕松發現的端點

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

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

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

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

如果多個容器分享同一個端點，他們如何均勻接受通信？這就是負載均衡性能服務流進來的地方。這個功能是Kubernetes和其它COE的關鍵區別點。Kubernetes有一個輕量級內部負載均衡器，可以路由流量到所有參與服務的pods。

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

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

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

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

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

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