1. 程式人生 > >Kubernetes --- 詳細介紹和架構詳解

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技術分享",加入我們一起學習交流,並且回覆’分享’會有大資料,雲端計算資源驚喜等著