【云原生】kubernetes核心組件

引言：

Kubernetes 是為運行分布式集群而建立的，分布式系統的本質使得網絡成為 Kubernetes 的核心和必要組成部分，了解 Kubernetes 網絡模型可以使你能夠正確運行、監控和排查應用程序故障。

一、Kubernetes的核心組件

1.1、Master組件

1.1.1?kube-apiserver

用于暴露 kubernetes API，任何資源請求或調用操作都是通過 kube-apiserver 提供的接口進行。
以 HTTP Restful API 提供接口服務，所有對象資源的增刪改查和監聽操作都交給 API Server 處理后再提交給Etcd 存儲。
可以理解成 API Server 是 K8S 的請求入口服務。API Server 負責接收 K8S 所有請求（來自 UI界面或者CLI 命令行工具），然后根據用戶的具體請求，去通知其他組件干活。可以說 API Server 是 K8S 集群架構的大腦。

1.1.2?Kube-controller-manager

運行管理控制，是 K8S 集群中處理常規任務的后臺線程，是 K8S 集群里所有資源對象的自動化控制中心。

????????在 K8S 集群中，一個資源對應一個控制器，而 Controller manager 就是負責管理這些控制器的。由一系列控制器組成，通過 API Server 監控整個集群的狀態，并確保集群處于預期的工作狀態，比如當某個 Node 意外宕機時，Controller Manager 會及時發現并執行自動化修復流程，確保集群始終處于預期的工作狀態。

控制器	說明
Node Controller（節點控制器）	負責在節點出現故障時發現和響應
Replication Controller（副本控制器）	負責保證集群中一個RC（資源對象Replication Controller）所關聯的Pod副本數始終保持預設值。可以理解成確保集群中有且僅有N個Pod實例，N是RC中定義的Pod副本數量
Endpoints Controller（端點控制器）	填充端點對象（即連接Services和Pods），負責監聽Service和對應的Pod副本的變化。可以理解端點是一個服務暴露出來的訪問點，如果需要訪問一個服務暴露出來的訪問點，如果需要訪問一個服務，則必須知道它的endpoint
Service Account & Token Controllers（服務賬戶和令牌控制器）	為新的命名空間創建默認賬戶和API訪問令牌
ResourceQuota Controller（資源配額控制器）	確保指定的資源對象在任何時候都不會超量占用系統物理資源
Namespace Controller（命名空間控制器）	管理namespace的聲明周期
Service Controller（服務控制器）	屬于K8S集群與外部的云平臺之間的一個接口控制器

1.1.3?kube-scheduler

是負責資源調度的進程，根據調度算法為新創建的 Pod 選擇一份合適的 Node 節點。可以理解成 K8S 所有 Node 節點的調度器。當用于要部署服務時，Scheduler 會根據調度算法選擇最合適的 Node 節點來部署 Pod。

預算策略（predicate）
優選策略（priorities）

1.1.4 配置存儲中心 — etcd

K8S 的存儲服務，負責存儲K8S集群的重要信息。etcd 是分布式鍵值存儲系統，存儲了 K8S 的關鍵配置和用戶配置，K8S 中僅 API Server 才具備讀寫權限，其他組件必須通過 API Server 的接口才能讀寫數據。

1.1.5 主節點工作流程

API Server 接收到請求創建一批 Pod，API Server 會讓 Controller-manager 按照所預設的模板去創建 Pod，Controller-manager 會通過 API Server 去找 Scheduler 為新創建的 Pod 選擇最適合的 Node 節點。比如運行這個 Pod 需要 2C4G 的資源，Schedular 會通過預算策略在所有 Node 節點中挑選最優的。Node 節點中還剩多少資源是通過匯報給 API Server 存儲在 etcd 里，API Server 會調用一個方法找到 etcd 里所有 Node 節點的剩余資源，再對比 Pod 所需要的資源，在所有 Node 節點中查找哪些 Node 節點符合要求。如果都符合，預算策略就交給優選策略處理，優選策略再通過 CPU 的負載、內存的剩余量等因素選擇最合適的 Node 節點，并把 Pod 調度到這個 Node 節點上運行。

1.2、 Node組件

1.2.1??Kubelet

