Kubernetes有哪些核心部件，架構(gòu)圖和流程圖又是怎樣的，kubectl和kubelet經(jīng)常分不清，聲明式API和命令式API又有什么區(qū)別，本文一一詳說。

1、Kubernetes集群概述

1.1、概述

Kubernetes 是一個容器編排平臺，它使用共享網(wǎng)絡(luò)將多個主機（物理服務(wù)器或虛擬機）構(gòu)建成集群。分為 Master Node（主節(jié)點）和Worker Node（工作節(jié)點），Master負(fù)責(zé)管理整個集群，Worker 負(fù)責(zé)接收請求并以Pod（容器集合）形式運行工作負(fù)載。下圖為Kubernetes 集群工作模式示意圖。

Master是集群的網(wǎng)關(guān)和中樞，負(fù)責(zé)為客戶端提供API接口調(diào)用、確保各資源對象不斷地接近用戶期望的狀態(tài)、并以最優(yōu)的方式調(diào)度Pod到指定Node，以及編排其他組件之間的通信等任務(wù)，它是客戶端訪問集群的唯一入口。生產(chǎn)環(huán)境通常部署多個Master，為了冗余和負(fù)載均衡。

Worker Node負(fù)責(zé)接收來自 Master 下發(fā)的指令并相應(yīng)創(chuàng)建或銷毀Pod 對象，以及路由、流量轉(zhuǎn)發(fā)等任務(wù)。在生產(chǎn)環(huán)境中，隨著微服務(wù)的增多或者業(yè)務(wù)應(yīng)用的擴容，Worker會隨之增多。

概括來說，Kubernetes將所有工作節(jié)點的資源（CPU、磁盤、內(nèi)存、網(wǎng)絡(luò)等）集合在一起形成了一臺更加強大的“服務(wù)器”，通過Master上的API接口暴露集群的計算和存儲接口，再由 Master通過調(diào)度算法將客戶端請求的工作負(fù)載指派至特定的Node上，并且Master 會自動處理因Worker Node的添加、故障、或移除等變動對 Pod 的影響。

Kubernetes是構(gòu)建在底層主機集群之上的“云原生應(yīng)用操作系統(tǒng)”，而容器是運行在其上的進(jìn)程。

Kubernetes 中每個對象都使用 “名稱”作為其唯一標(biāo)識符，出于名稱的隔離和復(fù)用、資源隔離的目的，使用“Namespace” 作為作用域。

1.2、通過聲明式API即可

在開發(fā)云原生應(yīng)用時，主要使用聲明式API，這種方式簡單易用，程序員朋友可以更好地集中精力開發(fā)業(yè)務(wù)。

在運行應(yīng)用時，用戶只需要通過 API聲明業(yè)務(wù)應(yīng)用的最終狀態(tài)（例如為 Nginx 應(yīng)用運行 6個實例等），Kubernetes 便能完成后續(xù)的所有任務(wù)，包括應(yīng)用本身的運行實例數(shù)量、路由策略、訪問策略以及存儲等。

以下為某個聲明式y(tǒng)aml的示例，Kubernetes 也支持使用命令行工具 kubectl 提交請求。

apiVersion: v1
kind: Pod

metadata:
  name: busybox
  namespace: test
  labels:
    app: busybox

spec:
  containers:
    - name: busybox
      image: busybox

2、Kubernetes 集群架構(gòu)

Kubernetes 屬于Server-Client架構(gòu)，Master  Node主要由API Server（kube-apiserver）、 Controller-Manager（Kube-controller-manager）和 Scheduler（kube-scheduler）這3個組件，以及一個用于存儲集群狀態(tài)的 etcd 存儲服務(wù)組成，它們構(gòu)成整個集群的控制平面；

而Worker Node則主要包含 kubelet、kube-proxy及容器運行時（以前Docker是常用的實現(xiàn)）3個組件，它們承載運行各類應(yīng)用容器。各組件如下圖所示：

2.1、Master 組件

Master是集群的大腦，它維護(hù)了Kubernetes 的所有對象記錄，負(fù)責(zé)管理對象狀態(tài)、并響應(yīng)集群中各種資源對象的管理操作，以及確保各資源對象的 實際狀態(tài) 與 所需狀態(tài) 相匹配?？刂破矫娓鹘M件及其主要功能如下：

