[轉帖]Kubernetes及容器編排的整體介紹【譯】

Kubernetes及容器編排的整體介紹【譯】

翻譯自The New Stack《Kubernetes 生態環境》
做者：JANAKIRAM MSV 和 KRISHNAN SUBRAMANIAN

僅僅在幾年前，不管是舊的cgroup仍是流行的Docker或者CNCF rkt，最可能發揮Linux容器功能的地方仍是在一些開發人員筆記本上的隔離的沙盒環境中。一般它還只是一個實驗環境，最可能是個開發平臺，根本就不是數據中心的一部分。

而今天，容器已經成爲在生產環境中部署新的、基於雲的應用程序的實際選擇。在3到4年的時間內，現代應用程序部署的方式已經從虛擬的基於機器的雲平臺轉變爲有規模的有組織的容器羣。

在本章中，咱們將討論在容器生態系統中的調度編排器（包括Kubernetes），介紹市場上的一些主要的編制工具，並描述它們的各類優勢。

Kubernetes的來歷

容器化的想法並不新鮮。某種形式的虛擬隔離，不管是出於安全性仍是多租戶的目的，自上世紀70年代以來就一直被用於數據中內心。

從chroot系統調用的出現開始，首先是在Unix，後來在BSD中，容器化的思想已經成爲企業IT的通行作法的一部分。從FreeBSD的Jails到Solaris的zones到Warden到LXC，容器一直在不斷髮展，全部的過程都愈來愈接近成爲採用的主流方案。

在容器在開發人員中流行以前，谷歌在Linux容器中運行它的一些核心web服務。2014年，Kubernetes創始人之一的Joe Beda在GlueCon的一次演講中聲稱，谷歌在一週內啓動了超過20億個容器。谷歌管理容器的能力的祕密在於它的內部數據中心管理工具：Borg。

谷歌將Borg改形成一個通用的容器編排調度器，於2014年將其發佈到開源社區，並將其捐贈給2015年Linux基金會的雲計算基礎（CNCF）項目。Red Hat、CoreOS、微軟、中興、Mirantis、華爲、富士通、Weaveworks、IBM、Engine Yard和SOFTICOM都是該項目的主要貢獻者。

在2013年Docker出現之後，容器的採用率發生了爆炸式增加，成爲了那些想要實現IT基礎設施現代化的企業的焦點。這種爆發的趨勢有四個主要緣由：

• 封裝：Docker解決了容器的用戶體驗問題，使它們更容易打包應用程序。在Docker以前，處理容器是很是困難的（Warden是個例外，它是由雲計算平臺抽象出來的）。
• 分發：自從雲計算的出現以來，現代應用程序體系結構逐漸變得更加分散。不管是初創公司仍是大型組織機構，都受到DevOps這種新方法和合做精神的啓發。近年來它們都已將注意力轉向了微服務架構。容器比迄今爲止的其餘各類體系結構設計得更模塊化，更適合於支持微服務。
• 可移植性：開發人員喜歡在任何地方構建應用程序並運行它——將代碼從他們的筆記本電腦推向生產環境，並指望它們在沒有重大修改的狀況下以徹底相同的方式工做。隨着Docker周圍普遍積累了更多的工具，其功能的廣度和深度更有助於開發人員採用容器。
• 速度：儘管在Docker以前已經存在了容器化的形式，但它們在最初的實現中卻啓動很是緩慢——在LXC的狀況下，常常會花費幾分鐘，而使用Docker則把時間縮短爲幾秒鐘。

自2015年7月發佈以來，Kubernetes已經成爲最受歡迎的容器編排引擎。四大公共雲服務提供商中有三家——谷歌、IBM和微軟——都提供了一個基於Kubernetes的服務平臺(CaaS)平臺。而第四名亞馬遜，則剛剛加入了CNCF，並有本身的計劃來支持這個平臺。儘管Amazon以EC2容器服務的形式擁有本身的託管容器平臺，可是AWS以運行了最多Kubernetes集羣而聞名。大型企業，如教育出版商Pearson，飛利浦的物聯網設備部門，TicketMaster，eBay和紐約時報等公司都正在生產環境中運用了Kubernetes技術。

 

什麼是編排？

