K8S Master基本架構(gòu)

      K8S的集群運(yùn)行依賴Master節(jié)點(diǎn)和Node節(jié)點(diǎn)的通信，為了更好的理解第4部分的Pod生命周期，我們這里先給出K8S Master的簡單架構(gòu)圖，后續(xù)的文章中，我們會(huì)分析Master、Node和Pod之間的關(guān)系。

Master的架構(gòu)圖：

其中：

API Server提供了HTTP Rest接口，它是k8s中的所有資源增刪改查的唯一入口，也是集群控制的入口；

Scheduler是負(fù)責(zé)資源調(diào)度的進(jìn)程；

Controller Manager是所有資源對象的自動(dòng)化控制中心；

Etcd提供資源對象的數(shù)據(jù)保存服務(wù)

其中每個(gè)組件都有很多知識(shí)點(diǎn)，這里我們只要有個(gè)宏觀的印象就可以了，后續(xù)的文章中，我們會(huì)逐一分析。

Pod的編排思想

     上一篇文章末尾，我們提到了應(yīng)用程序往k8s搬遷過程中的注意事項(xiàng)。這里重申一下，當(dāng)我們想要把虛擬機(jī)上的應(yīng)用程序搬遷到k8s中時(shí)，我們需要用Pod來構(gòu)建我們應(yīng)用程序模塊。這個(gè)時(shí)候，比較重要的一點(diǎn)是劃分我們應(yīng)用程序模塊，因?yàn)槿萜骱吞摂M機(jī)的設(shè)計(jì)模式不同，但是為了更好的理解和對比這二者的關(guān)系，我們可以設(shè)想下面的對應(yīng)關(guān)系：

k8s-----操作系統(tǒng)

Pod----虛擬機(jī)

容器----進(jìn)程

1、k8s相當(dāng)于物理機(jī)的操作系統(tǒng)，k8s管理Pod相當(dāng)于物理機(jī)的操作系統(tǒng)管理虛擬機(jī)

2、Pod相當(dāng)于虛擬機(jī)，Pod里面可能包含多個(gè)容器，對應(yīng)于虛擬機(jī)中的很多進(jìn)程

3、容器相當(dāng)于進(jìn)程，容器的本質(zhì)，其實(shí)就是一個(gè)進(jìn)程。

    有了這樣的概念，去理解Pod可能會(huì)更加形象。再說回我們的應(yīng)用程序遷移，假設(shè)我們的應(yīng)用程序存在：

web服務(wù)、日志分析、MySQL數(shù)據(jù)庫

三個(gè)關(guān)鍵的模塊，其中：

web服務(wù)和日志分析存在"超親密關(guān)系"，因?yàn)槿罩痉治瞿K要消費(fèi)web服務(wù)模塊產(chǎn)生的日志，所以他們必須部署在同一個(gè)服務(wù)器上。反之、web服務(wù)和MySQL數(shù)據(jù)庫之間完全可以通過TCP-IP的方式來訪問，就沒有必要部署在同一臺(tái)機(jī)器上。如果我們用容器運(yùn)行這個(gè)應(yīng)用，那么web服務(wù)需要和日志分析模塊打包在同一個(gè)Pod中，而MySQL數(shù)據(jù)庫服務(wù)單獨(dú)部署在一個(gè)Pod中即可，我們的應(yīng)用程序遷移到k8s中，可能就是下面的結(jié)構(gòu)：

將不同的進(jìn)程或者任務(wù)，編排在同一個(gè)Pod中，這本質(zhì)上，就是Pod的一種編排思想

Pod對象的屬性和容器的屬性？

     從上面的分析中不難看出，容器是隸屬于Pod中的一個(gè)元素，從yaml文件上看，容器就是Pod的整個(gè)yaml文件中的一個(gè)字段?，F(xiàn)在我們看看Pod和容器有哪些重要屬性。

先看Pod的屬性：

