kubernetes學習01—kubernetes介紹

1、簡介

一、Kubernetes代碼託管在GitHub上：https://github.com/kubernetes/kubernetes/。

 

二、Kubernetes是一個開源的，容器集羣管理系統，Kubernetes的目標是讓部署容器化的應用簡單而且高效（powerful）,Kubernetes提供了應用部署，規劃，更新，維護的一種機制。經過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是時間和空間上的惟一。

 

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

 

3、Kubernetes 特色

一、可移植：支持公有云，私有云，混合雲，多重雲（multi-cloud）

二、可擴展：模塊化, 插件化, 可掛載, 可組合

三、自動化：自動部署，自動重啓，自動複製，自動伸縮/擴展

 

4、爲何要使用容器？

一、傳統部署和容器部署

　　傳統的應用部署方式是經過插件或腳原本安裝應用。這樣作的缺點是應用的運行、配置、管理、全部生存週期將與當前操做系統綁定，這樣作並不利於應用的升級更新/回滾等操做，固然也能夠經過建立虛機的方式來實現某些功能，可是虛擬機很是重，並不利於可移植性。

　　新的方式是經過部署容器方式實現，每一個容器之間互相隔離，每一個容器有本身的文件系統 ，容器之間進程不會相互影響，能區分計算資源。相對於虛擬機，容器能快速部署，因爲容器與底層設施、機器文件系統解耦的，因此它能在不一樣雲、不一樣版本操做系統間進行遷移。

　　容器佔用資源少、部署快，每一個應用能夠被打包成一個容器鏡像，每一個應用與容器間成一對一關係也使容器有更大優點，使用容器能夠在build或release 的階段，爲應用建立容器鏡像，由於每一個應用不須要與其他的應用堆棧組合，也不依賴於生產環境基礎結構，這使得從研發到測試、生產能提供一致環境。相似地，容器比虛機輕量、更「透明」，這更便於監控和管理。最後，

 

二、容器優點總結：

• 快速建立/部署應用：與VM虛擬機相比，容器鏡像的建立更加容易。
• 持續開發、集成和部署：提供可靠且頻繁的容器鏡像構建/部署，並使用快速和簡單的回滾(因爲鏡像不可變性)。
• 開發和運行相分離：在build或者release階段建立容器鏡像，使得應用和基礎設施解耦。
• 開發，測試和生產環境一致性：在本地或外網（生產環境）運行的一致性。
• 雲平臺或其餘操做系統：能夠在 Ubuntu、RHEL、 CoreOS、on-prem、Google Container Engine或其它任何環境中運行。
• Loosely coupled，分佈式，彈性，微服務化：應用程序分爲更小的、獨立的部件，能夠動態部署和管理。
• 資源隔離
• 資源利用：更高效

 

5、使用Kubernetes能作什麼？

　　能夠在物理或虛擬機的Kubernetes集羣上運行容器化應用，Kubernetes能提供一個以「容器爲中心的基礎架構」，知足在生產環境中運行應用的一些常見需求，如：

•  多個進程（做爲容器運行）協同工做。（Pod）
•  存儲系統掛載
•  Distributing secrets
•  應用健康檢測
•  應用實例的複製
•  Pod自動伸縮/擴展
•  Naming and discovering
•  負載均衡
•  滾動更新
•  資源監控
•  日誌訪問
•  調試應用程序
•  提供認證和受權

 

6、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