Kubernetes --- 詳細介紹和架構詳解

Kubernetes是一個跨主機集羣的開源的容器調度平臺,它能夠自動化應用容器的部署,擴展和操做,提供以容器爲中心的基礎架構

目錄
一. Kubernetes用途
二. Kubernetes特色
三. 介紹容器技術
四. Kubernetes能作什麼?
五. 使用Kubernetes的好處
六. 瞭解架構

一. Kubernetes用途

Kubernetes是容器集羣管理系統,是一個開源的平臺,能夠實現容器集羣的自動化部署,自動擴縮容,維護等功能

• 快速部署應用
• 快速擴展應用
• 無縫對接新的應用功能
• 節省資源,優化硬件資源的使用

二. Kubernetes特色

• 可移植 : 支持公有云,私有云,混合雲,多重雲
• 可擴展 : 模塊化,插件化,可掛載,可組合,支持各類形式的擴展
• 自動化 : 自動部署,自動重啓,自動複製,自動伸縮/擴展,經過聲明式語法提供了強大的自修復能力

Kubernetes是Google2014年建立管理的,是Google10多年大規模容器管理技術Borg的開源版本

三. 介紹容器技術

Kubernetes使用Linux容器技術來提供應用的隔離,如Docker或者rkt

容器容許你在同一臺機器上運行多個服務,不只提供不一樣的環境給每一個服務,並且將它們互相隔離,容器相似於虛擬機,但開銷小不少

一個容器僅僅是運行在宿主機上被隔離的單個進程,僅消耗應用容器消耗的資源,不會有其餘進程的開銷

容器都是調用同一個內核,天然會有安全隱患

容器實現隔離機制介紹

有兩個機制可用 :
第一個是Linux命名空間,它使每一個進程只能看到它本身的系統視圖(文件,進程,網絡接口,主機名等)
第二個是Linux控制組(cgroups),它限制了進程能使用的資源量(CPU,內存,網絡帶寬等)

Docker容器鏡像層

容器鏡像層是隻讀的,容器運行時,一個新的可寫層在鏡像層之上被建立容器中進程寫入位於底層的一個文件時,此文件的一個拷貝在頂層被建立,進程寫得此時拷貝

容器鏡像可移植性的限制

一個在特定硬件架構之上編譯的容器化應用,只能在有相同硬件架構的機器上運行

容器優勢

• 敏捷的應用程序建立和部署 : 與虛擬機鏡像相比,容器鏡像更容器建立,提高了硬件的使用效率
• 持續開發,集成和部署 : 提供可靠與頻繁的容器鏡像構建和部署,能夠很方便及快速的回滾(因爲鏡像不可變性)
• 關注開發與運維的分離 : 在構建/發佈時建立應用程序容器鏡像,從而將應用程序和基礎架構分離
• 開發,測試和生產環境的一致性 : 在筆記本電腦上運行與雲中同樣
• 雲和操做系統的可移植性 : 可運行在Ubuntu,RHEL,CoreOS,內部部署,Google 容器引擎和其餘任何地方
• 以應用爲中心的管理 : 提高了操做系統的抽象級別,以便在使用邏輯資源的操做系統上運行應用程序
• 鬆耦合,分佈式,彈性伸縮,微服務 : 應用程序被分紅更小,更獨立的部分,能夠動態部署和管理,而不是巨型單體應用運行在專用的大型機上
• 資源隔離 : 經過對應用進行資源隔離,能夠很容易的預測應用程序性能
• 資源利用 : 高效率和高密度

四. Kubernetes能作什麼?

最基礎的,Kubernetes能夠在物理或虛擬機集羣上調度和運行應用程序容器.然而,Kubernetes還容許開發人員從物理和虛擬機'脫離',從以主機爲中心的基礎架構轉移到以容器爲中心的基礎架構,這樣能夠提供容器固有的所有優勢和益處.Kubernetes提供了基礎設施來構建一個真正以容器爲中心的開發環境

Kubernetes知足了生產中運行應用程序的許多常見的需求

• Pod提供複合應用並保留一個應用一個容器的容器模型
• 掛載外部存儲
• Secret管理
• 應用健康檢查
• 副本應用實例
• 橫向自動擴縮容
• 服務發現
• 負載均衡
• 滾動更新
• 資源監測
• 日誌採集和存儲
• 支持自檢和調試
• 認證和鑑權

這提供了平臺即服務(PAAS)的簡單性以及基礎架構即服務(IAAS)的靈活性,並促進跨基礎設施供應商的可移植性

五. 使用Kubernetes的好處

• 簡化應用程序部署
• 更好的利用硬件
• 健康檢查和自修復
• 自動擴容
• 簡化應用部署

六. 瞭解架構

Kubernetes集羣分爲兩部分 :

• Kubernetes控制平面
• (工做)節點

控制平面的組件 :

• etcd分佈式持久化存儲
• API服務器
• 調度器
• 控制器管理器

這些組件用來存儲,管理集羣狀態,但它們不是運行應用的容器

工做節點上運行的組件 :

• Kubelet
• Kubelet服務代理(kube-proxy)
• 容器進行時(Docker,rkt或者其餘)

附加組件 :

• Kubernetes DNS服務器
• 儀表板
• Ingress控制器
• Heapster(容器集羣監控)
• 容器網絡接口插件

etcd

建立的全部對象 - pod,ReplicationController,服務和私密憑據等,須要以持久化方式存儲到某個地方,這樣它們的manifest在API服務器重啓和失敗的時候纔不會丟失.爲此,Kubernetes使用了etcd

