---

一、 Pod

1. Pod 基礎概念

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

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

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

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

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

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

2.1 pasue 容器

??pause容器使得Pod中的所有容器可以共享兩種資源：網絡和存儲。

網絡

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

存儲

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

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

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

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

• 在pod中擔任Linux命名空間（如網絡命令空間）共享的基礎；
• 啟用PID命名空間，開啟init進程。

3. Pod 的概念和結構組成

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

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

4. Pod 的分類

自主式Pod

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

控制器管理的Pod

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

靜態Pod

??靜態 Pod 直接由特定節點上的 kubelet 進程來管理，不通過 master 節點上的 apiserver 。無法與控制器 Deployment 或者 DaemonSet 進行關聯，它由 kubelet 進程自己來監控，當 pod 崩潰時重啟該 pod ， kubelete 也無法對他們進行健康檢查。靜態 pod 始終綁定在某一個 kubelet ，并且始終運行在同一個節點上。 kubelet 會自動為每一個靜態 pod 在 Kubernetes 的 apiserver 上創建一個鏡像 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對應的啟動配置文件，修改node節點的kubelet配置文件，添加靜態Pod的環境變量配置 --pod-manifest-path 參數
systemctl status kubelet
/usr/lib/systemd/system/kubelet.service.d└─10-kubeadm.confvim /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

#在靜態Pod文件的管理目錄下準備 Pod 的 Json 或者 Yaml 文件
vim /etc/kubernetes/manifests/static-web.yaml
apiVersion: v1
kind: Pod
metadata:name: static-weblabels:app: static
spec:containers:- name: webimage: nginxports:- name: webcontainerPort: 80

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

5. Pod 容器的分類

5.1 基礎容器（infrastructure container）

維護整個 Pod 網絡和存儲空間

#node 節點中操作
#啟動一個Pod時，k8s會自動啟動一個基礎容器
cat /opt/kubernetes/cfg/kubelet
......
--pod-infra-container-image=registry.cn-hangzhou.aliyuncs.com/google-containers/pause-amd64:3.0"#每次創建 Pod 時候就會創建，運行的每一個Pod都有一個 pause-amd64 的基礎容器自動會運行，對于用戶是透明的
docker ps -a
registry.cn-hangzhou.aliyuncs.com/google-containers/pause-amd64:3.0   "/pause"

5.2 初始化容器（initcontainers）

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

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

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

Init 的容器作用

??因為init容器具有與應用容器分離的單獨鏡像，其啟動相關代碼具有如下優勢：

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

5.3 應用容器（Maincontainer）

并行啟動

#官網示例：
https://kubernetes.io/docs/concepts/workloads/pods/init-containers/

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

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

kubectl apply -f demo1.yamlkubectl describe pod myapp-podkubectl logs myapp-pod -c init-myservice

#創建myservice資源
vim myservice.yaml
apiVersion: v1
kind: Service
metadata:name: myservice
spec:ports:- protocol: TCPport: 80targetPort: 9376kubectl create -f myservice.yamlkubectl get svckubectl get pods -n kube-systemkubectl get pods

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

6. 鏡像拉取策略（imagePullPolicy）

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

鏡像拉取策略	說明
IfNotPresent	在鏡像已經存在的情況下，kubelet 將不再去拉取鏡像，僅當本地缺失時才從倉庫中拉取，默認的鏡像拉取策略
Always	每次創建 Pod 都會重新拉取一次鏡像
Never	Pod 不會主動拉取這個鏡像，僅使用本地鏡像

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

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

vim demo2.yaml
apiVersion: v1
kind: Pod
metadata:name: pod-demo2labels: app: pod-demo2
spec:containers:- name: nginximage: nginximagePullPolicy: IfNotPresentkubectl apply -f demo2.yaml

#master01 上操作
kubectl edit deployment/nginx-deployment
......template:metadata:creationTimestamp: nulllabels:app: nginxspec:containers:- image: nginx:1.15.4imagePullPolicy: IfNotPresent							#鏡像拉取策略為 IfNotPresentname: nginxports:- containerPort: 80protocol: TCPresources: {}terminationMessagePath: /dev/termination-logterminationMessagePolicy: FilednsPolicy: ClusterFirstrestartPolicy: Always										#Pod的重啟策略為 Always，默認值schedulerName: default-schedulersecurityContext: {}terminationGracePeriodSeconds: 30
......

創建測試案例

mkdir /opt/demo
cd /opt/demovim pod1.yaml
apiVersion: v1
kind: Pod
metadata:name: pod-test1
spec:containers:- name: nginximage: nginximagePullPolicy: Alwayscommand: [ "echo", "SUCCESS" ]kubectl create -f pod1.yamlkubectl get pods -o wide
pod-test1                         0/1     CrashLoopBackOff   4          3m33s
#此時 Pod 的狀態異常，原因是 echo 執行完進程終止，容器生命周期也就結束了

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.11Normal   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 containerNormal   Started    46s (x4 over 119s)  kubelet, 192.168.80.11  Started containerWarning  BackOff    19s (x7 over 107s)  kubelet, 192.168.80.11  Back-off restarting failed containerNormal   Pulling    5s (x5 over 2m8s)   kubelet, 192.168.80.11  pulling image "nginx"
#可以發現 Pod 中的容器在生命周期結束后，由于 Pod 的重啟策略為 Always，容器再次重啟了，并且又重新開始拉取鏡像

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

#查看 Pod 狀態
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 節點上使用 curl 查看頭部信息
curl -I http://172.17.36.4
HTTP/1.1 200 OK
Server: nginx/1.14.2......

二、部署 harbor 創建私有項目

總結

1. Pod 的定義

Pod 是 K8S 最小的創建和管理單元

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

1個 pause 容器（基礎容器/父容器/根容器）
1個或多個應用容器（業務容器）通常一個Pod最好只包含一個應用容器，一個應用容器最好只運行一個業務進程同一個Pod里的容器，都是運行在同一個Node節點上的，并且共享 NET MNT UTS IPC PID 命名空間

3. pause 容器的作用

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

4. Pod 的 3 種類型

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

5. Pod 的 3 種容器

pause容器（基礎容器/父容器/根容器）：給Pod的容器組作環境初始化，具體見上init容器（初始化容器/init container）：可以為應用容器事先提供運行環境或輔助工具；還可以阻塞或延遲應用容器的啟動如果Pod有多個init容器時，是串行啟動，要在上一個init容器成功的完成啟動、運行和退出后才會啟動下一個init容器應用容器（業務容器/main container）：提供應用程序業務如果Pod有多個應用容器時，默認是并行啟動的，應用容器要在所有init容器都成功的完成啟動、運行和退出后才會啟動

6. Pod 的 策略

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