這篇文章我們來(lái)深入了解Pod的基本概念及相關(guān)使用
一. Pod的設(shè)計(jì)思路
首先Pod是 Kubernetes 項(xiàng)目中最小的 API 對(duì)象案糙，而Pod也是由容器組組成的帝美。Pod 里的所有容器瘪匿，共享的是同一個(gè) Network Namespace，并且可以聲明共享同一個(gè) Volume吆寨。凡是調(diào)度窃款、網(wǎng)絡(luò)、存儲(chǔ)框沟，以及安全相關(guān)的屬性藏古，基本上是 Pod 級(jí)別的，而容器就成為Pod屬性中一個(gè)普通的字段定義忍燥。
我們可以這樣理解：容器是相當(dāng)于未來(lái)云計(jì)算的進(jìn)程拧晕，鏡像是安裝包，Pod則是傳統(tǒng)環(huán)境的機(jī)器梅垄，k8s是操作系統(tǒng)厂捞。pod是一個(gè)小家庭，它把密不可分的家庭成員(container)聚在一起队丝，Infra container則是家長(zhǎng)靡馁，掌管家中共通資源，家庭成員通過(guò)sidecar方式互幫互助机久，其樂(lè)融融～臭墨。
二. Pod的網(wǎng)絡(luò)通信Infra容器
在 Kubernetes 項(xiàng)目里，Pod 的實(shí)現(xiàn)需要使用一個(gè)中間容器膘盖，這個(gè)容器叫作 Infra 容器胧弛。在這個(gè) Pod 中，Infra 容器永遠(yuǎn)都是第一個(gè)被創(chuàng)建的容器侠畔，而其他用戶定義的容器结缚，則通過(guò) Join Network Namespace 的方式，與 Infra 容器關(guān)聯(lián)在一起软棺。這樣的組織關(guān)系红竭，可以用下面這樣一個(gè)示意圖來(lái)表達(dá)：
如上圖所示，這個(gè) Pod 里有兩個(gè)用戶容器 A 和 B喘落，還有一個(gè) Infra 容器德崭。很容易理解，在 Kubernetes 項(xiàng)目里揖盘，Infra 容器一定要占用極少的資源，所以它使用的是一個(gè)非常特殊的鏡像锌奴，叫作：k8s.gcr.io/pause兽狭。這個(gè)鏡像是一個(gè)用匯編語(yǔ)言編寫的、永遠(yuǎn)處于“暫停”狀態(tài)的容器箕慧，解壓后的大小也只有 100~200 KB 左右服球。而在 Infra 容器“Hold 住”Network Namespace 后，用戶容器就可以加入到 Infra 容器的 Network Namespace 當(dāng)中了
- 這也就意味著颠焦，對(duì)于 Pod 里的容器 A 和容器 B 來(lái)說(shuō)：
- 它們可以直接使用 localhost 進(jìn)行通信斩熊；
- 它們看到的網(wǎng)絡(luò)設(shè)備跟 Infra 容器看到的完全一樣；
- 一個(gè) Pod 只有一個(gè) IP 地址伐庭，也就是這個(gè) Pod 的 Network Namespace 對(duì)應(yīng)的 IP 地址粉渠；
- 當(dāng)然，其他的所有網(wǎng)絡(luò)資源圾另，都是一個(gè) Pod 一份霸株，并且被該 Pod 中的所有容器共享；
- Pod 的生命周期只跟 Infra 容器一致集乔，而與容器 A 和 B 無(wú)關(guān)去件。
而對(duì)于同一個(gè) Pod 里面的所有用戶容器來(lái)說(shuō)，它們的進(jìn)出流量扰路，也可以認(rèn)為都是通過(guò) Infra 容器完成的尤溜。這一點(diǎn)很重要，因?yàn)閷?lái)如果你要為 Kubernetes 開發(fā)一個(gè)網(wǎng)絡(luò)插件時(shí)汗唱，應(yīng)該重點(diǎn)考慮的是如何配置這個(gè) Pod 的 Network Namespace宫莱，而不是每一個(gè)用戶容器如何使用你的網(wǎng)絡(luò)配置，這是沒(méi)有意義的渡嚣。
這就意味著梢睛，如果你的網(wǎng)絡(luò)插件需要在容器里安裝某些包或者配置才能完成的話，是不可取的：Infra 容器鏡像的 rootfs 里幾乎什么都沒(méi)有识椰，沒(méi)有你隨意發(fā)揮的空間绝葡。當(dāng)然，這同時(shí)也意味著你的網(wǎng)絡(luò)插件完全不必關(guān)心用戶容器的啟動(dòng)與否腹鹉，而只需要關(guān)注如何配置 Pod藏畅，也就是 Infra 容器的 Network Namespace 即可。
三. 伴生容器與容器初始化
- sidecar： 伴生容器功咒，指的就是我們可以在一個(gè) Pod 中愉阎，啟動(dòng)一個(gè)輔助容器，來(lái)完成一些獨(dú)立于主進(jìn)程（主容器）之外的工作力奋。
- Init Container：初始化容器 就是用來(lái)做初始化工作的容器榜旦，可以是一個(gè)或者多個(gè)，如果有多個(gè)的話景殷，這些容器會(huì)按定義的順序依次執(zhí)行溅呢，只有所有的Init Container執(zhí)行完后澡屡，主容器才會(huì)被啟動(dòng)。我們知道一個(gè)Pod里面的所有容器是共享數(shù)據(jù)卷和網(wǎng)絡(luò)命名空間的咐旧，所以Init Container里面產(chǎn)生的數(shù)據(jù)可以被主容器使用到的驶鹉。
例如：我們現(xiàn)在有一個(gè) Java Web 應(yīng)用的 WAR 包，它需要被放在 Tomcat 的 webapps 目錄下運(yùn)行起來(lái)铣墨。假如室埋，你現(xiàn)在只能用 Docker 來(lái)做這件事情，那該如何處理這個(gè)組合關(guān)系呢伊约？
- 一種方法是姚淆，把 WAR 包直接放在 Tomcat 鏡像的 webapps 目錄下，做成一個(gè)新的鏡像運(yùn)行起來(lái)碱妆∪忭铮可是，這時(shí)候疹尾，如果你要更新 WAR 包的內(nèi)容上忍，或者要升級(jí) Tomcat 鏡像，就要重新制作一個(gè)新的發(fā)布鏡像纳本，非常麻煩窍蓝。
- 另一種方法是，你壓根兒不管 WAR 包繁成，永遠(yuǎn)只發(fā)布一個(gè) Tomcat 容器吓笙。不過(guò)，這個(gè)容器的 webapps 目錄巾腕，就必須聲明一個(gè) hostPath 類型的 Volume面睛，從而把宿主機(jī)上的 WAR 包掛載進(jìn) Tomcat 容器當(dāng)中運(yùn)行起來(lái)。不過(guò)尊搬，這樣你就必須要解決一個(gè)問(wèn)題叁鉴，即：如何讓每一臺(tái)宿主機(jī)，都預(yù)先準(zhǔn)備好這個(gè)存儲(chǔ)有 WAR 包的目錄呢佛寿？這樣來(lái)看幌墓，你只能獨(dú)立維護(hù)一套分布式存儲(chǔ)系統(tǒng)了。
實(shí)際上冀泻，有了 Pod 之后常侣，這樣的問(wèn)題就很容易解決了。我們可以把 WAR 包和 Tomcat 分別做成鏡像弹渔，然后把它們作為一個(gè) Pod 里的兩個(gè)容器“組合”在一起胳施。這個(gè) Pod 的配置文件如下所示：
apiVersion: v1
kind: Pod
metadata:
name: javaweb-2
spec:
initContainers:
- image: geektime/sample:v2
name: war
command: ["cp", "/sample.war", "/app"]
volumeMounts:
- mountPath: /app
name: app-volume
containers:
- image: geektime/tomcat:7.0
name: tomcat
command: ["sh","-c","/root/apache-tomcat-7.0.42-v2/bin/start.sh"]
volumeMounts:
- mountPath: /root/apache-tomcat-7.0.42-v2/webapps
name: app-volume
ports:
- containerPort: 8080
hostPort: 8001
volumes:
- name: app-volume
emptyDir: {}
在這個(gè) Pod 中，我們定義了兩個(gè)容器肢专，第一個(gè)容器使用的鏡像是geektime/sample:v2巾乳，這個(gè)鏡像里只有一個(gè) WAR 包（sample.war）放在根目錄下您没。而第二個(gè)容器則使用的是一個(gè)標(biāo)準(zhǔn)的 Tomcat 鏡像。
不過(guò)胆绊，你可能已經(jīng)注意到，WAR 包容器的類型不再是一個(gè)普通容器欧募，而是一個(gè) Init Container 類型的容器压状。在 Pod 中，所有 Init Container 定義的容器跟继，都會(huì)比 spec.containers 定義的用戶容器先啟動(dòng)种冬。并且，Init Container 容器會(huì)按順序逐一啟動(dòng)舔糖，而直到它們都啟動(dòng)并且退出了娱两，用戶容器才會(huì)啟動(dòng)。
所以金吗，這個(gè) Init Container 類型的 WAR 包容器啟動(dòng)后十兢，我執(zhí)行了一句"cp /sample.war /app"，把應(yīng)用的 WAR 包拷貝到 /app 目錄下摊唇，然后退出缭保。而后這個(gè) /app 目錄羊壹，就掛載了一個(gè)名叫 app-volume 的 Volume。接下來(lái)就很關(guān)鍵了宵呛。Tomcat 容器，同樣聲明了掛載 app-volume 到自己的 webapps 目錄下夕凝。所以宝穗，等 Tomcat 容器啟動(dòng)時(shí)，它的 webapps 目錄下就一定會(huì)存在 sample.war 文件：這個(gè)文件正是 WAR 包容器啟動(dòng)時(shí)拷貝到這個(gè) Volume 里面的码秉，而這個(gè) Volume 是被這兩個(gè)容器共享的逮矛。
像這樣，我們就用一種“組合”方式泡徙，解決了 WAR 包與 Tomcat 容器之間耦合關(guān)系的問(wèn)題橱鹏。實(shí)際上，這個(gè)所謂的“組合”操作堪藐，正是容器設(shè)計(jì)模式里最常用的一種模式莉兰，它的名字叫：sidecar。
在我們的這個(gè)應(yīng)用 Pod 中礁竞，Tomcat 容器是我們要使用的主容器糖荒，而 WAR 包容器的存在，只是為了給它提供一個(gè) WAR 包而已模捂。所以捶朵，我們用 Init Container初始化容器的方式優(yōu)先運(yùn)行 WAR 包容器蜘矢，扮演了一個(gè) sidecar 的角色。
四. Pod的生命周期狀態(tài)
- Pending综看。這個(gè)狀態(tài)意味著品腹，Pod 的 YAML 文件已經(jīng)提交給了 Kubernetes，API 對(duì)象已經(jīng)被創(chuàng)建并保存在 Etcd 當(dāng)中红碑。但是舞吭，這個(gè) Pod 里有些容器因?yàn)槟撤N原因而不能被順利創(chuàng)建。比如析珊，調(diào)度不成功羡鸥。
- Running。這個(gè)狀態(tài)下忠寻，Pod已經(jīng)調(diào)度成功惧浴，跟一個(gè)具體的節(jié)點(diǎn)綁定。它包含的容器都已經(jīng)創(chuàng)建成功奕剃，并且至少有一個(gè)正在運(yùn)行中衷旅。
- Succeeded。這個(gè)狀態(tài)意味著祭饭，Pod 里的所有容器都正常運(yùn)行完畢芜茵，并且已經(jīng)退出了。這種情況在運(yùn)行一次性任務(wù)時(shí)最為常見倡蝙。
- Failed九串。這個(gè)狀態(tài)下，Pod 里至少有一個(gè)容器以不正常的狀態(tài)（非 0 的返回碼）退出寺鸥。這個(gè)狀態(tài)的出現(xiàn)猪钮，意味著你得想辦法 Debug 這個(gè)容器的應(yīng)用，比如查看 Pod 的 Events 和日志胆建。
- Unknown烤低。這是一個(gè)異常狀態(tài)，意味著 Pod 的狀態(tài)不能持續(xù)地被 kubelet 匯報(bào)給 kube-apiserver笆载，這很有可能是主從節(jié)點(diǎn)（Master 和 Kubelet）間的通信出現(xiàn)了問(wèn)題扑馁。
五. Pod的鉤子Hook
Kubernetes 為我們的容器提供了生命周期鉤子的，就是我們說(shuō)的Pod Hook凉驻，Pod Hook 是由 kubelet 發(fā)起的腻要，當(dāng)容器中的進(jìn)程啟動(dòng)前或者容器中的進(jìn)程終止之前運(yùn)行，這是包含在容器的生命周期之中涝登。我們可以同時(shí)為 Pod 中的所有容器都配置 hook雄家。
Kubernetes 為我們提供了兩種鉤子函數(shù)：
- PostStart：這個(gè)鉤子在容器創(chuàng)建后立即執(zhí)行。但是胀滚，并不能保證鉤子將在容器ENTRYPOINT之前運(yùn)行趟济，因?yàn)闆](méi)有參數(shù)傳遞給處理程序乱投。主要用于資源部署、環(huán)境準(zhǔn)備等顷编。不過(guò)需要注意的是如果鉤子花費(fèi)太長(zhǎng)時(shí)間以至于不能運(yùn)行或者掛起戚炫， 容器將不能達(dá)到running狀態(tài)。
- PreStop：這個(gè)鉤子在容器終止之前立即被調(diào)用媳纬。它是阻塞的嘹悼，意味著它是同步的， 所以它必須在刪除容器的調(diào)用發(fā)出之前完成层宫。主要用于優(yōu)雅關(guān)閉應(yīng)用程序、通知其他系統(tǒng)等其监。如果鉤子在執(zhí)行期間掛起萌腿， Pod階段將停留在running狀態(tài)并且永不會(huì)達(dá)到failed狀態(tài)。
如果PostStart或者PreStop鉤子失敗抖苦， 它會(huì)殺死容器毁菱。所以我們應(yīng)該讓鉤子函數(shù)盡可能的輕量。當(dāng)然有些情況下锌历，長(zhǎng)時(shí)間運(yùn)行命令是合理的贮庞， 比如在停止容器之前預(yù)先保存狀態(tài)。
另外我們有兩種方式來(lái)實(shí)現(xiàn)上面的鉤子函數(shù)：
- Exec - 用于執(zhí)行一段特定的命令究西，不過(guò)要注意的是該命令消耗的資源會(huì)被計(jì)入容器窗慎。
- HTTP - 對(duì)容器上的特定的端點(diǎn)執(zhí)行HTTP請(qǐng)求
示例
apiVersion: v1
kind: Pod
metadata:
name: lifecycle-demo
spec:
containers:
- name: lifecycle-demo-container
image: nginx
lifecycle:
postStart:
exec:
command: ["/bin/sh", "-c", "echo Hello from the postStart handler > /usr/share/message"]
preStop:
exec:
command: ["/usr/sbin/nginx","-s","quit"]
在這個(gè)例子中，我們?cè)谌萜鞒晒?dòng)之后定義了Lifecycle字段卤材，即在 /usr/share/message 里寫入了一句“歡迎信息”（即 postStart 定義的操作）遮斥。而在這個(gè)容器被刪除之前，我們則先調(diào)用了 nginx 的退出指令（即 preStop 定義的操作）扇丛，從而實(shí)現(xiàn)了容器的“優(yōu)雅退出”
六. Pod的健康檢查
在 Kubernetes 中术吗，你可以為 Pod 里的容器定義一個(gè)健康檢查“探針”（Probe）。這樣帆精，kubelet 就會(huì)根據(jù)這個(gè) Probe 的返回值決定這個(gè)容器的狀態(tài)较屿，而不是直接以容器進(jìn)行是否運(yùn)行（來(lái)自 Docker 返回的信息）作為依據(jù)。這種機(jī)制卓练，是生產(chǎn)環(huán)境中保證應(yīng)用健康存活的重要手段隘蝎。
- liveness probe（存活探針）：確定你的應(yīng)用程序是否正在運(yùn)行，通俗點(diǎn)將就是是否還活著昆庇。一般來(lái)說(shuō)末贾，如果你的程序一旦崩潰了， Kubernetes 就會(huì)立刻知道這個(gè)程序已經(jīng)終止了整吆，然后就會(huì)重啟這個(gè)程序拱撵。而我們的 liveness probe 的目的就是來(lái)捕獲到當(dāng)前應(yīng)用程序還沒(méi)有終止辉川，還沒(méi)有崩潰，如果出現(xiàn)了這些情況拴测，那么就重啟處于該狀態(tài)下的容器乓旗，使應(yīng)用程序在存在 bug 的情況下依然能夠繼續(xù)運(yùn)行下去。
- readiness probe（可讀性探針）：確定容器是否已經(jīng)就緒可以接收流量過(guò)來(lái)了集索。這個(gè)探針通俗點(diǎn)講就是說(shuō)是否準(zhǔn)備好了屿愚，現(xiàn)在可以開始工作了。只有當(dāng) Pod 中的容器都處于就緒狀態(tài)的時(shí)候 kubelet 才會(huì)認(rèn)定該 Pod 處于就緒狀態(tài)务荆，因?yàn)橐粋€(gè) Pod 下面可能會(huì)有多個(gè)容器妆距。當(dāng)然 Pod 如果處于非就緒狀態(tài)，那么我們就會(huì)將他從我們的工作隊(duì)列(實(shí)際上就是我們后面需要重點(diǎn)學(xué)習(xí)的 Service)中移除出來(lái)函匕，這樣我們的流量就不會(huì)被路由到這個(gè) Pod 里面來(lái)了娱据，決定的這個(gè) Pod 是不是能被通過(guò) Service 的方式訪問(wèn)到，而并不影響 Pod 的生命周期盅惜。中剩。
探針支持的配置方式：
- exec：執(zhí)行一段命令
- http：檢測(cè)某個(gè) http 請(qǐng)求
- tcpSocket：檢查端口， kubelet 將嘗試在指定端口上打開容器的套接字抒寂。如果可以建立連接结啼，容器被認(rèn)為是健康的，如果不能就認(rèn)為是失敗的屈芜。
示例
apiVersion: v1
kind: Pod
metadata:
labels:
test: liveness
name: test-liveness-exec
spec:
containers:
- name: liveness
image: busybox
args:
- /bin/sh
- -c
- touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
livenessProbe:
exec:
command:
- cat
- /tmp/healthy
initialDelaySeconds: 5
periodSeconds: 5
在這個(gè) Pod 中郊愧，我們定義了一個(gè)容器。它在啟動(dòng)之后做的第一件事沸伏，就是在 /tmp 目錄下創(chuàng)建了一個(gè) healthy 文件糕珊，以此作為自己已經(jīng)正常運(yùn)行的標(biāo)志。而 30 s 過(guò)后毅糟，它會(huì)把這個(gè)文件刪除掉红选。與此同時(shí)，我們定義了一個(gè)這樣的 livenessProbe（健康檢查）姆另。它的類型是 exec喇肋，這意味著，它會(huì)在容器啟動(dòng)后迹辐，在容器里面執(zhí)行一句我們指定的命令蝶防，比如：“cat /tmp/healthy”。這時(shí)明吩，如果這個(gè)文件存在间学，這條命令的返回值就是 0，Pod 就會(huì)認(rèn)為這個(gè)容器不僅已經(jīng)啟動(dòng)，而且是健康的低葫，如果返回值為非0详羡，那么kubelet將會(huì)重啟這個(gè)容器。initialDelaySeconds:5嘿悬，在容器啟動(dòng) 5 s 后開始執(zhí)行健康檢查实柠，periodSeconds: 5每 5 s 執(zhí)行一次。
創(chuàng)建這個(gè)Pod查看過(guò)程
$ kubectl get pods
test-liveness-exec 1/1 Running 0 64s
30s后我們查看Pod的Event
$ kubectl describe pod test-liveness-exec
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 2m5s default-scheduler Successfully assigned default/test-liveness-exec to k8s-node01
Warning Unhealthy 66s (x3 over 76s) kubelet, k8s-node01 Liveness probe failed: cat: can't open '/tmp/healthy': No such file or directory
通過(guò)Event發(fā)現(xiàn)健康檢查探查到 /tmp/healthy 已經(jīng)不存在了善涨，所以它報(bào)告容器是不健康的窒盐，我們?cè)诳匆幌翽od的當(dāng)前狀態(tài)是否正常？
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
test-liveness-exec 1/1 Running 1 1m1s
我們可以看到Pod的狀態(tài)仍然是Running正常的钢拧，但是RESTARTS字段已經(jīng)由0已經(jīng)變成1了蟹漓，這是因?yàn)镻od已經(jīng)被kubelet重啟了。
livenessProbe 也可以定義為發(fā)起 HTTP 或者 TCP 請(qǐng)求的方式源内，定義格式如下：
livenessProbe:
httpGet:
path: /healthz
port: 8080
httpHeaders:
- name: X-Custom-Header
value: Awesome
initialDelaySeconds: 3
periodSeconds: 3
livenessProbe:
tcpSocket:
port: 8080
initialDelaySeconds: 15
periodSeconds: 20
Pod 其實(shí)可以暴露一個(gè)健康檢查 URL（比如 /healthz）牧牢，或者直接讓健康檢查去檢測(cè)應(yīng)用的監(jiān)聽端口。這兩種配置方法姿锭，在 Web 服務(wù)類的應(yīng)用中非常常用。
七. Pod的故障恢復(fù)機(jī)制
上面例子中健康檢查如果沒(méi)有通過(guò)伯铣，kubelet則會(huì)重啟這個(gè)容器呻此，這是因?yàn)槟J(rèn)Pod的恢復(fù)機(jī)制為Always，其實(shí)它是 Pod 的 Spec 部分的一個(gè)標(biāo)準(zhǔn)字段（pod.spec.restartPolicy）腔寡，我們可以根據(jù)自己的需求來(lái)定通過(guò)設(shè)置 restartPolicy改變 Pod 的恢復(fù)策略：
- Always：在任何情況下焚鲜，只要容器不在運(yùn)行狀態(tài)，就自動(dòng)重啟容器放前；
- OnFailure: 只在容器 異常時(shí)才自動(dòng)重啟容器忿磅；
- Never: 從來(lái)不重啟容器。
基本的設(shè)計(jì)原理:
只要 Pod 的 restartPolicy 指定的策略允許重啟異常的容器（比如：Always）凭语，那么這個(gè) Pod 就會(huì)保持 Running 狀態(tài)葱她，并進(jìn)行容器重啟。否則似扔，Pod 就會(huì)進(jìn)入 Failed 狀態(tài) 吨些。
對(duì)于包含多個(gè)容器的 Pod，只有它里面所有的容器都進(jìn)入異常狀態(tài)后炒辉，Pod 才會(huì)進(jìn)入 Failed 狀態(tài)豪墅。在此之前，Pod 都是 Running 狀態(tài)黔寇。此時(shí)偶器，Pod 的 READY 字段會(huì)顯示正常容器的個(gè)數(shù)
八. Pod的常用屬性定義
除了上文定義的一些屬性字段，我們常用的屬性還有以下字段定義：
- NodeSelector：是一個(gè)供用戶將 Pod 與 Node 進(jìn)行綁定的字段
- ImagePullPolicy：[Always | Never | IfNotPresent] # 【String】 每次都嘗試重新拉取鏡像 | 僅使用本地鏡像 | 如果本地有鏡像則使用，沒(méi)有則拉取
- Volume：volume是Pod中多個(gè)容器訪問(wèn)的共享目錄屏轰。volume被定義在pod上颊郎，被這個(gè)pod的多個(gè)容器掛載到相同或不同的路徑下。一般volume被用于持久化pod產(chǎn)生的數(shù)據(jù)亭枷。Kubernetes提供了眾多的volume類型袭艺，包括emptyDir、hostPath叨粘、nfs猾编、glusterfs、cephfs升敲、ceph rbd等答倡。
- NodeName：一旦 Pod 的這個(gè)字段被賦值，Kubernetes 項(xiàng)目就會(huì)被認(rèn)為這個(gè) Pod 已經(jīng)經(jīng)過(guò)了調(diào)度驴党，調(diào)度的結(jié)果就是賦值的節(jié)點(diǎn)名字瘪撇。所以，這個(gè)字段一般由調(diào)度器負(fù)責(zé)設(shè)置港庄，但用戶也可以設(shè)置它來(lái)“騙過(guò)”調(diào)度器倔既，當(dāng)然這個(gè)做法一般是在測(cè)試或者調(diào)試的時(shí)候才會(huì)用到。
- HostAliases：定義了 Pod 的 hosts 文件（比如 /etc/hosts）里的內(nèi)容鹏氧。
網(wǎng)上資料：
總結(jié)：在這篇文章中我們深度了解了Pod的設(shè)計(jì)模式和字段屬性定義渤涌，其實(shí)Pod 這個(gè)看似復(fù)雜的 API 對(duì)象，實(shí)際上就是對(duì)容器的進(jìn)一步抽象和封裝而已把还，Pod 對(duì)象就是容器的升級(jí)版实蓬。它對(duì)容器進(jìn)行了組合，添加了更多的屬性和字段吊履。
上篇文章：k8s三 | 使用YAML文件定義資源對(duì)象
系列文章：深入理解Kuerneters
參考資料：深入剖析Kubernetes-張磊安皱、從Docker到Kubernetes進(jìn)階-陽(yáng)明
