簡介

Kubernetes是一個開源的，用於管理雲平臺中多個主機上的容器化的應用，Kubernetes的目標是讓部署容器化的應用簡單並且高效（powerful）,Kubernetes提供了應用部署，規劃，更新，維護的一種機制。

Kubernetes一個核心的特點就是能夠自主的管理容器來保證雲平臺中的容器按照使用者的期望狀態執行著（比如使用者想讓apache一直執行，使用者不需要關心怎麼去做，Kubernetes會自動去監控，然後去重啟，新建，總之，讓apache一直提供服務），管理員可以載入一個微型服務，讓規劃器來找到合適的位置，同時，Kubernetes也系統提升工具以及人性化方面，讓使用者能夠方便的部署自己的應用（就像canary deployments）。

現在Kubernetes著重於不間斷的服務狀態（比如web伺服器或者快取伺服器）和原生雲平臺應用（Nosql）,在不久的將來會支援各種生產雲平臺中的各種服務，例如，分批，工作流，以及傳統資料庫。

在Kubenetes中，所有的容器均在Pod中執行,一個Pod可以承載一個或者多個相關的容器，在後邊的案例中，同一個Pod中的容器會部署在同一個物理機器上並且能夠共享資源。一個Pod也可以包含O個或者多個磁碟卷組（volumes）,這些卷組將會以目錄的形式提供給一個容器，或者被所有Pod中的容器共享，對於使用者建立的每個Pod,系統會自動選擇那個健康並且有足夠容量的機器，然後建立類似容器的容器,當容器建立失敗的時候，容器會被node agent自動的重啟,這個node agent叫kubelet,但是，如果是Pod失敗或者機器，它不會自動的轉移並且啟動，除非使用者定義了 replication controller。

使用者可以自己建立並管理Pod,Kubernetes將這些操作簡化為兩個操作：基於相同的Pod配置檔案部署多個Pod複製品；建立可替代的Pod當一個Pod掛了或者機器掛了的時候。而Kubernetes API中負責來重新啟動，遷移等行為的部分叫做“replication controller”，它根據一個模板生成了一個Pod,然後系統就根據使用者的需求建立了許多冗餘，這些冗餘的Pod組成了一個整個應用，或者服務，或者服務中的一層。一旦一個Pod被建立，系統就會不停的監控Pod的健康情況以及Pod所在主機的健康情況，如果這個Pod因為軟體原因掛掉了或者所在的機器掛掉了，replication controller 會自動在一個健康的機器上建立一個一摸一樣的Pod,來維持原來的Pod冗餘狀態不變，一個應用的多個Pod可以共享一個機器。

我們經常需要選中一組Pod，例如，我們要限制一組Pod的某些操作，或者查詢某組Pod的狀態，作為Kubernetes的基本機制，使用者可以給Kubernetes Api中的任何物件貼上一組 key:value的標籤，然後，我們就可以通過標籤來選擇一組相關的Kubernetes Api 物件，然後去執行一些特定的操作，每個資源額外擁有一組（很多） keys 和 values,然後外部的工具可以使用這些keys和vlues值進行物件的檢索，這些Map叫做annotations（註釋）。

Kubernetes支援一種特殊的網路模型，Kubernetes建立了一個地址空間，並且不動態的分配埠，它可以允許使用者選擇任何想使用的埠，為了實現這個功能，它為每個Pod分配IP地址。

現代網際網路應用一般都會包含多層服務構成，比如web前臺空間與用來儲存鍵值對的記憶體伺服器以及對應的儲存服務，為了更好的服務於這樣的架構，Kubernetes提供了服務的抽象，並提供了固定的IP地址和DNS名稱，而這些與一系列Pod進行動態關聯，這些都通過之前提到的標籤進行關聯，所以我們可以關聯任何我們想關聯的Pod，當一個Pod中的容器訪問這個地址的時候，這個請求會被轉發到本地代理（kube proxy）,每臺機器上均有一個本地代理，然後被轉發到相應的後端容器。Kubernetes通過一種輪訓機制選擇相應的後端容器，這些動態的Pod被替換的時候,Kube proxy時刻追蹤著，所以，服務的 IP地址（dns名稱），從來不變。

