# 簡介
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等高級引擎帶動容器技術興起和大眾化的同時，為容器集群管理提供獨了到見解和新思路。
