k8s pod内部容器_第三章 pod：运行于kubernetes中的容器
本章內(nèi)容涵蓋
創(chuàng)建、 啟動和停止 pod
使用標簽組織 pod 和其他資源
使用特定標簽對所有 pod 執(zhí)行操作
使用命名空間將多個 pod 分到不重疊的組中
調(diào)度 pod 到指定類型的工作節(jié)點
上一章 已經(jīng)大致介紹了在 Kubemetes 中創(chuàng)建的基本組件，包括它們的基本功 能概述。 那么接下來我們將更加詳細地介紹所有類型的 Kubemetes 對象(或資源)， 以便你理解在何時、 如何及為何要使用每一個對象。 其中 pod 是 Kubemetes 中最為 重要的核心概念，而其他對象僅僅是在管理、 暴露 pod 或被 pod 使用 ，所以我們將 首先介紹 pod 這一核心概念。
3.1 介紹pod
我們已經(jīng)了解到， pod 是一組并置的容器，代表了 Kubernetes 中的基本構(gòu)建模 塊。 在實際應用 中我們并不會單獨部署容器， 更多的是針對一組 pod 的容器進行部 署和操作。 然而這并不意味著一個 pod 總是要包含多個容器一一實際上只包含一個單獨容器的 pod 也是非常常見的。 值得注意的是，當一個 pod 包含多個容器時，這 些容器總是運行于同一個工作節(jié)點上——一個 pod 絕不會跨越多個工作節(jié)點，如圖 3.1 所示。
3.1.1 為何需要 pod
關(guān)于為何需要 pod 這種容器？為何不直接使用容器？為何甚至需要同時運行 多個容器？難道不能簡單地把所有進程都放在一個單獨的容器中嗎？接下來我們將 一一回答上述問題。
為何多個容器比單個容器中包含多個進程要好
想象一個由多個進程組成的應用程序，無論是通過 ipc (進程間通信)還是本 地存儲文件進行通信，都要求它們運行于同一 臺機器上。 在 Kubemetes 中，我們經(jīng) 常在容器中運行進程，由于每一個容器都非常像一臺獨立的機器，此時你可能認為 在單個容器中運行多個進程是合乎邏輯的，然而在實踐中這種做法并不合理。 容器被設計為每個容器只運行一個進程(除非進程本身產(chǎn)生子進程)。如果在 單個容器中運行多個不相關(guān)的進程，那么保持所有進程運行、管理它們的日志等將 會是我們的責任。例如，我們需要包含一種在進程崩潰時能夠自動重啟 的機制 。 同 時這些進程都將記錄到相同的標準輸出中，而此時我們將很難確定每個進程分別記 錄了什么 。
綜上所述，我們需要讓每個進程運行于自己的容器中，而這就是Docker和kubernetes期望使用的方式。
3.1.2 了解 pod
由于不能將多個進程聚集在一個單獨的容器中，我們需要另一種更高級的結(jié)構(gòu) 來將容器綁定在一起，并將它們作為一個單元進行管理，這就是 pod 背后的根本原理。 在包含容器的 pod 下，我們可以同時運行一些密切相關(guān)的進程，并為它們提供(幾 乎)相同的環(huán)境，此時這些進程就好像全部運行于單個容器中一樣，同時又保持著 一定的隔離。這樣一來，我們便能全面地利用容器所提供的特性，同時對這些進程 來說它們就像運行在一起一樣，實現(xiàn)兩全其美。
同一 pod 中容器之間的部分隔離
在上一章中，我們己經(jīng)了解到容器之間彼此是完全隔離的，但此時我們期望的 是隔離容器組，而不是單個容器，并讓每個容器組內(nèi)的容器共享一些資源，而不是 全部(換句話說，沒有完全隔離)。?Kubemetes 通過配置 Docker 來讓一個 pod 內(nèi)的 所有容器共享相同的 Linux 命名空間，而不是每個容器都有自己的一組命名空間。
由于一個 pod 中的所有容器都在相同的 network 和 UTS 命名空間下運行(在這 里我們討論的是 Linux 命名空間)，所以它們都共享相同的主機名和網(wǎng)絡接口。同樣 地，這些容器也都在相同的 IPC 命名空間下運行，因此能夠通過 IPC 進行通信。在 最新的 Kubemetes 和 Docker 版本中，它們也能夠共享相 同的 PID 命名空間，但是 該特征默認是未激活的。
注意 當同一個 pod 中的容器使用單獨的 PID 命名空間時，在容器中執(zhí)行 ps aux 就只會看到容器自己的進程。
但當涉及文件系統(tǒng)時，情況就有所不同。 由于大多數(shù)容器的文件系統(tǒng)來自容器 鏡像，因此默認情況下，每個容器的文件系統(tǒng)與其他容器完全隔離。但我們可以使 用名為 Volume 的 Kubemetes 資源來共享文件目錄， 關(guān)于這一概念將在第 6 章進行 討論。
容器如何共享相同的 IP 和端口空間
這里需強調(diào)的一點是，由于一個 pod 中的容器運行于相同的 Network 命名空間 中，因此它們共享相同的 IP 地址和端口空間。這意味著在同－ pod 中的容器運行的 多個進程需要注意不能綁定到相同的端口號，否則會導致端口沖突，但這只涉及同 - pod 中的容器。 由于每個 pod 都有獨立的端口空間，對于不同 pod 中的容器來說 則永遠不會遇到端口沖突。此外， 一個 pod 中的所有容器也都具有相同的 loopback 網(wǎng)絡接口，因此容器可以通過 localhost 與同一pod 中的其他容器進行通信。
介紹平坦 pod 間網(wǎng)絡
Kubemetes 集群中的所有 pod 都在同一個共享網(wǎng)絡地址空間中(如圖 3.2 所示)， 這意味著每個 pod 都可以通過其他 pod 的 IP 地址來實現(xiàn)相互訪問 。 換句話說，這也 表示它們之間沒有 NAT (網(wǎng)絡地址轉(zhuǎn)換)網(wǎng)關(guān)。當兩個 pod 彼此之間發(fā)送網(wǎng)絡數(shù)據(jù) 包時，它們都會將對方的實際 IP 地址看作數(shù)據(jù)包中的源 IP。
因此， pod 之間的通信其實是非常簡單的。 不論是將兩個 pod 安排在單一的還 是不同的工作節(jié)點上，同時不管實際節(jié)點間的網(wǎng)絡拓撲結(jié)構(gòu)如何，這些 pod 內(nèi)的容 器都能夠像在無 NAT 的平坦網(wǎng)絡中一樣相互通信，就像局域網(wǎng) CLAN)上的計算機 一樣。 此時，每個 pod 都有自己的 IP 地址，并且可以通過這個專門的網(wǎng)絡實現(xiàn) pod 之間互相訪問。這個專門的網(wǎng)絡通常是由額外的軟件基于真實鏈路實現(xiàn)的。
總結(jié)本節(jié)涵蓋的內(nèi)容： pod 是邏輯主機，其行為與非容器世界中的物理主機或 虛擬機非常相似。此外，運行在同一個 pod 中的進程與運行在同一物理機或虛擬機 上的進程相似，只是每個進程都封裝在一個容器之中。
3.1.3 通過 pod 合理管理容器
將 pod 視為獨立的機器，其中每個機器只托管一個特定的應用。過去我們習慣 于將各種應用程序塞進同一臺主機，但是 pod 不是這么干的。 由于 pod 比較輕量， 我們可以在幾乎不導致任何額外開銷的前提下?lián)碛斜M可能多的 pod。與將所有內(nèi)容 填充到一個 pod 中不同，我們應該將應用程序組織到多個 pod 中，而每個 pod 只包 含緊密相關(guān)的組件或進程。說到這里，對于一個由前端應用服務器和后端數(shù)據(jù)庫組成的多層應用程序，你 認為應該將其配置為單個 pod 還是兩個 pod 呢？下面我們將對該問題做進一步探討。
將多層應用分散到多個 pod 中
雖然我們可以在單個 pod 中同時運行前端服務器和數(shù)據(jù)庫這兩個容器，但這種 方式并不值得推薦。 前面我們已經(jīng)討論過，同－ pod 的所有容器總是運行在一起， 但對于 Web 服務器和數(shù)據(jù)庫來說，它們真的需要在同一臺計算機上運行嗎？答案顯 然是否定的，它們不應該被放到同一個 pod 中 。 那假如你非要把它們放在一起，有錯嗎？某種程度上來說，是的。
如果前端和后端都在同一個容器中，那么兩者將始終在同－臺計算機上運行。 如果你有一個雙節(jié)點 Kubemetes 集群， 而只有一個單獨的 pod，那么你將始終只會 用一個工作節(jié)點，而不會充分利用第二個節(jié)點上的計算資源(CPU 和內(nèi)存)。 因此 更合理的做法是將 pod 拆分到兩個工作節(jié)點上，允許 Kubemetes 將前端安排到一個 節(jié)點，將后端安排到另一個節(jié)點，從而提高基礎(chǔ)架構(gòu)的利用率。
另一個不應該將應用程序都放到單一pod 中的原因就是擴縮容。 pod 也是擴縮 容的基本單位，對于 Kubemetes 來說，它不能橫向擴縮單個容器，只能擴縮整個 pod。這意味著如果你的 pod 由一個前端和一個后端容器組成，那么當你擴大 pod 的 實例數(shù)量時，比如擴大為兩個， 最終會得到兩個前端容器和兩個后端容器。
通常來說，前端組件與后端組件具有完全不同的擴縮容需求，所以我們傾向于 分別獨立地擴縮它們。 更不用說，像數(shù)據(jù)庫這樣的后端服務器，通常比無狀態(tài)的前 端 web 服務器更難擴展。 因此，如果你需要單獨擴縮容器，那么這個容器很明確地 應該被部署在單獨的 pod 中。
何時在 pod 中使用多個容器
將多個容器添加到單個 pod 的主要原因是應用可能由一個主進程和一個或多個 輔助進程組成，如圖 3.3 所示。
例如， pod 中的主容器可以是一個僅僅服務于某個目錄中的文件的 Web 服務 器，而另 一個容器(所謂的 sidecar 容器) 則定期從夕陽H源下載 內(nèi) 容并將其存儲在 Web 服務器目錄中。在第 6 章中，我們將看到在這種情況下需要使用 Kubemetes Volume，并將其掛載到兩個容器中 。
sidecar 容器的其他例子包括日志輪轉(zhuǎn)器和收集器、數(shù)據(jù)處理器、通信適配器等。
決定何時在 pod 中使用多個容器
回顧一下容器應該如何分組到 pod 中 ： 當決定是將兩個容器放入一個 pod 還是 兩個單獨的 pod 時，我們需要問自己以下問題：
它們需要一起運行還是可以在不同的主機上運行？
它們代表的是一個整體還是相互獨立的組件？
它們必須一起進行擴縮容還是可以分別進行？
基本上，我們總是應該傾向于在單獨的 pod 中運行容器，除非有特定的原因要 求它們是同一pod 的一部分。 圖 3.4 將有助于我們記憶這一點。
盡管 pod 可以包含多個容器，但為了保持現(xiàn)在的簡單性， 本章將僅討論單容器 pod 有關(guān)的問題。 稍后我們將在第 6 章看到如何在一個 pod 中使用多個容器。
3.2 以YAML或JSON描i主文件創(chuàng)建pod
pod 和其他 Kubemetes 資源通常是通過向 Kubemetes REST API 提供 JSON 或 YAML 描述文件來創(chuàng)建的。 此外還有其他更簡單的創(chuàng)建資源的方法， 比如在前一章中使用的 kubectl run 命令，但這些方法通常只允許你配置一組有限的屬性。 另外， 通過 YAML 文件定義所有的 Kubemetes 對象之后，還可以將它們存儲在版本控制系 統(tǒng)中，充分利用版本控制所帶來的便利性。
因此，為了配置每種類型資源的各種屬性，我們 需要了解并理解 Kubemetes API 對象定義。 通過本書學習各種資源類型 時，我們將會了解其中的大部分內(nèi) 容。 需要注意的是，我們并不會解釋每二個獨立屬性，因此在創(chuàng)建對象時還應參考 http://kubernetes.io/ docs/reference 中的 Kubernetes API 參考文檔。
3.2.1 檢查現(xiàn)有 pod 的 YAML 描述文件
假設我們己經(jīng)在上一章中創(chuàng)建了一些 pod， 接下來就來看看這些 pod 的 YAML 文件是如何定義的。我們將使用帶有 -o yaml 選項的 kubectl get 命令來獲取 pod 的整個 YAML 定義，正如下面的代碼清單所示。
上述代碼清單的內(nèi)容看上去較為復雜，但一旦我們理解了基礎(chǔ)知識并知道如何區(qū)分重要部分和細枝末節(jié)時，它就變得非常簡單。此外，稍后我們將看到， 當創(chuàng)建 一個新的 pod 時， 需要寫的 YAML 相對來說則要短得多。
介紹 pod 定義的主要部分
pod 定義由這么幾個部分組成 ： 首先是 YAML中使用的 Kubernetes API 版本和 YAML 描述的資源類型；其次是幾乎在所有 Kubemetes 資源中都可以找到的三大重 要部分 ：
metadata 包括名稱、命名空間、標簽和關(guān)于該容器的其他信息。
spec 包含 pod 內(nèi)容的實際說明， 例如 pod 的容器、卷和其他數(shù)據(jù)。
status 包含運行中的 pod 的當前信息，例如 pod 所處的條件、 每個容器的描述和狀態(tài)，以及內(nèi)部 IP 和其他基本信息。
代碼清單 3.1 展示了一個正在運行的 pod 的完整描述，其中包含了它的狀態(tài)。 status 部分包含只讀的運行時數(shù)據(jù)，該數(shù)據(jù)展示了給定時刻的資源狀態(tài)。而在創(chuàng) 建新的 pod 時，永遠不需要提供 status 部分。 上述三部分展示了 Kubemetes API 對象的典型結(jié)構(gòu)。正如你將在整本書中看到 的那樣，其他對象也都具有相同的結(jié)構(gòu)，這使得理解新對象相對來說更加容易 。 對上述 YAML 中的每個屬性進行深究的意義并不大，因此接下來我們將關(guān)注如 何創(chuàng)建 pod 的最基本的 YAML。
3.2.2 為 pod 創(chuàng)建一個簡單的 YAML 描述文件
我們將創(chuàng)建一個名為 kubia-manual.yaml 的文件(可以在任意目錄下創(chuàng)建該文 件)，或者下載本書的代碼檔案文件，然后在 Chapter03 文件夾中找到該文件。下面 的清單展示了該文件的全部內(nèi)容。
很明顯，我們能夠感受到該代碼清單比代碼清單 3.1 中的定義要簡單得多。接 下來我們就對整個描述文件進行深入探討，該文件遵循 Kubernetes API 的 vl 版本。 我們描述的資源類型是 pod，名稱為 kubia-manual ： 該 pod 由基于 luksa/kubia 鏡像的單個容器組成。此外我們還給該容器命名，并表示它正在監(jiān)昕 8080 端口。
指定容器端口
在pod定義部分指定端口的行為純粹是展示性的(informational)。忽略它們對于客戶端是 否可以通過端口連接到 pod 不會帶來任何影響。如果容器通過綁定到地址 0.0.0.0 的端口接收連接，那么即使端口未明確列出在 pod spec 中， 其他 pod 也依舊能夠連接 到該端口 。 但明確定義端口仍是有意義的，在端口定義下，每個使用集群的人都可 以快速查看每個 pod 對外暴露的端口 。 此外， 我們將在本書的后續(xù)內(nèi)容中看到，明 確定義端口還允許你為每個端口指定一個名稱，這樣一來更加方便我們使用。
使用 kubectl explain 來發(fā)現(xiàn)可能的 API 對象字段
在準備 manifest 時，可以轉(zhuǎn)到 http://kubemetes.io/docs/api 上的 Kubemetes 參考文檔查看每個 API 對象支持哪些屬性，也可以使用 kubectl explain 命 令。 例如，當從頭創(chuàng)建一個 pod manifest 時，可以從請求 kubectl 來解釋 pod 開始：
Kubectl 打印出對象的解釋并列出對象可以包含的屬性，接下來就可以深入 了解各個屬性的更多信息。 例如，可以這樣查看 spec 屬性 ：
3.2.3 使用 kubectl create 來創(chuàng)建 pod
我們使用 kubectl create 命令從 YAML 文件創(chuàng)建 pod:
#kubectl create -f kubia-manual.yaml
pod/kubia-manual created
kubectl create - f 命令用于從 YAML 或 ISON 文件創(chuàng)建任何資源(不只 是 pod)。
得到運行中 pod 的完整定義
pod 創(chuàng)建完成后，可以請求kubernetes來獲取完整的YAML，可以看到它與我們之前看到的YAML文件非常相似。在下一節(jié)中我們將了解返回定義中出現(xiàn)的其他字段，接下來就直接使用以下命令來查看該pod的完整描述文件：
#kubectl get pod kubia-manual -o yaml
也可以讓 kubectl 返回 JSON 格式而不是 YAML 格式(顯然，即使你使用 YAML創(chuàng)建 pod，同樣也可以獲取 JSON 格式的描述文件〉 ：
#kubectl get pod kubia-manual -o json
在 pod 列表中查看新創(chuàng)建的 pod
創(chuàng)建好 pod 之后，如何知道它是否正在運行？ 此時可以列出 pod 來查看它們的 狀態(tài)：
這里可 以看到 kubia-manual 這個 pod， 狀態(tài)顯示它正在運行。 有可能你像筆 者一樣想要通過與 pod 的實際通信來確認其正在運行， 但該方法將在之后進行討論。 現(xiàn)在我們先查看應用的日志來檢查是否存在錯誤。
3.2.4 查看應用程序日志
小型 Node.js 應用將日志記錄到進程的標準輸出。容器化的應用程序通常會將 日志記錄到標準輸出和標準錯誤流，而不是將其寫入文件，這就允許用戶可以通過 簡單、標準的方式查看不同應用程序的日志。
容器運行時(在我們的例子中為 Docker)將這些流重定向到文件，并允許我們 運行以下命令來獲取容器的日志：
# docker logs
使用 ssh 命令登錄至lj pod 正在運行的節(jié)點，并使用 docker logs 命令查看其 日志，但 Kubernetes 提供了一種更為簡單的方法。
使用 kubectl logs 命令獲取 pod 日志
為了查看 pod 的日志(更準確地說是容器的日志)，只需要在本地機器上運行 以下命令(不需要 ssh 到任何地方) ：
在我們向 Node.js 應用程序發(fā)送任何 Web 請求之前，日志只顯示一條關(guān)于服 務器啟動的語句。正如我們所見，如果該 pod 只包含一個容器，那么查看這種在 Kubernetes 中運行的應用程序的日志則非常簡單。
注意每天或者每次日志文件達到 10MB 大小時， 容器 日志都會自動輪替。 kubectl logs 命令僅顯示最后一次輪替后的 日志條目 。
獲取多容器 pod 的日志時指定容器名稱
如果我們的 pod 包含多個容器，在運行 kubectl logs 命令時則必須通過包 含 -c ＜容器名稱＞選項來顯式指定容器名稱。在 kubia-manual pod 中，我們將 容器的名稱設置為 kubia，所以如果該 pod 中有其他容器，可以通過如下命令獲取其日志 ：
這里需要注意的是，我們只能獲取仍然存在的 pod 的日 志。 當一個 pod 被刪除時， 它的日志也會被刪除。如果希望在 pod 刪除之后仍然可以獲取其日志，我們需要設 置中心化的、 集群范圍的日志系統(tǒng)，將所有日志存儲到中心存儲中。在第 17 章中 我們將會解釋如何設置集中的日志系統(tǒng)。
3.2.5 向 pod 發(fā)送請求
通過kubectl get和kubectl logs命令顯示該pod正在運行，但我們?nèi)绾卧趯嶋H操作中看到該狀態(tài)呢？在前一章中，我們使用 kubectl expose 命令創(chuàng)建了一 個 service，以便在外部訪問該 pod。 由于有一整章專 門介紹 service，因此本章并不 打算使用該方法。 此外，還有其他連接到 pod 以進行測試和調(diào)試的方法，其中之一 便是通過端 口轉(zhuǎn)發(fā)。
將本地網(wǎng)絡端口轉(zhuǎn)發(fā)歪lj pod 中的端口
如果想要在不通過 service 的情況下與某個特定的 pod 進行通信 ( 出于調(diào)試或 其他原因),?Kubemetes 將允許我們配置端口轉(zhuǎn)發(fā)到該 pod。 可以通過 kubectl port-forward 命令完成上述操作。
用法是：?kubectl port-forward pod名 代理端口:pod端口
例如以下命令會將機器的本地端口 8888 轉(zhuǎn)發(fā) 到我們的 kubia- manual pod 的端口 8080 :
此時端口轉(zhuǎn)發(fā)正在運行，可以通過本地端口連接到我們的 pod。
通過端口轉(zhuǎn)發(fā)連接到 pod
在另一個終端中，可以使用 curl 命令向 pod 發(fā)送一個 HTTP 請求：(通過運行在 localhost:8888 上的 kubectl port-forward 代理)
圖 3.5 展示了發(fā)送請求時的簡化視圖。實際上， kubectl 進程和 pod 之間還有 一些額外的組件，但現(xiàn)在暫時不關(guān)注它們。
像這樣使用端口轉(zhuǎn)發(fā)是一種測試特定 pod 的有效方法，而我們也將在這本書中 學習其他類似的方法。
3.3 使用標簽組織pod
此時我們的集群中只有兩個正在運行的pod。但部署實際應用程序時，大多數(shù)用戶最終將運行更多的pod。隨著pod數(shù)量的增加，將它們分類到子集的需求也就變得越來越明顯了。
例如，對于微服務架構(gòu)，部署的微服務數(shù)量可以輕松超過20個甚至更多。這些組件可能是副本(部署同一組件的多個副本)和多個不同的發(fā)布版本?(stable、 beta、 canary 等)同時運行。這樣一來可能會導致我們在系統(tǒng)中擁有數(shù)百個 pod， 如 果沒有可 以有效組織這些組件的機制， 將會導致產(chǎn)生巨大的混亂， 如圖 3.6 所示。 該圖展示了多個微服務的 pod， 包括一些運行多副本集，以及其他運行于同一微服 務中的不同版本。
很明顯，我們需要一種能夠基于任意標準將上述 pod 組織成更小群體的方式， 這樣一來處理系統(tǒng)的每個開發(fā)人員和系統(tǒng)管理員都可以輕松地看到哪個 pod 是什么。 此外，我們希望通過一次操作對屬于某個組的所有 pod 進行操作，而不必單獨為每 個 pod 執(zhí)行操作。
那就是通過標簽來組織 pod 和所有其他 Kubemetes 對象。
3.3.1 介紹標簽
標簽是一種簡單卻功能強大的 Kubemetes 特性，不僅可以組織 pod，也可以組 織所有其他的 Kubemetes 資源。詳細來講， 標簽是可以附加到資源的任意鍵值對，用以選擇具有該確切標簽的資源(這是通過標簽選擇器完成的)。 只要標簽的 key 在 資源內(nèi)是唯一的， 一個資源便可以擁有多個標簽。 通常在我們創(chuàng)建資源時就會將標 簽附加到資源上，但之后我們也可以再添加其他標簽，或者修改現(xiàn)有標簽的值，而 無須重新創(chuàng)建資源。
接下來回到圖 3.6 中的微服務示例。 通過給這些 pod 添加標簽，可以得到一個 更組織化的系統(tǒng)， 以便我們理解。 此時每個 pod 都標有兩個標簽 ：
app，它指定 pod 屬于哪個應用、組件或微服務。
rel， 它顯示在 pod 中運行的應用程序版本是 stable、 beta 還是 canary。
定義 金絲在發(fā)布是指在吾l~署新版本時，先只讓一小部分用戶體驗新版本以觀察 新版本的表現(xiàn)， 然后再向所有用戶進行推廣，這樣可以防止暴露有問題的版本給過 多的用戶 。
如圖 3.7 所示，通過添加這兩個標簽基本上可以將 pod 組織為兩個維度(基于 應用的橫向維度和基于版本的縱向維度)。
每個可以訪問集群的開發(fā)或運維人員都可以通過查看 pod 標簽輕松看到系統(tǒng)的 結(jié)構(gòu)，以及每個 pod 的角色。
3.3.2 創(chuàng)建 pod 時指定標簽
現(xiàn)在，可以通過創(chuàng)建一個帶有兩個標簽的新 pod 來查看標簽的實際應用。使用 以下代碼清單中的內(nèi)容創(chuàng)建一個名為 kubia-manual-with-labels.yaml 的新文件。
metadata.labels 部分己經(jīng)包含了 creation method=manual 和 env=prod 標簽。 現(xiàn)在來創(chuàng)建該 pod:
kubectl get pods 命令默認不會列出任何標簽，但我們可以使用 --show-labels 選項來查看 ：
如果你只對某些標簽感興趣，可以使用 L 選項指定它們并將它們分別顯示在 自己的列中，而不是列出所有標簽。 接下來我們再次列出所有 pod，并將附加到 pod kubia-manual-v2 上的兩個標簽的列展示如下：
3.3.3 修改現(xiàn)有 pod 的標簽
標簽也可以在現(xiàn)有 pod 上進行添加和修改。 由于 pod kubia -manual 也是手動 創(chuàng)建的，所以為其添加 creation method=manual 標簽 ：
現(xiàn)在，將 kubia- manual- v2 pod 上的 env=prod 標簽更改為 env=debug, 以演示現(xiàn)有標簽也可以被更改。
注意 在更改現(xiàn)有標簽時 ，需要使用 --overwrite 選項
再次列出 pod 以查看更新后的標簽：
正如我們所看到，目前將標簽附加到資源上看起來并沒有什么價值，在現(xiàn)有資 源上更改標簽也是如此。 但在下一章中我們將證實，這會是一項令人難以置信的強 大功能。 而首先我們需要看看這些標簽除了在列出 pod 時用以簡單顯示外， 還可以 用來做什么。
閱讀本章之后，你應該對 Kubemetes 的核心模塊有了系統(tǒng)的了解。 在接下來的 幾章中學到的概念也都與 pod 有著直接關(guān)聯(lián)。
在本章中，你應該已經(jīng)掌握 ： ·
如何決定是否應將某些容器組合在一個 pod 中。
pod 可以運行多個進程，這和非容器世界中的物理主機類似。
可以編寫 YAML 或 JSON 描述文件用于創(chuàng)建 pod， 然后查看 pod 的規(guī)格及其 當前狀態(tài)。
使用標簽來組織 pod，并且一次在多個 pod 上執(zhí)行操作。
可以使用節(jié)點標簽將 pod 只調(diào)度到提供某些指定特性的節(jié)點上。
注解允許人們、工具或庫將更大的數(shù)據(jù)塊附加到 pod。
命名空間可用于允許不同團隊使用同 一 集群，就像它們使用單獨的 Kubemetes 集群一樣。
使用 kubectl explain 命令快速查看任何 Kubernetes 資源的信息。
創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎勵來咯，堅持創(chuàng)作打卡瓜分現(xiàn)金大獎總結(jié)
以上是生活随笔為你收集整理的k8s pod内部容器_第三章 pod：运行于kubernetes中的容器的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： java jstack 工具_java命
- 下一篇： Pytorch出现RuntimeErro