所有Kubernetes中的資源，比如Pod,都通過一個叫URI的東西來區分，這個URI有一個UID,URI的重要組成部分是：物件的型別（比如pod），物件的名字，物件的名稱空間，對於特殊的物件型別，在同一個名稱空間內，所有的名字都是不同的，在物件只提供名稱，不提供名稱空間的情況下，這種情況是假定是預設的名稱空間。UID是時間和空間上的唯一。

（譯者：張志明）

起源

大規模容器叢集管理工具，從Borg到Kubernetes

在Docker 作為高階容器引擎快速發展的同時，Google也開始將自身在容器技術及叢集方面的積累貢獻出來。在Google內部，容器技術已經應用了很多年，Borg系統執行管理著成千上萬的容器應用，在它的支援下，無論是谷歌搜尋、Gmail還是谷歌地圖，可以輕而易舉地從龐大的資料中心中獲取技術資源來支撐服務執行。

Borg是叢集的管理器，在它的系統中，執行著眾多叢集，而每個叢集可由成千上萬的伺服器聯接組成，Borg每時每刻都在處理來自眾多應用程式所提交的成百上千的Job, 對這些Job進行接收、排程、啟動、停止、重啟和監控。正如Borg論文中所說，Borg提供了3大好處:

1）隱藏資源管理和錯誤處理，使用者僅需要關注應用的開發。

2) 服務高可用、高可靠。

3) 可將負載執行在由成千上萬的機器聯合而成的叢集中。

作為Google的競爭技術優勢，Borg理所當然的被視為商業祕密隱藏起來，但當Tiwtter的工程師精心打造出屬於自己的Borg系統（Mesos）時， Google也審時度勢地推出了來源於自身技術理論的新的開源工具。

2014年6月，谷歌雲端計算專家埃裡克·布魯爾（Eric Brewer）在舊金山的釋出會為這款新的開源工具揭牌，它的名字Kubernetes在希臘語中意思是船長或領航員，這也恰好與它在容器叢集管理中的作用吻合，即作為裝載了集裝箱（Container）的眾多貨船的指揮者，負擔著全域性排程和執行監控的職責。

雖然Google推出Kubernetes的目的之一是推廣其周邊的計算引擎（Google Compute Engine）和谷歌應用引擎（Google App Engine）。但Kubernetes的出現能讓更多的網際網路企業可以享受到連線眾多計算機成為叢集資源池的好處。

Kubernetes對計算資源進行了更高層次的抽象，通過將容器進行細緻的組合，將最終的應用服務交給使用者。Kubernetes在模型建立之初就考慮了容器跨機連線的要求，支援多種網路解決方案，同時在Service層次構建叢集範圍的SDN網路。其目的是將服務發現和負載均衡放置到容器可達的範圍，這種透明的方式便利了各個服務間的通訊，併為微服務架構的實踐提供了平臺基礎。而在Pod層次上，作為Kubernetes可操作的最小物件，其特徵更是對微服務架構的原生支援。

Kubernetes專案來源於Borg，可以說是集結了Borg設計思想的精華，並且吸收了Borg系統中的經驗和教訓。

Kubernetes作為容器叢集管理工具，於2015年7月22日迭代到 v 1.0並正式對外公佈，這意味著這個開源容器編排系統可以正式在生產環境使用。與此同時，谷歌聯合Linux基金會及其他合作伙伴共同成立了CNCF基金會( Cloud Native Computing Foundation)，並將Kuberentes 作為首個編入CNCF管理體系的開源專案，助力容器技術生態的發展進步。Kubernetes專案凝結了Google過去十年間在生產環境的經驗和教訓，從Borg的多工Alloc資源塊到Kubernetes的多副本Pod，從Borg的Cell叢集管理，到Kubernetes設計理念中的聯邦叢集，在Docker等高階引擎帶動容器技術興起和大眾化的同時，為容器叢集管理提供獨了到見解和新思路。

（作者：楊樂）