Kube.NETes有哪些核心部件，架構圖和流程圖又是怎樣的，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
- 1.
- 2.
- 3.
- 4.
- 5.
- 6.
- 7.
- 8.
- 9.
- 10.
- 11.
- 12.
- 13.
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 的所有對象記錄，負責管理對象狀態、并響應集群中各種資源對象的管理操作，以及確保各資源對象的 實際狀態 與 所需狀態 相匹配?？刂破矫娓鹘M件及其主要功能如下：
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下發的任務、以及上報任務和自身的情況。
