一、前言

在之前k8s組件一篇中，我們談到了pod這個組件，了解到pod是k8s中資源管理的最小單位，可以說Pod是整個k8s對外提供服務的最基礎的個體，有必要對Pod做深入的學習和探究。

二、再看k8s架構圖

為了加深對k8s中pod的理解，再來回顧下k8s的完整架構

三、pod特點

結合上面這張圖，關于pod，可以總結下面幾點：

• Pod是一組容器, 是K8S中最小的單位,，一個Pod可包含多個容器，但通常情況下每個Pod中僅運行一個容器，可以把Pod理解成豌豆莢, Pod內的每個容器就像是一顆豌豆 ；
• Pod 的核心是運行容器，必須指定容器引擎，比如 Docker是其中一種技術 ；

四、pod分類

根據(jù)pod是否自主創(chuàng)建，可以分為兩種

• 自主創(chuàng)建：直接創(chuàng)建出來的Pod，這種pod刪除后就沒有了，也不會自動重建 ；
• 控制器創(chuàng)建：通過控制器創(chuàng)建的pod，這類Pod刪除了之后還會自動重建 ；

五、pod中的容器

從上圖可以發(fā)現(xiàn)，容器是運行在pod中的，也可以簡單理解為pod是容器運行的外部容器，所以一個pod理論上可以運行很多個docker容器，關于這一點，做兩點說明：

• 每個Pod中一個容器，的模式是最常見的用法，Pod是容器的簡單封裝，K8S管理Pod而不是直接管理容器 ；
• 一個Pod中同時運行多個需要互相協(xié)作的容器，它們共享資源，同一個Pod中的容器可以作為service單位 ；

六、Pod中的網絡

對于k8s集群中的某個節(jié)點來說，可能部署了多個pod，這些不同的pod之間如果也需要互相通信怎么辦呢？這就需要說到pod中的網絡了；

• 一個 pod 包含一組容器，一個 pod 不會跨越多個工作節(jié)點 ；
• 每個Pod都會被分配一個唯一的IP地址，Pod中的所 有容器共享網絡空間，包括IP地址和端口 ；
• Pod內 部的容器可以使用localhost互相通信 ；

補充：k8s中的網絡通信模型

K8S集群的有4種網絡：

????????具體如下：同一pod內的容器間通信、各pod彼此之間的通信、pod與service間的通信、以及集群外部的流量同service之間的通信

七、Pod中的存儲

• Volume 也可以用來持久化Pod中的存儲資源，以防容器重啟后文件丟失 ；
• Pod中 的所有容器都可以訪問共享的Volume ；

八、Pod常用操作命令

1、查看k8s集群中系統(tǒng)運行的pod

kubectl get pod -n kube-system

2、查看創(chuàng)自己創(chuàng)建的pod

kubectl get pod
或
kubectl get pod,svc,deploy

3、刪除pod

直接刪除pod：

kubectl delete pod pod名稱 -n 名稱空間

刪除通過控制器創(chuàng)建的pod：

kubectl delete pod控制器名稱 -n 名稱空間

補充說明：

• 如果是通過deploy控制器創(chuàng)建的pod, 直接刪除則會自動創(chuàng)建新的；
• -n 非必須，表示某個具體的命名空間；

4、啟動一個pod【命令方式啟動】

kubectl run pod名稱 --image=鏡像 --port=80 --namespace 命名空間名字

比如在上一篇中，我們創(chuàng)建了一個nginx的pod，可以寫成：

kubectl run test-nignx-pod --image=nginx:1.23.0 --port=80 --namespace test

5、啟動一個pod【yaml方式啟動】

在當前目錄下創(chuàng)建一個yaml的文件

配置內容如下：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deploy  
  labels:
    chapter: first-app
spec:
  selector:
     matchLabels:  
       app: nginx
  replicas: 1
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name : nginx
        image: nginx:1.23.0
        ports:
        - containerPort: 80

然后使用apply的方式啟動

kubectl apply -f ./test-nginx.yaml

注意點：

通過 apply -f 的方式創(chuàng)建的pod，刪除的時候，也需要通過apply -f 的方式刪除

6、通過deployment控制器導出yaml文件

在當前集群下，我們有下面這個pod

?使用下面的命令導出這個pod對應的yaml

kubectl create deployment test-nginx3 --image=nginx:1.23.0 --namespace test -o yaml --dry-run=client > ./nginx.yaml

執(zhí)行之后可以發(fā)現(xiàn)在當前目錄下創(chuàng)建了一個yaml的文件

