概述

Pod 是k8s 系統中可以創建和管理的最小單元

k8s 不會直接處理容器，而是 Pod

Pod 是由一個或多個container （容器）組成

一個pod中容器共享網絡命令空間（如果一個pod里面有三個容器，那么這三個容器之間的網絡是共享的）

pod是短暫存在的（假設一個pod重新創建或啟動后，其ip是會變化的）

每一個 Pod 都有一個特殊的被稱為”根容器“的 Pause容器

Pause 容器對應的鏡 像屬于 Kubernetes 平臺的一部分，除了 Pause 容器，每個 Pod還包含一個或多個緊密相關的用戶業務容器

pod存在的意義

（1）創建容器使用docker，一個docker對應一個容器，一個容器有進程，一個容器運行一個應用程序

創建一個容器（docker），docker的設計是一個單進程，而一個容器運行一個應用程序，當然也可以運行多個，但是現在多個的話是不方便管理的

（2）pod是多進程設計，運行多個應用程序

一個pod里面有多個容器，每個容器里面都可以運行一個應用程序

（3）Pod的存在也是為了親密性應用

兩個應用或多個應用直接進行交互（一個pod里面的多個容器進行信息的交互）

里面的容器進行網絡直接的調用（一個Pod里面的多個容器進行網絡調用時，可以通過socket和127.0.0.1等進行網絡的調用）

Pod里面的多個應用需要頻繁調用

Pod的實現機制

機制一：共享網絡

容器使用docker創建，所以容器本身之間是相互隔離的，這個隔離是通過Linux中的namespace和group進行隔離的

在pod中有多個容器，那么在Pod里面是怎么實現共享網絡的？

共享網絡的前提條件：

容器在同一個namespace里面

pod的實現：

Pod里面有多個容器，在pod的操作中，首先會創建一個容器，這個容器是pod自己默認創建的根容器：Pause，也被稱為info容器

當在pod里面創建業務容器時，這些業務容器都會加入到info容器/Pause里面，加入之后，info容器便會獨立出一個地方有IP地址、mac地址、port，并且加入的容器都會有同一個namespace。

這些創建的容器便會生成對應的信息，存放到同一個namespace里面，然后，他們便會共享同一個ip、mac和port

簡單來說，就是通過一個Pause容器，將創建的業務容器加入到同一個namespace空間中，實現網絡的共享

總結：通過Pause容器，把其他業務容器加入到Pause容器里面，讓所有業務容器在同一個名稱空間中，可以實現網絡共享

示例如下：

在一個 Pod 里的多個容器共享 Pod 的 IP 和端口 namespace，所以一個 Pod 內的多個容器之間可以通過 localhost 來進行通信,所需要注意的是不同容器要注意不要有端口沖突即可。不同的 Pod 有不同的 IP,不同 Pod 內的多個容器之前通信，不可以使用 IPC（如果沒有特殊指定的話）通信，通常情況下使用 Pod的 IP 進行通信

機制二：共享存儲

一個 Pod 里的多個容器可以共享存儲卷，這個存儲卷會被定義為 Pod 的一部分，并且可 以掛載到該 Pod 里的所有容器的文件系統上。

在pod的容器中操作的時候，會產生許多的數據，而這些數據，當這些數據需要一直使用，這時候便需要對這些數據進行持久化

比如持久化操作日志數據、業務數據

這個持久的操作是怎么實現的？

如當有三個node節點，在node節點上可以去創建pod，當第一個節點node1掛掉了，那么這時候就需要其他節點去操作，這時候便需要去獲取node1的數據去重新創建運行鏡像

這個持久化的操作，便使用了數據卷（Volumn）這個概念去解決

總結：引入數據卷概念Volumn，使用數據卷進行持久化存儲

示例如下：

Pod鏡像拉取策略

在其pod的配置文件中，有這么一段，其中圈住的便是對該pod的該鏡像拉取時，所做的策略配置，這種策略一共有三種：

IfNotPresent：默認，鏡像在宿主機上不存在時才拉取

Always：每次創建Pod都會重新拉取一次鏡像

Never：Pod永遠不會主動拉取這個鏡像

Pod資源限制

在pod創建后，會調度到某一個node節點上去，在調度過程中有這么一個特點：舉例如下

當前集群中有三個node節點：node1（2核4g內存）、node2（4核16g內存）、node3（1核2g內存）；pod至少要一個支持2核4g的要求

當pod在創建后，node1和node2滿足要求，node3不滿足

這個所做的配置在如下圖所示的位置（cpu大小：1核等于1000m）

requests：在pod調度時所做的限制：cpu250m、內存64m；通過這個限制去找到對應的node節點

limits：限定調度時，最大的大小：cpu不超過500m、內存不超過128m

這兩個配置便是限制最大是多大，沒有最小

這個限制本身不是pod做到的，而是docker做到的，docker在創建pod里容器時做到這個資源的限制

Pod重啟機制

當pod里面的容器終止或退出后，后續還要做什么操作（重啟或結束等）

這個配置的設置是下面下面的yaml文件位置設置（框中內容），其有三種重啟機制：

Always：當容器終止退出后，總是重啟容器，默認策略。用在不斷提供服務的地方

onFailure：當容器異常退出（退出狀態碼非0）時，才重啟容器。

其狀態碼如下框中所示

Never：當容器終止退出，從不重啟容器。當有一個批量任務，只需要執行一次

Pod健康檢查

比如之前，我們需要檢查k8s中集群的狀態，通過容器檢查是否正常運行，其檢查的過程中有一個特點，如下，

通過查看，可以發現容器的目前狀態是running的，輸入這個容器是running狀態，但是這個容器可能本身有問題，但是還是running狀態

