如何理解Kubernetes核心概念與組件

本篇內容主要講解“如何理解Kubernetes核心概念與組件”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“如何理解Kubernetes核心概念與組件”吧!

Kubernetes是一個開源的容器編排引擎，用來對容器化應用進行自動化部署、  擴縮和管理。然而并非所有項目都需要微服務化，也并非所有項目需要Kubernetes，例如管理后臺、定時任務服務、非分布式數據庫等就沒有必要容器化部署，Kubernetes更適合部署分布式微服務應用。

Kubernetes架構

Kubernetes系統采用C/S架構設計，系統架構分為Master、Node兩部分，Master為Server端(主控節點)，Node為Client端(工作節點)。

Master主控節點作為集群的大腦負責管理所有工作節點(Node)、負責調度Pod運行在哪些工作節點上、負責控制集群運行過程中的所有狀態，其中節點表示云虛擬服務器。

Node工作節點負責管理容器、監控和上報運行在本節點上的所有Pod的運行狀態。

運行在Master主控節點上的組件有kube-apiserver、kube-controller-manager、kube-scheduler組件。

kube-apiserver負責將Kubernetes“資源組/資源版本/資源”以RESTful風格的形式對外暴露并提供服務。集群中的所有組件都通過kube-apiserver組件操作資源對象。kube-apiserver組件也是集群中唯一與Etcd集群進行交互的核心組件。

kube-controller-manager管理Kubernetes集群中的節點(Node)、Pod副本、服務、端點(Endpoint)、命名空間(Namespace)、服務賬戶(ServiceAccount)等。負責確保Kubernetes系統的實際狀態收斂到所需狀態，其默認提供了一些控制器(Controller)，例如DeploymentControllers控制器、StatefulSet控制器、Namespace控制器及PersistentVolume控制器等，每個控制器通過kube-apiserver組件提供的接口實時監控整個集群每個資源對象的當前狀態，當發生故障而導致系統狀態出現變化時，嘗試將系統狀態修復到期望狀態。

kube-scheduler調度器組件負責在Kubernetes集群中為一個Pod資源對象找到合適的節點并在該節點上運行。調度器每次只調度一個Pod資源對象，為每一個Pod資源對象尋找合適節點的過程是一個調度周期。調度器組件監控整個集群的Pod資源對象和Node資源對象，在監控到新的Pod資源對象時通過調度算法為其選擇最優節點。

運行在Node工作節點上的組件有kubelet、kube-proxy、container組件。

kubelet負責接收、處理、上報kube-apiserver組件下發的任務。kubelet進程啟動時會向kube-apiserver注冊節點(Node)自身信息。它主要負責所在節點(Node)上的Pod資源對象的創建、修改、監控、刪除、驅逐及Pod生命周期管理等。kubelet組件實現了3種開放接口，分別是CRI(容器運行時接口)、CNI(容器網絡接口)和CSI(容器存儲接口)。

kube-proxy作為節點上的網絡代理，運行在每個Kubernetes節點上。它監控kube-apiserver的服務和端點資源變化，并通過iptables/ipvs等配置負載均衡器，為一組Pod提供統一的TCP/UDP流量轉發和負載均衡功能，但只會向Kubernetes服務及其后端Pod發出請求。

資源概念

在kubernetes中，資源是最核心的概念，整個生態系統都圍繞資源運作。Kubernetes本質上是一個資源控制系統，負責注冊、管理、調度資源并維護資源的狀態。

Kubernetes將資源分組和版本化：

• Group:資源組

• Version:資源版本

• Resource:資源

• Kind:資源種類(分類)

資源對象與資源操作方法：

• 資源對象(Resource Object)：一個資源對象包含的字段有資源組、資源版本、資源種類;

• 資源操作方法(Verbs)：每一個資源都擁有資源操作方法，實現對Etcd的CURD操作，kubernetes支持的8種資源操作方法是create、delete、deletecollection、get、list、patch、update、watch。

Kubernetes支持兩類資源組，分別是擁有組名的資源組和沒有組名的資源組：

擁有組名的資源組：其表現形式為//，例如apps/v1/deployments;

沒有組名的資源組：核心資源組，其表現形式為/，例如/v1/pods。

Kubernetes提供的Restful API使用GVR(資源分組/資源版本/資源)生成path，如下表格示例：

擁有組名的資源組的path以/apis為前綴，沒有組名的資源組的path以/api為前綴。以/api/v1/configmaps為例，v1為資源版本號、configmaps為資源名稱。

資源還可以擁有子資源，例如pods有logs子資源。用kubectl查詢日記則命令為kubectl logs  [pod]，對應API的path為：/api/v1/pods/logs。

kubernetes支持8種資源操作方法，但并非每種資源都需要支持8種資源操作方法。如pods/logs子資源就只擁有get操作方法，因為日志只需要執行查看操作。

Kubernetes系統支持命名空間(Namespace)，每個命名空間相當于一個“虛擬集群”，不同命名空間之間可以進行隔離。命名空間常用于劃分不同的環境，例如生產環境、測試環境、開發環境等使用不同的命名空間進行劃分，也可用于劃分無關聯的項目，如用于劃分項目A、項目B。

