Kubernetes的工作原理是什么

Kubernetes的工作原理是什么，相信很多沒有經驗的人對此束手無策，為此本文總結了問題出現的原因和解決方法，通過這篇文章希望你能解決這個問題。

1. Kubernetes 核心組件分析

1.1 核心概念：Pod

• Pod 是 Kubernetes 中最小的可部署的計算單元

• 這樣的一組容器被“打包”到一起組成了一個Pod 并接受 Kubernetes 的調度，編排等控制邏輯。

• 為了讓大家更好的理解“一組容器“的概念，接下來為大家詳細剖析 Pod 的內部架構。

Pod 的內部架構

藍色部分代表的是整個 Pod。其中右上角的net namespace 是 Pod 級別的 namespace，它代表了 Pod 中的所有容器。

圖中有4個 Container（即：PauseContainer/Container A/Container B/Container C/），他們在創建的時候都被加入到了 namespace 當中。

那么，Pod 級別的 Container 是從哪里來的呢？從圖中可以看到，真正工作的 Container 我們把它標注為 A，B，C。Pause Container 的作用相當于一個占位符。當我們創建 Pod 的時候，會首先創建一個 Pause Container。該容器創建出來的namespace，就相當于整個 Pod 的 namespace。然后后面的容器再創建出來（比如說Container A/B/C）這些容器在創建出來的時候，就都會選擇加入到 Pause Container 創建出來的 net namespace 當中。

當然，也不是所有的 namespace 都是不隔離的。Container 左側是一個 image，每一個 container 都有一個鏡像，每一個鏡像又相當于一個容器的 Root ffs。既然每個容器的 Root ffs 是不相同的，那么顯而易見，mnt namespace 就是隔離的。

這樣我們就可以清楚地看到，哪些 namespce 在 Pod 當中是互相隔離的，而哪些是在  Pod 級別當中共享的。

Pod 在 Kubernetes 中的展現形式

通常，我們習慣用 Yaml 來描述 Kubernetes 里的資源。Yaml 中的內容其實就是我們對資源參數的描述。

我們先看 Pod 在 Yaml 中的前四行。這四行是資源在 Yaml 中的通用字段。ApiVersion/kind 用于表示 Kubernetes 的資源類型是什么。通過 metadata 來聲明資源的源數據。Spec 字段和資源類型是強相關的了。不同的資源會有不同的 spec 定義。那在 Pod 資源當中，最核心的是關于容器的定義了。

下面幾行，關于容器的定義，是一個數組類型的，這也符合我們對 Pod 的定義：即它是由一組容器形成的。這些字段包含：聲明容器鏡像，啟動容器的命令，容器鏡像的拉取方式，以及容器的名稱。

1.2 核心概念 Kubelet

Kubelet 是 Kubernetes 集群的“節點代理”。也可以說是 Kubernetes 部署在每個節點的agent。

Kubelet 啟動后會向 Kubernetes 集群注冊自己，并上報節點的相關信息。此時在 Kubernetes 集群中就增加了一臺新的可用的 Node 節點（可能是一個物理機，也可能是一個虛擬機，甚至是一個容器）。

Kubelet 發現有屬于自己節點的 Pod 符合創建條件后，會按照Pod聲明的配置去啟動容器。

1.3 Kubernetes 控制面的相關組件

上面這張圖分為3個部分作介紹：

1. 下半部分：也就是之前介紹過的Kubelet/Pod。

2. 左上角：Kubectl。也就是Kubernetes 的命令行工具。可以通過Kubectl來提交資源的Yaml 給Kubernetes 集群。也可以進行一系列的運維操作。

3. 右面：Master 節點。也就是Kubernetes 控制面的相關組件了。其中，API Sever是Kubernetes 中所有源數據的集成入口。也是整個Kubernetes 集群的中樞組件。其他組件（包括Controller, Scheduler等）在獲取數據都需要和API Sever 打交道。API Sever 也會接受這些組件的協入請求，并最終將數據寫入ETCD 當中。同時，API Sever 也會緩存所有的源數據。當其他組件發起“讀”請求時，就會將數據直接從內存中發給對方。盡量避免ETCD 成為系統的瓶頸。除了源數據存儲功能，API Server 還提供了一個Watch 機制。能夠主動推送某種資源的變化。而Scheduler會向API Sever 注冊并且監聽Pod 的資源變更事件。Scheduler 整體的調度邏輯可以簡化并概括為兩個：過濾、打分。

每次對Pod進行調度的時候，首先將不符合條件的Node（如：機器上已經沒有資源了，不符合某些標簽，選擇器的要求等）過濾掉。過濾完成后我們得到一個符合要求的Node列表，Scheduler  會通過打分算法，來計算每一個Node 的分數。最終選擇一個得分最高的節點做為Pod 需要綁定的節點。最終Scheduler 會將結果回寫到API Sever 當中。

編排組件：Controller。Controller 通過幾種固定的workload。通過控制器的方式，來完成運行時服務器的編排工作。

2. 快速搭建 Kubernetes 集群

2.1 搭建工具：Kubeadm 簡介

Kubeadm 是 Kubernetes 官方提供的用于快速安裝 Kubernetes 集群的工具。

下圖是 Kubeadm 的配置文件

在配置文件當中，我們指定了 dns 的類型，ETCD 存儲目錄以及要創建的 Kubernetes 的版本以及相關的參數。

2.2 搭建環境

初始 Master 節點

Kubeadm init—config kubeadm.conf

安裝 flannel cni

https://raw.githusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

3. Demo：演示如何操作一個 Pod

創建一個 Namespace

Kubectl create namespace demo

創建 Pod

Kubectl apply –f pod.yaml

查看 Pod 運行狀態

Kubectl describe pods demo-pod–n demo

查看 Pod 輸出日志

Kubectl logs demo-pod –n demo

查看 Pods 列表

Kubectl get pods-n demo

刪除 Pod

Kubectl delete-f pod.yaml

 MoreCommand

Basic Commands: create，expose, run, setBasic Commands: explain, get，edit，deleteDeploy Commands: rollout，scale，autoscale

看完上述內容，你們掌握Kubernetes的工作原理是什么的方法了嗎？如果還想學到更多技能或想了解更多相關內容，歡迎關注億速云行業資訊頻道，感謝各位的閱讀！