目錄K8S Master基本架構

目前成都創新互聯公司已為1000多家的企業提供了網站建設、域名、虛擬空間、網站托管、服務器租用、企業網站設計、奇臺網站維護等服務，公司將堅持客戶導向、應用為本的策略，正道將秉承"和諧、參與、激情"的文化，與客戶和合作伙伴齊心協力一起成長，共同發展。

      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 podNAME                                READY     STATUS             RESTARTS   AGEmysql-pd7jr                         1/1       Running            0          118dmyweb-60r22                         1/1       Running            0          80d[root@VM-16-13-centos ~]# [root@VM-16-13-centos ~]# kubectl get pod mysql-pd7jr -o yamlapiVersion: v1kind: Podmetadata:  ...spec:  ...status:  ...  hostIP: 127.0.0.1  phase: Running  podIP: 172.17.0.2  startTime: 2020-11-20T09:01:39Z

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

分享文章：詳解kubernetespod的編排和生命周期
文章起源：http://www.js-pz168.com/article28/hipjp.html

成都網站建設公司_創新互聯，為您提供網站營銷、微信小程序、網站排名、網站改版、網站制作、企業網站制作

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