什么是Kubernetes？

Borg系統(tǒng)是谷歌內(nèi)部使用很多的容器管理系統(tǒng)，在早期是采用Chroot Jail實現(xiàn)安全隔離，后期采用Namespace，資源隔離是采用CGroup實現(xiàn)。

為什么谷歌要推出Kubernetes開源版本呢？我個人的理解是：

• 使用開源社區(qū)的力量來解決谷歌未解決的問題
• 在云原生領(lǐng)域分一杯羹
• 推動云原生的發(fā)展，畢竟谷歌在容器領(lǐng)域已經(jīng)玩了許多年了

Kubernetes具有以下特點：

• ?便攜性: 無論公有云、私有云、混合云還是多云架構(gòu)都全面支持
• 可擴展: 它是模塊化、可插拔、可掛載、可組合的，支持各種形式的擴展
• 自修復(fù): 它可以自保持應(yīng)用狀態(tài)、可自重啟、自復(fù)制、自縮放的，通過聲明式語法提供了強大的自修復(fù)能力

使用 Kubernetes, 您可以快速高效地響應(yīng)客戶需求:

• 快速、可預(yù)測地部署您的應(yīng)用程序
• 擁有即時擴展應(yīng)用程序的能力
• 不影響現(xiàn)有業(yè)務(wù)的情況下，無縫地發(fā)布新功能
• 優(yōu)化硬件資源，降低成本

Kubernetes是一個聲明式系統(tǒng)，聲明式系統(tǒng)和命令式系統(tǒng)?是有本質(zhì)的區(qū)別。所謂聲明式系統(tǒng)?關(guān)注點是做什么，即告訴你將要達成什么樣的期望，至于怎么達到是你系統(tǒng)的事情。而命令式系統(tǒng)則是必須按照相應(yīng)的規(guī)定或者步驟達到某個目標(biāo)或者完成某個任務(wù)，其關(guān)注點是在怎么做。

命令式強調(diào)的是How，它需要你通過step-by-step的方式告訴計算機如何完成一個任務(wù)，在這種場景下，計算機是不具備“智能”，智能很機械的完成任務(wù)，至于完成的結(jié)果如何，需要看編程者的水平了。

而聲明式強調(diào)的是What，你只需要告訴計算機你想要什么，然后由計算機自己去執(zhí)行，這時候的計算機是具備一定的“智能”。當(dāng)然，聲明式不一定會滿足你所有的需要。

在日常工作中，命令式編程比較普遍，這種編程實現(xiàn)比較方便，只需要按照一定的步驟開發(fā)即可，但是在一些特定的場合，聲明式要比命令式方便，其實大多數(shù)聲明式語言都是針對特定任務(wù)的領(lǐng)域?qū)Ｓ谜Z言，即DSL。

最常見的聲明式語言就是SQL，只需要告訴計算機你想要的結(jié)果集，數(shù)據(jù)庫就會幫你設(shè)計獲取這個結(jié)果集的執(zhí)行路徑，并返回結(jié)果。

Kubernetes就是一個聲明式系統(tǒng)，在使用Kubernetes的時候，用戶不需要去定義A->B->C這種Workflow，而是直接去描述一個期望狀態(tài)，然后Kubernetes就會幫助用戶達到這個狀態(tài)，至于如何達到這個狀態(tài)，用戶不需要關(guān)心。這種設(shè)計使得Kubernetes更加易用和健壯，也更具彈性和擴展性。

Kubernetes的架構(gòu)

Kubernetes整體是Master-Slave架構(gòu)，如下：

其中：

• etcd 保存了整個集群的狀態(tài)，就是一個數(shù)據(jù)庫，只有API Server能與其通信；
• apiserver 提供了資源操作的唯一入口，并提供認(rèn)證、授權(quán)、訪問控制、API 注冊和發(fā)現(xiàn)等機制；
• controller manager 負(fù)責(zé)維護集群的狀態(tài)，比如故障檢測、自動擴展、滾動更新等；
• scheduler 負(fù)責(zé)資源的調(diào)度，按照預(yù)定的調(diào)度策略將 Pod 調(diào)度到相應(yīng)的機器上；
• kubelet 負(fù)責(zé)維護容器的生命周期，同時也負(fù)責(zé) Volume（CSI）和網(wǎng)絡(luò)（CNI）的管理；
• container runtime 負(fù)責(zé)鏡像管理以及 Pod 和容器的真正運行（CRI）；
• kube-proxy 負(fù)責(zé)為 Service 提供 cluster 內(nèi)部的服務(wù)發(fā)現(xiàn)和負(fù)載均衡；
• registry是鏡像倉庫，負(fù)責(zé)存儲容器鏡像
• kubectl和dashboard都是客戶端工具