雖然容器有助於提升開發人員的生產力，但編排工具爲尋求優化DevOps和Ops投資的團隊提供了許多好處。容器編制的一些好處包括:

• 高效的資源管理。
• 服務的無縫擴展。
• 高可用性。
• 在規模上操做開銷較低。
• 一個聲明式模型(對於大多數編制工具)減小了對更加自治化管理的阻礙。
• 操做式基礎設施即服務(IaaS)，但又具有相似平臺即服務(PaaS) 可管理的功能。

容器解決了開發人員的生產力問題，使DevOps工做流變得能夠無縫鏈接。開發人員能夠建立Docker鏡像、運行Docker容器並在該容器中開發代碼。然而，對開發人員生產力的提高並不能自動轉化爲生產環境中的效率。

從開發人員的筆記本電腦的本地環境中分離出的生產環境比原有的規模要大得多。不管您運行成規模的多級應用程序或基於微服務的應用程序，管理大量的容器和支持它們的節點集羣並不是易事。編制是實現規模所需的組件，由於規模須要自動化。

雲計算的分佈式特性帶來了咱們如何感知虛擬機基礎結構的典型轉換。「牛與寵物」的觀點——把一個容器當作牲畜相似的使用單元，而不是最喜歡的動物——幫助重塑了人們對基礎設施根本的觀念。把這個觀念付諸實踐，容器在規模上擴展和完善了收縮和資源可用性的定義。

典型的容器編排平臺的基本特徵包括:

• 調度
• 資源管理
• 服務發現
• 健康檢查
• 自動伸縮
• 更新和升級

目前容器編排市場由開源軟件主導。在本文出版的時候，Kubernetes依然是領導者。但在咱們深刻研究Kubernetes以前，咱們應該花一點時間將其與市場上其餘主要的編制工具進行比較。

Docker Swarm

Docker公司是負責最受歡迎的容器產品的公司，它提供Docker Swarm做爲容器的編制工具。在Docker中，全部容器都是標準化的。在操做系統級別的每一個容器的執行由runc處理，這是遵循Open Container Initiative（OCI）規範的實現。Docker與另外一個開源組件「containerd」一塊兒工做，以管理由runc在特定主機上執行的容器的生命週期。在一個主機操做系統上，Docker、containerd和runc執行程序負責處理容器操做。

圖1.1：典型的Docker Swarm主節點與工做節點之間的配置關係

簡單地說，Swarm——由Docker Swarm編排——是一組運行Docker的節點。如圖1.1所示。Swarm中的一個節點充當其餘節點的管理器，幷包括調度程序和服務發現組件的容器。

Docker的理念要求在容器級別進行標準化，並使用Docker應用程序編程接口（API）來處理業務流程，包括底層基礎設施的使用。Docker Swarm使用現有的Docker API和網絡框架，而不擴展它們，結合Docker Compose工具而更適合構建多容器應用程序。它使開發人員和操做人員更容易將一個應用程序從5個或6個容器擴展到數百個。

注意：Docker Swarm使用Docker API，使它能夠輕鬆地適應現有的容器環境。採用Docker Swarm可能意味着要在Docker上背注一擲，目前，Swarm的調度器選項是有限的。

Apache Mesos

Apache

Mesos是一個開放源碼的集羣管理器，它的出現早於Docker Swarm和Kubernetes。再加上Marathon，一個用於基於容器的應用程序的編排框架，它爲Docker Swarm和Kubernetes提供了一個有效的替代方案。Mesos也可使用其餘框架來同時支持容器化和非容器化的工做負載。

圖1.2：Apache Mesos，構建多種多樣、高性能的工做負載

Mesos的平臺，如圖1.2所示，顯示了節點之間的主/從關係。在這個方案中，分佈式應用程序經過一個稱爲ZooKeeper的組件在集羣之間進行協調。這個ZooKeeper的工做就是爲一個集羣選擇控制節點，或者分配備用控制節點，並用代理逐步分配給每一個其它節點。這些代理創建了主/從關係。在Master中，主守護進程創建了所謂的「框架」，它像橋樑同樣，在主節點和工做節點之間延伸。運行在這個框架上的調度器肯定了哪些工做節點能夠接受資源，而守護進程則設置了要共享的資源。這是一個複雜的方案，但它的優勢是可以適應多種類型和分佈式負載的標準，而不只僅是容器。

