【本文專欄于[頭條号]、[知乎]同步釋出，可關注同名賬号訂閱相關文章，每周固定更新】
【全文5489字，閱讀時間約15分鐘，建議先收藏】
Kubernetes是一個流行的開源平台，重要用于容器編排——也就是說，它用于管理由多個容器建構的應用程式。自2013年Docker容器化項目啟動以來，容器已經變得越來越流行，但是與此同時，大型分布式容器化應用程式會是以變得越來越難以協調。通過使應用程式容器化，我們更容易大規模管理應用程式。而Kubernetes已經成為這場容器革命中關鍵的部分。
先從容器編排談起
容器支援類似虛拟機間的彼此隔離，但是開銷更小，靈活性更大。是以，容器改變了人們對開發、部署和運維的想法。在容器化體系結構中，構成應用程式的不同服務被打包到單獨的容器中，并支援跨實體或虛拟機叢集部署。但是這就産生了對容器編排的需求——這是一種能夠支援對基于容器的應用程式進行自動部署、自動管理、自動擴充、自動組網的工具。
何謂Kubernetes？
Kubernetes最開始隻是一個開源項目，目前已經成為最流行的容器編制工具之一;它允許我們大規模部署和管理多容器應用程式。實際上，Kubernetes最常與Docker一起使用，Docker是目前最流行的容器化平台，它也可以與任何符合開放容器協定(Open container Initiative, OCI)的鏡像格式和運作時标準的容器系統一起運作。而且，由于Kubernetes是開源的，對如何使用它的限制相對較少，是以任何想要運作容器的人都可以自由地使用它，我們可以在任何能夠運作容器的地方使用它——在本地、在公共雲中，或者兩者兼而有之。
谷歌和Kubernetes
Kubernetes最初是谷歌内部的一個項目。它是谷歌内部使用的早期容器管理工具Google Borg的繼承者(雖然不是直接的繼承者)。谷歌在2014年開源了Kubernetes，部分原因是Kubernetes提供的分布式微服務架構使得在雲中運作應用程式變得很容易。谷歌将容器、微服務和Kubernetes的采用視為潛在的推動客戶使用其雲服務的動力(盡管Kubernetes也可以運作在Azure和AWS上)。Kubernetes目前由雲原生計算基金會(Cloud Native Computing Foundation)維護，該基金會本身屬于Linux基金會。
Kubernetes vs Docker&Kubernetes vs Docker Swarm
Kubernetes并沒有取代Docker，而是增強了它。不過，Kubernetes确實取代了一些因Docker而生的進階技術。
Docker Swarm就是這樣一種被取代的技術，它是與Docker捆綁在一起的編排工具。目前我們仍然可以使用Docker Swarm來代替Kubernetes，但是Docker公司已經同意讓Kubernetes成為Docker社群和Docker企業版的一部分。但這也不代表Kubernetes是Docker Swarm的替代品。Kubernetes比Swarm複雜得多，需要更多的配置更多的内容。但是，從長遠來看，這項工作的目的将會帶來巨大的回報——一個更易于管理、更有彈性的應用程式基礎設施。對于開發工作和更小的容器叢集，Docker叢集提供了一個更簡單的選擇。
Kubernetes與Mesos的競争
Kubernetes還有另外一個競争對手——Mesos。Mesos是一個Apache項目，最初由Twitter的開發人員開發;它實際上被看作是谷歌Borg項目的一個解決方案。
Mesos實際上已經提供了容器編排服務，但它的野心遠不止于此。它的目标是成為一種雲作業系統，能夠協調容器和非容器元件。為此，許多不同的平台可以在mesos中運作——包括Kubernetes本身。
Kubernetes 架構：Kubernetes的工作原理
Kubernetes的體系結構使用了各種概念和抽象。其中一些是對現有的、熟悉的概念的變體，但另一些則是針對Kubernetes的。
Kubernetes叢集
最進階别的Kubernetes抽象叢集是指運作Kubernetes的機器組(本身是叢集級應用程式)及其管理的容器。一個Kubernetes叢集必須有一個master，其管理和控制叢集中所有其他Kubernetes機器。一個高度可用的Kubernetes叢集可以跨多台機器建立多個master副本。但是同一時間隻有一個master運作作業排程和controller-manager。
Kubernetes節點和Pod
每個叢集都包含Kubernetes節點。節點可能是實體機器或vm。同樣，這個想法也是抽象的：無論應用程式運作在什麼平台上，Kubernetes都負責在該平台上的部署。Kubernetes甚至可以確定某些容器隻運作在vm或實體機上。
節點運作的pods，這是Kubernetes建立或管理的最基本的對象。每個pod表示Kubernetes中運作的應用程式或程序的單個執行個體，并由一個或多個容器組成。Kubernetes将一個pod中的所有容器視為一個組進行啟動、停止和建立副本。Pods的概念讓使用者更近關注與應用程式上，而不是容器本身。有關Kubernetes需要如何配置的詳細資訊(從pod啟動開始)儲存在Etcd(一個分布式鍵值存儲)中。
在節點上建立和銷毀pod需要符合使用者在pod定義中指定的期望狀态。Kubernetes提供了一個稱為控制器的抽象概念，用于處理吊艙如何向上、展開和向下旋轉的後勤問題。根據所管理的應用程式的類型的不同，對應有幾種不同的類型的控制器。例如，“StatefulSet”控制器用于處理需要持久狀态的應用程式。另一種控制器是deployment控制器，用于将應用程式進行滾動更新或降級，将應用程式更新到新版本，或者在出現問題時将應用程式復原到已知的好版本。
Kubernetes服務
因為pod存在生存和死亡，是以我們需要一個不同的抽象概念來管理應用程式生命周期。應用程式應該是一個持久實體，即使運作組成應用程式的容器的pod本身不是持久的。為此，Kubernetes提供了一個抽象概念稱為service（服務）。
Kubernetes中的服務描述了如何通過網絡通路給定的pod組(或其他Kubernetes對象)。正如Kubernetes文檔所指出的，構成應用程式後端的pod可能會發生變化，但是前端不必知道或跟蹤這些細節。我們隻需要知道service，就可以隐藏後端的細節。
Kubernetes内部的一些片段使情況更加完整。Scheduler元件将工作負載配置設定給各個節點，以便在資源之間實作平衡，進而使部署滿足應用程式要求。controller manager元件確定應用程式、工作負載等的系統狀态比對Etcd中設定的預期狀态。
需要記住的是，容器使用的任何底層機制(如Docker本身)都不會被Kubernetes所替代。相反，Kubernetes将如何使用這些機制以保證應用程式規模化運作進行了抽象。
Kubernetes入口
Kubernetes服務被認為是在叢集中運作的。但是您希望能夠從外部通路這些服務。Kubernetes有幾個元件可以以不同程度的簡化和健壯性來實作這一需求，包括NodePort和LoadBalancer，但是最靈活的元件是Ingress。Ingress是一個API，用于管理對叢集服務的外部通路，通常通過HTTP方式進行。
Ingress确實需要一些配置來正确設定。（Matthew Palmer寫了一本關于Kubernetes開發的書，他在他的網站上介紹了如何配置Ingress）
Kubernetes Dashboard（儀表闆）
Kubernetes的一個元件Dashboard可以幫助我們控制所有其他元件，這是一個基于web的UI，我們可以使用它部署和定位并處理應用程式故障，管理叢集資源。Dashboard預設情況下沒有安裝，但是我們能很容易的把它部署到叢集中。
Kubernetes的優勢
因為Kubernetes引入了新的抽象和概念，而且Kubernetes的學習周期較長，是以通常會問使用Kubernetes的長期回報是什麼。下面舉了一些具體方案來告訴你在Kubernetes内部運作應用程式會變得更簡單。
Kubernetes為我們管理應用程式健康狀況、副本、負載平衡和硬體資源配置設定
Kubernetes最基本的職責之一就是保持應用程式的正常運作和響應使用者的需求。那些變得“不健康”，或者不符合我們的健康定義的應用程式，Kubernetes可以幫我們自動修複。
Kubernetes提供的另一個好處是最大限度地使用硬體資源，包括記憶體、存儲I/O和網絡帶寬。應用程式可以對其資源使用設定寬松的限制和硬性限制。許多使用最少資源的應用程式可以打包在同一個硬體裝置上。需要擴充的應用程式可以放在有增長空間的系統上。同樣，跨叢集更新，或者在更新中斷時復原，都可以實作自動化。
Kubernetes使用Helm charts簡化了預配置應用程式的部署
像Debian Linux的APT和Python的Pip這樣的包管理器為使用者省去了手動安裝和配置應用程式的麻煩。當應用程式擁有多個外部依賴項時，這個功能顯得尤其友善。
Helm本質上是Kubernetes的一個包管理器。許多當下流行的軟體應用程式必須作為一組互相依賴的容器在Kubernetes中運作。Helm提供了一種定義方法，即“圖表”，它描述了如何将應用程式或服務作為Kubernetes中的一組容器運作。
如果你正在建構一個私有的自定義應用程式，你就必須從頭開始建立你自己的Helm charts。但是，如果您使用的是具有公共部署模式的流行應用程式，那麼很可能已經有人為它編寫了一個Helm chart，并将其釋出到官方Helm charts存儲庫中。另一個尋找官方Helm charts的地方是Kubeapps.com目錄。
Kubernetes簡化了對存儲、secrets和其他應用程式相關資源的管理
容器通常是不可變的，不管你往裡面放什麼都不應該改變。但是應用程式需要狀态，這意味着它們需要一種可靠的方法來處理外部存儲卷。這使得容器在應用程式的一個生命周期中生存、死亡和重生的方式都變得更加複雜。
Kubernetes提供了抽象概念，允許容器和應用程式以與其他資源相同的解耦方式進行存儲。許多常見的存儲類型，從Amazon EBS卷到普通的NFS共享，都可以通過Kubernetes存儲驅動程式(稱為卷)通路。通常，卷被綁定到一個特定的pod，但是一個稱為“持久卷”的子類型可以用于存儲需要獨立于任何pod生存的資料。
容器通常需要與“secrets”一起工作—諸如API密鑰或服務密碼之類的證書。我們不希望這些證書寫死到容器中或公開存儲在磁盤卷中。雖然第三方解決方案可以做到這一點，比如Docker secrets和HashiCorp Vault，Kubernetes也有自己的機制來處理原生的secrets來保證這些secrets能被小心儲存。例如，Etcd必須配置為在節點之間發送秘密時使用SSL/TLS，而不是使用純文字。
Kubernetes應用程式可以在混合雲和多重雲環境中運作
雲計算的一個長期夢想是能夠在任何雲環境中，或者在任何公有或私有雲的混合雲中運作任何應用程式。這不僅可以避免廠商壟斷，還可以更好的利用有别單一雲環境的優勢。
Kubernetes提供了一組基本類型，統稱為聯邦，用于保持跨多個區域和雲的多個叢集之間的同步。例如，一個給定的應用程式部署可以在多個叢集之間保持一緻，不同的叢集可以共享服務發現，以便可以從任何叢集通路後端資源。聯邦還可以用于建立高可用性或容錯性高的Kubernetes部署，無論我們是否跨多個雲環境。
對Kubernetes來說，聯邦還相對較新。并不是所有的API資源都支援跨聯邦執行個體。但是這些缺點将在Kubernetes的未來版本中得到解決。
擷取Kubernetes
Kubernetes有很多可用的形式——從開源版本到商業支援的發行版，再到公共雲服務——最好的方法是根據用例來确定從哪裡獲得它。
- 如果想自己完成所有工作，可以從Kubernetes的GitHub存儲庫下載下傳源代碼和大多數常見平台的預建構二進制檔案。
- 如果您正在使用Docker社群或Docker Enterprise，Docker的最新版本附帶了Kubernetes安裝包。對于docker專家來說，這顯然是比Kubernetes更容易上手的方法，因為你使用你已經很熟悉的産品實作的。
- 如果您正在進行内部部署或在私有雲中部署，選擇一個基礎架構中内置Kubernetes的私有雲都是有利的。标準發行版、認證版和受支援的Kubernetes發行版可以從幾十個供應商獲得，包括Canonical、IBM、Mesosphere、Mirantis、Oracle、Pivotal、Red Hat、Suse、VMware等等。
- 如果您在公共雲中部署服務，三大公共雲供應商都提供Kubernetes作為服務。谷歌雲平台提供了谷歌Kubernetes引擎。微軟Azure提供Azure Kubernetes服務。亞馬遜已經将Kubernetes添加到其現有的彈性容器服務中。托管Kubernetes服務還可以從IBM、Nutanix、Oracle、Pivotal、Platform9、Rancher Labs、Red Hat、VMware和許多其他供應商獲得。
