共計 3027 個字符，預計需要花費 8 分鐘才能閱讀完成。
這篇文章主要講解了“Kubernetes 方法有哪些”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著丸趣 TV 小編的思路慢慢深入，一起來研究和學習“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 可以以這三種方式暴露出來：內部、外部和負載均衡。
內部：比如數據庫和緩存端點的一定的服務，不需要被暴露。他們只被其它內部 pods 使用到應用程序。這些服務通過一個只在集群中可進入的 IP 地址被暴露，但是沒有到暴露到外部世界。Kubernetes 通過暴露一個端點來隱藏敏感服務，這個端點對于內部依賴是可用的。這個功能通過隱藏私有 pods 帶來一個額外的安全層。
外部：Service 運行網頁服務器或者公開可訪問的 pods，這些通過一個外部端點被暴露出來。這些端點通過特定端口在每個節點上是可得的。
負載均衡器：在云提供商提供一個外部負載均衡的場景下，service 可被連接到那里。比如，pods 可能會通過一個彈性負載均衡器（ELB）接收流量，或者通過谷歌 GCE 的 HTTP 負載均衡器接收。這個功能令第三方負載均衡器整合到 Kubernetes service。
Kubernetes 負起了接管發現任務和微服務負載均衡器的重任。它將陷在底層基礎設施中處理復雜的管道的開發運維人員解救了出來。開發人員也可以使用主機名或者環境變量的標準管理來將注意力集中在他們的代碼上，而不需要擔心額外的代碼（比如注冊和發現服務的）。
感謝各位的閱讀，以上就是“Kubernetes 方法有哪些”的內容了，經過本文的學習后，相信大家對 Kubernetes 方法有哪些這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是丸趣 TV，丸趣 TV 小編將為大家推送更多相關知識點的文章，歡迎關注！