2.1.1、API Server

API Server 是Kubernetes 控制平面的前端，支持不同類型應(yīng)用的生命周期編排，包括部署、縮放和滾動更新等。它還是整個集群的網(wǎng)關(guān)接口，用于接收、校驗以及響應(yīng)所有的REST請求，并將結(jié)果狀態(tài)存儲到（etcd）中。

2.1.2、集群狀態(tài)存儲

Kubernetes集群的所有狀態(tài)信息都需要存儲于etcd 中。etcd 是分布式鍵值存儲，可用于服務(wù)發(fā)現(xiàn)、共享配置以及一致性保障 （如數(shù)據(jù)庫主節(jié)點選擇、分布式等）。

etcd還為其存儲的數(shù)據(jù)提供了監(jiān)聽 （warch）機制，用于監(jiān)聽和推送變更。API Server是Kubernetes集群中唯一能夠與etcd通信的組件，它封裝了這種監(jiān)聽機制，并借此同其他各組件高效協(xié)同。這一點類似于多個應(yīng)用服務(wù)器借助zookeeper協(xié)同。

2.1.3、控制器管理器

控制器負(fù)責(zé)實現(xiàn)客戶端通過 API Server 提交的請求，它驅(qū)動API 對象的當(dāng)前狀態(tài)逼近期望狀態(tài)。Kubernetes 提供了驅(qū)動 Node、Pod 、 Server、Endpoint、ServiceAccount 和 Token 等數(shù)十種類型對象的控制器。

2.1.4、調(diào)度器

Kubernetes 系統(tǒng)上的調(diào)度是指為 API Server 接收到的每一個Pod 創(chuàng)建請求，并在集群中為其匹配出一個最佳工作節(jié)點。kube-scheduler 是默認(rèn)調(diào)度器程序，它調(diào)度時的考量因素包括：硬件、軟件與策略約束、親和與反親和、污點等特征。

2.2、Worker Node 組件

Worker Node 組件是集群的體力勞動者，為了保證有足夠的資源運行成百上千個容器化應(yīng)用，一個集群通常會有多個 Worker Node 。每個Node 會定期向 Master 報告自身的狀態(tài)變動，并接受 Master 的管理。

2.2.1、kubelet

kubelet 是 Kubernetes 中最重要的組件之一，是運行于每個 Node之上的“節(jié)點代理”服務(wù)，負(fù)責(zé)接收并執(zhí)行 Master 發(fā)來的指令，以及管理當(dāng)前 Node 上 Pod 對象的容器等任務(wù)。它支持從 API Server 接收 Pod 資源定義，并通過 容器運行時 去創(chuàng)建、啟動和監(jiān)視容器。

kubelet 會持續(xù)監(jiān)視當(dāng)前節(jié)點上各Pod 的健康狀態(tài)，并在任何 Pod 出現(xiàn)問題時將其重建。同時也會及時跟Master通信，將自身情況上報于Master。

2.2.2、容器運行時環(huán)境

Pod 是一組容器集合，真正負(fù)責(zé)運行容器的是底層的 容器運行時 。kubelet 通過 CRI(容器運行時接口）可支持多種類型的 OCI 容器運行時，例如 docker、containerd、CRI-O、runC、Kata等。

2.2.3、kube-proxy

kube-proxy 是需要運行于集群中每個節(jié)點之上的服務(wù)進(jìn)程，它把 API Server 上的Service 資源對象轉(zhuǎn)換為當(dāng)前節(jié)點上的 iptables 或（與）ipvs 規(guī)則，這些規(guī)則 能夠?qū)⒛切?發(fā)往Service 對象 ClusterIP 的流量 分發(fā)至它后端的 Pod 端點之上。

kube-proxy是 Kubernetes的核心網(wǎng)絡(luò)組件，它本質(zhì)上更像是Pod 的代理及負(fù)載均衡器，負(fù)責(zé)確保集群中 Node、Service 和Pod 對象之間的通信。

2.3、圖解架構(gòu)