?文件內容是不是和前面我們自己創(chuàng)建的那個yaml很像，看起來似乎更加完整，需要注意的是，這個里面的有些參數(shù)是可以手動修改的，比如：replicas 這個表示生成的nginx的pod個數(shù)；

然后就可以使用apply的命令創(chuàng)建pod了

kubectl apply -f nginx.yaml

7、查看某個名稱空間下 pod 的詳細信息

kubectl get pod -n ns名稱 -o wide

比如，查看default名稱空間下的pod信息，就能看到上面通過yaml文件創(chuàng)建的pod；

kubectl get pod -n default -o wide

通過k8s創(chuàng)建出來的pod，會分給當前的pod一個IP地址，可以直接通過curl 進行訪問【同一個集群下的其他節(jié)點都可訪問】

九、Pod延伸補充說明

1、pod鏡像拉取策略?

pod鏡像拉取策略可以通過imagePullPolicy字段配置鏡像拉取策略，如下：

spec:
  containers:
    - name: nginx
      image: nginx:1.23.0
      imagePullPolicy: Always	#可取 Always（默認值）、IfNotPresent、Never

imagePullPolicy可以使用以下3種策略值：

Always: 默認值，每次創(chuàng)建pod都會重新拉取一次鏡像;
IfNotPresent: 鏡像在宿主機上不存在時才拉取;
Never: 永遠不會主動拉取鏡像，使用本地鏡像，需要你手動拉取鏡像下來;

2、pod使用資源限制配置

我們知道，集群中的節(jié)點都是有一定的配置的，比如CPU,內存等信息，總不能因為創(chuàng)建的某個pod把節(jié)點的資源給打滿了，因此可以在配置文件中進行配置，以使用apply -f 的方式創(chuàng)建一個pod，配置文件中關鍵配置如下：

resources：
	requests：
		memory："內存大小"
		cpu："cpu占用大小"
	limits:	
		memory："內存占用大小"
		cpu："cpu占用大小"

下面是一段完整的標簽配置和說明

spec:  
  containers: 
  - name: string   #必選，容器名稱
    image: string  #必選，容器的鏡像名稱
  
    resources: #資源限制和請求的設置
      limits:  #資源限制的設置
        cpu: string     #Cpu的限制，單位為core數(shù)，將用于docker run --cpu-shares參數(shù)
        memory: string  #內存限制，單位可以為Mib/Gib，將用于docker run --memory參數(shù)
      requests: #資源請求的設置
        cpu: string    #Cpu請求，容器啟動的初始可用數(shù)量
        memory: string #內存請求,容器啟動的初始可用數(shù)量

如下為一段實際使用中的配置

更多配置，請參考文檔：k8s文檔

3、關于pod的創(chuàng)建流程

以通過kubectl apply -f xxx.yaml 這種方式創(chuàng)建的pod進行說明，結合本文開頭的k8s架構圖：

• kubectl向apiserver發(fā)送創(chuàng)建pod的請求；
• apiserver把pod的創(chuàng)建信息存儲到etcd進行保存；
• scheduler監(jiān)聽到未綁定node的pod資源，通過調度算法對該pod資源選定一個合適的node進行綁定，然后響應給apiserver，更新pod狀態(tài)并存儲到etcd中；
• 在綁定的node中，Controller-Manager通知kubelet收到分配到自身節(jié)點上的pod，調用容器引擎api創(chuàng)建容器，并把容器狀態(tài)響應給apiserver；

4、Pod調度策略

默認情況下，一個Pod在哪個Node節(jié)點上運行，是由Scheduler組件采用相應的算法計算出來的，這個過程是不受人工控制的。但是在實際使用中，這并不滿足的需求，因為很多情況下，我們想控制某些Pod到達某些節(jié)點上，那么應該怎么做呢？這就要求了解k8s對Pod的調度規(guī)則 。

下面列舉幾個影響pod調度的因素：

pod資源限制

scheduler根據(jù)requests找到足夠大小的node進行調度

使用節(jié)點選擇器標簽（nodeSelector）

節(jié)點選擇器可以將節(jié)點分開，比如k8s集群中有多個節(jié)點，為了區(qū)分生產，開發(fā)和測試環(huán)境，就可以利用節(jié)點選擇器標簽進行劃分；

例如，當前需要把pod調度到開發(fā)環(huán)境中，則可以通過scheduler將pod調度到標簽選擇器中為env_role:dev的node中 ，對應的yaml核心配置如下：

nodeSelector: 
  env_role:dev/prod

關于節(jié)點選擇器，后續(xù)還會通過一文詳細講解其使用。