詳解kubernetes pod的編排和生命周期

K8S Master基本架構

      K8S的集群運行依賴Master節點和Node節點的通信,為瞭更好的理解第4部分的Pod生命周期,我們這裡先給出K8S Master的簡單架構圖,後續的文章中,我們會分析Master、Node和Pod之間的關系。

Master的架構圖:

其中:

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

Scheduler是負責資源調度的進程;

Controller Manager是所有資源對象的自動化控制中心;

Etcd提供資源對象的數據保存服務

其中每個組件都有很多知識點,這裡我們隻要有個宏觀的印象就可以瞭,後續的文章中,我們會逐一分析。

Pod的編排思想

     上一篇文章末尾,我們提到瞭應用程序往k8s搬遷過程中的註意事項。這裡重申一下,當我們想要把虛擬機上的應用程序搬遷到k8s中時,我們需要用Pod來構建我們應用程序模塊。這個時候,比較重要的一點是劃分我們應用程序模塊,因為容器和虛擬機的設計模式不同,但是為瞭更好的理解和對比這二者的關系,我們可以設想下面的對應關系:

k8s—–操作系統

Pod—-虛擬機

容器—-進程

1、k8s相當於物理機的操作系統,k8s管理Pod相當於物理機的操作系統管理虛擬機

2、Pod相當於虛擬機,Pod裡面可能包含多個容器,對應於虛擬機中的很多進程

3、容器相當於進程,容器的本質,其實就是一個進程。

    有瞭這樣的概念,去理解Pod可能會更加形象。再說回我們的應用程序遷移,假設我們的應用程序存在:

web服務、日志分析、MySQL數據庫

三個關鍵的模塊,其中:

web服務和日志分析存在”超親密關系”,因為日志分析模塊要消費web服務模塊產生的日志,所以他們必須部署在同一個服務器上。反之、web服務和MySQL數據庫之間完全可以通過TCP-IP的方式來訪問,就沒有必要部署在同一臺機器上。如果我們用容器運行這個應用,那麼web服務需要和日志分析模塊打包在同一個Pod中,而MySQL數據庫服務單獨部署在一個Pod中即可,我們的應用程序遷移到k8s中,可能就是下面的結構:

將不同的進程或者任務,編排在同一個Pod中,這本質上,就是Pod的一種編排思想

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

     從上面的分析中不難看出,容器是隸屬於Pod中的一個元素,從yaml文件上看,容器就是Pod的整個yaml文件中的一個字段。現在我們看看Pod和容器有哪些重要屬性。

先看Pod的屬性:

1、凡是調度、網絡、存儲、安全相關的屬性,基本都是Pod相關的。

    調度,自然不用說,Pod是k8s的最小調度單元;網絡,同一個Pod中的容器共享Pod的網絡;存儲,可以通過Pod掛載卷的方式讓不同的容器共享Pod的存儲;安全,也是以Pod為維度來控制的。

2、凡是跟容器的Linux Namespace相關的屬性,也是Pod級別的。

    Pod的設計初衷,就是要容器之間共享Namespace。

3、凡是Pod中的容器要共享宿主機的Namespace,也一定是Pod級別的。

  這個更加容易理解,因為Pod要共享主機的Namespace,那麼Pod中的容器必然是要共享相同的Namespace,所以這個設置一定是Pod級別的。

再看Container的2個重要屬性:

1、ImagePullPolicy:這個屬性定義瞭鏡像拉取的策略,它的默認值是always,也就是每次創建Pod都拉取一次鏡像,它還有2個其他的取值,分別是never和ifnotpresent,這兩個比較容易理解,一種是從來不拉取鏡像,一種是隻有在不存在鏡像的時候才拉取鏡像。這裡需要註意一點,如果我們的版本號配置的是latest這種的,那麼ImagePullPolicy會被默認值always。

2、Lifecycle:顧名思義,它是在容器的生命周期中執行某些動作,它有兩個常見的參數,分別是postStart和preStop,就是在容器開始後或者容器結束前執行的一個特定操作。

Pod的生命周期

Pod的生命周期,主要體現在Pod的API的status部分,Pod的生命周期從開始到結束包含下面的幾個過程:

1、Pending,表示Pod的yaml文件已經交給k8s,並且保存在etcd(etcd是k8s中的元信息庫)中瞭。但是它由於調度不成功等原因沒有被創建。

2、Running,這個詞語具有迷惑性,它表示Pod已經調度成功,跟一臺具體的節點服務器綁定,Pod中的容器不一定全部都正常運行瞭,但是至少有一個在運行。

3、Succeeded,這個狀態意味著所有的容器都啟動完畢,並且已經退出。

4、Failed,這個很好理解,就是Pod中的容器至少有一個以非0狀態退出,也就是異常退出瞭。

5、Unknow。這是一個異常狀態,表示當前Pod的狀態不能正常的匯報給kube-apiserver瞭,這可能是主從節點之間的通信有問題。

如下所示為一個狀態為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的編排和生命周期的詳細內容,更多關於kubernetes pod的編排和生命周期的資料請關註WalkonNet其它相關文章!

推薦閱讀:

    None Found