目錄
一、理論
1.pod
2.pod容器分類(lèi)
3.鏡像拉取策略
4.pod 的重啟策略
二、實(shí)驗(yàn)
1.Pod容器的分類(lèi)
2.鏡像拉取策略
三、問(wèn)題
1.apiVersion 報(bào)錯(cuò)
2.pod v1版本資源未注冊(cè)
3.格式錯(cuò)誤
4.取行顯示指定pod信息
四、總結(jié)
一、理論
1.pod
(1)? 概念
?Pod是kubernetes中最小的資源管理組件，Pod也是最小化運(yùn)行容器化應(yīng)用的資源對(duì)象。一個(gè)Pod代表著集群中運(yùn)行的一個(gè)進(jìn)程。kubernetes中其他大多數(shù)組件都是圍繞著Pod來(lái)進(jìn)行支撐和擴(kuò)展Pod功能的，例如，用于管理Pod運(yùn)行的StatefulSet和Deployment等控制器對(duì)象，用于暴露Pod應(yīng)用的Service和Ingress對(duì)象，為Pod提供存儲(chǔ)的PersistentVolume存儲(chǔ)資源對(duì)象等。
pod:
node:
service:
（2）K8S集群中Pod兩種使用方式
①??一個(gè)Pod中運(yùn)行一個(gè)容器
? ? ? ? “每個(gè)Pod中一個(gè)容器”的模式是最常見(jiàn)的用法；在這種使用方式中，你可以把Pod想象成是單個(gè)容器的封裝，kuberentes管理的是Pod而不是直接管理容器。
②??在一個(gè)Pod中同時(shí)運(yùn)行多個(gè)容器。
? ? ? ? 一個(gè)Pod中也可以同時(shí)封裝幾個(gè)需要緊密耦合互相協(xié)作的容器，它們之間共享資源。這些在同一個(gè)Pod中的容器可以互相協(xié)作成為一個(gè)service單位，比如一個(gè)容器共享文件，另一個(gè)“sidecar”容器來(lái)更新這些文件。Pod將這些容器的存儲(chǔ)資源作為一個(gè)實(shí)體來(lái)管理。
? ? ? ? 一個(gè)Pod下的容器必須運(yùn)行于同一節(jié)點(diǎn)上。現(xiàn)代容器技術(shù)建議一個(gè)容器只運(yùn)行一個(gè)進(jìn)程，該進(jìn)程在容器中PID命令空間中的進(jìn)程號(hào)為1，可直接接收并處理信號(hào)，進(jìn)程終止時(shí)容器生命周期也就結(jié)束了。若想在容器內(nèi)運(yùn)行多個(gè)進(jìn)程，需要有一個(gè)類(lèi)似Linux操作系統(tǒng)init進(jìn)程的管控類(lèi)進(jìn)程，以樹(shù)狀結(jié)構(gòu)完成多進(jìn)程的生命周期管理。運(yùn)行于各自容器內(nèi)的進(jìn)程無(wú)法直接完成網(wǎng)絡(luò)通信，這是由于容器間的隔離機(jī)制導(dǎo)致，k8s中的Pod資源抽象正是解決此類(lèi)問(wèn)題，Pod對(duì)象是一組容器的集合，這些容器共享Network、UTS及IPC命令空間，因此具有相同的域名、主機(jī)名和網(wǎng)絡(luò)接口，并可通過(guò)IPC直接通信。
? ? ? ? Pod資源中針對(duì)各容器提供網(wǎng)絡(luò)命令空間等共享機(jī)制的是底層基礎(chǔ)容器pause，基礎(chǔ)容器（也可稱(chēng)為父容器）pause就是為了管理Pod容器間的共享操作，這個(gè)父容器需要能夠準(zhǔn)確地知道如何去創(chuàng)建共享運(yùn)行環(huán)境的容器，還能管理這些容器的生命周期。為了實(shí)現(xiàn)這個(gè)父容器的構(gòu)想，kubernetes中，用pause容器來(lái)作為一個(gè)Pod中所有容器的父容器。這個(gè)pause容器有兩個(gè)核心的功能，一是它提供整個(gè)Pod的Linux命名空間的基礎(chǔ)。二來(lái)啟用PID命名空間，它在每個(gè)Pod中都作為PID為1進(jìn)程（init進(jìn)程），并回收僵尸進(jìn)程。
（3）pause
? ? pause容器使得Pod中的所有容器可以共享兩種資源：網(wǎng)絡(luò)和存儲(chǔ)。
①?網(wǎng)絡(luò)：
? ? ? ? 每個(gè)Pod都會(huì)被分配一個(gè)唯一的IP地址。Pod中的所有容器共享網(wǎng)絡(luò)空間，包括IP地址和端口。Pod內(nèi)部的容器可以使用localhost互相通信。Pod中的容器與外界通信時(shí)，必須分配共享網(wǎng)絡(luò)資源（例如使用宿主機(jī)的端口映射）。
②?存儲(chǔ)：
? ? ? ?Pod可以指定多個(gè)共享的Volume。Pod中的所有容器都可以訪問(wèn)共享的Volume。Volume也可以用來(lái)持久化Pod中的存儲(chǔ)資源，以防容器重啟后文件丟失。
?③?小結(jié)
? ? ? ? 每個(gè)Pod都有一個(gè)特殊的被稱(chēng)為“基礎(chǔ)容器”的Pause容器。Pause容器對(duì)應(yīng)的鏡像屬于Kubernetes平臺(tái)的一部分，除了Pause容器，每個(gè)Pod還包含一個(gè)或者多個(gè)緊密相關(guān)的用戶(hù)應(yīng)用容器。
（4）pause容器功能
①??在pod中擔(dān)任Linux命名空間（如網(wǎng)絡(luò)命令空間）共享的基礎(chǔ)；
②??啟用PID命名空間，開(kāi)啟init進(jìn)程。
（5）pod設(shè)計(jì)特殊組成結(jié)構(gòu)目的
①?原因一：在一組容器作為一個(gè)單元的情況下，難以對(duì)整體的容器簡(jiǎn)單地進(jìn)行判斷及有效地進(jìn)行行動(dòng)。比如，一個(gè)容器死亡了，此時(shí)是算整體掛了么？那么引入與業(yè)務(wù)無(wú)關(guān)的Pause容器作為Pod的基礎(chǔ)容器，以它的狀態(tài)代表著整個(gè)容器組的狀態(tài)，這樣就可以解決該問(wèn)題。
②?原因二：Pod里的多個(gè)應(yīng)用容器共享Pause容器的IP，共享Pause容器掛載的Volume，這樣簡(jiǎn)化了應(yīng)用容器之間的通信問(wèn)題，也解決了容器之間的文件共享問(wèn)題。
（6）pod分類(lèi)
通常把Pod分為兩類(lèi)：
1.自主式Pod
1）創(chuàng)建方式（類(lèi)似自營(yíng)）
kubectl run pod 用于創(chuàng)建一個(gè)自主/靜態(tài)pod
注意：它就是創(chuàng)建一個(gè)pod，這個(gè)pod一旦掛了就不會(huì)在node上拉起來(lái)，這個(gè)pod式靜態(tài)pod，它不是存在etcd，二十存在node當(dāng)中
2）概念
這種Pod本身是不能自我修復(fù)的，當(dāng)Pod被創(chuàng)建后（不論是由你直接創(chuàng)建還是被其他Controller），都會(huì)被Kuberentes調(diào)度到集群的Node上。直到Pod的進(jìn)程終止、被刪掉、因?yàn)槿鄙儋Y源而被驅(qū)逐、或者Node故障之前這個(gè)Pod都會(huì)一直保持在那個(gè)Node上。Pod不會(huì)自愈。如果Pod運(yùn)行的Node故障，或者是調(diào)度器本身故障，這個(gè)Pod就會(huì)被刪除。同樣的，如果Pod所在Node缺少資源或者Pod處于維護(hù)狀態(tài)，Pod也會(huì)被驅(qū)逐。
2.控制器管理的Pod
1）創(chuàng)建方式（類(lèi)似有人管）
kubectl create deployment 用于創(chuàng)建deployment控制管理器的pod
注意：這種pod是在控制管理器當(dāng)中，舉例：比如pod運(yùn)行在node1上，控制器會(huì)保證pod的數(shù)量,如果node1掛了，它會(huì)在node2或者其他node節(jié)點(diǎn)重新拉取pod的數(shù)量
2）概念
Kubernetes使用更高級(jí)的稱(chēng)為Controller的抽象層，來(lái)管理Pod實(shí)例。Controller可以創(chuàng)建和管理多個(gè)Pod，提供副本管理、滾動(dòng)升級(jí)和集群級(jí)別的自愈能力。例如，如果一個(gè)Node故障，Controller就能自動(dòng)將該節(jié)點(diǎn)上的Pod調(diào)度到其他健康的Node上。雖然可以直接使用Pod，但是在Kubernetes中通常是使用Controller來(lái)管理Pod的。
2.pod容器分類(lèi)
（1）基礎(chǔ)容器（infrastructure?container）
維護(hù)整個(gè) Pod 網(wǎng)絡(luò)和存儲(chǔ)空間
node 節(jié)點(diǎn)中操作
啟動(dòng)一個(gè)容器時(shí)，k8s會(huì)自動(dòng)啟動(dòng)一個(gè)基礎(chǔ)容器
cat /opt/kubernetes/cfg/kubelet每次創(chuàng)建 Pod 時(shí)候就會(huì)創(chuàng)建，運(yùn)行的每一個(gè)容器都有一個(gè) pause-amd64 的基礎(chǔ)容器自動(dòng)會(huì)運(yùn)行，對(duì)于用戶(hù)是透明的
#在mster上創(chuàng)建pod
[root@master01 ~]# kubectl create deployment nginx-demo1 --image=nginx:1.14
#查看pod 被調(diào)度在哪個(gè)node節(jié)點(diǎn)上
[root@master01 ~]# kubectl get pod nginx-demo1-7bf84576d8-nhv9n -o wide
#在node01節(jié)點(diǎn)上，查看容器，發(fā)現(xiàn)自動(dòng)創(chuàng)建了pause容器
[root@node01 ~]# docker ps | grep nginx-demo1
（2）初始化容器（initcontainers）
?Init容器必須在應(yīng)用程序容器啟動(dòng)之前運(yùn)行完成，而應(yīng)用程序容器是并行運(yùn)行的，所以Init容器能夠提供了一種簡(jiǎn)單的阻塞或延遲應(yīng)用容器的啟動(dòng)的方法。
Init 容器與普通的容器非常像，除了以下兩點(diǎn)：
●Init 容器總是運(yùn)行到成功完成為止
●每個(gè) Init 容器都必須在下一個(gè) Init 容器啟動(dòng)之前成功完成啟動(dòng)和退出如果 Pod 的 Init 容器失敗，k8s 會(huì)不斷地重啟該 Pod，直到 Init 容器成功為止。然而，如果 Pod 對(duì)應(yīng)的重啟策略（restartPolicy）為 Never，它不會(huì)重新啟動(dòng)。
Init 的容器作用
因?yàn)閕nit容器具有與應(yīng)用容器分離的單獨(dú)鏡像，其啟動(dòng)相關(guān)代碼具有如下優(yōu)勢(shì)：
●Init 容器可以包含一些安裝過(guò)程中應(yīng)用容器中不存在的實(shí)用工具或個(gè)性化代碼。例如，沒(méi)有必要僅為了在安裝過(guò)程中使用類(lèi)似 sed、 awk、 python 或 dig 這樣的工具而去FROM 一個(gè)鏡像來(lái)生成一個(gè)新的鏡像。
●Init 容器可以安全地運(yùn)行這些工具，避免這些工具導(dǎo)致應(yīng)用鏡像的安全性降低。
●應(yīng)用鏡像的創(chuàng)建者和部署者可以各自獨(dú)立工作，而沒(méi)有必要聯(lián)合構(gòu)建一個(gè)單獨(dú)的應(yīng)用鏡像。
●Init 容器能以不同于Pod內(nèi)應(yīng)用容器的文件系統(tǒng)視圖運(yùn)行。因此，Init容器可具有訪問(wèn) Secrets 的權(quán)限，而應(yīng)用容器不能夠訪問(wèn)。
●由于 Init 容器必須在應(yīng)用容器啟動(dòng)之前運(yùn)行完成，因此 Init 容器提供了一種機(jī)制來(lái)阻塞或延遲應(yīng)用容器的啟動(dòng)，
直到滿(mǎn)足了一組先決條件。一旦前置條件滿(mǎn)足，Pod內(nèi)的所有的應(yīng)用容器會(huì)并行啟動(dòng)。
(3)??應(yīng)用容器（Maincontainer）
并行啟動(dòng)官網(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;']這個(gè)例子是定義了一個(gè)具有 2 個(gè) Init 容器的簡(jiǎn)單 Pod。 第一個(gè)等待 myservice 啟動(dòng)， 第二個(gè)等待 mydb 啟動(dòng)。 一旦這兩個(gè) Init容器都啟動(dòng)完成，Pod 將啟動(dòng) spec 中的應(yīng)用容器。
kubectl describe pod myapp-pod
kubectl logs myapp-pod -c init-myservicevim 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
vim mydb.yaml
apiVersion: v1
kind: Service
metadata:
name: mydb
spec:
ports:
- protocol: TCP
port: 80
targetPort: 9377
kubectl create -f mydb.yaml
kubectl get pods特別說(shuō)明：
●在Pod啟動(dòng)過(guò)程中，Init容器會(huì)按順序在網(wǎng)絡(luò)和數(shù)據(jù)卷初始化之后啟動(dòng)。每個(gè)容器必須在下一個(gè)容器啟動(dòng)之前成功退出。
●如果由于運(yùn)行時(shí)或失敗退出，將導(dǎo)致容器啟動(dòng)失敗，它會(huì)根據(jù)Pod的restartPolicy指定的策略進(jìn)行重試。然而，如果Pod的restartPolicy設(shè)置為Always，Init容器失敗時(shí)會(huì)使用RestartPolicy策略。
●在所有的Init容器沒(méi)有成功之前，Pod將不會(huì)變成Ready狀態(tài)。Init容器的端口將不會(huì)在Service中進(jìn)行聚集。正在初始化中的Pod處于Pending狀態(tài)，但應(yīng)該會(huì)將Initializing狀態(tài)設(shè)置為true。
●如果Pod重啟，所有Init容器必須重新執(zhí)行。
●對(duì)Init容器spec的修改被限制在容器image字段，修改其他字段都不會(huì)生效。更改Init容器的image字段，等價(jià)于重啟該P(yáng)od。
●Init容器具有應(yīng)用容器的所有字段。除了readinessProbe，因?yàn)镮nit容器無(wú)法定義不同于完成（completion）的就緒（readiness）之外的其他狀態(tài)。這會(huì)在驗(yàn)證過(guò)程中強(qiáng)制執(zhí)行。
●在Pod中的每個(gè)app和Init容器的名稱(chēng)必須唯一；與任何其它容器共享同一個(gè)名稱(chēng)，會(huì)在驗(yàn)證時(shí)拋出錯(cuò)誤。
3.鏡像拉取策略
? ? ? ? Pod 的核心是運(yùn)行容器，必須指定容器引擎，比如 Docker，啟動(dòng)容器時(shí)，需要拉取鏡像，k8s 的鏡像拉取策略可以由用戶(hù)指定：
1、IfNotPresent：在鏡像已經(jīng)存在的情況下，kubelet 將不再去拉取鏡像，僅當(dāng)本地缺失時(shí)才從倉(cāng)庫(kù)中拉取，默認(rèn)的鏡像拉取策略
2、Always：每次創(chuàng)建 Pod 都會(huì)重新拉取一次鏡像；
3、Never：Pod 不會(huì)主動(dòng)拉取這個(gè)鏡像，僅使用本地鏡像。
注意：對(duì)于標(biāo)簽為“:latest”的鏡像文件，其默認(rèn)的鏡像獲取策略即為“Always”；而對(duì)于其他標(biāo)簽的鏡像，其默認(rèn)策略則為“IfNotPresent”。
(1) 官方示例
https://kubernetes.io/docs/concepts/containers/images
[root@master01 ~]# vim pod1.yaml
#當(dāng)kind： 的值為Pod，則表示創(chuàng)建自主式pod
apiVersion: v1
kind: Pod
metadata:
name: pod-test1
spec:
containers:
- name: nginx
image: nginx
imagePullPolicy: Always
#command字段可以定義容器啟動(dòng)后的第一個(gè)命令
command: [ "echo", "SUCCESS" ]
kubectl create -f pod1.yaml
kubectl get pods -o wide
pod-test1 0/1 CrashLoopBackOff 2 2m17s
#此時(shí) Pod 的狀態(tài)異常，原因是 echo 執(zhí)行完進(jìn)程終止，容器生命周期也就結(jié)束了
(2)?更新資源（方式一 僅注釋command）
此時(shí) Pod 的狀態(tài)異常，原因是 echo 執(zhí)行完進(jìn)程終止，容器生命周期也就結(jié)束了
kubectl describe pod pod-test1
......
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 4m44s default-scheduler Successfully assigned default/pod-test1 to node02
Normal Pulled 3m34s (x4 over 4m40s) kubelet, node02 Successfully pulled image "nginx"
Normal Created 3m34s (x4 over 4m40s) kubelet, node02 Created container nginx
Normal Started 3m34s (x4 over 4m40s) kubelet, node02 Started container nginx
Warning BackOff 3m4s (x8 over 4m32s) kubelet, node02 Back-off restarting failed container
Normal Pulling 2m50s (x5 over 4m43s) kubelet, node02 Pulling image "nginx"
可以發(fā)現(xiàn) Pod 中的容器在生命周期結(jié)束后，由于 Pod 的重啟策略為 Always，容器再次重啟了，并且又重新開(kāi)始拉取鏡像
修改 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)
[root@master demo]# kubectl get pods -o wide | awk 'NR==1 || NR==12'
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
pod-test1 1/1 Running 0 4m42s 10.244.1.37 node02 <none> <none>
在任意 node 節(jié)點(diǎn)上使用 curl 查看頭部信息
[root@node01 ~]# curl -I http://10.244.1.37
HTTP/1.1 200 OK
Server: nginx/1.21.5
......#使用edit 在線(xiàn)修改，查看資源配置
[root@master ~]# kubectl edit pod pod-test1
(3) 更新資源（方式二 同時(shí)注釋imagePullPolicy和command）
#修改pod1.yaml文件
[root@master ~]#vim pod1.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod-test1
spec:
containers:
- name: nginx
#修改 nginx 鏡像版本,指定標(biāo)簽
image: nginx:1.14
#注釋鏡像拉取策略
#imagePullPolicy: Always
#command: [ "echo", "SUCCESS" ] #刪除
#刪除原有的資源
kubectl delete -f pod1.yaml
#更新資源
kubectl apply -f pod1.yaml
[root@master ~]# kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
myapp-pod 1/1 Running 0 88m 10.244.2.39 node01 <none> <none>
pod-test1 1/1 Running 0 2m43s 10.244.2.40 node01 <none> <none>
#使用edit 在線(xiàn)修改，查看資源配置
[root@master ~]# kubectl edit pod pod-test1
4.pod 的重啟策略
（1）概念
重啟策略(restartPolicy) : Pod在遇到故障之后重啟的動(dòng)作
Always:當(dāng)容器終止退出后,總是重啟容器,默認(rèn)策略
OnFailure:當(dāng)容器異常退出(退出狀態(tài)碼非0)時(shí),重啟容器;正常退出則不重啟容器
Never:當(dāng)容器終止退出,從不重啟容器。注意: K8s中不支持重啟Pod資源,只有刪除重建
（2）示例
創(chuàng)建啟動(dòng)一個(gè)pod，查看狀態(tài)
[root@master01 ~]# vim pod3.yaml
apiVersion: v1
kind: Pod
metadata:
name: foo
spec:
containers:
- name: busybox
image: busybox
args:
- /bin/sh
- -c
- sleep 20; exit 3
#創(chuàng)建pod
kubectl apply -f pod3.yaml
#查看pod狀態(tài)
kubectl get pods
修改yaml 文件，設(shè)置重啟策略為Never
[root@master ~]# vim pod3.yaml
apiVersion: v1
kind: Pod
metadata:
name: foo
spec:
containers:
- name: busybox
image: busybox
args:
- /bin/sh
- -c
- sleep 20; exit 3
#設(shè)置重啟策略為從不
restartPolicy: Never
[root@master ~]# kubectl delete -f pod3.yaml
[root@master ~]# kubectl apply -f pod3.yaml
#在74s后，即使過(guò)了 20s 也沒(méi)有新的狀態(tài)出現(xiàn).因?yàn)橹貑⒉呗允荖ever，所以，不會(huì)重啟
[root@master ~]# kubectl get pods foo -w
NAME READY STATUS RESTARTS AGE
foo 0/1 ContainerCreating 0 40s
foo 1/1 Running 0 54s
foo 0/1 Error 0 74s
#新開(kāi)一個(gè)終端查看狀態(tài)
[root@master ~]# kubectl get pods foo
NAME READY STATUS RESTARTS AGE
foo 0/1 Error 0 103s
二、實(shí)驗(yàn)
1.Pod容器的分類(lèi)
（1）基礎(chǔ)容器（infrastructure?container）
在mster上創(chuàng)建pod
查看pod 被調(diào)度在哪個(gè)node節(jié)點(diǎn)上
在node01節(jié)點(diǎn)上，查看容器，發(fā)現(xiàn)自動(dòng)創(chuàng)建了pause容器
（2）?應(yīng)用容器(業(yè)務(wù)容器) （Maincontainer）
①聲明式啟動(dòng)應(yīng)用容器
聲明式啟動(dòng)
②?查看信息
pod一直沒(méi)有起來(lái)，兩個(gè)init進(jìn)程沒(méi)有完成
查看容器的詳細(xì)信息
容器狀態(tài)是false
顯示調(diào)度到node01節(jié)點(diǎn)成功（拉取鏡像，創(chuàng)建容器成功）
查看日志（無(wú)法解析myservice）
③?創(chuàng)建啟動(dòng)myservice，查看日志
聲明式創(chuàng)建資源
查看service，已經(jīng)有了名為myservice的service資源
查看pod,init進(jìn)程有一個(gè)已經(jīng)成功運(yùn)行
④?查看容器mydb日志
⑤?創(chuàng)建啟動(dòng)容器mydb，查看應(yīng)用容器的狀態(tài)
聲明式創(chuàng)建資源
查詢(xún)pod顯示正在初始化
在兩個(gè)init容器啟動(dòng)成功并結(jié)束后，應(yīng)用容器成功啟動(dòng)
2.鏡像拉取策略
(1)??更新資源（方式一 僅注釋command）
生成容器：
獲取信息：
此時(shí) Pod 的狀態(tài)異常，原因是 echo 執(zhí)行完進(jìn)程終止，容器生命周期也就結(jié)束了
查看詳細(xì)信息
修改 pod1.yaml 文件
刪除原有的資源
更新資源
查看 Pod 狀態(tài)
在任意 node 節(jié)點(diǎn)上使用 curl 查看頭部信息
(2) 更新資源（方式二 同時(shí)注釋imagePullPolicy和command）
刪除原有的資源并更新資源
查看詳細(xì)信息
使用edit 在線(xiàn)修改，查看資源配置
由于指定了鏡像的標(biāo)簽，所有默認(rèn)的鏡像拉取策略就是IfNotPresent
重啟策略Always
3.pod 的重啟策略
(1)??創(chuàng)建啟動(dòng)一個(gè)pod，查看狀態(tài)
編輯
創(chuàng)建pod
查看pod狀態(tài)
因?yàn)橛衧leep 20,所以在睡眠狀態(tài)時(shí)，容器還在運(yùn)行，等睡眠狀態(tài)過(guò)了，容器就會(huì)關(guān)閉銷(xiāo)毀
容器銷(xiāo)毀
pod重啟策略默認(rèn)是always，所以開(kāi)始重啟pod
pod重建，里面的容器目前正在執(zhí)行sleep 20的命令，等睡眠狀態(tài)過(guò)了容器又會(huì)銷(xiāo)毀，pod又變成error，再次觸發(fā)重啟策略
(2)?修改yaml 文件，設(shè)置重啟策略為Never
設(shè)置重啟策略為從不
刪除
重新生成
在24s后，即使過(guò)了 20s 也沒(méi)有新的狀態(tài)出現(xiàn).因?yàn)橹貑⒉呗允荖ever，所以，不會(huì)重啟
新開(kāi)一個(gè)終端查看狀態(tài)
因?yàn)橹貑⒉呗允荖ever，所以不會(huì)重啟pod
三、問(wèn)題
1.apiVersion 報(bào)錯(cuò)
（1）報(bào)錯(cuò)
error: error validating "pod1.yaml": error validating data: apiVersion not set; if you choose to ignore these errors, turn validation off with --validate=false
（2）原因分析
apiVersion 未正確設(shè)置
（3）解決方法
修改前：
修改后：
2.pod v1版本資源未注冊(cè)
（1）報(bào)錯(cuò)
Error from server (BadRequest): error when creating "pod1.yaml": pod in version "v1" cannot be handled as a Pod: no kind "pod" is registered for version "v1" in scheme "k8s.io/kubernetes/pkg/api/legacyscheme/scheme.go:30"
（2）原因分析
報(bào)了版本的錯(cuò)誤，一查以為是沒(méi)有pod這種v1版本的資源，沒(méi)注冊(cè)
最后才發(fā)現(xiàn)是yaml文件中的pod的首字母需要大寫(xiě)Pod
（3）解決方法
修改前：
修改后：
成功
3.格式錯(cuò)誤
(1) 報(bào)錯(cuò)
（2）原因分析
配置格式錯(cuò)誤
（3）解決方法
修改錯(cuò)誤配置
修改前：
修改后：
4.取行顯示指定pod信息
（1）需求
只需求截取第1行標(biāo)題欄和第12行信息
（2）問(wèn)題
grep命令缺失標(biāo)題欄
（3）解決方法
用awk命令取行取列
[root@master demo]# kubectl get pods -o wide | awk 'NR==1 || NR==12'
用sed命令取行
[root@master demo]# kubectl get pods -o wide | sed -n '1p;12p'
[root@master demo]# kubectl get pods -o wide | sed -n '/test1/p'
pod-test1 1/1 Running 0 53m 10.244.1.37 node02 <none> <none>
（4）awk小結(jié)
awk里的行與列，一般不叫行與列：行叫記錄（Record），列叫字段（Field）
①指定行號(hào)（第1行、第3行）
[root@master demo]# kubectl get pods -o wide | awk 'NR==1'
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
[root@master demo]# kubectl get pods -o wide | awk 'NR==2'
nginx-65fc77987d-2b6b9 1/1 Running 2 46h 10.244.2.22 node01 <none> <none>
[root@master demo]#
②?取范圍（3行以?xún)?nèi)的）
[root@master demo]# kubectl get pods -o wide | awk 'NR<=3'
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-65fc77987d-2b6b9 1/1 Running 2 46h 10.244.2.22 node01 <none> <none>
nginx-6cbd4b987c-6t2nt 1/1 Running 2 46h 10.244.2.27 node01 <none> <none>
[root@master demo]# kubectl get pods -o wide | awk 'NR==1,NR==3'
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-65fc77987d-2b6b9 1/1 Running 2 46h 10.244.2.22 node01 <none> <none>
nginx-6cbd4b987c-6t2nt 1/1 Running 2 46h 10.244.2.27 node01 <none> <none>
③取指定行（第1行和第3行）
[root@master demo]# kubectl get pods -o wide | awk 'NR==1 || NR==3'
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-6cbd4b987c-6t2nt 1/1 Running 2 46h 10.244.2.27 node01 <none> <none>
④ 取包含nginx字符串行
[root@master demo]# kubectl get pods -o wide | awk '/nginx/'
nginx-65fc77987d-2b6b9 1/1 Running 2 46h 10.244.2.22 node01 <none> <none>
nginx-6cbd4b987c-6t2nt 1/1 Running 2 46h 10.244.2.27 node01 <none> <none>
nginx-6cbd4b987c-bqtfp 1/1 Running 2 46h 10.244.1.34 node02 <none> <none>
nginx-6cbd4b987c-g4xxm 1/1 Running 2 46h 10.244.1.35 node02 <none> <none>
nginx-deployment-6959f4b694-nds9n 1/1 Running 2 3d19h 10.244.2.23 node01 <none> <none>
nginx-deployment-6959f4b694-qm5p9 1/1 Running 2 3d19h 10.244.1.32 node02 <none> <none>
nginx-deployment-6959f4b694-qmpd6 1/1 Running 2 3d19h 10.244.2.24 node01 <none> <none>
nginx-test-86bdc44976-5kj74 1/1 Running 1 26h 10.244.1.31 node02 <none> <none>
nginx-test-86bdc44976-kvgb4 1/1 Running 1 26h 10.244.2.26 node01 <none> <none>
nginx-test-86bdc44976-s24d6 1/1 Running 1 26h 10.244.2.25 node01 <none> <none>
⑤?取包含deployment字符串行到test字符串的行
[root@master demo]# kubectl get pods -o wide | awk '/deployment/,/test1/'
nginx-deployment-6959f4b694-nds9n 1/1 Running 2 3d19h 10.244.2.23 node01 <none> <none>
nginx-deployment-6959f4b694-qm5p9 1/1 Running 2 3d19h 10.244.1.32 node02 <none> <none>
nginx-deployment-6959f4b694-qmpd6 1/1 Running 2 3d19h 10.244.2.24 node01 <none> <none>
nginx-test-86bdc44976-5kj74 1/1 Running 1 26h 10.244.1.31 node02 <none> <none>
nginx-test-86bdc44976-kvgb4 1/1 Running 1 26h 10.244.2.26 node01 <none> <none>
nginx-test-86bdc44976-s24d6 1/1 Running 1 26h 10.244.2.25 node01 <none> <none>
pod-test1 1/1 Running 0 33m 10.244.1.37 node02 <none> <none>
⑥?包含deployment的行和test1的行
[root@master demo]# kubectl get pods -o wide | awk '/deployment|test1/'
nginx-deployment-6959f4b694-nds9n 1/1 Running 2 3d19h 10.244.2.23 node01 <none> <none>
nginx-deployment-6959f4b694-qm5p9 1/1 Running 2 3d19h 10.244.1.32 node02 <none> <none>
nginx-deployment-6959f4b694-qmpd6 1/1 Running 2 3d19h 10.244.2.24 node01 <none> <none>
pod-test1 1/1 Running 0 43m 10.244.1.37 node02 <none> <none>
效果同grep -E
[root@master demo]# kubectl get pods -o wide | grep -E 'deployment|test1'
nginx-deployment-6959f4b694-nds9n 1/1 Running 2 3d19h 10.244.2.23 node01 <none> <none>
nginx-deployment-6959f4b694-qm5p9 1/1 Running 2 3d19h 10.244.1.32 node02 <none> <none>
nginx-deployment-6959f4b694-qmpd6 1/1 Running 2 3d19h 10.244.2.24 node01 <none> <none>
pod-test1 1/1 Running 0 40m 10.244.1.37 node02 <none> <n
（5）sed小結(jié)
sed命令提取指定的行
①?提取第1行
[root@master demo]# kubectl get pods -o wide | sed -n '1p'
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
②?提取第1行到第3行
[root@master demo]# kubectl get pods -o wide | sed -n '1,3p'
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-65fc77987d-2b6b9 1/1 Running 2 46h 10.244.2.22 node01 <none> <none>
nginx-6cbd4b987c-6t2nt 1/1 Running 2 46h 10.244.2.27 node01 <none> <none>
③只提取第1行和第12行
[root@master demo]# kubectl get pods -o wide | sed -n '1p;12p'
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
pod-test1 1/1 Running 0 51m 10.244.1.37 node02 <none> <none>
④提取奇數(shù)行
⑤提取偶數(shù)行
⑥提取匹配test1的行
[root@master demo]# kubectl get pods -o wide | sed -n '/test1/p'
pod-test1 1/1 Running 0 53m 10.244.1.37 node02 <none> <none>
⑦提取同時(shí)匹配pod和test1的行
[root@master demo]# kubectl get pods -o wide | sed -n '/pod\|test1/p'
pod-test1 1/1 Running 0 55m 10.244.1.37 node02 <none> <none>
四、總結(jié)
Pod是kubernetes中最小的資源管理組件，Pod也是最小化運(yùn)行容器化應(yīng)用的資源對(duì)象。
? pause容器使得Pod中的所有容器可以共享兩種資源：網(wǎng)絡(luò)和存儲(chǔ)。
pod 的運(yùn)行方式有2種：
自主式pod：沒(méi)有自愈能力
控制器管理pod： 有自愈能力（Pod被刪除后會(huì)重新拉起新pod）pod 中有 3 種容器：
基礎(chǔ)容器（pause）：
初始化容器環(huán)境，開(kāi)啟pid=1的init進(jìn)程來(lái)管理其他容器的生命周期
提供網(wǎng)絡(luò)和存儲(chǔ)空間的共享環(huán)境基礎(chǔ)
init 容器
是在基礎(chǔ)容器之后，應(yīng)用容器之前運(yùn)行的容器
多個(gè)容器是串行運(yùn)行
init 容器必須在上一init容器運(yùn)行成功且退出后才會(huì)運(yùn)行
應(yīng)用容器（main c）
運(yùn)行業(yè)務(wù)的容器
在init容器都成功運(yùn)行和退出后運(yùn)行的
多個(gè)應(yīng)用容器是并行運(yùn)行的
在 一個(gè)pod 中，init 容器和應(yīng)用容器的名稱(chēng)都是唯一的
pod 的鏡像拉取策略 imagePullPolicy，配置在Containers字段的下面，是它的子字段：
IfNotPresent
是帶有指定標(biāo)簽的鏡像的默認(rèn)拉取測(cè)試。
本地有，則用本地鏡像。本地沒(méi)有則從倉(cāng)庫(kù)中拉取鏡像
Always
是沒(méi)有標(biāo)簽的鏡像或者使用哦latest標(biāo)簽的鏡像拉取策略
創(chuàng)建pod總是從倉(cāng)庫(kù)拉取鏡像
Never
不從倉(cāng)庫(kù)拉取鏡像，僅使用本地鏡像注意：
image : nginx:latest 鏡像的標(biāo)簽為latest或者無(wú)標(biāo)簽，默認(rèn)的鏡像拉取的策略為Always
nginx:1.14鏡像的標(biāo)簽為非latest,默認(rèn)的鏡像拉取的策略為IfNotPresent
pod 重啟策略 restartPolicy ，配置在containers字段同一層，和containers同屬 spec的子字段文章來(lái)源：http://www.zghlxwxcb.cn/news/detail-701635.html
Always
默認(rèn)的重啟策略。
容器退出時(shí)總是重啟容器
Never
容器退出，從不重啟容器
OnFailure
只有容器異常退出（非0狀態(tài)碼退出）,才會(huì)重啟容器
?文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-701635.html
到了這里，關(guān)于云原生Kubernetes：pod基礎(chǔ)的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