與Docker Swarm不一樣，Mesos和Marathon都有本身的API，這使得它們比其餘編配工具更復雜。
然而，Mesos在支持Docker容器和虛擬機(如VMware vSphere和KVM)方面更加靈活。Mesos還支持支持大數據和高性能工做負載框架。

注意: Apache Mesos是混合環境的完美編配工具，它包含容器和非容器的工做負載。儘管Apache Mesos是穩定的，但許多人認爲它爲容器用戶提供了更陡峭的學習曲線。

Kubernetes

Kubernetes最初是由谷歌發起的開源項目，如今是雲計算基礎（CNCF）的一部分，它能夠用很低的運行開銷對容器進行互聯網級規模的無縫管理。

Kubernetes並不固定要求容器的格式，而且使用它本身的API和命令行接口（CLI）來進行容器編排。

圖1.3：Kubernetes的控制器與節點之間的關係，之前也稱爲「minions」

它支持多種容器格式，不僅是包括Docker的，也支持rkt——最初由CoreOS建立，如今是CNCF託管的項目。該系統也是高度模塊化且易於定製的，容許用戶選擇任何調度器、網絡系統、存儲系統和監控工具集。它以單個集羣開始，並能夠無縫地擴展到大規模的 Web應用。

咱們以前提到的一個編排器的六個主要特徵體如今Kubernetes中的如下方面中：

• 調度：Kubernetes調度程序確保在任什麼時候候均可以知足對基礎設施上的資源的需求。
• 資源管理：在Kubernetes的環境中，資源是編排器能夠實例化和管理的邏輯結構，例如服務或應用程序部署。
• 服務發現：Kubernetes支持共享系統的服務，能夠經過名稱來發現。這樣，包含服務的pods能夠在整個物理基礎結構中分佈運行，而沒必要保留網絡服務來定位它們。
• 健康檢查：Kubernetes利用稱爲「活性探針」和「就緒探針」的功能，給編排器提供應用程序狀態的週期性的指示。
• 自動伸縮：使用Kubernetes，當一個pod的指定CPU資源未被充分利用時，pod自動伸縮器能自動生成更多的副本。
• 更新/升級：一個自動化的滾動升級系統使每一個Kubernetes的部署保持更新和穩定。

注意：Kubernetes是由一個很是活躍的社區創建的。它爲用戶提供了更多的選擇來擴展編排引擎以知足他們的需求。因爲它使用了本身的API，因此更熟悉Docker的用戶將會遇到一些學習難點。

Kubernetes 體系結構

如今一個打包爲一組容器的應用程序須要一個足夠健壯的基礎設施來處理集羣的需求和動態編排的壓力。這樣的基礎設施應該爲跨主機的調度、監視、升級和從新定位容器提供支撐。它必須將底層的計算、存儲和網絡原語做爲資源池來處理。每一個容器的工做負載應該可以充分利用提供給它的資源，包括CPU內核、存儲單元和網絡。

圖1.4：從容器編制引擎的角度來看的系統資源層

Kubernetes是一個開放源碼的集羣管理器，它封裝了底層的物理基礎設施，使其更容易在很大規模上運行容器應用程序。一個應用程序，經過Kubernetes的整個生命週期管理，是由一組pod成集合做並協調成一個單元工做的。一個高效的集羣管理器層讓Kubernetes可以有效地將這個應用程序與它的支持基礎結構分離開來，如圖1.4所示。一旦Kubernetes基礎結構被徹底配置好，DevOps團隊就能夠專一於管理已部署的工做負載，而不是管理底層資源池。

Kubernetes API能夠用來建立提供微服務的關鍵構建塊的組件。這些組件是自主的，這意味着它們獨立於其餘組件存在。它們被設計爲鬆散耦合、可擴展和適用於各類工做負載。API爲內部組件提供了這種擴展性，以及在Kubernetes上運行擴展組件和容器。

Pod

Pod是Kubernetes的工做負載管理的核心單元，它充當了共享相同運行環境和資源的容器的邏輯邊界。將相關的容器分組到pod中，就能夠彌補因爲容器化取代了第一代虛擬化所帶來的配置挑戰，從而使其可以一塊兒運行多個相互依賴的進程。