Node 節點的監視器，以及與 Master 節點的通訊器。Kubelet 是 Master 節點安插在 Node 節點上的 “眼線”，它會定時向 API Server 匯報自己 Node 節點上運行的服務的狀態，并接受來自 Master 節點的指示采取調整措施。

????????從 Master 節點獲取自己節點上 Pod 的期望狀態（比如運行什么容器、運行的副本數量、網絡或者存儲如何配置等），直接跟容器引擎交互實現容器的生命周期管理，如果自己節點上 Pod 的狀態與期望狀態不一致，則調用對應的容器平臺接口（即 docker 的接口）達到這個狀態。管理鏡像和容器的清理工作，保證節點上鏡像不會占滿磁盤空間，退出的容器不會占用太多資源。

1.2.2?Kube-Proxy

在每個 Node 節點上實現 Pod 網絡代理，是 Kuberbetes Service資源的載體，負責維護網絡規劃和四層負載均衡工作。負責寫入規則至 iptables、ipvs 實現服務映射訪問的。
Kube-Proxy 本身不是直接給 Pod 提供網絡，Pod 的網絡是由 Kubelet 提供的，Kube-Proxy實際上維護的是虛擬的 Pod 集群網絡。
Kube-apiserver 通過監控 Kube-Proxy 進行對 Kubernets Service 的更新和端點的維護。
Kube-Proxy 是 K8S 集群內部的負載均衡器。它是一個分布式代理服務器，在 K8S 的每個節點上都會運行一個Kube-proxy。

1.2.3 docker 或?rocket

容器引擎，運行容器，負責本機的容器創建和管理工作

二、kubernetes 核心概念

Kubernetes 包含多種類型的資源對象：Pod、Label、Service、Replication Controller 等。
所有的資源對象都可以通過 Kubernetes 提供的 kubectl 工具進行增、刪、改、查等操作，并將其保存在 etcd中持久化存儲。
Kubernets其實是一個高度自動化的資源控制系統，通過跟蹤對比etcd存儲里保存的資源期望狀態與當前環境中的實際資源狀態的差異，來實現自動控制和自動糾錯等高級功能。

2.1、Pod

Pod 是 Kuberntes 創建或部署的最小/最簡單的基本單位，一個 Pod 代表集群上正在運行的一個進程。
可以把 Pod 理解成豌豆莢，而同一 Pod 內的每個容器是一個個豌豆。
一個 Pod 由一個或多個容器組成，Pod 中容器共享網絡、存儲和計算資源，在同一臺 Docker 主機上運行。
一個 Pod 里可以運行多個容器，又叫邊車（SideCar）模式。而在生產環境中一般都是單個容器或者具有強關聯互補的多個容器組成一個Pod。
同一個 Pod 之間的容器可以通過 localhost 互相訪問，并且可以掛載 Pod 內的所有的數據卷；但是不同的 Pod之間的容器不能用 localhost 訪問，也不能掛載其他 Pod 的數據卷。

2.2、Pod控制器

Pod 控制器是 Pod 啟動的一種模板，用來保證在 K8S 里啟動的 Pod 應始終按照用戶的預期運行（副本數、生命周期、健康狀態檢查等）。K8S 內提供了眾多的 Pod 控制器，常用的有以下幾種：

Deployment：無狀態應用部署。Deployment 的作用就是管理和控制 Pod 和ReplicaSet，管控它們運行在用戶期望的狀態中。
Replicaset：確保預期的 Pod 副本數量。ReplicaSet 的作用就是管理和控制 Pod，管控他們好好干活。但是ReplicaSet 受控于 Deployment。可以理解成 Deployment 就是總包工頭，主要負責監督底下的工人 Pod干活，確保每時每刻有用戶要求數量的 Pod 在工作。如果一旦發現某個工人 Pod 不行了，就趕緊新拉一個 Pod 過來替換它。而ReplicaSet 就是總包工頭手下的小包工頭。從 K8S 使用者角度來看，用戶會直接操作 Deployment 部署服務，而當Deployment 被部署的時候，K8S 會自動生成要求的 ReplicaSet 和 Pod。用戶只需要關心 Deployment而不操心 ReplicaSet。資源對象 Replication Controller 是 ReplicaSet 的前身，官方推薦用Deployment 取代 Replication Controller 來部署服務。
Daemonset：確保所有節點運行同一類Pod，保證每個節點上都有一個此類 Pod 運行，通常用于實現系統級后臺任務。
Statefulset：有狀態應用部署。
**Job：一次性任務。**根據用戶的設置，Job 管理的 Pod 把任務成功完成就自動退出了。
Cronjob：周期性計劃性任務。
Ingress：管理 L7 層的網絡模式（http/https 流量）
ingress 包含：nginx、Haproxy、traffic、 istio、kong
PV/PVC:動態存儲。NFS接入到k8s時，不能直接掛載，要利用pv/pvc來管理，共享存儲也是資源，由pv/pvc來管理。比如10G不夠了，擴容由pv/pvc來進行動態擴容處理。

