Kubernetes 是什麼？

Kubernetes簡介

Kubernetes 是一個可移植的、可擴展的開源平臺，用於管理容器化的工做負載和服務，可促進聲明式配置和自動化。Kubernetes 擁有一個龐大且快速增加的生態系統。Kubernetes 的服務、支持和工具普遍可用。

名稱 Kubernetes 源於希臘語，意爲 「舵手」 或 「飛行員」。Google 在 2014 年開源了 Kubernetes 項目。Kubernetes 創建在 Google 在大規模運行生產工做負載方面擁有十幾年的經驗的基礎上，結合了社區中最好的想法和實踐。

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是時間和空間上的惟一。

Kubernetes起源

大規模容器集羣管理工具，從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等高級引擎帶動容器技術興起和大衆化的同時，爲容器集羣管理提供獨了到看法和新思路。