etcd是一個響應快,分佈式,一致的Key-value存儲.由於它是分佈式的,故能夠運行多個etcd實例來獲取高可用性和更好的性能

惟一能直接和etcd通訊的是Kubernetes的API服務器.全部其餘組件經過API服務器間接地讀取,寫入數據到etcd.這帶來一些好處,其中之一就是加強樂觀鎖系統,驗證系統的健壯性;而且,經過把實際存儲機制從其餘組件抽離,將來替換起來也更容易.值得強調的是,etcd是Kubernetes存儲集羣狀態和元數據的惟一的地方

API服務器

Kubernetes API服務器做爲中心組件,其餘組件或者客戶端都會去調用它.以RESTful API的形式提供了能夠查詢,修改集羣狀態的CRUD(Create,Read,Update,Delete)接口.他將狀態存儲到etcd中

API服務器除了提供一種一致的方式將對象存儲到etcd,也對這些對象作校驗,這樣客戶端就沒法存入非法的對象(直接寫入存儲的話是有可能的).除了檢驗,還會處理樂觀鎖,這樣對於併發更新的狀況,對對象作更改就不會被其餘客戶端覆蓋

API服務器的客戶端之一就是使用的命令行工具kubectl,也支持監聽資源

調度器

一般不會去指定pod應該運行在哪一個集羣節點上,這項工做交給調度器.宏觀來看,調度器的操做比較簡單.就是利用API服務器的監聽機制等待新建立的pod,而後給每一個新的,沒有節點集的pod分配節點

調度器不會命令選中的節點去運行pod.調度器作的就是經過API服務器更新pod的定義.而後API服務器再去通知Kubelet該pod已經被調度過.當目標節點上的Kubelet發現該pod被調度到本節點,他就會建立而且運行pod的容器

儘管宏觀上調度的過程看起來比較簡單,但實際上爲pod選擇最佳節點的任務並不簡單.固然,最簡單的調度方式是不關心節點上已經運行的pod,隨機選擇一個節點.另外一方面,調度器能夠利用高級技術,例如機器學習,來預測接下來幾分鐘或幾小時哪一種類型的pod將會被調度,而後以最大的硬件利用率,無須從新調度已運行pod的方式來調度.Kubernetes的默認調度器實現方式處於最簡單和最複雜程度之間

控制器管理器

API服務器只作了存儲資源到etcd和通知客戶端有變動的工做.調度器則只是給pod分配節點,因此須要有活躍的組件確保系統真實狀態朝API服務器定義的指望的狀態收斂.這個工做由控制器管理器裏的控制器來實現

單個控制器,管理器進程當前組合了多個執行不一樣非衝突任務的控制器.這些控制器最終會被分解到不一樣的進程,若是須要的話,咱們可以用自定義實現替換它們每個

控制器包括 :

• Replication管理器(ReplicationController資源的管理器)
• ReplicaSet,DaemonSet以及Job控制器
• Deployment控制器
• StatefulSet控制器
• Node控制器
• Service控制器
• Endpoints控制器
• Namespace控制器
• PersistentVolume控制器
• 其餘

Kubelet

Kubelet就是負責全部運行在工做節點上內容的組件.它第一個任務就是在API服務器中建立一個Node資源來註冊該節點.而後須要持續監控API服務器是否把該節點分配給pod,而後啓動pod容器.具體實現方式是告知配置好的容器進行時來從特定容器鏡像運行容器,Kubelet隨後持續監控運行的容器,向API服務器報告他們的狀態,事件和資源消耗

Kubelet也是運行容器存活探針的組件,當探針報錯時它會重啓容器.最後一點,當pod從API服務器刪除時,Kubelet終止容器,並通知服務器pod已經被終止了

kube-proxy

每一個工做節點都會運行kube-proxy,用於確保客戶端能夠經過Kubernetes API鏈接到你定義的服務

kube-proxy確保對服務IP和端口的鏈接最終能到達支持服務的某個pod處.若是有多個pod支撐一個服務,那麼代理會發揮對pod的負載均衡做用

Kubernetes插件

DNS服務器

集羣中的全部pod默認配置使用集羣內部DNS服務器.這使得pod可以輕鬆地經過名稱查詢到服務,甚至是無頭服務pod的IP地址

DNS服務pod經過kube-dns服務對外暴露,使得該pod可以像其餘pod同樣在集羣中移動.服務的IP地址在集羣每一個容器的/etc/reslv.conf文件的nameserver中定義.kube-dns pod利用API服務器的監控機制來訂閱Service和Endpoint的變更,以及DNS記錄的變動,是的其客戶端老是可以獲取到最新的DNS信息.客觀的說,在Service和Endpoint資源發生變化到DNS pod收到訂閱通知時間點之間,DNS記錄可能會無效

Ingress控制器

Ingress控制器運行一個反向代理服務器,根據集羣中定義的Ingress,service以及Endpoint資源來配置該控制器.因此須要訂閱這些資源,而後每次其中一個發生變化則更新代理服務器的配置

儘管Ingress資源的定義指向一個Service,Ingress控制器會直接將流量轉到服務的pod而不通過服務IP.當外部客戶端經過Ingress控制器鏈接時,會對客戶端IP進行保存,這使得在某些用例中,控制器比Service更受歡迎

其餘插件都須要監聽集羣狀態,當有變動時執行相應動做

我天天會寫文章記錄K8S學習之路,另外我本身整理了些雲計算的學習資料,目前所有放在個人公衆號"SmallBird技術分享",加入咱們一塊兒學習交流,而且回覆’分享’會有大數據,雲計算資源驚喜等着你~