2. 程式人生 > 實用技巧 >kubernetes的Pod

kubernetes的Pod

阿新 • • 發佈：2020-12-14

1、Pod基本概念

  • 最小的部署單元
  • 包含多個容器（一組容器的組合）
  • 一個Pod中容器共享網路名稱空間
  • Pod是短暫的

2、Pod存在意義

  • 建立容器使用docker，一個docker對應是一個容器，一個容器有程序，一個容器執行一個應用程式
  • Pod多程序設計執行多個應用程式
  1. 一個Pod有多個容器，一個容器執行一個應用程式
  • Pod存在是為了親密性應用
  1. 兩個應用之間進行互動
  2. 網路之間呼叫
  3. 兩個應用需要頻繁呼叫

3、Pod實現機制

  • 共享網路
  • 共享儲存

共享網路

容器本身之間相互隔離的，一般是通過 namespace 和 group進行隔離，那麼Pod裡面的容器如何實現通訊？

  • 首先需要滿足前提條件，也就是容器都在同一個namespace之間

關於Pod實現原理，首先會在Pod會建立一個根容器： pause容器，然後我們在建立業務容器 【nginx，redis 等】，在我們建立業務容器的時候，會把它新增到 info容器 中

而在 info容器 中會獨立出 ip地址，mac地址，port 等資訊，然後實現網路的共享

完整步驟如下

  • 通過 Pause 容器，把其它業務容器加入到Pause容器裡，讓所有業務容器

共享儲存

Pod持久化資料，專門儲存到某個地方中

使用 Volumn資料捲進行共享儲存，案例如下所示

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  
 
- name: write
    image: centos
    command: ["bash","-c","for i in (1..100);do echo $i >> /data/hello;sleep 1;done"]
    wolumeMounts:
    - name: data
      mountPath: /data
  - name: read
    image: centos
    command: ["bash","-c","tail -f /data/hello"]
    volumeMounts:
    - name: data
      mountPath: 
 
/data
  volumes:
  - name: data
    emptyDir: {}

Pod映象拉取策略

我們以具體例項來說，拉取策略就是 imagePullPolicy

拉取策略主要分為了以下幾種

  • IfNotPresent：預設值，映象在宿主機上不存在才拉取
  • Always：每次建立Pod都會重新拉取一次映象
  • Never：Pod永遠不會主動拉取這個映象

Pod資源限制

也就是我們Pod在進行排程的時候，可以對排程的資源進行限制，例如我們限制 Pod排程是使用的資源是 2c4g，那麼在排程對應的node節點時，只會佔用對應的資源，對於不滿足資源的節點，將不會進行排程

示例

我們在下面的地方進行資源的限制

這裡分了兩個部分

  • request：表示排程所需的資源
  • limits：表示最大所佔用的資源

Pod重啟機制

因為Pod中包含了很多個容器，假設某個容器初選問題了，那麼就會觸發Pod重啟機制

重啟策略主要分為以下三種

  • Always：當容器終止退出後，總是重啟容器，預設策略 【nginx等，需要不斷提供服務】
  • OnFailure：當容器異常退出（退出狀態碼非0）時，才重啟容器。
  • Never：當容器終止退出，從不重啟容器 【批量任務】

Pod健康檢查

通過容器檢查，原來我們使用下面的命令來檢查

kubectl get pod

但是有的時候，程式可能出現了java堆記憶體溢位，程式還在執行，但是不能對外提供服務了，這個時候就不能通過 容器檢查來判斷服務是否可用了

這個時候就可以使用應用層面的檢查

# 存活檢查，如果檢查失敗，將殺死容器，根據Pod的restartPolicy【重啟策略】來操作
livenessProbe

# 就緒檢查，如果檢查失敗，Kubernetes會把Pod從Service endpoints中剔除
readinessProbe

Probe支援以下三種檢查方式

  • http Get：傳送HTTP請求，返回200 - 400 範圍狀態碼為成功
  • exec：執行Shell命令返回狀態碼是0為成功
  • tcpSocket：發起TCP socket建立成功

Pod排程策略

建立Pod流程

  • 首先建立一個pod，然後建立一個API Server 和 Etcd【把創建出來的資訊儲存在etcd中】
  • 然後建立 Scheduler，監控API Server是否有新的Pod，如果有的話，會通過排程演算法，把pod排程某個node上
  • 在node節點，會通過 kubelet -- apiserver 讀取etcd 拿到分配在當前node節點上的pod，然後通過docker建立容器

影響Pod排程的屬性

Pod資源限制對Pod的排程會有影響

根據request找到足夠node節點進行排程

節點選擇器標籤影響Pod排程

關於節點選擇器，其實就是有兩個環境，然後環境之間所用的資源配置不同

我們可以通過以下命令，給我們的節點新增標籤，然後節點選擇器就會進行排程了

kubectl label node node1 env_role=prod

節點親和性

節點親和性 nodeAffinity 和 之前nodeSelector 基本一樣的，根據節點上標籤約束來決定Pod排程到哪些節點上

  • 硬親和性：約束條件必須滿足
  • 軟親和性：嘗試滿足，不保證

支援常用操作符：in、NotIn、Exists、Gt、Lt、DoesNotExists

反親和性：就是和親和性剛剛相反，如 NotIn、DoesNotExists等

汙點和汙點容忍

概述

nodeSelector 和 NodeAffinity，都是Prod排程到某些節點上，屬於Pod的屬性，是在排程的時候實現的。

Taint 汙點：節點不做普通分配排程，是節點屬性

場景

  • 專用節點【限制ip】
  • 配置特定硬體的節點【固態硬碟】
  • 基於Taint驅逐【在node1不放，在node2放】

檢視汙點情況

kubectl describe node k8smaster | grep Taint

汙點值有三個

  • NoSchedule：一定不被排程
  • PreferNoSchedule：儘量不被排程【也有被排程的機率】
  • NoExecute：不會排程，並且還會驅逐Node已有Pod

未節點新增汙點

kubectl taint node [node] key=value:汙點的三個值

舉例：

kubectl taint node k8snode1 env_role=yes:NoSchedule

刪除汙點

kubectl taint node k8snode1 env_role:NoSchedule-

演示

我們現在建立多個Pod，檢視最後分配到Node上的情況

首先我們建立一個 nginx 的pod

kubectl create deployment web --image=nginx

然後使用命令檢視

kubectl get pods -o wide

我們可以非常明顯的看到，這個Pod已經被分配到 k8snode1 節點上了

下面我們把pod複製5份，在檢視情況pod情況

kubectl scale deployment web --replicas=5

我們可以發現，因為master節點存在汙點的情況，所以節點都被分配到了 node1 和 node2節點上

我們可以使用下面命令，把剛剛我們建立的pod都刪除

kubectl delete deployment web

現在給了更好的演示汙點的用法，我們現在給 node1節點打上汙點

kubectl taint node k8snode1 env_role=yes:NoSchedule

然後我們檢視汙點是否成功新增

kubectl describe node k8snode1 | grep Taint

然後我們在建立一個 pod

# 建立nginx pod
kubectl create deployment web --image=nginx
# 複製五次
kubectl scale deployment web --replicas=5

然後我們在進行檢視

kubectl get pods -o wide

我們能夠看到現在所有的pod都被分配到了 k8snode2上，因為剛剛我們給node1節點設定了汙點

最後我們可以刪除剛剛新增的汙點

kubectl taint node k8snode1 env_role:NoSchedule-

汙點容忍

汙點容忍就是某個節點可能被排程，也可能不被排程

相關推薦

no