Kubernetes - 詳細介紹和架構詳解 - ⎝⎛CodingNote.cc ⎞⎠

Kubernetes — 詳細介紹和架構詳解

2019 年 10 月 3 日
筆記

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更受歡迎