一、簡介
1、Kubernetes代碼託管在GitHub上：https://github.com/kubernetes/kubernetes/。
2、Kubernetes是一個開源的，容器集羣管理系統，Kubernetes的目標是讓部署容器化的應用簡單並且高效（powerful）,Kubernetes提供了應用部署，規劃，更新，維護的一種機制。通過Kubernetes你可以：
- 快速部署應用
- 快速擴展應用
- 無縫對接新的應用功能
- 節省資源，優化硬件資源的使用
3、Kubernetes一個核心的特點就是能夠自主的管理容器來保證雲平臺中的容器按照用戶的期望狀態運行着（比如用戶想讓apache一直運行，用戶不需要關心怎麼去做，Kubernetes會自動去監控，然後去重啓，新建，總之，讓apache一直提供服務），管理員可以加載一個微型服務，讓規劃器來找到合適的位置，同時，Kubernetes也系統提升工具以及人性化方面，讓用戶能夠方便的部署自己的應用（就像canary deployments）。
4、現在Kubernetes着重於不間斷的服務狀態（比如web服務器或者緩存服務器）和原生雲平臺應用（Nosql）,在不久的將來會支持各種生產雲平臺中的各種服務，例如，分批，工作流，以及傳統數據庫。
5、在Kubenetes中，所有的容器均在Pod中運行,一個Pod可以承載一個或者多個相關的容器，在後邊的案例中，同一個Pod中的容器會部署在同一個物理機器上並且能夠共享資源。一個Pod也可以包含O個或者多個磁盤卷組（volumes）,這些卷組將會以目錄的形式提供給一個容器，或者被所有Pod中的容器共享，對於用戶創建的每個Pod,系統會自動選擇那個健康並且有足夠容量的機器，然後創建類似容器的容器,當容器創建失敗的時候，容器會被node agent自動的重啓,這個node agent叫kubelet,但是，如果是Pod失敗或者機器，它不會自動的轉移並且啓動，除非用戶定義了 replication controller。
6、用戶可以自己創建並管理Pod,Kubernetes將這些操作簡化爲兩個操作：基於相同的Pod配置文件部署多個Pod複製品；創建可替代的Pod當一個Pod掛了或者機器掛了的時候。而Kubernetes API中負責來重新啓動，遷移等行爲的部分叫做“replication controller”，它根據一個模板生成了一個Pod,然後系統就根據用戶的需求創建了許多冗餘，這些冗餘的Pod組成了一個整個應用，或者服務，或者服務中的一層。一旦一個Pod被創建，系統就會不停的監控Pod的健康情況以及Pod所在主機的健康情況，如果這個Pod因爲軟件原因掛掉了或者所在的機器掛掉了，replication controller 會自動在一個健康的機器上創建一個一摸一樣的Pod,來維持原來的Pod冗餘狀態不變，一個應用的多個Pod可以共享一個機器。
7、我們經常需要選中一組Pod，例如，我們要限制一組Pod的某些操作，或者查詢某組Pod的狀態，作爲Kubernetes的基本機制，用戶可以給Kubernetes Api中的任何對象貼上一組 key:value的標籤，然後，我們就可以通過標籤來選擇一組相關的Kubernetes Api 對象，然後去執行一些特定的操作，每個資源額外擁有一組（很多） keys 和 values,然後外部的工具可以使用這些keys和vlues值進行對象的檢索，這些Map叫做annotations（註釋）。
8、Kubernetes支持一種特殊的網絡模型，Kubernetes創建了一個地址空間，並且不動態的分配端口，它可以允許用戶選擇任何想使用的端口，爲了實現這個功能，它爲每個Pod分配IP地址。
9、現代互聯網應用一般都會包含多層服務構成，比如web前臺空間與用來存儲鍵值對的內存服務器以及對應的存儲服務，爲了更好的服務於這樣的架構，Kubernetes提供了服務的抽象，並提供了固定的IP地址和DNS名稱，而這些與一系列Pod進行動態關聯，這些都通過之前提到的標籤進行關聯，所以我們可以關聯任何我們想關聯的Pod，當一個Pod中的容器訪問這個地址的時候，這個請求會被轉發到本地代理（kube proxy）,每臺機器上均有一個本地代理，然後被轉發到相應的後端容器。Kubernetes通過一種輪訓機制選擇相應的後端容器，這些動態的Pod被替換的時候,Kube proxy時刻追蹤着，所以，服務的 IP地址（dns名稱），從來不變。
10、所有Kubernetes中的資源，比如Pod,都通過一個叫URI的東西來區分，這個URI有一個UID,URI的重要組成部分是：對象的類型（比如pod），對象的名字，對象的命名空間，對於特殊的對象類型，在同一個命名空間內，所有的名字都是不同的，在對象只提供名稱，不提供命名空間的情況下，這種情況是假定是默認的命名空間。UID是時間和空間上的唯一。
二、起源—大規模容器集羣管理工具，從Borg到Kubernetes
1、在Docker 作爲高級容器引擎快速發展的同時，Google也開始將自身在容器技術及集羣方面的積累貢獻出來。在Google內部，容器技術已經應用了很多年，Borg系統運行管理着成千上萬的容器應用，在它的支持下，無論是谷歌搜索、Gmail還是谷歌地圖，可以輕而易舉地從龐大的數據中心中獲取技術資源來支撐服務運行。
2、Borg是集羣的管理器，在它的系統中，運行着衆多集羣，而每個集羣可由成千上萬的服務器聯接組成，Borg每時每刻都在處理來自衆多應用程序所提交的成百上千的Job, 對這些Job進行接收、調度、啓動、停止、重啓和監控。正如Borg論文中所說，Borg提供了3大好處:
1）隱藏資源管理和錯誤處理，用戶僅需要關注應用的開發。
2) 服務高可用、高可靠。
3) 可將負載運行在由成千上萬的機器聯合而成的集羣中。
3、作爲Google的競爭技術優勢，Borg理所當然的被視爲商業祕密隱藏起來，但當Tiwtter的工程師精心打造出屬於自己的Borg系統（Mesos）時， Google也審時度勢地推出了來源於自身技術理論的新的開源工具。
4、2014年6月，谷歌雲計算專家埃裏克·布魯爾（Eric Brewer）在舊金山的發佈會爲這款新的開源工具揭牌，它的名字Kubernetes在希臘語中意思是船長或領航員，這也恰好與它在容器集羣管理中的作用吻合，即作爲裝載了集裝箱（Container）的衆多貨船的指揮者，負擔着全局調度和運行監控的職責。
5、雖然Google推出Kubernetes的目的之一是推廣其周邊的計算引擎（Google Compute Engine）和谷歌應用引擎（Google App Engine）。但Kubernetes的出現能讓更多的互聯網企業可以享受到連接衆多計算機成爲集羣資源池的好處。
6、Kubernetes對計算資源進行了更高層次的抽象，通過將容器進行細緻的組合，將最終的應用服務交給用戶。Kubernetes在模型建立之初就考慮了容器跨機連接的要求，支持多種網絡解決方案，同時在Service層次構建集羣範圍的SDN網絡。其目的是將服務發現和負載均衡放置到容器可達的範圍，這種透明的方式便利了各個服務間的通信，併爲微服務架構的實踐提供了平臺基礎。而在Pod層次上，作爲Kubernetes可操作的最小對象，其特徵更是對微服務架構的原生支持。
7、Kubernetes項目來源於Borg，可以說是集結了Borg設計思想的精華，並且吸收了Borg系統中的經驗和教訓。
8、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等高級引擎帶動容器技術興起和大衆化的同時，爲容器集羣管理提供獨了到見解和新思路。
三、Kubernetes 特點
1、可移植：支持公有云，私有云，混合雲，多重雲（multi-cloud）
2、可擴展：模塊化, 插件化, 可掛載, 可組合
3、自動化：自動部署，自動重啓，自動複製，自動伸縮/擴展
四、爲什麼要使用容器？
1、傳統部署和容器部署
傳統的應用部署方式是通過插件或腳本來安裝應用。這樣做的缺點是應用的運行、配置、管理、所有生存週期將與當前操作系統綁定，這樣做並不利於應用的升級更新/回滾等操作，當然也可以通過創建虛機的方式來實現某些功能，但是虛擬機非常重，並不利於可移植性。
新的方式是通過部署容器方式實現，每個容器之間互相隔離，每個容器有自己的文件系統 ，容器之間進程不會相互影響，能區分計算資源。相對於虛擬機，容器能快速部署，由於容器與底層設施、機器文件系統解耦的，所以它能在不同雲、不同版本操作系統間進行遷移。
容器佔用資源少、部署快，每個應用可以被打包成一個容器鏡像，每個應用與容器間成一對一關係也使容器有更大優勢，使用容器可以在build或release 的階段，爲應用創建容器鏡像，因爲每個應用不需要與其餘的應用堆棧組合，也不依賴於生產環境基礎結構，這使得從研發到測試、生產能提供一致環境。類似地，容器比虛機輕量、更“透明”，這更便於監控和管理。最後，
2、容器優勢總結：
- 快速創建/部署應用：與VM虛擬機相比，容器鏡像的創建更加容易。
- 持續開發、集成和部署：提供可靠且頻繁的容器鏡像構建/部署，並使用快速和簡單的回滾(由於鏡像不可變性)。
- 開發和運行相分離：在build或者release階段創建容器鏡像，使得應用和基礎設施解耦。
- 開發，測試和生產環境一致性：在本地或外網（生產環境）運行的一致性。
- 雲平臺或其他操作系統：可以在 Ubuntu、RHEL、 CoreOS、on-prem、Google Container Engine或其它任何環境中運行。
- Loosely coupled，分佈式，彈性，微服務化：應用程序分爲更小的、獨立的部件，可以動態部署和管理。
- 資源隔離
- 資源利用：更高效
五、使用Kubernetes能做什麼？
可以在物理或虛擬機的Kubernetes集羣上運行容器化應用，Kubernetes能提供一個以“容器爲中心的基礎架構”，滿足在生產環境中運行應用的一些常見需求，如：
- 多個進程（作爲容器運行）協同工作。（Pod）
- 存儲系統掛載
- Distributing secrets
- 應用健康檢測
- 應用實例的複製
- Pod自動伸縮/擴展
- Naming and discovering
- 負載均衡
- 滾動更新
- 資源監控
- 日誌訪問
- 調試應用程序
- 提供認證和授權
六、Kubernetes不是什麼？
Kubernetes並不是傳統的PaaS（平臺即服務）系統。
- Kubernetes不限制支持應用的類型，不限制應用框架。限制受支持的語言runtimes (例如, Java, Python, Ruby)，滿足12-factor applications 。不區分 “apps” 或者“services”。 Kubernetes支持不同負載應用，包括有狀態、無狀態、數據處理類型的應用。只要這個應用可以在容器裏運行，那麼就能很好的運行在Kubernetes上。
- Kubernetes不提供中間件（如message buses）、數據處理框架（如Spark）、數據庫(如Mysql)或者集羣存儲系統(如Ceph)作爲內置服務。但這些應用都可以運行在Kubernetes上面。
- Kubernetes不部署源碼不編譯應用。持續集成的 (CI)工作流方面，不同的用戶有不同的需求和偏好的區域，因此，我們提供分層的 CI工作流，但並不定義它應該如何工作。
- Kubernetes允許用戶選擇自己的日誌、監控和報警系統。
- Kubernetes不提供或授權一個全面的應用程序配置 語言/系統（例如，jsonnet）。
- Kubernetes不提供任何機器配置、維護、管理或者自修復系統。
另一方面，大量的Paas系統都可以運行在Kubernetes上，比如Openshift、Deis、Gondor。可以構建自己的Paas平臺，與自己選擇的CI系統集成。
由於Kubernetes運行在應用級別而不是硬件級，因此提供了普通的Paas平臺提供的一些通用功能，比如部署，擴展，負載均衡，日誌，監控等。這些默認功能是可選的。
另外，Kubernetes不僅僅是一個“編排系統”；它消除了編排的需要。“編排”的定義是指執行一個預定的工作流：先執行A，之B，然C。相反，Kubernetes由一組獨立的可組合控制進程組成。怎麼樣從A到C並不重要，達到目的就好。當然集中控制也是必不可少，方法更像排舞的過程。這使得系統更加易用、強大、彈性和可擴展。
參考文獻
【1】https://www.kubernetes.org.cn/k8s
【2】http://docs.kubernetes.org.cn/227.html