一、 Pod

1. Pod 基礎(chǔ)概念

??Pod是kubernetes中最小的資源管理組件，Pod也是最小化運行容器化應(yīng)用的資源對象。一個Pod代表著集群中運行的一個進程。kubernetes中其他大多數(shù)組件都是圍繞著Pod來進行支撐和擴展Pod功能的，例如，用于管理Pod運行的StatefulSet和Deployment等控制器對象，用于暴露Pod應(yīng)用的Service和Ingress對象，為Pod提供存儲的PersistentVolume存儲資源對象等。

2. 在 Kubrenetes 集群中 Pod 使用方式

• 一個Pod中運行一個容器。“每個Pod中一個容器” 的模式是最常見的用法；在這種使用方式中，`你可以把Pod想象成是單個容器的封裝，kuberentes管理的是Pod而不是直接管理容器。

• 在一個Pod中同時運行多個容器。一個Pod中也可以同時封裝幾個需要緊密耦合互相協(xié)作的容器，它們之間共享資源。這些在同一個Pod中的容器可以互相協(xié)作成為一個service單位，比如一個容器共享文件，另一個“sidecar”容器來更新這些文件。Pod將這些容器的存儲資源作為一個實體來管理。

??一個Pod下的容器必須運行于同一節(jié)點上。現(xiàn)代容器技術(shù)建議一個容器只運行一個進程，該進程在容器中PID命名空間中的進程號為1，可直接接收并處理信號，進程終止時容器生命周期也就結(jié)束了。若想在容器內(nèi)運行多個進程，需要有一個類似Linux操作系統(tǒng)init進程的管控類進程，以樹狀結(jié)構(gòu)完成多進程的生命周期管理。運行于各自容器內(nèi)的進程無法直接完成網(wǎng)絡(luò)通信，這是由于容器間的隔離機制導(dǎo)致，k8s中的Pod資源抽象正是解決此類問題，Pod對象是一組容器的集合，這些容器共享NET、MNT、UTS及IPC命名空間，因此具有相同的域名、主機名和網(wǎng)絡(luò)接口，并可通過IPC直接通信。

??Pod資源中針對各容器提供網(wǎng)絡(luò)命名空間等共享機制的是底層基礎(chǔ)容器pause，基礎(chǔ)容器（也可稱為父容器）pause就是為了管理Pod容器間的共享操作，這個父容器需要能夠準確地知道如何去創(chuàng)建共享運行環(huán)境的容器，還能管理這些容器的生命周期。為了實現(xiàn)這個父容器的構(gòu)想，kubernetes中，用pause容器來作為一個Pod中所有容器的父容器。這個pause容器有兩個核心的功能，一是它提供整個Pod的Linux命名空間的基礎(chǔ)。二來啟用PID命名空間，它在每個Pod中都作為PID為1進程（init進程），并回收僵尸進程。

2.1 pasue 容器

??pause容器使得Pod中的所有容器可以共享兩種資源：網(wǎng)絡(luò)和存儲。

網(wǎng)絡(luò)

??每個Pod都會被分配一個唯一的IP地址。Pod中的所有容器共享網(wǎng)絡(luò)空間，包括IP地址和端口。Pod內(nèi)部的容器可以使用localhost互相通信。Pod中的容器與外界通信時，必須分配共享網(wǎng)絡(luò)資源（例如使用宿主機的端口映射）。

存儲

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

??總結(jié)：每個Pod都有一個特殊的被稱為“基礎(chǔ)容器”的Pause容器。Pause容器對應(yīng)的鏡像屬于Kubernetes平臺的一部分，除了Pause容器，每個Pod還包含一個或者多個緊密相關(guān)的用戶應(yīng)用容器。

2.2 kubernetes 中的 pause 容器提供的功能

??kubernetes中的pause容器主要為每個容器提供以下功能：

• 在pod中擔任Linux命名空間（如網(wǎng)絡(luò)命令空間）共享的基礎(chǔ)；
• 啟用PID命名空間，開啟init進程。

3. Pod 的概念和結(jié)構(gòu)組成

• 原因一：在一組容器作為一個單元的情況下，難以對整體的容器簡單地進行判斷及有效地進行行動。比如，一個容器死亡了，此時是算整體掛了么？那么引入與業(yè)務(wù)無關(guān)的Pause容器作為Pod的基礎(chǔ)容器，以它的狀態(tài)代表著整個容器組的狀態(tài)，這樣就可以解決該問題。

• 原因二：Pod里的多個應(yīng)用容器共享Pause容器的IP，共享Pause容器掛載的Volume，這樣簡化了應(yīng)用容器之間的通信問題，也解決了容器之間的文件共享問題。

4. Pod 的分類

自主式Pod

??這種Pod本身是不能自我修復(fù)的，當Pod被創(chuàng)建后（不論是由你直接創(chuàng)建還是被其他Controller），都會被Kuberentes調(diào)度到集群的Node上。直到Pod的進程終止、被刪掉、因為缺少資源而被驅(qū)逐、或者Node故障之前這個Pod都會一直保持在那個Node上。Pod不會自愈。如果Pod運行的Node故障，或者是調(diào)度器本身故障，這個Pod就會被刪除。同樣的，如果Pod所在Node缺少資源或者Pod處于維護狀態(tài)，Pod也會被驅(qū)逐。

控制器管理的Pod

??Kubernetes使用更高級的稱為Controller的抽象層，來管理Pod實例。Controller可以創(chuàng)建和管理多個Pod，提供副本管理、滾動升級和集群級別的自愈能力。例如，如果一個Node故障，Controller就能自動將該節(jié)點上的Pod調(diào)度到其他健康的Node上。雖然可以直接使用Pod，但是在Kubernetes中通常是使用Controller來管理Pod的。

靜態(tài)Pod

??靜態(tài) Pod 直接由特定節(jié)點上的 kubelet 進程來管理，不通過 master 節(jié)點上的 apiserver 。無法與控制器 Deployment 或者 DaemonSet 進行關(guān)聯(lián)，它由 kubelet 進程自己來監(jiān)控，當 pod 崩潰時重啟該 pod ， kubelete 也無法對他們進行健康檢查。靜態(tài) pod 始終綁定在某一個 kubelet ，并且始終運行在同一個節(jié)點上。 kubelet 會自動為每一個靜態(tài) pod 在 Kubernetes 的 apiserver 上創(chuàng)建一個鏡像 Pod（Mirror Pod），因此我們可以在 apiserver 中查詢到該 pod，但是不能通過 apiserver 進行控制（例如不能刪除）。

#查看kubelet配置文件 /var/lib/kubelet/config.yaml
cat /var/lib/kubelet/config.yaml | grep staticPodPath
staticPodPath: /etc/kubernetes/manifests

#也可以通過下面命令找到kubelet對應(yīng)的啟動配置文件，修改node節(jié)點的kubelet配置文件，添加靜態(tài)Pod的環(huán)境變量配置 --pod-manifest-path 參數(shù)
systemctl status kubelet
/usr/lib/systemd/system/kubelet.service.d
     └─10-kubeadm.conf

vim /usr/lib/systemd/system/kubelet.service.d/10-kubeadm.conf
Environment="KUBELET_SYSTEM_PODS_ARGS=--pod-manifest-path=/etc/kubernetes/manifests --allowprivileged=true"

systemctl daemon-reload
systemctl restart kubelet

#在靜態(tài)Pod文件的管理目錄下準備 Pod 的 Json 或者 Yaml 文件
vim /etc/kubernetes/manifests/static-web.yaml
apiVersion: v1
kind: Pod
metadata:
  name: static-web
  labels:
    app: static
spec:
  containers:
    - name: web
      image: nginx
      ports:
        - name: web
          containerPort: 80

??運行中的 kubelet 周期掃描配置的目錄下文件的變化，當這個目錄中有文件出現(xiàn)或消失時創(chuàng)建或刪除 pods。
在 Master 節(jié)點同樣也可以看到該 Pod，如果執(zhí)行 kubectl delete pod static-web-node01 命令刪除該 Pod 發(fā)現(xiàn)，并不能刪除。

5. Pod 容器的分類

5.1 基礎(chǔ)容器（infrastructure container）

維護整個 Pod 網(wǎng)絡(luò)和存儲空間

#node 節(jié)點中操作
#啟動一個Pod時，k8s會自動啟動一個基礎(chǔ)容器
cat /opt/kubernetes/cfg/kubelet
......
--pod-infra-container-image=registry.cn-hangzhou.aliyuncs.com/google-containers/pause-amd64:3.0"

#每次創(chuàng)建 Pod 時候就會創(chuàng)建，運行的每一個Pod都有一個 pause-amd64 的基礎(chǔ)容器自動會運行，對于用戶是透明的
docker ps -a
registry.cn-hangzhou.aliyuncs.com/google-containers/pause-amd64:3.0   "/pause"

5.2 初始化容器（initcontainers）

??Init容器必須在應(yīng)用程序容器啟動之前運行完成，而應(yīng)用程序容器是并行運行的，所以Init容器能夠提供了一種簡單的阻塞或延遲應(yīng)用容器的啟動的方法。

??Init 容器與普通的容器非常像，除了以下兩點：

init 容器總是運行到成功完成為止；

每個 Init 容器都必須在下一個 Init 容器啟動之前成功完成啟動和退出。
如果 Pod 的 Init 容器失敗，k8s 會不斷地重啟該 Pod，直到 Init 容器成功為止。然而，如果 Pod 對應(yīng)的重啟策略（restartPolicy）為 Never，它不會重新啟動。

Init 的容器作用

??因為init容器具有與應(yīng)用容器分離的單獨鏡像，其啟動相關(guān)代碼具有如下優(yōu)勢：

• Init 容器可以包含一些安裝過程中應(yīng)用容器中不存在的實用工具或個性化代碼。例如，沒有必要僅為了在安裝過程中使用類似 sed、 awk、 python 或 dig 這樣的工具而去FROM 一個鏡像來生成一個新的鏡像。
• Init 容器可以安全地運行這些工具，避免這些工具導(dǎo)致應(yīng)用鏡像的安全性降低。
• 應(yīng)用鏡像的創(chuàng)建者和部署者可以各自獨立工作，而沒有必要聯(lián)合構(gòu)建一個單獨的應(yīng)用鏡像。
• Init 容器能以不同于Pod內(nèi)應(yīng)用容器的文件系統(tǒng)視圖運行。因此，Init容器可具有訪問 Secrets 的權(quán)限，而應(yīng)用容器不能夠訪問。
• 由于 Init 容器必須在應(yīng)用容器啟動之前運行完成，因此 Init 容器提供了一種機制來阻塞或延遲應(yīng)用容器的啟動，直到滿足了一組先決條件。一旦前置條件滿足，Pod內(nèi)的所有的應(yīng)用容器會并行啟動。

5.3 應(yīng)用容器（Maincontainer）

并行啟動

#官網(wǎng)示例：
https://kubernetes.io/docs/concepts/workloads/pods/init-containers/

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
spec:
  containers:
  - name: myapp-container
    image: busybox:1.28
    command: ['sh', '-c', 'echo The app is running! && sleep 3600']
  initContainers:
  - name: init-myservice
    image: busybox:1.28
    command: ['sh', '-c', 'until nslookup myservice; do echo waiting for myservice; sleep 2; done;']
  - name: init-mydb
    image: busybox:1.28
    command: ['sh', '-c', 'until nslookup mydb; do echo waiting for mydb; sleep 2; done;']

??這個例子是定義了一個具有 2 個 Init 容器的簡單 Pod。 第一個等待 myservice 啟動， 第二個等待 mydb 啟動。 一旦這兩個 Init容器都啟動完成，Pod 將啟動 spec 中的應(yīng)用容器。

kubectl apply -f demo1.yaml

kubectl describe pod myapp-pod

kubectl logs myapp-pod -c init-myservice

#創(chuàng)建myservice資源
vim myservice.yaml
apiVersion: v1
kind: Service
metadata:
  name: myservice
spec:
  ports:
  - protocol: TCP
    port: 80
    targetPort: 9376
    
kubectl create -f myservice.yaml

kubectl get svc

kubectl get pods -n kube-system

kubectl get pods

#特別說明：
1)在Pod啟動過程中，Init容器會按順序在網(wǎng)絡(luò)和數(shù)據(jù)卷初始化之后啟動。每個容器必須在下一個容器啟動之前成功退出。
2)如果由于運行時或失敗退出，將導(dǎo)致容器啟動失敗，它會根據(jù)Pod的restartPolicy指定的策略進行重試。然而，如果Pod的restartPolicy設(shè)置為Always，Init容器失敗時會使用RestartPolicy策略。
3)在所有的Init容器沒有成功之前，Pod將不會變成Ready狀態(tài)。Init容器的端口將不會在Service中進行聚集。正在初始化中的Pod處于Pending狀態(tài)，但應(yīng)該會將Initializing狀態(tài)設(shè)置為true。
4)如果Pod重啟，所有Init容器必須重新執(zhí)行。
5)對Init容器spec的修改被限制在容器image字段，修改其他字段都不會生效。更改Init容器的image字段，等價于重啟該Pod。
6)Init容器具有應(yīng)用容器的所有字段。除了readinessProbe，因為Init容器無法定義不同于完成（completion）的就緒（readiness）之外的其他狀態(tài)。這會在驗證過程中強制執(zhí)行。
7)在Pod中的每個app和Init容器的名稱必須唯一；與任何其它容器共享同一個名稱，會在驗證時拋出錯誤。

6. 鏡像拉取策略（imagePullPolicy）

??Pod 的核心是運行容器，必須指定容器引擎，比如 Docker，啟動容器時，需要拉取鏡像，k8s 的鏡像拉取策略可以由用戶指定：

??注意：對于標簽為“:latest”的鏡像文件，其默認的鏡像獲取策略即為“Always”；而對于其他標簽的鏡像，其默認策略則為“IfNotPresent”。

#官方示例：
https://kubernetes.io/docs/concepts/containers/images

vim demo2.yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod-demo2
  labels: 
    app: pod-demo2
spec:
  containers:
    - name: nginx
      image: nginx
      imagePullPolicy: IfNotPresent

kubectl apply -f demo2.yaml

#master01 上操作
kubectl edit deployment/nginx-deployment
......
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx:1.15.4
        imagePullPolicy: IfNotPresent							#鏡像拉取策略為 IfNotPresent
        name: nginx
        ports:
        - containerPort: 80
          protocol: TCP
        resources: {}
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
      dnsPolicy: ClusterFirst
      restartPolicy: Always										#Pod的重啟策略為 Always，默認值
      schedulerName: default-scheduler
      securityContext: {}
      terminationGracePeriodSeconds: 30
......

創(chuàng)建測試案例

mkdir /opt/demo
cd /opt/demo

vim pod1.yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod-test1
spec:
  containers:
    - name: nginx
      image: nginx
      imagePullPolicy: Always
      command: [ "echo", "SUCCESS" ]


kubectl create -f pod1.yaml

kubectl get pods -o wide
pod-test1                         0/1     CrashLoopBackOff   4          3m33s
#此時 Pod 的狀態(tài)異常，原因是 echo 執(zhí)行完進程終止，容器生命周期也就結(jié)束了

kubectl describe pod pod-test1
......
Events:
  Type     Reason     Age                 From                    Message

----     ------     ----                ----                    -------

  Normal   Scheduled  2m10s               default-scheduler       Successfully assigned default/pod-test1 to 192.168.80.11
  Normal   Pulled     46s (x4 over 119s)  kubelet, 192.168.80.11  Successfully pulled image "nginx"
  Normal   Created    46s (x4 over 119s)  kubelet, 192.168.80.11  Created container
  Normal   Started    46s (x4 over 119s)  kubelet, 192.168.80.11  Started container
  Warning  BackOff    19s (x7 over 107s)  kubelet, 192.168.80.11  Back-off restarting failed container
  Normal   Pulling    5s (x5 over 2m8s)   kubelet, 192.168.80.11  pulling image "nginx"
#可以發(fā)現(xiàn) Pod 中的容器在生命周期結(jié)束后，由于 Pod 的重啟策略為 Always，容器再次重啟了，并且又重新開始拉取鏡像

#修改 pod1.yaml 文件
cd /opt/demo
vim pod1.yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod-test1
spec:
  containers:
    - name: nginx
      image: nginx:1.14							#修改 nginx 鏡像版本
      imagePullPolicy: Always
      #command: [ "echo", "SUCCESS" ]			#刪除
      
#刪除原有的資源
kubectl delete -f pod1.yaml 

#更新資源
kubectl apply -f pod1.yaml 

#查看 Pod 狀態(tài)
kubectl get pods -o wide
NAME                              READY   STATUS    RESTARTS   AGE   IP            NODE            NOMINATED NODE
pod-test1                         1/1     Running   0          33s   172.17.36.4   192.168.80.11   <none>

#在任意 node 節(jié)點上使用 curl 查看頭部信息
curl -I http://172.17.36.4
HTTP/1.1 200 OK
Server: nginx/1.14.2......

文章來源地址http://www.zghlxwxcb.cn/news/detail-758899.html

二、部署 harbor 創(chuàng)建私有項目

總結(jié)

1. Pod 的定義

Pod 是 K8S 最小的創(chuàng)建和管理單元

2. 一個 Pod 能包含幾個容器

1個 pause 容器（基礎(chǔ)容器/父容器/根容器）
1個或多個應(yīng)用容器（業(yè)務(wù)容器）

通常一個Pod最好只包含一個應(yīng)用容器，一個應(yīng)用容器最好只運行一個業(yè)務(wù)進程

同一個Pod里的容器，都是運行在同一個Node節(jié)點上的，并且共享 NET MNT UTS IPC PID 命名空間

3. pause 容器的作用

是作為共享 NET MNT UTS IPC PID 命名空間的基礎(chǔ)
給Pod里的其它容器提供網(wǎng)絡(luò)、存儲資源的共享
作為PID=1的進程（init進程）管理整個Pod容器組的生命周期

4. Pod 的 3 種類型

控制器管理的Pod：由scheduler進行調(diào)度的；被控制器管理的；有自愈能力，一旦Pod掛掉了，會被重新拉起；有副本管理、滾動更新等功能
自主式Pod：由scheduler進行調(diào)度的；不被控制器管理；沒有自愈能力，一旦Pod掛掉了，不會被重新拉起；沒有副本管理、滾動更新等功能
靜態(tài)Pod：不由scheduler調(diào)度的，而是由kubelet自行管理的；始終與kubelet運行在同一個Node節(jié)點上，不能被直接刪除
         靜態(tài)Pod資源配置文件默認放置在/etc/kubernetes/manifests目錄中，當此目錄中有Pod資源配置文件存在或者消失時kubelet會自動創(chuàng)建或刪除靜態(tài)Pod

5. Pod 的 3 種容器

pause容器（基礎(chǔ)容器/父容器/根容器）：給Pod的容器組作環(huán)境初始化，具體見上

init容器（初始化容器/init container）：可以為應(yīng)用容器事先提供運行環(huán)境或輔助工具；還可以阻塞或延遲應(yīng)用容器的啟動
                                       如果Pod有多個init容器時，是串行啟動，要在上一個init容器成功的完成啟動、運行和退出后才會啟動下一個init容器

應(yīng)用容器（業(yè)務(wù)容器/main container）：提供應(yīng)用程序業(yè)務(wù)
                                     如果Pod有多個應(yīng)用容器時，默認是并行啟動的，應(yīng)用容器要在所有init容器都成功的完成啟動、運行和退出后才會啟動

6. Pod 的 策略

#Pod 的 3 種鏡像拉取策略：   spec.containers.imagePullPolicy
IfNotPresent：優(yōu)先使用本地已存在的鏡像，如果本地沒有則從倉庫拉取鏡像。是標簽為非latest的鏡像的默認鏡像拉取策略
Always：總是從倉庫拉取鏡像，無論本地是否已存在鏡像。是標簽為latest或無標簽的鏡像的默認鏡像拉取策略
Never：僅使用本地鏡像，總是不從倉庫拉取鏡像
-------------------------------------------------------------------------------------------
#Pod 的 3 種容器重啟策略： spec.restartPolicy
Always：當Pod中的容器退出時，總是重啟容器，無論容器退出狀態(tài)碼如何。是默認的容器重啟策略
OnFailure：當Pod中的容器異常退出時（容器退出狀態(tài)碼為非0），才會重啟容器；正常退出的容器（容器退出狀態(tài)碼為0）不會重啟
Never：當Pod中的容器退出時，總是不重啟容器，無論容器退出狀態(tài)碼如何。

到了這里，關(guān)于【Kubernetes】Kubernetes之Pod詳解的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！