每一個pod是一個或多個使用遠程過程調用（RPC）進行通訊的容器的集合，共享存儲和網絡堆棧。適用的場景是一些容器須要耦合和共存的應用——例如，一個web服務器容器和一個緩存容器。它們很容易被包裝在一個pod裏。一個pod能夠手動伸縮，也能夠經過稱爲水平pod自動伸縮（HPA）的特性來定義。經過這種方法，pod內包裝的容器數量按比例增長。

Pod支持開發和部署之間的功能分離。當開發人員專一於他們的代碼時，操做人員能夠將注意力集中在更廣闊的視角上，考慮相關容器可能被組合成一個功能單元。這樣有助於達到可移植性的最佳數量，由於一個pod只是多個容器鏡像像管理的一個清單。

服務

Kubernetes的服務模型依賴於微服務的最基本、最重要的方面：發現機制。

一個單獨的pod或一個副本集（稍後解釋）能夠經過服務暴露給內部或外部客戶，該服務將一組帶有特定標準的pod聯起來。任何其標籤匹配選擇器的pod將自動被服務發現。該體系結構提供了一種靈活的、鬆散耦合的服務發現機制。

當一個pod被建立時，它被分配一個只有在集羣內訪問的IP地址。但不能保證pod的IP地址在整個生命週期中保持不變。Kubernetes能夠在運行時遷移或從新實例化pod，從而爲pod提供一個新的IP地址。

爲了解決這種不肯定性，服務能確保路由到集羣中適當的pod，而不考慮它的調度節點，每一個服務公開一個IP地址，也可能公開一個DNS地址，這兩個入口都不會改變。須要與一組pod進行通訊的內部或外部用戶將使用該服務的IP地址，或者更常見的DNS地址。這樣，服務就充當了鏈接pod與其餘pod的粘合劑的角色。

服務發現

Kubernetes中的任何API對象，包括一個節點或一個pod，均可能具備與其相關的鍵值對--用於標識和組合共享一個公共特徵或屬性的對象的附加的元數據。Kubernetes引用這些鍵值對做爲標籤。

選擇器是用來查詢與標籤值匹配的Kubernetes對象的一種標準。這種強大的技術支持對象的鬆散耦合。能夠生成新的對象，其標籤與選擇器的值相匹配。標籤和選擇器造成了Kubernetes的主要分組機制，用於標識操做應用的組件。

一個副本集依賴於標籤和選擇器來決定哪一個pod將參與縮放操做。在運行時，能夠經過副本集對pod進行縮放，確保每次部署都運行所需數量的pod。每一個副本集始終維護一個預約義的pod集。

圖1.5：Kubernetes集羣關注的是pod，而它們以服務的方式提供給外面的世界

任何標籤與服務定義的選擇器相匹配的pod將能夠被終端公開訪問。當一個縮放操做由一個副本集發起時，由該操做建立的新pod將當即開始接收流量。而後，服務經過在匹配的pod中路由流量提供基本的負載平衡。

圖1.5描述了服務發現如何在Kubernetes集羣中工做。這裏有三種類型的pod，由紅、綠、黃相間的盒子表明。一個副本控制器已經擴展了這些pod，以在全部可用節點上運行實例。每一個類的pod都經過一個由彩色圓圈表示的服務向客戶發佈。假設每一個pod都有color=value的標籤，它的相關服務將有一個匹配它的選擇器。

當客戶到達紅色服務時，請求被路由到任何與標籤color=red匹配的pod中。若是一個新的紅色pod被縮放調度器產生，那麼它將當即被服務發現，由於它的具備匹配的標籤和選擇器。

能夠將服務配置爲將pod公開給內部和外部的使用者。一個暴露給內部的服務能夠經過一個ClusterIP地址得到，這個地址只能在集羣中路由。不須要暴露給外部的數據庫pod和其餘敏感資源，能夠配置爲使用ClusterIP。當一個服務須要被外部訪問時，它可能經過每一個節點的特定端口來發布，這被稱爲NodePort。在公共雲環境中，Kubernetes能夠提供自動配置的負載平衡器，以便將流量路由到相應的節點。

Master控制節點