上面的架構(gòu)是邏輯架構(gòu)，在實際的生產(chǎn)運用中，為了達到高可用，會對架構(gòu)做對應(yīng)的調(diào)整，調(diào)整對象就是主節(jié)點，如下：

主要做了以下改變：

（1）將Master節(jié)點從單節(jié)點變成了多節(jié)點，在kube-apiserver前增加了load balancer用來負(fù)載，其他組件通信都是通過LB進行

（2）將etcd和master節(jié)點獨立開，避免由于某個master節(jié)點故障導(dǎo)致ectd受影響

Kubernetes架構(gòu)的設(shè)計原則是：

• 只有APIServer可以直接訪問Etcd存儲，其他服務(wù)必須通過Kubernetes API來訪問集群的狀態(tài)
• 單節(jié)點故障原則上不應(yīng)該影響集群的狀態(tài)
• 在沒有新請求的情況下，所有組件應(yīng)該在故障恢復(fù)后繼續(xù)執(zhí)行上次最后收到的請求
• 所有組件應(yīng)該在內(nèi)存中保持所需要的狀態(tài)，APIServer將狀態(tài)寫入Etcd存儲，而其他組件則通過APIServer更新并監(jiān)聽所有的變化，最終由Controller Manager去協(xié)調(diào)
• 優(yōu)先使用事件監(jiān)聽而不是輪詢

Kubernetes的重要組件

上面介紹了Kubernetes的整體架構(gòu)以及簡單介紹了各個組件的作用，但是它們之間的關(guān)系具體如何并沒有做過多的介紹，我們現(xiàn)在來看看各個組件以及它們之間是怎么協(xié)作的。

（1）kubectl 客戶端首先將CLI命令轉(zhuǎn)化為RESTful的API調(diào)用，然后發(fā)送到kube-apiserver。

（2）kube-apiserver 在認(rèn)證、授權(quán)、準(zhǔn)入驗證過后，將任務(wù)元信息并存儲到etcd，然后kube-scheduler會對任務(wù)進行調(diào)度，并將調(diào)度結(jié)果返回給kube-apiserver。

（3）一旦 kube-scheduler 返回一個適合調(diào)度的目標(biāo)節(jié)點后，kube-apiserver 就把任務(wù)的節(jié)點信息存入etcd，并創(chuàng)建任務(wù)。

（4）此時目標(biāo)節(jié)點中的 kubelet正監(jiān)聽apiserver，當(dāng)監(jiān)聽到有新任務(wù)需要調(diào)度到本節(jié)點后，kubelet通過本地runtime創(chuàng)建任務(wù)容器，執(zhí)行作業(yè)。

（5）接著kubelet將任務(wù)狀態(tài)等信息返回給apiserver存儲到etcd。

（6）kube-proxy也會監(jiān)聽apiserver，如果有網(wǎng)絡(luò)策略相關(guān)的操作，就會在本機上創(chuàng)建對應(yīng)的iptables或者ipvs規(guī)則。

（7）這樣我們的任務(wù)已經(jīng)在運行了，此時control-manager發(fā)揮作用保證任務(wù)一直是我們期望的狀態(tài)。

其主要組件如下：

• Etcd
• API Server
• Controller Manager
• Scheduler
• Kubelet
• Kube-proxy

Etcd

Etcd 是兼具一致性和高可用性的鍵值存儲，可用于服務(wù)發(fā)現(xiàn)、共享配置以及一致性保障，在Kubernetes中，Etcd是作為唯一的存儲，保存Kubernetes的所有API對象。

在生產(chǎn)級Kubernetes中etcd通常會以集群的方式存在，安全原因，它只能從 API 服務(wù)器訪問。

API Server

API Server是Kubernetes最重要的核心組件之一，主要提供以下功能：

• 提供集群管理的REST API接口，包括：

• 認(rèn)證
• 授權(quán)
• 準(zhǔn)入

• 為其他模塊提供數(shù)據(jù)交互和通信的樞紐
• API Server提供Etcd的數(shù)據(jù)緩存，減少集群對Etcd的訪問

Controller Manager

