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

1、Kubernetes集群概述

1.1、概述

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

Master是集群的網關和中樞，負責為客戶端提供API接口調用、確保各資源對象不斷地接近用戶期望的狀態、并以最優的方式調度Pod到指定Node，以及編排其他組件之間的通信等任務，它是客戶端訪問集群的唯一入口。生產環境通常部署多個Master，為了冗余和負載均衡。

Worker Node負責接收來自 Master 下發的指令并相應創建或銷毀Pod 對象，以及路由、流量轉發等任務。在生產環境中，隨著微服務的增多或者業務應用的擴容，Worker會隨之增多。

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

Kubernetes是構建在底層主機集群之上的“云原生應用操作系統”，而容器是運行在其上的進程。

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

1.2、通過聲明式API即可

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

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

以下為某個聲明式yaml的示例，Kubernetes 也支持使用命令行工具 kubectl 提交請求。

apiVersion: v1
kind: Pod

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

spec:
  containers:
    - name: busybox
      image: busybox

2、Kubernetes 集群架構

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

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

2.1、Master 組件

Master是集群的大腦，它維護了Kubernetes 的所有對象記錄，負責管理對象狀態、并響應集群中各種資源對象的管理操作，以及確保各資源對象的 實際狀態 與 所需狀態 相匹配。控制平面各組件及其主要功能如下：

2.1.1、API Server

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

2.1.2、集群狀態存儲

Kubernetes集群的所有狀態信息都需要存儲于etcd 中。etcd 是分布式鍵值存儲，可用于服務發現、共享配置以及一致性保障 （如數據庫主節點選擇、分布式等）。

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

2.1.3、控制器管理器

控制器負責實現客戶端通過 API Server 提交的請求，它驅動API 對象的當前狀態逼近期望狀態。Kubernetes 提供了驅動 Node、Pod 、 Server、Endpoint、ServiceAccount 和 Token 等數十種類型對象的控制器。

2.1.4、調度器

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

2.2、Worker Node 組件

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

2.2.1、kubelet

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

kubelet 會持續監視當前節點上各Pod 的健康狀態，并在任何 Pod 出現問題時將其重建。同時也會及時跟Master通信，將自身情況上報于Master。

2.2.2、容器運行時環境

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

2.2.3、kube-proxy

kube-proxy 是需要運行于集群中每個節點之上的服務進程，它把 API Server 上的Service 資源對象轉換為當前節點上的 iptables 或（與）ipvs 規則，這些規則 能夠將那些 發往Service 對象 ClusterIP 的流量 分發至它后端的 Pod 端點之上。

kube-proxy是 Kubernetes的核心網絡組件，它本質上更像是Pod 的代理及負載均衡器，負責確保集群中 Node、Service 和Pod 對象之間的通信。

2.3、圖解架構

如上圖所示：

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

3、核心擴展部件

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

3.1、網絡插件

網絡插件是必要部件，常用的有Flannel、Calico等。我主要使用Calico ，云廠商一般是結合VPC有自己的一套實現。

3.2、CoreDNS

Kubernetes使用DNS應用程序實現名稱解析和服務發現功能，它自1.11 版本起默認使用 CoreDNS。之前的版本中用到的是kube-dns。

3.3、Dashboard

一套WebUI，用于可視化 Kubernetes集群。Dashboard可用于獲取集群中資源對象的詳細信息，例如集群中的 Node、Namespace、 Volume、ClusterRole 和Job 等，也可以創建或者修改這些資源對象。

3.4、容器資源監控系統

監控系統是分布式應用的重要基礎設施，Kubernetes常用的指標監控部件有Metrics-Server、Prometheus 等。

3.5、集群日志系統

日志系統是構建可觀測分布式應用的基礎設施，有助于幫助開發人員發現和定位問題。Kubernetes 常用的日志系統是由ElasticSearch、Fluentd 和 Kibana（EFK） 組合提供的解決方案，或者使用ELK等方案。

3.6、Ingress Controller

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

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

4、小小疑問

4.1、聲明式API和命令式API

一個注重結果，一個注重過程。

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

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

4.2、區分kubectl和kubelet

初學者經常分不清kubectl和kubelet的區別，通過上文可以知道：

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

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