K8S的集群運行依賴(lài)Master節點(diǎn)和Node節點(diǎn)的通信,為了更好的理解第4部分的Pod生命周期,我們這里先給出K8S Master的簡(jiǎn)單架構圖,后續的文章中,我們會(huì )分析Master、Node和Pod之間的關(guān)系。
Master的架構圖:
其中:
API Server提供了HTTP Rest接口,它是k8s中的所有資源增刪改查的唯一入口,也是集群控制的入口;
Scheduler是負責資源調度的進(jìn)程;
Controller Manager是所有資源對象的自動(dòng)化控制中心;
Etcd提供資源對象的數據保存服務(wù)
其中每個(gè)組件都有很多知識點(diǎn),這里我們只要有個(gè)宏觀(guān)的印象就可以了,后續的文章中,我們會(huì )逐一分析。
,我們提到了應用程序往k8s搬遷過(guò)程中的注意事項。這里重申一下,當我們想要把虛擬機上的應用程序搬遷到k8s中時(shí),我們需要用Pod來(lái)構建我們應用程序模塊。這個(gè)時(shí)候,比較重要的一點(diǎn)是劃分我們應用程序模塊,因為容器和虛擬機的設計模式不同,但是為了更好的理解和對比這二者的關(guān)系,我們可以設想下面的對應關(guān)系:
k8s-----操作系統
Pod----虛擬機
容器----進(jìn)程
1、k8s相當于物理機的操作系統,k8s管理Pod相當于物理機的操作系統管理虛擬機
2、Pod相當于虛擬機,Pod里面可能包含多個(gè)容器,對應于虛擬機中的很多進(jìn)程
3、容器相當于進(jìn)程,容器的本質(zhì),其實(shí)就是一個(gè)進(jìn)程。
有了這樣的概念,去理解Pod可能會(huì )更加形象。再說(shuō)回我們的應用程序遷移,假設我們的應用程序存在:
web服務(wù)、日志分析、MySQL數據庫
三個(gè)關(guān)鍵的模塊,其中:
web服務(wù)和日志分析存在"超親密關(guān)系",因為日志分析模塊要消費web服務(wù)模塊產(chǎn)生的日志,所以他們必須部署在同一個(gè)服務(wù)器上。反之、web服務(wù)和MySQL數據庫之間完全可以通過(guò)TCP-IP的方式來(lái)訪(fǎng)問(wèn),就沒(méi)有必要部署在同一臺機器上。如果我們用容器運行這個(gè)應用,那么web服務(wù)需要和日志分析模塊打包在同一個(gè)Pod中,而MySQL數據庫服務(wù)單獨部署在一個(gè)Pod中即可,我們的應用程序遷移到k8s中,可能就是下面的結構:
將不同的進(jìn)程或者任務(wù),編排在同一個(gè)Pod中,這本質(zhì)上,就是Pod的一種編排思想
從上面的分析中不難看出,容器是隸屬于Pod中的一個(gè)元素,從yaml文件上看,容器就是Pod的整個(gè)yaml文件中的一個(gè)字段?,F在我們看看Pod和容器有哪些重要屬性。
先看Pod的屬性:
1、凡是調度、網(wǎng)絡(luò )、存儲、安全相關(guān)的屬性,基本都是Pod相關(guān)的。
調度,自然不用說(shuō),Pod是k8s的最小調度單元;網(wǎng)絡(luò ),同一個(gè)Pod中的容器共享Pod的網(wǎng)絡(luò );存儲,可以通過(guò)Pod掛載卷的方式讓不同的容器共享Pod的存儲;安全,也是以Pod為維度來(lái)控制的。
2、凡是跟容器的Linux Namespace相關(guān)的屬性,也是Pod級別的。
Pod的設計初衷,就是要容器之間共享Namespace。
3、凡是Pod中的容器要共享宿主機的Namespace,也一定是Pod級別的。
這個(gè)更加容易理解,因為Pod要共享主機的Namespace,那么Pod中的容器必然是要共享相同的Namespace,所以這個(gè)設置一定是Pod級別的。
再看Container的2個(gè)重要屬性:
1、ImagePullPolicy:這個(gè)屬性定義了鏡像拉取的策略,它的默認值是always,也就是每次創(chuàng )建Pod都拉取一次鏡像,它還有2個(gè)其他的取值,分別是never和ifnotpresent,這兩個(gè)比較容易理解,一種是從來(lái)不拉取鏡像,一種是只有在不存在鏡像的時(shí)候才拉取鏡像。這里需要注意一點(diǎn),如果我們的版本號配置的是latest這種的,那么ImagePullPolicy會(huì )被默認值always。
2、Lifecycle:顧名思義,它是在容器的生命周期中執行某些動(dòng)作,它有兩個(gè)常見(jiàn)的參數,分別是postStart和preStop,就是在容器開(kāi)始后或者容器結束前執行的一個(gè)特定操作。
Pod的生命周期,主要體現在Pod的API的status部分,Pod的生命周期從開(kāi)始到結束包含下面的幾個(gè)過(guò)程:
1、Pending,表示Pod的yaml文件已經(jīng)交給k8s,并且保存在etcd(etcd是k8s中的元信息庫)中了。但是它由于調度不成功等原因沒(méi)有被創(chuàng )建。
2、Running,這個(gè)詞語(yǔ)具有迷惑性,它表示Pod已經(jīng)調度成功,跟一臺具體的節點(diǎn)服務(wù)器綁定,Pod中的容器不一定全部都正常運行了,但是至少有一個(gè)在運行。
3、Succeeded,這個(gè)狀態(tài)意味著(zhù)所有的容器都啟動(dòng)完畢,并且已經(jīng)退出。
4、Failed,這個(gè)很好理解,就是Pod中的容器至少有一個(gè)以非0狀態(tài)退出,也就是異常退出了。
5、Unknow。這是一個(gè)異常狀態(tài),表示當前Pod的狀態(tài)不能正常的匯報給kube-apiserver了,這可能是主從節點(diǎn)之間的通信有問(wè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的編排和生命周期的詳細內容,更多關(guān)于kubernetes pod的編排和生命周期的資料請關(guān)注腳本之家其它相關(guān)文章!
免責聲明:本站發(fā)布的內容(圖片、視頻和文字)以原創(chuàng )、來(lái)自本網(wǎng)站內容采集于網(wǎng)絡(luò )互聯(lián)網(wǎng)轉載等其它媒體和分享為主,內容觀(guān)點(diǎn)不代表本網(wǎng)站立場(chǎng),如侵犯了原作者的版權,請告知一經(jīng)查實(shí),將立刻刪除涉嫌侵權內容,聯(lián)系我們QQ:712375056,同時(shí)歡迎投稿傳遞力量。
Copyright ? 2009-2022 56dr.com. All Rights Reserved. 特網(wǎng)科技 特網(wǎng)云 版權所有 特網(wǎng)科技 粵ICP備16109289號
域名注冊服務(wù)機構:阿里云計算有限公司(萬(wàn)網(wǎng)) 域名服務(wù)機構:煙臺帝思普網(wǎng)絡(luò )科技有限公司(DNSPod) CDN服務(wù):阿里云計算有限公司 百度云 中國互聯(lián)網(wǎng)舉報中心 增值電信業(yè)務(wù)經(jīng)營(yíng)許可證B2
建議您使用Chrome、Firefox、Edge、IE10及以上版本和360等主流瀏覽器瀏覽本網(wǎng)站