k8s之pod

Pod是Kubernetes最重要的基本概念，如圖1.4所示是Pod的組成示意 圖，咱們看到每一個Pod都有一個特殊的被稱爲「根容器」的Pause容器。 Pause容器對應的鏡像屬於Kubernetes平臺的一部分，除了Pause容器， 每一個Pod還包含一個或多個緊密相關的用戶業務容器。

爲何Kubernetes會設計出一個全新的Pod的概念而且Pod有這樣特

殊的組成結構?

緣由之一:在一組容器做爲一個單元的狀況下，咱們難以簡單地 對「總體」進行判斷及有效地行動。好比，一個容器死亡了，此時算是整 體死亡麼?是N/M的死亡率麼?引入業務無關而且不易死亡的Pause容 器做爲Pod的根容器，以它的狀態表明整個容器組的狀態，就簡單、巧 妙地解決了這個難題。

緣由之二:Pod裏的多個業務容器共享Pause容器的IP，共享Pause容 器掛接的V olume，這樣既簡化了密切關聯的業務容器之間的通訊問 題，也很好地解決了它們之間的文件共享問題。

Kubernetes爲每一個Pod都分配了惟一的IP地址，稱之爲Pod IP，一個 Pod裏的多個容器共享Pod IP地址。Kubernetes要求底層網絡支持集羣內 任意兩個Pod之間的TCP/IP直接通訊，這一般採用虛擬二層網絡技術來 實現，例如Flannel、Open vSwitch等，所以咱們須要牢記一點:在 Kubernetes裏，一個Pod裏的容器與另外主機上的Pod容器可以直接通 信。

Pod其實有兩種類型:普通的Pod及靜態Pod(Static Pod)。後者比 較特殊，它並沒被存放在Kubernetes的etcd存儲裏，而是被存放在某個 具體的Node上的一個具體文件中，而且只在此Node上啓動、運行。而 普通的Pod一旦被建立，就會被放入etcd中存儲，隨後會被Kubernetes Master調度到某個具體的Node上並進行綁定(Binding)，隨後該Pod被 對應的Node上的kubelet進程實例化成一組相關的Docker容器並啓動。在 默認狀況下，當Pod裏的某個容器中止時，Kubernetes會自動檢測到這個 問題而且從新啓動這個Pod(重啓Pod裏的全部容器)，若是Pod所在的 Node宕機，就會將這個Node上的全部Pod從新調度到其餘節點上。 Pod、容器與Node的關係如圖1.5所示。

Kubernetes裏的全部資源對象均可以採用Y AML或者JSON格式的文 件來定義或描述，下面是咱們在以前的Hello World例子裏用到的myweb 這個Pod的資源定義文件:

Kind爲Pod代表這是一個Pod的定義，metadata裏的name屬性爲Pod 的名稱，在metadata裏還能定義資源對象的標籤，這裏聲明myweb擁有 一個name=myweb的標籤。在Pod裏所包含的容器組的定義則在spec一節 中聲明，這裏定義了一個名爲myweb、對應鏡像爲kubeguide/tomcat- app:v1的容器，該容器注入了名爲MYSQL_SERVICE_HOST='mysql'和 MYSQL_SERVICE_PORT='3306'的環境變量(env關鍵字)，而且在 8080端口(containerPort)啓動容器進程。Pod的IP加上這裏的容器端口 (containerPort)，組成了一個新的概念—Endpoint，它表明此Pod裏的 一個服務進程的對外通訊地址。一個Pod也存在具備多個Endpoint的情 況，好比當咱們把Tomcat定義爲一個Pod時，能夠對外暴露管理端口與

服務端口這兩個Endpoint。

咱們所熟悉的Docker V olume在Kubernetes裏也有對應的概念—Pod V olume，後者有一些擴展，好比能夠用分佈式文件系統GlusterFS實現 後端存儲功能;Pod V olume是被定義在Pod上，而後被各個容器掛載到 本身的文件系統中的。

這裏順便提一下Kubernetes的Event概念。Event是一個事件的記 錄，記錄了事件的最先產生時間、最後重現時間、重複次數、發起者、 類型，以及致使此事件的緣由等衆多信息。Event一般會被關聯到某個 具體的資源對象上，是排查故障的重要參考信息，以前咱們看到Node的 描述信息包括了Event，而Pod一樣有Event記錄，當咱們發現某個Pod遲 遲沒法建立時，能夠用kubectl describe pod xxxx來查看它的描述信息， 以定位問題的成因，好比下面這個Event記錄信息代表Pod裏的一個容器 被探針檢測爲失敗一次:

每一個Pod均可以對其能使用的服務器上的計算資源設置限額，當前 能夠設置限額的計算資源有CPU與Memory兩種，其中CPU的資源單位 爲CPU(Core)的數量，是一個絕對值而非相對值。

對於絕大多數容器來講，一個CPU的資源配額至關大，因此在 Kubernetes裏一般以千分之一的CPU配額爲最小單位，用m來表示。通 常一個容器的CPU配額被定義爲100~300m，即佔用0.1~0.3個CPU。由

於CPU配額是一個絕對值，因此不管在擁有一個Core的機器上，仍是在 擁有48個Core的機器上，100m這個配額所表明的CPU的使用量都是同樣 的。與CPU配額相似，Memory配額也是一個絕對值，它的單位是內存 字節數。

在Kubernetes裏，一個計算資源進行配額限定時須要設定如下兩個 參數。

◎ Requests:該資源的最小申請量，系統必須知足要求。 ◎ Limits:該資源最大容許使用的量，不能被突破，當容器試圖

使用超過這個量的資源時，可能會被Kubernetes「殺掉」並重啓。

一般，咱們會把Requests設置爲一個較小的數值，符合容器平時的 工做負載狀況下的資源需求，而把Limit設置爲峯值負載狀況下資源佔 用的最大量。下面這段定義代表MySQL容器申請最少0.25個CPU及 64MiB內存，在運行過程當中MySQL容器所能使用的資源配額爲0.5個 CPU及128MiB內存:

本節最後給出Pod及Pod周邊對象的示意圖做爲總結，如圖1.6所 示，後面部分還會涉及這張圖裏的對象和概念，以進一步增強理解。

文章來源於Kubernetes權威指南