鎮(zhèn)江網(wǎng)站推廣南寧seo外包要求
目錄
一、理論
1.pod
2.pod容器分類
3.鏡像拉取策略(image PullPolicy)
二、實(shí)驗(yàn)
1.Pod容器的分類
2.鏡像拉取策略
三、問題
1.apiVersion 報(bào)錯(cuò)
2.pod v1版本資源未注冊(cè)
3.取行顯示指定pod信息
四、總結(jié)
一、理論
1.pod
(1)? 概念
?Pod是kubernetes中最小的資源管理組件,Pod也是最小化運(yùn)行容器化應(yīng)用的資源對(duì)象。一個(gè)Pod代表著集群中運(yùn)行的一個(gè)進(jìn)程。kubernetes中其他大多數(shù)組件都是圍繞著Pod來進(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è)容器”的模式是最常見的用法;在這種使用方式中,你可以把Pod想象成是單個(gè)容器的封裝,kuberentes管理的是Pod而不是直接管理容器。
②??在一個(gè)Pod中同時(shí)運(yùn)行多個(gè)容器。
? ? ? ? 一個(gè)Pod中也可以同時(shí)封裝幾個(gè)需要緊密耦合互相協(xié)作的容器,它們之間共享資源。這些在同一個(gè)Pod中的容器可以互相協(xié)作成為一個(gè)service單位,比如一個(gè)容器共享文件,另一個(gè)“sidecar”容器來更新這些文件。Pod將這些容器的存儲(chǔ)資源作為一個(gè)實(shí)體來管理。
? ? ? ? 一個(gè)Pod下的容器必須運(yùn)行于同一節(jié)點(diǎn)上?,F(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è)類似Linux操作系統(tǒng)init進(jìn)程的管控類進(jìn)程,以樹狀結(jié)構(gòu)完成多進(jìn)程的生命周期管理。運(yùn)行于各自容器內(nèi)的進(jìn)程無法直接完成網(wǎng)絡(luò)通信,這是由于容器間的隔離機(jī)制導(dǎo)致,k8s中的Pod資源抽象正是解決此類問題,Pod對(duì)象是一組容器的集合,這些容器共享Network、UTS及IPC命令空間,因此具有相同的域名、主機(jī)名和網(wǎng)絡(luò)接口,并可通過IPC直接通信。
? ? ? ? Pod資源中針對(duì)各容器提供網(wǎng)絡(luò)命令空間等共享機(jī)制的是底層基礎(chǔ)容器pause,基礎(chǔ)容器(也可稱為父容器)pause就是為了管理Pod容器間的共享操作,這個(gè)父容器需要能夠準(zhǔn)確地知道如何去創(chuàng)建共享運(yùn)行環(huán)境的容器,還能管理這些容器的生命周期。為了實(shí)現(xiàn)這個(gè)父容器的構(gòu)想,kubernetes中,用pause容器來作為一個(gè)Pod中所有容器的父容器。這個(gè)pause容器有兩個(gè)核心的功能,一是它提供整個(gè)Pod的Linux命名空間的基礎(chǔ)。二來啟用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中的所有容器都可以訪問共享的Volume。Volume也可以用來持久化Pod中的存儲(chǔ)資源,以防容器重啟后文件丟失。
?③?小結(jié)
? ? ? ? 每個(gè)Pod都有一個(gè)特殊的被稱為“基礎(chǔ)容器”的Pause容器。Pause容器對(duì)應(yīng)的鏡像屬于Kubernetes平臺(tái)的一部分,除了Pause容器,每個(gè)Pod還包含一個(gè)或者多個(gè)緊密相關(guān)的用戶應(yīng)用容器。
(4)pause容器功能
①??在pod中擔(dān)任Linux命名空間(如網(wǎng)絡(luò)命令空間)共享的基礎(chǔ);
②??啟用PID命名空間,開啟init進(jìn)程。
(5)pod設(shè)計(jì)特殊組成結(jié)構(gòu)目的
①?原因一:在一組容器作為一個(gè)單元的情況下,難以對(duì)整體的容器簡(jiǎn)單地進(jìn)行判斷及有效地進(jìn)行行動(dòng)。比如,一個(gè)容器死亡了,此時(shí)是算整體掛了么?那么引入與業(yè)務(wù)無關(guān)的Pause容器作為Pod的基礎(chǔ)容器,以它的狀態(tài)代表著整個(gè)容器組的狀態(tài),這樣就可以解決該問題。
②?原因二:Pod里的多個(gè)應(yīng)用容器共享Pause容器的IP,共享Pause容器掛載的Volume,這樣簡(jiǎn)化了應(yīng)用容器之間的通信問題,也解決了容器之間的文件共享問題。
(6)pod分類
通常把Pod分為兩類:
1.自主式Pod
1)創(chuàng)建方式(類似自營)kubectl run pod 用于創(chuàng)建一個(gè)自主/靜態(tài)pod
注意:它就是創(chuàng)建一個(gè)pod,這個(gè)pod一旦掛了就不會(huì)在node上拉起來,這個(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)建方式(類似有人管)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í)的稱為Controller的抽象層,來管理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來管理Pod的。
2.pod容器分類
(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ì)于用戶是透明的
docker ps -a
(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 容器可以包含一些安裝過程中應(yīng)用容器中不存在的實(shí)用工具或個(gè)性化代碼。例如,沒有必要僅為了在安裝過程中使用類似 sed、 awk、 python 或 dig 這樣的工具而去FROM 一個(gè)鏡像來生成一個(gè)新的鏡像。●Init 容器可以安全地運(yùn)行這些工具,避免這些工具導(dǎo)致應(yīng)用鏡像的安全性降低?!駪?yīng)用鏡像的創(chuàng)建者和部署者可以各自獨(dú)立工作,而沒有必要聯(lián)合構(gòu)建一個(gè)單獨(dú)的應(yīng)用鏡像?!馡nit 容器能以不同于Pod內(nèi)應(yīng)用容器的文件系統(tǒng)視圖運(yùn)行。因此,Init容器可具有訪問 Secrets 的權(quán)限,而應(yīng)用容器不能夠訪問?!裼捎?Init 容器必須在應(yīng)用容器啟動(dòng)之前運(yùn)行完成,因此 Init 容器提供了一種機(jī)制來阻塞或延遲應(yīng)用容器的啟動(dòng),
直到滿足了一組先決條件。一旦前置條件滿足,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-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;']
這個(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-podkubectl logs myapp-pod -c init-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 podsvim mydb.yaml
apiVersion: v1
kind: Service
metadata:name: mydb
spec:ports:- protocol: TCPport: 80targetPort: 9377
kubectl create -f mydb.yamlkubectl get pods
特別說明:
●在Pod啟動(dòng)過程中,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容器沒有成功之前,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容器無法定義不同于完成(completion)的就緒(readiness)之外的其他狀態(tài)。這會(huì)在驗(yàn)證過程中強(qiáng)制執(zhí)行。
●在Pod中的每個(gè)app和Init容器的名稱必須唯一;與任何其它容器共享同一個(gè)名稱,會(huì)在驗(yàn)證時(shí)拋出錯(cuò)誤。
3.鏡像拉取策略(image PullPolicy)
? ? ? ? Pod 的核心是運(yùn)行容器,必須指定容器引擎,比如 Docker,啟動(dòng)容器時(shí),需要拉取鏡像,k8s 的鏡像拉取策略可以由用戶指定:
1、IfNotPresent:在鏡像已經(jīng)存在的情況下,kubelet 將不再去拉取鏡像,僅當(dāng)本地缺失時(shí)才從倉庫中拉取,默認(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/imageskubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:name: private-image-test-1
spec:containers:- name: uses-private-imageimage: $PRIVATE_IMAGE_NAMEimagePullPolicy: Alwayscommand: [ "echo", "SUCCESS" ]
EOF
(2) 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,默認(rèn)值schedulerName: default-schedulersecurityContext: {}terminationGracePeriodSeconds: 30
......
(3)? 創(chuàng)建測(cè)試案例
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
此時(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 node02Normal Pulled 3m34s (x4 over 4m40s) kubelet, node02 Successfully pulled image "nginx"Normal Created 3m34s (x4 over 4m40s) kubelet, node02 Created container nginxNormal Started 3m34s (x4 over 4m40s) kubelet, node02 Started container nginxWarning BackOff 3m4s (x8 over 4m32s) kubelet, node02 Back-off restarting failed containerNormal Pulling 2m50s (x5 over 4m43s) kubelet, node02 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: nginximage: 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
......
二、實(shí)驗(yàn)
1.Pod容器的分類
(1)基礎(chǔ)容器(infrastructure?container)
2.鏡像拉取策略
(1)?創(chuàng)建測(cè)試案例
生成容器:
獲取信息:
此時(shí) Pod 的狀態(tài)異常,原因是 echo 執(zhí)行完進(jìn)程終止,容器生命周期也就結(jié)束了
查看詳細(xì)信息
修改 pod1.yaml 文件
刪除原有的資源
更新資源
查看 Pod 狀態(tài)
在任意 node 節(jié)點(diǎn)上使用 curl 查看頭部信息
三、問題
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ò)誤,一查以為是沒有pod這種v1版本的資源,沒注冊(cè)
最后才發(fā)現(xiàn)是yaml文件中的pod的首字母需要大寫Pod
(3)解決方法
修改前:
修改后:
成功
3.取行顯示指定pod信息
(1)需求
只需求截取第1行標(biāo)題欄和第12行信息
(2)問題
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行以內(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ì)象。
K8S集群中Pod兩種使用方式:
①??一個(gè)Pod中運(yùn)行一個(gè)容器②??在一個(gè)Pod中同時(shí)運(yùn)行多個(gè)容器。
? pause容器使得Pod中的所有容器可以共享兩種資源:網(wǎng)絡(luò)和存儲(chǔ)。