2.2.1 Deployment—無狀態應用部署

Nginx 這種類型的服務，只開啟反向代理的功能的時候，假設nginx 宕了，重新跑一個新的，替換過來，可以直接用。沒有差異化稱為無狀態。

無狀態服務：LVS（加入集群后，無特殊性需求—需求）

服務不依賴自身的狀態，實例的狀態數據可以維護再內存中
任何一個請求都可以被任意一個實例處理
不存儲狀態數據，實例可以水平擴展，通過負載均衡將請求分發到各個節點
在一個封閉的系統中，只存在一個數據閉環
通常存在于單體架構集群中

2.2.2?Statefulset—有狀態應用部署

里面運行的是mysql，mysql 宕了，配置一樣，不能直接用，數據有差異性，加入集群后滿足特定規則，存儲數據的規則，才能使用，有差異化稱為有狀態。

有狀態服務：例如數據庫
由特殊狀態需求，例如需要持久化、需要特定的數據支持

服務本身依賴或者存在局部的狀態數據，這些數據需要自身持久化或者可以通過其他節點恢復。
一個請求只能被某個節點（或者同等狀態下的節點）處理。
存儲狀態數據，實例的拓展需要整個系統參與狀態的遷移。
在一個封閉的系統中，存在多個數據閉環，需要考慮這些閉環的數據一致性問題。
通常存在于分布式架構中。

2.2.3?小結

無狀態服務：就是沒有特殊狀態的服務，各個請求對于服務器來說統一無差別處理，請求自身攜帶了所有服務端所需要的所有參數（服務端自身不存儲跟請求相關的任何數據，不包括數據庫存儲信息）。

有狀態服務：與之相反，有狀態服務在服務端保留之前請求的信息，用以處理當前請求，比如session等。

簡化

有狀態：需要持久化，多次請求之間需要共享一些信息
無狀態：一次性，不需要持久化的特殊狀態，每次請求都是一條新的數據

對于docker來說，更適合應用無狀態服務，而kubernetes，提供了一種解決方案----》多種存儲類型—》例如

configmap(配置管理中心)，主要存儲配置文件
PS:configmap是一個獨立的資源，類似于docker run -itd -v /nginx conf:/usr/nginx/conf nginx:1.21 /bin/bash

把nginx.conf---->寫成一個nginx-confimap.yaml文件
把nginx---->pod nginx.yaml ,通過相同的標簽：label=nginx來關聯

Secret:用戶密碼、需要加密的文件

mysql-secrets.yml加密形式的配置文件（賬號密碼）和mysql.yaml通過標簽關聯在一起
volume：基本數據（網頁文件），docker run -itd -v /nginx_html:/usr/local/nginx/html/ nginx:1.21 /bin/bash

PV/PVC:動態創建過程

2.3、Label標簽

標簽，是 K8S 特色的管理方式，便于分類管理資源對象。Label 可以附加到各種資源對象上，例如Node、Pod、Service、RC 等，用于關聯對象、查詢和篩選。
一個 Label 是一個 key-value 的鍵值對，其中 key 與 value 由用戶自己制定。
一個資源對象可以定義任意數量的 Label，同一個 Label 也可以被添加到任意數量的資源對象中，也可以在對象創建后動態添加或者刪除。
可以通過給指定的資源對象捆綁一個或多個不同的 Label，來實現多維度的資源分組管理功能。
與 Label 類似的，還有 Annotation（注釋）。區別在于有效的標簽值必須為 63個字符或更少，并且必須為空或以字母數字字符（[a-z0-9A-Z]）開頭和結尾，中間可以包含橫杠（-）、下劃線（_）、點（.）和字母或數字。注釋值則沒有字符長度限制。