1、凡是調(diào)度、網(wǎng)絡(luò)、存儲(chǔ)、安全相關(guān)的屬性，基本都是Pod相關(guān)的。

    調(diào)度，自然不用說，Pod是k8s的最小調(diào)度單元；網(wǎng)絡(luò)，同一個(gè)Pod中的容器共享Pod的網(wǎng)絡(luò)；存儲(chǔ)，可以通過Pod掛載卷的方式讓不同的容器共享Pod的存儲(chǔ)；安全，也是以Pod為維度來控制的。

2、凡是跟容器的Linux Namespace相關(guān)的屬性，也是Pod級(jí)別的。

    Pod的設(shè)計(jì)初衷，就是要容器之間共享Namespace。

3、凡是Pod中的容器要共享宿主機(jī)的Namespace，也一定是Pod級(jí)別的。

  這個(gè)更加容易理解，因?yàn)镻od要共享主機(jī)的Namespace，那么Pod中的容器必然是要共享相同的Namespace，所以這個(gè)設(shè)置一定是Pod級(jí)別的。

再看Container的2個(gè)重要屬性：

1、ImagePullPolicy：這個(gè)屬性定義了鏡像拉取的策略，它的默認(rèn)值是always，也就是每次創(chuàng)建Pod都拉取一次鏡像，它還有2個(gè)其他的取值，分別是never和ifnotpresent，這兩個(gè)比較容易理解，一種是從來不拉取鏡像，一種是只有在不存在鏡像的時(shí)候才拉取鏡像。這里需要注意一點(diǎn)，如果我們的版本號(hào)配置的是latest這種的，那么ImagePullPolicy會(huì)被默認(rèn)值always。

2、Lifecycle：顧名思義，它是在容器的生命周期中執(zhí)行某些動(dòng)作，它有兩個(gè)常見的參數(shù)，分別是postStart和preStop，就是在容器開始后或者容器結(jié)束前執(zhí)行的一個(gè)特定操作。

Pod的生命周期

Pod的生命周期，主要體現(xiàn)在Pod的API的status部分，Pod的生命周期從開始到結(jié)束包含下面的幾個(gè)過程：

1、Pending，表示Pod的yaml文件已經(jīng)交給k8s，并且保存在etcd（etcd是k8s中的元信息庫）中了。但是它由于調(diào)度不成功等原因沒有被創(chuàng)建。

2、Running，這個(gè)詞語具有迷惑性，它表示Pod已經(jīng)調(diào)度成功，跟一臺(tái)具體的節(jié)點(diǎn)服務(wù)器綁定，Pod中的容器不一定全部都正常運(yùn)行了，但是至少有一個(gè)在運(yùn)行。

3、Succeeded，這個(gè)狀態(tài)意味著所有的容器都啟動(dòng)完畢，并且已經(jīng)退出。

4、Failed，這個(gè)很好理解，就是Pod中的容器至少有一個(gè)以非0狀態(tài)退出，也就是異常退出了。

5、Unknow。這是一個(gè)異常狀態(tài)，表示當(dāng)前Pod的狀態(tài)不能正常的匯報(bào)給kube-apiserver了，這可能是主從節(jié)點(diǎn)之間的通信有問題。

如下所示為一個(gè)狀態(tài)為running的Pod

[root@VM-16-13-centos ~]# kubectl get pod
NAME                                READY     STATUS             RESTARTS   AGE
mysql-pd7jr                         1/1       Running            0          118d
myweb-60r22                         1/1       Running            0          80d

[root@VM-16-13-centos ~]# 
[root@VM-16-13-centos ~]# kubectl get pod mysql-pd7jr -o yaml
apiVersion: v1
kind: Pod
metadata:
  ...
spec:
  ...
status:
  ...
  hostIP: 127.0.0.1
  phase: Running
  podIP: 172.17.0.2
  startTime: 2020-11-20T09:01:39Z

以上就是詳解kubernetes pod的編排和生命周期的詳細(xì)內(nèi)容，更多關(guān)于kubernetes pod的編排和生命周期的資料請關(guān)注腳本之家其它相關(guān)文章！