kubernetes學習01—kubernetes介紹
一、簡介
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並不重要，達到目的就好。當然集中控制也是必不可少，方法更像排舞的過程。這使得系統更加易用、強大、彈性和可擴充套件。