2.4、Label 選擇器（Label selector）

給某個資源對象定義一個 Label，就相當于給它打了一個標簽
隨后可以通過標簽選擇器（Label selector）查詢和篩選擁有某些 Label 的資源對象。

標簽選擇器目前有兩種：

基于等值關系（等于、不等于）
基于集合關系（屬于、不屬于、存在）。

2.5、Service

在 K8S 的集群里，雖然每個 Pod 會被分配一個單獨的 IP 地址，但由于 Pod 是有生命周期的（它們可以被創建，而且銷毀之后不會再啟動），隨時可能會因為業務的變更，導致這個 IP 地址也會隨著 Pod 的銷毀而消失。Service 就是用來解決這個問題的核心概念。

K8S 中的 Service 并不是我們常說的 “服務” 的含義，而更像是網關層，可以看做一組提供相同服務的 Pod 的對外訪問的接口、流量均衡器。

Service 作用于哪些 Pod 是通過標簽選擇器來定義的。

在 K8S 集群中，Service 可以看做一組提供相同服務的 Pod 的對外訪問接口。客戶端需要訪問的服務就是 Service 對象。每個 Service 都有一個固定的虛擬 IP（這個 IP 也被稱為 Cluster IP），自動并且動態地綁定后端的 Pod，所有的網絡請求直接訪問 Service 的虛擬 IP，Service 會自動向后端做轉發。

Service 除了提供穩定的對外訪問方式之外，還能起到負載均衡（Load Balance）的功能，自動把請求流量分不到后端所有的服務上，Service 可以做到對客戶透明地進行水平擴展（scale）。而實現 service 這一功能的關鍵，就是 kube-proxy。kube-proxy 運行在每個節點上，監聽 API Server 中服務對象的變化，可通過以下三種流量調度模式：userspace（廢棄）、iptables（瀕臨廢棄）、ipvs（推薦，性能最好）來實現網絡的轉發。

**Service 是 K8S 服務的核心，屏蔽了服務細節，統一對外暴露服務接口，真正做到了 “微服務”。**比如我們的一個服務 A，部署了 3 個副本，也就是 3 個 Pod；對于用戶來說，只需要關注一個 Service 的入口就可以，而不需要操心究竟也應該請求哪一個 Pod。優勢非常明顯：一方面外部用戶不需要感知因為 Pod 上服務的意外崩潰、K8S 重新拉起 Pod 而造成的 IP 變更，外部用戶也不需要感知因升級、變更服務帶來的 Pod 替換而造成的 IP 變化。

創建service需要ServiceController,EndpointControllre,kube-proxy,三個模塊同時協作。

ServiceController是控制service來創建對應的Pod關聯的規則
EndpointController是定義后端pod的具體位置，也就是endpoint（upstream + consul的自動發現和更新）
kube-proxy是用來定義具體的后端轉發和分流規則的

以上組成了一個service所必要的功能

2.5.1?ServiceController

當一個service對象狀態發生變化的時候，informer都會通知ServiceController，創建對應的服務。

2.5.2?EndpointController

EndpointController會同時訂閱service和pod的增刪事件。
EndpointController看成是nginx的upstream + consyul中的發現、更新

其功能如下

負責生成和維護所有endpoint對象的控制器
負責監聽service和對應pod變化
監聽到service被刪除，則刪除和該service同名的endpoint對象
監聽到新的service被創建，則根據新建service信息（YAML）獲取相關pod列表，然后創建對應endpoint對象
監聽到service被更新，則根據更新后的service信息獲取相關pod列表，然后更新對應的endpoint對象
監聽到pod事件，則更新對應的service和endpoint對象，將podIP記錄到endpoint中

2.5.3?kube-proxy

kube-proxy負責service實現，實現了k8s內部service和外部node port到service的訪問。
kube-proxy采用iptables的方式配置負載均衡，基于iptables的kube-proxy的主要職責包括兩大塊：一塊是傾聽service更新事件，并更新service相關的iptables規則，一塊是偵聽endpoint更新事件，更新endpoint相關的iptables規則（如kube-svc鏈中的規則），然后將包請求轉入endpoint對應的pod.