與大多數現代分佈式計算平臺同樣，Kubernetes利用了一個主/從架構。 如圖1.6所示，master封裝了從API中運行應用程序的節點，這些節點是與編排調度器進行通訊的。

圖1.6：Master 在Kubernetes體系結構中的位置

Master負責提供Kubernetes API，調度工做負載的部署，管理集羣，並控制整個系統的通訊。如圖1.6所示，Master監視每一個節點上運行的容器以及全部註冊節點的健康狀態。容器鏡像做爲可部署的構件，必須經過私有或公共的鏡像（image）倉庫讓Kubernetes集羣能夠訪問使用。負責調度和運行應用程序的節點從鏡像倉庫中得到應用服務的鏡像。

如圖1.7所示，Kubernetes Master運行如下組件，它們組成了控制面板：

圖1.7：Kubernetes Master的組件

etcd

etcd是由CoreOS開發的，它是一個持久的、輕量級的、分佈式的、鍵值的數據存儲服務，它維護集羣的配置數據。它表示在任什麼時候間點上集羣的整體狀態，做爲惟一的事實數據來源。其餘各類組件和服務監視對etcd存儲進行更改，以保持應用程序達到指望的狀態。該狀態由聲明式策略（其實是一個聲明該應用程序的最佳環境的文件）定義，所以編排調度器能夠經過一系列工做來得到該環境。該策略定義了編排調度器如何處理應用程序的各類屬性，例如實例數量、存儲需求和資源分配。

API Server

API服務器經過HTTP協議以JSON方式發佈Kubernetes API，爲編排調度器的內部和外部端點提供REST接口。CLI、web UI或其餘工具可能向API服務器發出請求。服務器處理並驗證請求，而後更新etcd中API對象的狀態。這使得客戶終端可以跨工做節點來配置工做負載和容器。

Scheduler 調度器

調度器基於對資源可用性評估來爲每一個pod選擇運行的節點，而後跟蹤資源利用率，以確保pod不會超過它分配的限額。它維護和跟蹤資源需求、資源可用性以及各類其餘用戶提供的約束和策略指標；例如，服務質量(QoS)、親和/反親和性需求和局部性數據。操做團隊能夠聲明式的定義資源模型。調度器將這些聲明解釋爲爲每一個工做負載提供和分配正確資源集的指令。

Controller 控制器

控制器是Kubernetes體系結構的一部分，是Master的一部分。控制器的職責是確保集羣始終保持節點和pod的指望狀態。經過咱們所說的指望狀態，達到由pods的YAML配置文件所聲明和請求使用的資源和系統的當前需求和約束的平衡。

控制器經過不斷地監視集羣的健康情況和部署在集羣上的工做負載來維護節點和pod的穩定狀態。例如，當一個節點變得不健康時，在該節點上運行的那些pod可能沒法訪問。在這種狀況下，控制器的任務是在不一樣的節點中調度相同數量的新pod提供服務。這個活動確保集羣在任什麼時候間點都保持預期狀態。

Kubernetes控制器在生產中運行容器化的工做負載時起着相當重要的做用，這使得一個團隊能夠部署和運行容器化的應用程序，這些應用程序複雜程度遠遠超出了典型的無狀態和擴展的場景。控制器管理者負責管理核心Kubernetes控制器：

• ReplicationController （ReplicaSet) 維護集羣中特定部署的pod數目。它保證任什麼時候候都能有指定數量的pod在系統的節點上運行。
• StatefulSet 有狀態集相似於副本集，是對於須要持久性和定義良好的標識符的pod的定義。
• DaemonSet 確保包在一個pod裏的一個或多個容器被運行在集羣的每一個節點中。這是一種特殊類型的控制器，它強制一個pod在每一個節點上運行。做爲DaemonSet的一部分運行中的pod的數量與節點的數量成正比。
• Job和cron job 控制器處理後臺進程和批處理進程。

 

這些控制器與API服務器通訊，以建立、更新和刪除它們管理的資源，如pod和服務節點。

關鍵型應用程序須要更高級別的資源可用性。經過使用一個副本集，Kubernetes確保了預約義的pod數量一直在運行。但這些pod是無狀態的，短暫的。因爲如下緣由，很難運行有狀態的工做負載，例如數據庫集羣或大數據棧：