Kubernetes在后臺運行許多不同的控制器進程，當(dāng)服務(wù)配置發(fā)生更改時（例如，替換運行 pod 的鏡像，或更改配置 yaml 文件中的參數(shù)），控制器會發(fā)現(xiàn)更改并開始朝著新的期望狀態(tài)工作。

從邏輯上講，每個控制器都是一個單獨的進程， 但是為了降低復(fù)雜性，它們都被編譯到同一個可執(zhí)行文件，并在一個進程中運行。控制器包括:

• 節(jié)點控制器（Node Controller）: 負(fù)責(zé)在節(jié)點出現(xiàn)故障時進行通知和響應(yīng)
• 任務(wù)控制器（Job controller）: 監(jiān)測代表一次性任務(wù)的 Job 對象，然后創(chuàng)建 Pods 來運行這些任務(wù)直至完成
• 端點控制器（Endpoints Controller）: 填充端點(Endpoints)對象(即加入 Service 與 Pod)
• 服務(wù)帳戶和令牌控制器（Service Account & Token Controllers）: 為新的命名空間創(chuàng)建默認(rèn)帳戶和 API 訪問令牌

下面就是Deployment Controller和ReplicaSet Controller兩個控制器的工作流程。

Scheduler

kube-scheduler 負(fù)責(zé)監(jiān)視新創(chuàng)建、未指定運行Node的 Pods，決策出一個讓pod運行的節(jié)點。例如，如果應(yīng)用程序需要 1GB 內(nèi)存和 2 個 CPU 內(nèi)核，那么該應(yīng)用程序的 pod 將被安排在至少具有這些資源的節(jié)點上。每次需要調(diào)度 pod 時，調(diào)度程序都會運行。調(diào)度程序必須知道可用的總資源以及分配給每個節(jié)點上現(xiàn)有工作負(fù)載的資源。調(diào)度決策考慮的因素包括單個 Pod 和 Pod 集合的資源需求、硬件/軟件/策略約束、親和性和反親和性規(guī)范、數(shù)據(jù)位置、工作負(fù)載間的干擾和最后時限。

調(diào)度總共分為三個階段：

• Predict：預(yù)選階段，過濾不能滿足業(yè)務(wù)需求的節(jié)點
• Priority：優(yōu)選階段，選擇最優(yōu)的節(jié)點
• Bind：綁定階段，將最優(yōu)節(jié)點和Pod進行綁定，完成調(diào)度

Kubelet

Kubelet是每個節(jié)點上的核心組件之一，負(fù)責(zé)管理節(jié)點的資源對象。

• 從不同源獲取Pod清單，并按需啟停Pod

Pod清單可以來自本地文件目錄、給定的Http Server、API Server等

Kubelet將Container Runtime、Network、Stroage抽象成CRI、CNI、CSI

• 負(fù)責(zé)匯報節(jié)點的健康狀態(tài)以及資源信息
• 負(fù)責(zé)Pod的健康檢查和狀態(tài)匯報

Kube-proxy

kube-proxy 是集群中每個節(jié)點上運行的網(wǎng)絡(luò)代理， 實現(xiàn) Kubernetes 服務(wù)（Service） 概念的一部分。用于處理單個主機子網(wǎng)劃分并向外部世界公開服務(wù)。它跨集群中的各種隔離網(wǎng)絡(luò)將請求轉(zhuǎn)發(fā)到正確的 pod/容器。kube-proxy 維護節(jié)點上的網(wǎng)絡(luò)規(guī)則。這些網(wǎng)絡(luò)規(guī)則允許從集群內(nèi)部或外部的網(wǎng)絡(luò)會話與 Pod 進行網(wǎng)絡(luò)通信。如果操作系統(tǒng)提供了數(shù)據(jù)包過濾層并可用的話，kube-proxy 會通過它來實現(xiàn)網(wǎng)絡(luò)規(guī)則。否則， kube-proxy 僅轉(zhuǎn)發(fā)流量本身。

其他組件

上面介紹的這些組件是集群的架子，光有架子還不夠，還需要第三方的組件讓其更強大：

• kube-dns：負(fù)責(zé)為整個集群提供DNS服務(wù)，常用的是CoreDNS
• Ingress Controller：為集群提供外網(wǎng)訪問入口
• Metrics-Server：為集群提供監(jiān)控資源
• DashBoard：提供GUI，方便運維
• Prometheus：收集并監(jiān)控集群資源
• Grafana：圖形化展示監(jiān)控數(shù)據(jù)
• ELK：收集、存儲、查詢集群日志