1. Apiserver
唯一與etcd進(jìn)行數(shù)據(jù)交互的組件，也是其他核心組件連接交互的樞紐，承載整個(gè)架構(gòu)的核心和最大的壓力。Controller Manager、Scheduler、Kube-proxy 和 Kubelet 等均通過 API Server watch API 監(jiān)測資源變化情況，并對(duì)資源作相應(yīng)的操作，所有需要更新資源狀態(tài)的操作均通過 API Server 的 REST API 進(jìn)行，所以一般要對(duì)apiserver組件做高可用配置。
由于apiserver是整個(gè)架構(gòu)的核心，所以在安全上尤為重要，k8s集群對(duì)apiserver做了多重安全控制。從認(rèn)證、授權(quán)到準(zhǔn)入控制三部曲。
2. Control Manager控制器
通過list watch方式監(jiān)控本身負(fù)責(zé)的apiserver資源變化，控制著deployment、replicatset、namespaces、nodes、serviceaccount等控制器
3. Scheduler調(diào)度器
scheduler通過list watcher方式監(jiān)控apiserver任務(wù)的調(diào)度，接到pod任務(wù)調(diào)度的scheduler將通過調(diào)度策略進(jìn)行pod的創(chuàng)建，調(diào)度策略分為預(yù)選策略和優(yōu)選策略。
預(yù)選策略：是從集重列出所有node工作節(jié)點(diǎn)，通過調(diào)度算法將不滿足條件的node去掉。例舉：A.磁盤、cpu、內(nèi)存、負(fù)載等基礎(chǔ)資源是否充足 B. Hosts ports是否沖突 C.檢查 pod.Spec.NodeName 是否與候選節(jié)點(diǎn)一致 D.pod.Spec.NodeSelector 是否匹配? E.NoVolumeZoneConflict：檢查 volume zone 是否沖突 F.PodToleratesNodeTaints：檢查 Pod 是否容忍 Node Taints 等等。
優(yōu)選策略：優(yōu)先級(jí)排序，選擇優(yōu)先級(jí)最高的節(jié)點(diǎn)。 例舉：A.NodeAffinityPriority：優(yōu)先調(diào)度到匹配 NodeAffinity 的節(jié)點(diǎn)上 B.TaintTolerationPriority：優(yōu)先調(diào)度到匹配 TaintToleration 的節(jié)點(diǎn)上 C.?LeastRequestedPriority：優(yōu)先調(diào)度到請求資源少的節(jié)點(diǎn)上? D.InterPodAffinityPriority：優(yōu)先將 Pod 調(diào)度到相同的拓?fù)渖希ㄈ缤粋€(gè)節(jié)點(diǎn)、Rack、Zone 等） E.SelectorSpreadPriority：優(yōu)先減少節(jié)點(diǎn)上屬于同一個(gè) Service 或 Replication Controller 的 Pod 數(shù)量
5. Kubelet
每個(gè)Node節(jié)點(diǎn)上都運(yùn)行一個(gè) Kubelet 服務(wù)進(jìn)程，默認(rèn)監(jiān)聽 10250 端口，接收并執(zhí)行 Master 發(fā)來的指令，管理 Pod 及 Pod 中的容器。每個(gè) Kubelet 進(jìn)程會(huì)在 API Server 上注冊所在Node節(jié)點(diǎn)的信息，定期向 Master 節(jié)點(diǎn)匯報(bào)該節(jié)點(diǎn)的資源使用情況，并通過 cAdvisor 監(jiān)控節(jié)點(diǎn)和容器的資源。Kubelet 可以通過設(shè)置啟動(dòng)參數(shù) --register-node 來確定是否向 API Server 注冊自己；如果 Kubelet 沒有選擇自注冊模式，則需要用戶自己配置 Node 資源信息，同時(shí)需要告知 Kubelet 集群上的 API Server 的位置；Kubelet 在啟動(dòng)時(shí)通過 API Server 注冊節(jié)點(diǎn)信息，并定時(shí)向 API Server 發(fā)送節(jié)點(diǎn)新消息，API Server 在接收到新消息后，將信息寫入 etcd。
6.?Kube-proxy
每臺(tái)機(jī)器上都運(yùn)行一個(gè) kube-proxy 服務(wù)，它監(jiān)聽 API server 中 service 和 endpoint 的變化情況，并通過 iptables等來為服務(wù)配置負(fù)載均衡（僅支持 TCP 和 UDP）。kube-proxy 可以直接運(yùn)行在物理機(jī)上，也可以以 static pod 或者 daemonset 的方式運(yùn)行。其實(shí)kube-proxy基本上負(fù)責(zé)的是代理、負(fù)載均衡等網(wǎng)絡(luò)層面的事情，最終體現(xiàn)在iptables（ipvs）規(guī)則。
7. Etcd
Etcd 是 CoreOS 基于 Raft 開發(fā)的分布式 key-value 存儲(chǔ)，可用于服務(wù)發(fā)現(xiàn)、共享配置以及一致性保障（如數(shù)據(jù)庫選主、分布式鎖等）
8. 創(chuàng)建pod的整體流程
官網(wǎng)圖例：
8.1 創(chuàng)建replicaset工作流程：
a. 首先通過kubectl命令或api接口方式向apiserver發(fā)起創(chuàng)建replicaset的請求，api響應(yīng)命令,通過一系列認(rèn)證授權(quán)，比如通過kubectl apply -f xx.yaml或kubectl create等方式。
b. apiserver將要?jiǎng)?chuàng)建replicaset的信息保存為yaml，再寫入etcd。截至目前，僅僅在ectd中加入一條信息，沒有實(shí)際的進(jìn)展。
c. Control manager通過list watch監(jiān)控到apiserver數(shù)據(jù)變化，apiserver在etcd中讀取到需要?jiǎng)?chuàng)建rs的需求，然后control manager調(diào)用apiserver接口獲取創(chuàng)建多少個(gè)pod的信息，apiserver將信息同步更新保存在etcd中。
d.?scheduler檢測到未綁定 Node 的 Pod，通過list watch調(diào)用apiserver接口在etcd中獲取到相應(yīng)信息，執(zhí)行調(diào)度策略，先經(jīng)過過濾不滿足的node預(yù)選策略，再通過pod優(yōu)選策略最終決定將pod調(diào)度到哪個(gè)node上，apiserver將信息同步更新保存在etcd中。
e. 被選中node的kubelet將通過list watch 實(shí)時(shí)監(jiān)控apiserver讀取etd數(shù)據(jù)，檢測到有新的 Pod 調(diào)度過來，通過 Container Runtime 運(yùn)行該 Pod，Kubelet 通過 Container Runtime 取到 Pod 狀態(tài)，并更新到 API Server 中，并同步更新寫入到etcd中。
8.2 創(chuàng)建pod工作流程：
創(chuàng)建pod的工作流程大體和創(chuàng)建rs工作流程差不多，具體差異是pod不再受rs的管理。
a. 用戶通過 REST API 創(chuàng)建一個(gè) Pod
b. API Server 將其寫入 etcd
c. Scheduluer 檢測到未綁定 Node 的 Pod，開始調(diào)度并更新 Pod 的 Node 綁定
d. Kubelet 檢測到有新的 Pod 調(diào)度過來，通過 Container Runtime 運(yùn)行該 Pod
e. Kubelet 通過 Container Runtime 取到 Pod 狀態(tài)，并更新到 API Server 中