• 每一個pod在運行時分配一個任意名稱。
• 在任何可用節點上均可以安排一個pod，除非使用關聯規則，在這種狀況下，pod只能在有特定標籤或在規則中指定的標籤的節點上調度。
• 在任什麼時候間點均可以從新啓動和從新定位。
• 一個pod可能永遠不會被它的名稱或IP地址直接引用。

從1.5版本開始，Kubernetes引入了有狀態集(由StatefulSets表示)的概念，用於運行高可用的工做負載。參與有狀態集的有狀態pod具備如下屬性：

• 一個穩定的主機名，它將永遠由DNS解析。
• 一個序數索引號，用來表示副本集中的pod的順序位置。
• 與主機名和序號相關聯的穩定存儲。

穩定的主機名及其序號索引號使一個pod可以以可預測和一致的方式與另外一個pod進行通訊。這是無狀態pod和有狀態pod之間的根本區別。

Node

節點是Kubernetes集羣的工做站，負責運行容器化的工做負載；日誌、監視和服務發現；和可選的附加組件。它的目的是嚮應用程序公開計算、網絡和存儲資源。每一個節點包括一個容器運行時，例如Docker或rkt，以及與控制器Master通訊的代理。節點能夠是在雲中運行的虛擬機(VM)，也能夠是數據中心內的實體機服務器。

如圖1.8所示，每一個節點包含如下內容:

圖1.8：顯示了Kubernetes節點中的大量組件的一個分解視圖

容器運行器

容器運行器負責在節點中運行的每一個容器的生命週期管理。在節點上安排了一個pod以後，容器運行器就會從鏡像倉庫中拉取出pod所指定的鏡像。當一個pod被終止時，運行器將殺死屬於該pod的容器。Kubernetes能夠與任何兼容OCI的容器運行器進行通訊，包括Docker和rkt。

Kubelet

kubelet是確保節點上全部容器都健康運行的組件。它與容器運行器進行通訊，以執行諸如啓動、中止和維護容器等操做。

每一個kubelet還監測pod的狀態。當一個pod不知足副本控制器定義的理想狀態時，它可能在相同的節點上被從新啓動。節點的狀態每隔幾秒經過心跳消息傳遞給控制器。若是控制器檢測到節點故障，副本控制器會觀察到這個狀態的變化，並將這些pod安排到其餘健康的節點上。

Kube-proxy

kube-proxy組件是做爲一個網絡代理和負載均衡器來實現的。它根據IP地址和傳入請求的端口號將流量路由到合適的容器。它還利用了基於os的特定網絡功能，經過操做iptables定義的策略和規則。每一個kube-proxy均可以與特定容器的網絡層集成，如flannel和Calico。

圖1.9：headless服務提供狀態數據庫和服務之間的鏈接點

可使用一個名爲headless服務的東西直接將pod用於外部服務，如緩存、對象存儲和數據庫。如圖1.9所示，這本質上與服務是同樣的，但不須要使用kube-proxy或負載平衡。對headless服務的調用將解析爲服務專門選擇的集羣的IP地址。經過這種方式，您可使用自定義的邏輯來選擇IP地址，繞過正常的路由。

Logging Layer

編排調度器常用日誌記錄做爲在每一個節點上收集資源使用和性能指標的方法，例如CPU、內存、文件和網絡使用。CNCF定義了一個統一的日誌層，用於Kubernetes或其餘的編排調度器，稱爲Fluentd。該組件產生的緣由是Kubernetes 主節點控制器須要跟蹤可用的集羣資源，以及整個基礎設施的健康狀態。

Add-Ins

Kubernetes支持附加插件形式的服務。這些可選的服務（如DNS和儀表板）與其餘應用程序同樣部署，但與諸如Fluentd和kube-proxy等節點上的其餘核心組件集成。例如，儀表板外接程序從Fluentd提取指標，以充分的顯示資源利用率。DNS插件經過名稱解析擴展了kube-proxy。

區分各類Kubernetes平臺

自從雲計算成爲現代企業的規範以來，系統架構師一直困惑如何平衡雲平臺應該採用的封裝方式。適當的封裝能夠提升操做效率，同時提升開發人員的生產力。