比如java中的java堆內存溢出，這個進程還存在，但是目前是不能提供服務

所以，通過容器檢查，是不能檢查其是否能正常提供服務的（雖然容器是running狀態的）

在k8s集群中，要檢查狀態，是根據容器檢查，但是雖然容器是running狀態，但是有時候其是不能對外提供服務的，所以通過容器檢查是不能正常檢查其狀態的

所以，便需要在應用層面進行檢查，在k8s集群中提供了兩種檢查機制，可以通過這兩個方法去檢查，如下：

livenessProbe（存活檢查）：如果檢查失敗，將殺死容器，根據Pod的restartPolicy來操作。

readinessProbe（就緒檢查）：如果檢查失敗，Kubernetes會把pod從service endpoints中剔除。

Probe支持以下三種檢查方法：

httpGet：發送HTTP請求，返回200-400范圍狀態碼為成功。

exec：執行shel1命令返回狀態碼是0為成功。

tcpsocket：發起TCP Socket建立成功。

舉例如下：

通過健康檢查，集群的狀態

Pod調度策略

創建Pod流程

先將總體的圖給出，下面便對該圖進行說明

步驟如下：

創建一個pod，首先會進入到API Server里面，過后將其一些信息存儲到etcd里面

這時候，scheduler通過監聽，明白有沒有新pod的創建，當有新pod創建后，其便會監聽到其是否新pod的創建，當監聽到有新pod創建后，便首先會到API Server里面，然后去etcd里面去讀取到創建的那個pod，讀取到過后，通過調度算法將其分配到某個的node節點中

上面的兩個步驟，都是在master節點上進行的操作，過后便進入node節點上，第二步調度到某一個node節點后，便再會去對應的node節點做對應的操作，node節點上的操作如下：

node節點里面有一個組件kubelet，通過kubelet，先去訪問API Server，然后也會去讀取etcd，拿到分配給當前節點的pod的信息（分配到了的話才會讀取到，沒有分配到便不會讀取到），讀取到過后，會通過docker去創建這個容器，創建之后，會將創建的狀態返回給API Server，然后在etcd中存儲

以上便是創建的過程

影響pod調度的屬性

有下面三個影響屬性

Pod資源限制

節點選擇器標簽

節點親和性

污點和污點容忍

Pod資源限制

Pod資源限制影響pod調用：上面說明過這個資源限制

在調度過程，這個限制，會在進行pod調度時，會根據request找到滿足要求的node節點進行調度

節點選擇器標簽

節點選擇器標簽影響pod調度：這個屬性是在yaml文件里面配置的，如下

下面的配置說明的是將當前的node調度到dev（開發環境）中去

一個pod中有多個節點，這些節點分為不同的環境：如當前集群有四個node節點，node1和node2是開發環境（dev），node3和node4是p生產環境（prod），當在創建才pod的時配置了上面的節點選擇器屬性，那么在調度中，該pod便會在node1和node2這兩個節點中進行調度

在進行這個操作時，之前便必須給node節點起一個別名，這個操作如下：給node1節點起一個標簽名字dev，然后便可以在pod的配置文件里面進行配置

查看

節點親和性

這個的配置也是在pod的yaml文件里面進行配置的，配置位置如下

節點親和性 modeAffinit和之前nodeSelector基本一樣的，根據節點上標簽約束來絕對Pod調度到哪些節點上
但是modeAffinit的功能更加強大，nodeSelector需要k8s集群中的node節點有對應的標簽，如果沒有的話，便不能進行調度，處于等待狀態。如果使用modeAffinit的話，即使沒有這個節點，也可以繼續向下運行，另外其還支持常用操作符。

其有兩種配置：
硬親和性：約束條件必須滿足，如果滿足不了就處于等待狀態，和nodeSelector類似
軟親和性：嘗試滿足，不滿足的話也可以

這里也還可以配置一個屬性：反親和性，比如上面的DoseNotExists

污點（Taint）和污點容忍

modeAffinit和之前nodeSelector：都是將Pod調度到某些節點上，是Pod屬性，在調度的時候實現

Taint污點：節點不做普通分配調度，是節點屬性，其針對特定的場景進行分配，其使用的場景如下

專用節點

配置特點硬件節點

基于Taint驅逐：其本身不做分配，分配到當前節點以外的其他節點中去。比如集群有三個節點，node1和node2中加這個驅逐，那么創建的對應的pod將會分配到node3中去

演示：

會使用的一些命令

• 查看當前節點污點情況
  

• 污點中的值主要有三個

  • NoScheduler：該節點一定不會被調到
  • PreferNoScheduler：盡量不被調度，但是也有被調度的幾率
  • NoExecute：不會調度，并且還會驅逐到node已有的pod（當前節點不會調度，而且還會把節點驅逐到其他節點中去）

• 為節點添加污點

  kubectl taint node [node節點主機名稱:如node1/node2] key=value:污點三個值

  演示如下：

  • 查看集群中node的情況
    

  • 創建一個node，并查看情況
    
    

  • 添加污點演示
    刪除所有的pod
    

  • 打污點
    
    現在去創建pod，查看之前創建pod后的情況，可以發現現在創建的都是在node2這個節點上
    

  • 刪除污點
    

• 污點容忍：就算是設置值為NoSchedule（一定不會被調度）后，這個節點也可能會被調度到，有可能不會被調度到。
  這個的實現其實也是在yaml文件中，做下面的修改

  下面配置中的key是之前設置的內容（比如之前我們設置的是env_role，NoSchedule，那么在這個地方key的值也為env_role和effect的值也是NoSchedule）
  

總結

以上是生活随笔為你收集整理的kubernetes（4）Pod的核心概念、Pod的调度的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。