如上圖所示：

• 開發(fā)/運維人員可以通過kubectl命令，或者使用由Kubernetes提供的客戶端SDK，調(diào)用apiserver提供的接口。
• 調(diào)用apiserver接口后，Kubernetes將資源定義信息存入到etcd數(shù)據(jù)庫，資源定義信息就是期望狀態(tài)。
• 收到定義信息后，controller-manager會努力將期望狀態(tài)變?yōu)閷嶋H狀態(tài)，并且會把實際狀態(tài)寫入到etcd數(shù)據(jù)庫中。
• 如果定義信息沒有被scheduler模塊調(diào)度，那么實際狀態(tài)就是待調(diào)度，當(dāng)scheduler把pod調(diào)度到用戶指定的節(jié)點時，這時實際狀態(tài)則就是真實的Pod運行狀態(tài)了。
• 當(dāng)scheduler把 “pod應(yīng)該調(diào)度到哪個節(jié)點” 的信息寫入到etcd數(shù)據(jù)庫時，這時節(jié)點上的kubelet會利用list-watch機制收到這個信息，然后kubelet根據(jù)收到的信息運行pod的定義信息，并且把pod運行起來。
• 每個節(jié)點上都會有kube-proxy服務(wù)，包括master節(jié)點，利用kube-proxy模塊，可以作為集群的流量入口。
• 每個節(jié)點必須安裝好容器運行時（比如docker、containerd），因為最終把容器進(jìn)程跑起來的還是要靠 容器運行時 。

3、核心擴展部件

常用的核心擴展部件包括如下幾個：

3.1、網(wǎng)絡(luò)插件

網(wǎng)絡(luò)插件是必要部件，常用的有Flannel、Calico等。我主要使用Calico ，云廠商一般是結(jié)合VPC有自己的一套實現(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可用于獲取集群中資源對象的詳細(xì)信息，例如集群中的 Node、Namespace、 Volume、ClusterRole 和Job 等，也可以創(chuàng)建或者修改這些資源對象。

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)建可觀測分布式應(yīng)用的基礎(chǔ)設(shè)施，有助于幫助開發(fā)人員發(fā)現(xiàn)和定位問題。Kubernetes 常用的日志系統(tǒng)是由ElasticSearch、Fluentd 和 Kibana（EFK） 組合提供的解決方案，或者使用ELK等方案。

3.6、Ingress Controller

Ingress資源是 Kubernetes 將集群外部 HTTP流量引入到集群內(nèi)部的資源類型，它僅用于控制流量的規(guī)則和配置的集合，它不能進(jìn)行“流量穿透”，要通過Ingress控制器發(fā)揮作用。常用的Ingress控制器有Nginx等。

在以上這些附件中，CoreDNS、監(jiān)控系統(tǒng)、日志系統(tǒng)和 Ingress 控制器，這種基礎(chǔ)支撐類服務(wù)一般安裝在集群內(nèi)部。而Dashboard是提高用戶效率和體驗的可視化工具，一般在集群外部獨立安裝。

4、小小疑問

4.1、聲明式API和命令式API

一個注重結(jié)果，一個注重過程。

聲明式（declarative）編程：著重于最終結(jié)果，如何達(dá)成結(jié)果則要依賴于給定語言的基礎(chǔ)組件能力，程序員只需要指定做什么而非如何去做；聲明式編程常用于數(shù)據(jù)庫和配置管理軟件中，關(guān)系型數(shù)據(jù)庫的SQL語言便是最典型的代表之一。

命令式（imperative）編程：稱為過程式編程更合適，它需要由程序員指定做事情的具體步驟，更注重如何達(dá)成結(jié)果的過程。

4.2、區(qū)分kubectl和kubelet

初學(xué)者經(jīng)常分不清kubectl和kubelet的區(qū)別，通過上文可以知道：

kubectl是一個Kubernetes輕量級的客戶端，用于調(diào)用Api-Server的接口，一般安裝在Master節(jié)點。

kubelet是安裝在每個Node節(jié)點上的代理，用于與Master高效通信，以及完成Master下發(fā)的任務(wù)、以及上報任務(wù)和自身的情況。