在雲計算的早期，虛擬機是計算的基本單元。最終用戶被迫在所謂的IaaS+平臺之間進行選擇，好比AWS，以及像Heroku、Engine Yard、Cloud Foundry和OpenShift這樣的PaaS平臺。封裝級別決定了開發人員對平臺底層基礎結構的直接控制程度。更深層次的封裝意味着開發人員須要使用平臺提供的API來驅動編碼。

如今，容器做爲計算的基本單元出現了，用戶也面臨着相似的問題，關於選擇正確封裝級別的需求。正以下面的表格所示，在容器編排領域有許多不一樣類型的Kubernetes發行版。用戶的需求——包括工做環境、專業知識的可用性以及用戶正在處理的特定場境——將肯定是把容器做爲服務（CaaS）仍是封裝的平臺的重要考慮因素。沒有一個簡單明瞭的框架可以保證完美的知足一切需求。但表1.1多是一個開始。

表1.1：Kubernetes發行類型的比較，從徹底社區生產到徹底商業化

一個CaaS平臺包括Kubernetes項目，和爲其部署和管理提供所需的額外工具。一個封裝好的平臺，在規模化的另外一端，遠遠超出了CaaS提供的運營效率，專一於提升開發人員的生產力。在CaaS中，開發人員須要將他們本身的代碼打包到一個容器中，以便它能夠部署在集羣中。儘管基於docker的容器在開發人員的名義上解決了這個打包問題，封裝好的應用程序平臺還能夠在內部徹底封裝構建容器映像的過程——自動化過程，而不是由開發人員那樣手動控制。一旦他把他的代碼Push到像GitHub這樣的源代碼控制工具上，或者像Jenkins這樣的持續集成/持續交付(CI/ CD)系統裏，開發人員的任務就中止了，而交給平臺作其他的事情。

經過設計，CaaS與Kubernetes開源項目緊密地結合在一塊兒，幫助它大規模的運行和管理容器。但CaaS模型但願開發人員可以處理全部應用程序的依賴項。從文化的角度來看，DevOps模型遵循了Dev和Ops一塊兒與跨功能知識協同工做的文化。在這個場景中，兩個團隊都知道的是完成一件事是須要依賴很長的列表。

封裝好的應用程序平臺使用Kubernetes做爲核心組件，幫助它以比CaaS更少的開銷運行容器。開發人員沒必要擔憂管理運行時或任何應用程序依賴項。相反，他們能夠專一於編寫應用程序代碼並將其推送到源代碼控制存儲庫或CI/CD系統。封裝好的平臺提升了開發人員的生產力，同時削減了底層組件的控制。能夠說DevOps仍然是這個模型的中心。但因爲封裝，並不須要這種跨功能的知識——它變成了冗餘的繁雜工做。開發人員不須要了解Kubernetes的基礎，也不須要了解如何管理它。

正如咱們前面提到的，在CaaS和封裝好平臺之間選擇不存在簡單的框架。您的選擇取決於您的團隊但願達到的開發生產力水平和您所能預見的團隊的特定需求集合。

 

開始使用Kubernetes

這裏有一些方法能夠開始Kubernetes的部署：

1. 註冊一個託管的CaaS服務。
2. 下載並安裝一個單處理器的安裝程序，用於在單個PC上測試Kubernetes，好比CoreOS’Tectonic Sandbox。
3. 經過克隆Kubernetes GitHub repo創建一個本地集羣
4. 嘗試一下Kubernetes集羣，Play withKubernetes，這將給你一個完整的Kubernetes環境，你能夠從你的瀏覽器運行。

包括IBM Bluemix、谷歌雲平臺和微軟Azure在內的公共雲服務提供商提供了託管的Kubernetes做爲服務。經過免費的積分和試用優惠，咱們很容易就能把一個小的Kubernetes集羣用來進行測試。有關在Kubernetes部署第一個應用程序的詳細信息，請參閱您選擇的服務的文檔。

Minikube是一個單節點Kubernetes集羣，用於學習和探索環境。它是強烈推薦給過去沒有經驗的初學者。

在功能更強大的主機上，Kubernetes能夠被配置爲基於Vagrant的多節點集羣。GitHub repo有關於設置Vagrant boxes的說明。