Kube.NETes有哪些核心部件，架構(gòu)圖和流程圖又是怎樣的，kubectl和kubelet經(jīng)常分不清，聲明式API和命令式API又有什么區(qū)別，本文一一詳說(shuō)。
1、Kubernetes集群概述
1.1、概述
Kubernetes 是一個(gè)容器編排平臺(tái)，它使用共享網(wǎng)絡(luò)將多個(gè)主機(jī)（物理服務(wù)器或虛擬機(jī)）構(gòu)建成集群。分為 Master Node（主節(jié)點(diǎn)）和Worker Node（工作節(jié)點(diǎn)），Master負(fù)責(zé)管理整個(gè)集群，Worker 負(fù)責(zé)接收請(qǐng)求并以Pod（容器集合）形式運(yùn)行工作負(fù)載。下圖為Kubernetes 集群工作模式示意圖。
Master是集群的網(wǎng)關(guān)和中樞，負(fù)責(zé)為客戶端提供API接口調(diào)用、確保各資源對(duì)象不斷地接近用戶期望的狀態(tài)、并以最優(yōu)的方式調(diào)度Pod到指定Node，以及編排其他組件之間的通信等任務(wù)，它是客戶端訪問(wèn)集群的唯一入口。生產(chǎn)環(huán)境通常部署多個(gè)Master，為了冗余和負(fù)載均衡。
Worker Node負(fù)責(zé)接收來(lái)自 Master 下發(fā)的指令并相應(yīng)創(chuàng)建或銷毀Pod 對(duì)象，以及路由、流量轉(zhuǎn)發(fā)等任務(wù)。在生產(chǎn)環(huán)境中，隨著微服務(wù)的增多或者業(yè)務(wù)應(yīng)用的擴(kuò)容，Worker會(huì)隨之增多。
概括來(lái)說(shuō)，Kubernetes將所有工作節(jié)點(diǎn)的資源（CPU、磁盤(pán)、內(nèi)存、網(wǎng)絡(luò)等）集合在一起形成了一臺(tái)更加強(qiáng)大的“服務(wù)器”，通過(guò)Master上的API接口暴露集群的計(jì)算和存儲(chǔ)接口，再由 Master通過(guò)調(diào)度算法將客戶端請(qǐng)求的工作負(fù)載指派至特定的Node上，并且Master 會(huì)自動(dòng)處理因Worker Node的添加、故障、或移除等變動(dòng)對(duì) Pod 的影響。
Kubernetes是構(gòu)建在底層主機(jī)集群之上的“云原生應(yīng)用操作系統(tǒng)”，而容器是運(yùn)行在其上的進(jìn)程。
Kubernetes 中每個(gè)對(duì)象都使用 “名稱”作為其唯一標(biāo)識(shí)符，出于名稱的隔離和復(fù)用、資源隔離的目的，使用“Namespace” 作為作用域。
1.2、通過(guò)聲明式API即可
在開(kāi)發(fā)云原生應(yīng)用時(shí)，主要使用聲明式API，這種方式簡(jiǎn)單易用，程序員朋友可以更好地集中精力開(kāi)發(fā)業(yè)務(wù)。
在運(yùn)行應(yīng)用時(shí)，用戶只需要通過(guò) API聲明業(yè)務(wù)應(yīng)用的最終狀態(tài)（例如為 Nginx 應(yīng)用運(yùn)行 6個(gè)實(shí)例等），Kubernetes 便能完成后續(xù)的所有任務(wù)，包括應(yīng)用本身的運(yùn)行實(shí)例數(shù)量、路由策略、訪問(wèn)策略以及存儲(chǔ)等。
以下為某個(gè)聲明式y(tǒng)aml的示例，Kubernetes 也支持使用命令行工具 kubectl 提交請(qǐng)求。
apiVersion: v1
kind: Pod
metadata:
name: busybox
namespace: test
labels:
App: busybox
spec:
contAIners:
- name: busybox
image: busybox
- 1.
- 2.
- 3.
- 4.
- 5.
- 6.
- 7.
- 8.
- 9.
- 10.
- 11.
- 12.
- 13.
2、Kubernetes 集群架構(gòu)
Kubernetes 屬于Server-Client架構(gòu)，Master Node主要由API Server（kube-apiserver）、 Controller-Manager（Kube-controller-manager）和 Scheduler（kube-scheduler）這3個(gè)組件，以及一個(gè)用于存儲(chǔ)集群狀態(tài)的 etcd 存儲(chǔ)服務(wù)組成，它們構(gòu)成整個(gè)集群的控制平面；
而Worker Node則主要包含 kubelet、kube-proxy及容器運(yùn)行時(shí)（以前Docker是常用的實(shí)現(xiàn)）3個(gè)組件，它們承載運(yùn)行各類應(yīng)用容器。各組件如下圖所示：
2.1、Master 組件
Master是集群的大腦，它維護(hù)了Kubernetes 的所有對(duì)象記錄，負(fù)責(zé)管理對(duì)象狀態(tài)、并響應(yīng)集群中各種資源對(duì)象的管理操作，以及確保各資源對(duì)象的 實(shí)際狀態(tài) 與 所需狀態(tài) 相匹配。控制平面各組件及其主要功能如下：
2.1.1、API Server
API Server 是Kubernetes 控制平面的前端，支持不同類型應(yīng)用的生命周期編排，包括部署、縮放和滾動(dòng)更新等。它還是整個(gè)集群的網(wǎng)關(guān)接口，用于接收、校驗(yàn)以及響應(yīng)所有的REST請(qǐng)求，并將結(jié)果狀態(tài)存儲(chǔ)到（etcd）中。
2.1.2、集群狀態(tài)存儲(chǔ)
Kubernetes集群的所有狀態(tài)信息都需要存儲(chǔ)于etcd 中。etcd 是分布式鍵值存儲(chǔ)，可用于服務(wù)發(fā)現(xiàn)、共享配置以及一致性保障 （如數(shù)據(jù)庫(kù)主節(jié)點(diǎn)選擇、分布式等）。
etcd還為其存儲(chǔ)的數(shù)據(jù)提供了監(jiān)聽(tīng) （warch）機(jī)制，用于監(jiān)聽(tīng)和推送變更。API Server是Kubernetes集群中唯一能夠與etcd通信的組件，它封裝了這種監(jiān)聽(tīng)機(jī)制，并借此同其他各組件高效協(xié)同。這一點(diǎn)類似于多個(gè)應(yīng)用服務(wù)器借助zookeeper協(xié)同。
2.1.3、控制器管理器
控制器負(fù)責(zé)實(shí)現(xiàn)客戶端通過(guò) API Server 提交的請(qǐng)求，它驅(qū)動(dòng)API 對(duì)象的當(dāng)前狀態(tài)逼近期望狀態(tài)。Kubernetes 提供了驅(qū)動(dòng) Node、Pod 、 Server、Endpoint、ServiceAccount 和 Token 等數(shù)十種類型對(duì)象的控制器。
2.1.4、調(diào)度器
Kubernetes 系統(tǒng)上的調(diào)度是指為 API Server 接收到的每一個(gè)Pod 創(chuàng)建請(qǐng)求，并在集群中為其匹配出一個(gè)最佳工作節(jié)點(diǎn)。kube-scheduler 是默認(rèn)調(diào)度器程序，它調(diào)度時(shí)的考量因素包括：硬件、軟件與策略約束、親和與反親和、污點(diǎn)等特征。
2.2、Worker Node 組件
Worker Node 組件是集群的體力勞動(dòng)者，為了保證有足夠的資源運(yùn)行成百上千個(gè)容器化應(yīng)用，一個(gè)集群通常會(huì)有多個(gè) Worker Node 。每個(gè)Node 會(huì)定期向 Master 報(bào)告自身的狀態(tài)變動(dòng)，并接受 Master 的管理。
2.2.1、kubelet
kubelet 是 Kubernetes 中最重要的組件之一，是運(yùn)行于每個(gè) Node之上的“節(jié)點(diǎn)代理”服務(wù)，負(fù)責(zé)接收并執(zhí)行 Master 發(fā)來(lái)的指令，以及管理當(dāng)前 Node 上 Pod 對(duì)象的容器等任務(wù)。它支持從 API Server 接收 Pod 資源定義，并通過(guò) 容器運(yùn)行時(shí) 去創(chuàng)建、啟動(dòng)和監(jiān)視容器。
kubelet 會(huì)持續(xù)監(jiān)視當(dāng)前節(jié)點(diǎn)上各Pod 的健康狀態(tài)，并在任何 Pod 出現(xiàn)問(wèn)題時(shí)將其重建。同時(shí)也會(huì)及時(shí)跟Master通信，將自身情況上報(bào)于Master。
2.2.2、容器運(yùn)行時(shí)環(huán)境
Pod 是一組容器集合，真正負(fù)責(zé)運(yùn)行容器的是底層的 容器運(yùn)行時(shí) 。kubelet 通過(guò) CRI(容器運(yùn)行時(shí)接口）可支持多種類型的 OCI 容器運(yùn)行時(shí)，例如 docker、containerd、CRI-O、runC、Kata等。
2.2.3、kube-proxy
kube-proxy 是需要運(yùn)行于集群中每個(gè)節(jié)點(diǎn)之上的服務(wù)進(jìn)程，它把 API Server 上的Service 資源對(duì)象轉(zhuǎn)換為當(dāng)前節(jié)點(diǎn)上的 iptables 或（與）ipvs 規(guī)則，這些規(guī)則 能夠?qū)⒛切?發(fā)往Service 對(duì)象 ClusterIP 的流量 分發(fā)至它后端的 Pod 端點(diǎn)之上。
kube-proxy是 Kubernetes的核心網(wǎng)絡(luò)組件，它本質(zhì)上更像是Pod 的代理及負(fù)載均衡器，負(fù)責(zé)確保集群中 Node、Service 和Pod 對(duì)象之間的通信。
2.3、圖解架構(gòu)
如上圖所示：
- 開(kāi)發(fā)/運(yùn)維人員可以通過(guò)kubectl命令，或者使用由Kubernetes提供的客戶端SDK，調(diào)用apiserver提供的接口。
- 調(diào)用apiserver接口后，Kubernetes將資源定義信息存入到etcd數(shù)據(jù)庫(kù)，資源定義信息就是期望狀態(tài)。
- 收到定義信息后，controller-manager會(huì)努力將期望狀態(tài)變?yōu)閷?shí)際狀態(tài)，并且會(huì)把實(shí)際狀態(tài)寫(xiě)入到etcd數(shù)據(jù)庫(kù)中。
- 如果定義信息沒(méi)有被scheduler模塊調(diào)度，那么實(shí)際狀態(tài)就是待調(diào)度，當(dāng)scheduler把pod調(diào)度到用戶指定的節(jié)點(diǎn)時(shí)，這時(shí)實(shí)際狀態(tài)則就是真實(shí)的Pod運(yùn)行狀態(tài)了。
- 當(dāng)scheduler把 “pod應(yīng)該調(diào)度到哪個(gè)節(jié)點(diǎn)” 的信息寫(xiě)入到etcd數(shù)據(jù)庫(kù)時(shí)，這時(shí)節(jié)點(diǎn)上的kubelet會(huì)利用list-watch機(jī)制收到這個(gè)信息，然后kubelet根據(jù)收到的信息運(yùn)行pod的定義信息，并且把pod運(yùn)行起來(lái)。
- 每個(gè)節(jié)點(diǎn)上都會(huì)有kube-proxy服務(wù)，包括master節(jié)點(diǎn)，利用kube-proxy模塊，可以作為集群的流量入口。
- 每個(gè)節(jié)點(diǎn)必須安裝好容器運(yùn)行時(shí)（比如docker、containerd），因?yàn)樽罱K把容器進(jìn)程跑起來(lái)的還是要靠 容器運(yùn)行時(shí) 。
3、核心擴(kuò)展部件
常用的核心擴(kuò)展部件包括如下幾個(gè)：
3.1、網(wǎng)絡(luò)插件
網(wǎng)絡(luò)插件是必要部件，常用的有Flannel、Calico等。我主要使用Calico ，云廠商一般是結(jié)合VPC有自己的一套實(shí)現(xiàn)。
3.2、CoreDNS
Kubernetes使用DNS應(yīng)用程序?qū)崿F(xiàn)名稱解析和服務(wù)發(fā)現(xiàn)功能，它自1.11 版本起默認(rèn)使用 CoreDNS。之前的版本中用到的是kube-dns。
3.3、Dashboard
一套WebUI，用于可視化 Kubernetes集群。Dashboard可用于獲取集群中資源對(duì)象的詳細(xì)信息，例如集群中的 Node、Namespace、 Volume、ClusterRole 和Job 等，也可以創(chuàng)建或者修改這些資源對(duì)象。
3.4、容器資源監(jiān)控系統(tǒng)
監(jiān)控系統(tǒng)是分布式應(yīng)用的重要基礎(chǔ)設(shè)施，Kubernetes常用的指標(biāo)監(jiān)控部件有Metrics-Server、Prometheus 等。
3.5、集群日志系統(tǒng)
日志系統(tǒng)是構(gòu)建可觀測(cè)分布式應(yīng)用的基礎(chǔ)設(shè)施，有助于幫助開(kāi)發(fā)人員發(fā)現(xiàn)和定位問(wèn)題。Kubernetes 常用的日志系統(tǒng)是由ElasticSearch、Fluentd 和 Kibana（EFK） 組合提供的解決方案，或者使用ELK等方案。
3.6、Ingress Controller
Ingress資源是 Kubernetes 將集群外部 HTTP流量引入到集群內(nèi)部的資源類型，它僅用于控制流量的規(guī)則和配置的集合，它不能進(jìn)行“流量穿透”，要通過(guò)Ingress控制器發(fā)揮作用。常用的Ingress控制器有Nginx等。
在以上這些附件中，CoreDNS、監(jiān)控系統(tǒng)、日志系統(tǒng)和 Ingress 控制器，這種基礎(chǔ)支撐類服務(wù)一般安裝在集群內(nèi)部。而Dashboard是提高用戶效率和體驗(yàn)的可視化工具，一般在集群外部獨(dú)立安裝。
4、小小疑問(wèn)
4.1、聲明式API和命令式API
一個(gè)注重結(jié)果，一個(gè)注重過(guò)程。
聲明式（declarative）編程：著重于最終結(jié)果，如何達(dá)成結(jié)果則要依賴于給定語(yǔ)言的基礎(chǔ)組件能力，程序員只需要指定做什么而非如何去做；聲明式編程常用于數(shù)據(jù)庫(kù)和配置管理軟件中，關(guān)系型數(shù)據(jù)庫(kù)的SQL語(yǔ)言便是最典型的代表之一。
命令式（imperative）編程：稱為過(guò)程式編程更合適，它需要由程序員指定做事情的具體步驟，更注重如何達(dá)成結(jié)果的過(guò)程。
4.2、區(qū)分kubectl和kubelet
初學(xué)者經(jīng)常分不清kubectl和kubelet的區(qū)別，通過(guò)上文可以知道：
kubectl是一個(gè)Kubernetes輕量級(jí)的客戶端，用于調(diào)用Api-Server的接口，一般安裝在Master節(jié)點(diǎn)。
kubelet是安裝在每個(gè)Node節(jié)點(diǎn)上的代理，用于與Master高效通信，以及完成Master下發(fā)的任務(wù)、以及上報(bào)任務(wù)和自身的情況。