資源對象描述文件定義

Kubernetes資源可分為內置資源和自定義資源，它們都通過資源對象描述文件進行定義。一個資源對象需要用5個字段來描述，分別是Group/Version、Kind、MetaData、Spec、Status。

以Service資源描述文件為例，配置如下：

apiVersion: v1 kind: Service metadata:   name: test-service   namespace: default spec:   ....

• apiVersion：即Group/Version，Service在核心資源組，所以沒有資源組名，v1為資源版本;

• Kind：資源種類;

• MetaData：定義元數據信息，如資源名稱、命名空間;

• Spec：描述Service的期望狀態;

• Status：描述資源對象的實際狀態，隱藏的，不需要配置，由Kubernetes系統提供和更新。

Pod調度

Pod資源對象支持優先級與搶占機制。當kube-scheduler調度器運行時，根據Pod資源對象的優先級進行調度，高優先級的Pod資源對象排在調度隊列的前面，優先獲得合適的節點(Node)，再為低優先級的Pod資源對象選擇合適的節點。

當高優先級的Pod資源對象沒有找到合適的節點時，調度器會嘗試搶占低優先級的Pod資源對象的節點，搶占過程是將低優先級的Pod資源對象從所在的節點上驅逐走，使高優先級的Pod資源對象運行在該節點上，被驅逐走的低優先級的Pod資源對象會重新進入調度隊列并等待再次選擇合適的節點。

在默認的情況下，若不啟用優先級功能，則現有Pod資源對象的優先級都為0。為Pod資源配置優先級的步驟如下：

1、通過PriorityClass資源對象描述文件創建PriorityClass資源對象，配置文件如下：

apiVersion: scheduling.k8s.io/v1 kind: PriorityClass metadata:  name: MainResourceHighPriority value: 10000 globalDefault: false description: "highest priority"

• value：表示優先級，值越高優先級越高;

• globalDefault：是否為全局默認，當Pod沒有指定使用的優先級時默認使用此優先級。

• 2、修改Pod資源對象描述文件，為Pod指定優先級

通過Deployment配置Pod資源時，只需要在Deployment描述文件的Spec下的Spec添加一項名為priorityClassName的配置，如下：

apiVersion: apps/v1 kind: Deployment metadata:   name: test-server   namespace: default spec:   replicas: 1     # 配置pod     spec:       containers:         - name: test-server-pod           image: test-server:latest           imagePullPolicy: IfNotPresent           ports:             - name: http-port               containerPort: 8080           envFrom:             - configMapRef:                 name: common-config       serviceAccountName: admin-sa       priorityClassName: MainResourceHighPriority

親和性調度

與調度相關的還有親和性調度。kube-scheduler調度器自動為Pod資源對象選擇全局最優或局部最優節點(即節點的硬件資源足夠多、節點負載足夠小等)。在生產環境中，一般希望能夠更多地干預Pod資源對象的調度，例如，將不需要依賴GPU硬件資源的Pod資源對象分配給沒有GPU硬件資源的節點，將需要依賴GPU硬件資源的Pod資源對象分配給具有GPU硬件資源的節點。開發者只需要在這些節點上打上相應的標簽，然后調度器就可以通過標簽進行Pod資源對象的調度，這種調度策略被稱為親和性和反親和性調度。

• 親和性(Affinity)：用于多業務就近部署，例如允許將兩個業務(如廣告點擊服務與IP查詢服務)的Pod資源對象盡可能地調度到同一個節點上，減少網絡開銷;

• 反親和性(Anti-Affinity)：允許將一個業務的Pod資源對象的多副本實例調度到不同的節點上，以實現高可用性，例如訂單服務的POD期望有三個副本，將三個副本部署在不同的節點上。

Pod資源對象目前支持兩種親和性和一種反親和性：

• NodeAffinity：節點親和性，將某個Pod資源對象調度到特定的節點上，如需要GPU的POD調度到有GPU的節點上;

• PodAffinity：Pod資源對象親和性，將某個Pod資源對象調度到與另一個Pod資源對象相鄰的位置，例如調度到同一主機，調度到同一硬件集群，調度到同一機房，以縮短網絡傳輸延時;

• PodAntiAffinity：Pod資源對象反親和性，將一個Pod資源對象的多副本實例調度到不同的節點上，調度到不同的硬件集群上等，這樣可以降低風險并提升Pod資源對象的可用性。

內置調度算法

kube-scheduler調度器默認提供了兩類調度算法，分別是預選調度算法和優選調度算法。

• 預選調度算法：檢查節點是否符合運行“待調度Pod資源對象”的條件，如果符合條件，則將其加入可用節點列表;

• 優選調度算法：為每一個可用節點計算出一個最終分數，kube-scheduler調度器會將分數最高的節點作為最優運行“待調度Pod資源對象”的節點。

到此，相信大家對“如何理解Kubernetes核心概念與組件”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！