Kubernetes 已成為雲原生應用佈署的標準平台，但有效運用其功能構建高效系統仍是挑戰。本文旨在幫助開發者掌握 Kubernetes 設計模式，從而構建更可靠、可擴充套件的雲原生應用。本文並非 Kubernetes 入門或操作手冊，而是聚焦於設計模式的應用，涵蓋基礎模式、行為模式、結構模式、組態模式、安全模式和進階模式等六大部分。每個模式都包含名稱、問題、解決方案、討論和更多資訊等環節，並提供可執行的示例程式碼。本文適合具備 Kubernetes 基礎知識的開發者，也對架構師和其他技術人員有參考價值。第二版新增了安全模式相關章節，並更新了 Kubernetes 1.26 的新功能，同時擴充套件了示例程式碼和內容。
Kubernetes 設計模式：雲原生應用的可重用元素
Kubernetes 已成為現代雲原生應用開發的基礎，其重要性不言而喻。作為容器協調平台的佼佼者，Kubernetes 不僅提供了強大的自動化佈署、擴充套件和管理功能，更為開發者們開啟了一扇通往高效、可靠系統的大門。然而，隨著 Kubernetes 的普及，如何有效地利用其強大的功能，設計出符合業務需求的系統架構，成為了許多開發者和架構師面臨的挑戰。
為何 Kubernetes 設計模式至關重要
在 Kubernetes 的世界裡，設計模式扮演著至關重要的角色。這些模式不僅是開發者經驗的總結，更是解決實際問題的有效工具。透過學習和應用這些設計模式，開發者可以更快速地上手 Kubernetes，更有效地構建出可靠、可擴充套件的雲原生應用。
本文的目的與架構
本文旨在幫助開發者深入瞭解 Kubernetes 的核心概念，並掌握最常見的雲原生應用設計模式。全書圍繞著 Kubernetes 和設計模式兩大主題展開，首先對 Kubernetes 的起源、發展以及其在現代應用開發中的角色進行了詳細介紹。接著，本文探討了多種實用的設計模式，並結合實際案例進行了深入淺出的分析。
Kubernetes 的起源與發展
Kubernetes 的誕生源自 Google 內部的容器協調平台 Borg。多年的實踐經驗讓 Google 決定將 Borg 的經驗開源，形成了後來的 Kubernetes。如今，Kubernetes 已成為 GitHub 上最受歡迎的專案之一，其強大的功能和靈活性使其成為許多 Platform-as-a-Service 系統的基礎，例如 Red Hat OpenShift。
設計模式的重要性
正如 Brendan Burns 在序言中所說，Kubernetes 的目標是讓分散式系統的開發變得像電腦科學 101 一樣簡單。而本文正是實作這一目標的重要工具。透過對 Kubernetes 核心工具和概念的深入講解，本文幫助讀者瞭解如何利用這些工具構建出符合業務需求的系統。
內容解密：
本文的重點在於介紹 Kubernetes 的設計模式及其在雲原生應用開發中的實踐。透過對 Kubernetes 起源、發展以及設計模式的深入分析，本文為讀者提供了一條清晰的學習路徑，使其能夠更好地理解和應用 Kubernetes。無論是對於初學者還是有經驗的開發者，本文都具有重要的參考價值。
Kubernetes 設計模式導論
Kubernetes 作為現代雲端原生應用的基礎架構，其設計模式對於開發者與維運人員至關重要。本文假設讀者具備一定的 Kubernetes 基礎知識，並在第一章中回顧了 Kubernetes 的核心概念，為後續章節奠定了基礎。
設計模式的概念起源
簡而言之，設計模式描述了一個可重複使用的解決方案，用於解決特定問題。這一定義同樣適用於本文所描述的模式，不同之處在於我們的解決方案變異性相對較小。設計模式與配方不同，它不提供逐步的解決方案，而是提供一個藍圖，用於解決一類別相似的問題。例如，Alexandrian 模式中的「Beer Hall」描述瞭如何建造公共飲酒廳，讓「陌生人和朋友成為飲酒夥伴」而非「孤獨的錨點」。所有按照此模式建造的大廳看起來各不相同，但分享共同的特徵，如開放的壁龕可容納四到八人，以及一個可供百人聚會享用飲品、音樂和其他活動的場所。
設計模式的作用
然而，設計模式的作用不僅僅是提供解決方案，它還關乎形成一種語言。本文中的模式形成了一種密集、以名詞為中心的語言，其中每個模式都帶有獨特的名稱。當這種語言建立後，這些名稱會自動喚起人們相似的心理表徵。例如，當我們談論「table」時，任何說英語的人都會假設我們指的是由四條腿和一個桌面組成的木製傢俱，你可以在上面放置物品。同樣，在軟體工程領域，當討論到「factory」時，在物件導向程式語言的上下文中，我們會立即聯想到一個用於生產其他物件的物件。因為我們立即理解了模式背後的解決方案，所以可以繼續解決尚未解決的問題。
本文的結構安排
本文採用了一種簡單的模式格式來描述每個設計模式，包括以下幾個部分：
名稱：每個模式都有一個名稱，這也是章節的標題。名稱是模式語言的核心。
問題：本部分詳細描述了模式所要解決的問題空間。
解決方案：本部分展示瞭如何在 Kubernetes 環境中應用該模式來解決問題。同時，也包含了與其他相關或從屬模式的交叉參照。
討論：本部分討論瞭解決方案在特定上下文中的優缺點。
更多資訊：本部分提供了與該模式相關的其他資訊來源。
本文的組織方式
本文共分為六個部分：
第一部分，「基礎模式」，涵蓋了 Kubernetes 的核心概念，這些是構建根據容器的雲端原生應用的基礎原則和實踐。
第二部分，「行為模式」，描述了建立在基礎模式之上的執行時方面概念，用於管理不同型別的容器。
第三部分，「結構模式」，包含了與 Pod 內部容器組織相關的模式，Pod 是 Kubernetes 平台的基本單位。
第四部分，「組態模式」，探討了在 Kubernetes 中處理應用程式組態的各種方式。這些是粒度較細的模式，包括將應用程式連線到其組態的具體方法。
第五部分，「安全模式」，解決了將應用程式容器化和佈署到 Kubernetes 上時出現的各種安全問題。
第六部分，「進階模式」，收集了一些進階概念，例如何擴充套件平台本身，或如何在叢集內直接建置容器映像。
每個模式章節都是獨立的，讀者可以按任意順序閱讀各章節。根據上下文，同一個模式可能適用於多個類別。
本文讀者物件
本文主要針對希望設計和開發雲原生應用程式，並使用Kubernetes作為平台的開發者。最適合那些對容器和Kubernetes概念有基本瞭解，並希望進一步提升技能的讀者。然而，您無需瞭解Kubernetes的底層細節即可理解本文中的使用案例和模式。架構師、顧問和其他技術人員也將受益於本文中描述的可重複使用的模式。
本文根據真實專案中的使用案例和經驗教訓，匯集了多年來在該領域工作的最佳實踐和模式。我們的目標是幫助您理解以Kubernetes為先的思維方式，並建立更好的雲原生應用程式，而不是重新發明輪子。本文採用輕鬆的寫作風格，類別似於一系列可以獨立閱讀的散文。
本文不是什麼
讓我們簡要看看本文不是什麼：
- 本文不是一步一步地指導如何設定Kubernetes叢集本身。每個示例都假設您已經安裝並執行了Kubernetes。您可以透過多種方式嘗試示例。如果您對如何設定Kubernetes叢集感興趣，我們推薦Brendan Burns、Joe Beda、Kelsey Hightower和Lachlan Evenson的《Kubernetes: Up and Running》（O’Reilly）。
- 本文不是關於為其他團隊操作和管理Kubernetes叢集。我們刻意跳過了Kubernetes的管理和操作方面，並採取了開發者優先的視角。本文可以幫助維運團隊瞭解開發者如何使用Kubernetes，但它不足以用於管理和自動化Kubernetes叢集。如果您對如何操作Kubernetes叢集感興趣，我們推薦Brendan Burns、Eddie Villalba、Dave Strebel和Lachlan Evenson的《Kubernetes Best Practices》（O’Reilly）。
您將學到什麼
本文中有很多值得探索的內容。有些模式乍一看似乎像是摘自Kubernetes手冊，但仔細觀察後，您會發現這些模式是從概念角度出發的，這在其他書籍中是找不到的。其他模式則透過詳細步驟來解決具體問題，如第IV部分“組態模式”。在某些章節中，我們解釋了不符合模式定義的Kubernetes功能。不要糾結於它是否是模式或功能。在所有章節中，我們從第一原理出發，關注使用案例、經驗教訓和最佳實踐。這才是真正有價值的部分。
無論模式粒度如何，您將學習到Kubernetes為每個特定模式提供的所有內容，並附有豐富的示例來說明這些概念。所有這些示例都經過測試，我們會告訴您如何在“使用程式碼示例”中取得完整的原始碼。
第二版的新內容
自第一版出版以來，Kubernetes生態系統在過去四年中不斷增長。因此，已經有了許多Kubernetes版本，並且更多使用Kubernetes的工具和模式已經成為事實上的標準。
幸運的是，本文中描述的大多數模式經受住了時間的考驗，仍然有效。因此，我們更新了這些模式，增加了直到Kubernetes 1.26的新功能，並刪除了過時和棄用的部分。在大多數情況下，只需要進行微小的更改，除了第29章“彈性擴充套件”和第30章“映像構建器”，由於這些領域的新發展，這兩章經歷了重大更改。
此外，我們新增了五個新模式，並引入了一個新的類別，第V部分“安全模式”，該部分填補了第一版的空白，為開發者提供了重要的安全相關模式。
我們的GitHub示例已經更新和擴充套件。最後，我們為讀者增加了50%的內容。
本文使用的慣例
本文中使用了以下排版慣例：
- 斜體：表示新術語、URL、電子郵件地址、檔名和副檔名。
等寬字型：用於程式清單，以及在段落中參照程式元素，如變數或函式名稱、資料函式庫、資料型別、環境變數、陳述式和關鍵字。
正如前面提到的，模式形成了一種簡單、相互連線的語言。為了強調這種模式網路，每個模式都以大寫字母和斜體顯示（例如，Sidecar）。當模式名稱也是Kubernetes核心概念（例如_Init Container_或_Controller_）時，我們僅在直接參照模式本身時使用這種特定的格式。在有意義的地方，我們也會相互連結模式章節，以便於導航。
我們還使用以下慣例：
- 所有可以在shell或編輯器中輸入的內容都以等寬字型顯示。
- Kubernetes資源名稱始終以大寫字母顯示（例如，Pod）。如果資源是組合名稱，如ConfigMap，我們保持原樣，以利於更自然的“組態對映”，並明確表示它指的是Kubernetes概念。
- 有時，Kubernetes資源名稱與常見概念（如“服務”或“節點”）相同。在這些情況下，我們僅在參照資源本身時使用資源名稱格式。
提示
此元素表示提示或建議。
注意
此元素表示一般性註解。
警告
此元素表示警告或注意事項。
使用程式碼示例
每個模式都有完全可執行的示例，您可以在隨附的網頁上找到。您可以在每個章節的“更多資訊”部分找到每個模式示例的連結。
“更多資訊”部分還包含與該模式相關的其他資訊的連結。我們在示例儲存函式庫中保持這些列表更新。
本文中所有示例的原始碼都可在GitHub上獲得。儲存函式庫和網站還提供了有關如何取得Kubernetes叢集以嘗試示例的指標和說明。請檢視提供的資訊。
Kubernetes 模式第二版相關資源與致謝說明
在探討 Kubernetes 模式第二版的內容時，資原始檔扮演著至關重要的角色。這些檔案包含了豐富的註解，能夠進一步加深讀者對範例程式碼的理解。
範例程式碼與資源
許多範例使用了一個名為 random-generator 的 REST 服務，該服務在被呼叫時傳回亂數。此服務專門為本文中的範例設計，其原始碼同樣可在 GitHub 上找到，而其容器映像 k8spatterns/random-generator 則託管在 Docker Hub 上。
在描述資源欄位時，本文採用 JSON 路徑表示法（例如，.spec.replicas 指向資源 spec 區段中的 replicas 欄位）。
程式碼授權與貢獻
所有範例程式碼均依據創用 CC 姓名標示 4.0 (CC BY 4.0) 授權條款釋出。您可以自由使用、分享及改編這些程式碼，無論是商業還是非商業專案，但請務必對本文進行適當的標示。
若您發現範例程式碼或檔案中的問題，或有任何疑問，請在 GitHub 問題追蹤器上提出 issue。我們會密切關注這些 issue，並樂意回答任何問題。
聯絡資訊
本文的網頁上列出了勘誤表、範例及額外資訊，您可透過以下網址存取：https://oreil.ly/kubernetes_patterns-2e。
致謝
作者致謝
Bilgin 對他的妻子 Ayshe 表示永恆的感激，感謝她在他撰寫本文期間給予的無盡支援與耐心。他同樣感謝他的可愛女兒 Selin 和 Esin，她們總是能讓他展露笑容。最後，Bilgin 感謝他的優秀共同作者 Roland，讓這個專案變為現實。
Roland 對他的妻子 Tanja 在撰寫過程中給予的堅定支援與寬容表示深深的感激，並感謝他的兒子 Jakob 給予的鼓勵。此外，Roland 特別感謝 Bilgin 的卓越見解與寫作，若沒有他，本文就不可能完成。
審閱者與編輯致謝
完成本文的兩版是一個長達數年的旅程，我們在此感謝讓我們保持正確方向的審閱者們。在此特別鳴謝 Paolo Antinori 和 Andrea Tarocchi 對第一版的幫助。同時，也感謝 Marko Lukša、Brandon Philips、Michael Hüttermann、Brian Gracely、Andrew Block、Jiri Kremser、Tobias Schneck 和 Rick Wagner 等人的專業知識與建議。
對於第二版的完成，我們同樣感謝所有支援我們的人。我們要感謝技術審閱者 Ali Ok、Dávid Šimanský、Zbyněk Roubalík、Erkan Yanar、Christoph Stäbler、Andrew Block 和 Adam Kaplan，以及開發編輯 Rita Fernando，感謝她在整個過程中的耐心與鼓勵。
特別鳴謝
我們特別感謝 Abhishek Koserwal 在第 26 章「存取控制」中不懈的努力與奉獻。他的貢獻在我們最需要的時候出現，並產生了巨大的影響。
圖表說明
此圖示展示了 Kubernetes 模式相關資源與致謝說明的結構關係。
@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam rectangleBackgroundColor #F5F5F5
skinparam rectangleBorderColor #333333
skinparam arrowColor #333333
title 圖表說明
rectangle "託管於" as node1
rectangle "容器映像" as node2
rectangle "描述" as node3
rectangle "允許" as node4
rectangle "提供" as node5
rectangle "感謝" as node6
node1 --> node2
node2 --> node3
node3 --> node4
node4 --> node5
node5 --> node6
@enduml
此圖示說明
此圖示呈現了 Kubernetes 模式相關資源的主要組成部分及其相互關係，包括範例程式碼的託管位置、JSON 路徑表示法的應用，以及創用 CC 授權條款的許可範圍等。
雲原生之路：Kubernetes 與微服務架構的技術核心
在介紹雲原生應用的設計與實作時，瞭解 Kubernetes 的核心概念至關重要。本章將探討這些關鍵概念，並闡述如何利用它們來構建可自動化管理的分散式應用。這些抽象概念與相關原則和模式，將有助於開發能在 Kubernetes 上良好運作的雲原生應用。
走向雲原生：微服務架構的重要性
微服務架構是建立雲原生應用的主流架構風格之一。它透過將業務功能模組化來降低軟體複雜度，但同時也增加了維運的複雜性。因此，成功實施微服務的關鍵前提是建立能夠在 Kubernetes 上規模化運作的應用。
微服務設計的核心原則
微服務運動帶來了豐富的理論、技術和工具，用於從零開始建立微服務或將單體架構拆分為微服務。這些實踐大多根據 Eric Evans 的領域驅動設計（Domain-Driven Design），並涉及有限上下文（bounded contexts）和聚合根（aggregates）等概念。有限上下文透過將大型模型劃分為不同的元件來處理複雜性，而聚合根則進一步將有限上下文分組為具有明確事務邊界的模組。
然而，除了業務領域的考量之外，對於任何分散式系統（無論是否根據微服務），其外部結構和執行時的耦合性也是技術上需要關注的問題。容器和容器協調工具（如 Kubernetes）引入了新的原語和抽象來解決分散式應用的問題。
容器與雲原生平台的互動
在整本文中，我們將容器視為黑盒子來探討容器與平台之間的互動。然而，我們特別強調了容器內部的內容的重要性。容器和雲原生平台為分散式應用帶來了巨大的好處，但如果容器內的內容品質不佳，那麼規模化後的分散式系統也將存在問題。圖 1-1 說明瞭建立優秀雲原生應用所需的技能組合，以及 Kubernetes 模式在其中的位置。
圖 1-1：邁向雲原生的路徑
建立優秀的雲原生應用需要在多個設計技術上具有熟悉度：
乾淨程式碼的重要性：開發團隊及其建立的工件對應用的長期維護性具有最大的影響。團隊應致力於編寫乾淨程式碼、進行適當的自動化測試、不斷重構以提高程式碼品質，並遵循軟體工藝原則。
領域驅動設計：從業務角度進行軟體設計，使架構盡可能貼近現實世界。這種方法最適合導向物件的程式語言，但也有其他方法可以用於為現實世界的問題建模和設計軟體。具有正確業務和事務邊界、易於使用的介面和豐富 API 的模型，是成功進行容器化和自動化的基礎。
六角架構及其變體：透過解耦應用元件並提供標準化的介面來提高應用的靈活性和可維護性。六角架構使系統的核心業務邏輯與周圍的基礎設施解耦，從而更容易將系統移植到不同的環境或平台。
微服務架構風格和十二要素應用方法論：迅速成為建立分散式應用的規範。它們為設計不斷變化的分散式應用提供了寶貴的原則和實踐。應用這些原則可以建立出針對規模化、彈性和變化速度進行最佳化的實作，這些是現代軟體的共同需求。
容器化技術：容器已迅速被採用為封裝和執行分散式應用（無論是微服務還是函式）的標準方式。建立模組化、可重用的容器是另一個基本的前提。
雲原生原則：用於描述在大規模上自動化容器化應用的原則、模式和工具。我們使用「雲原生」來描述這些實踐和技術。
結語
本章概述了 Kubernetes 和雲原生應用的核心概念，包括微服務架構、領域驅動設計、六角架構等關鍵技術和方法。這些知識為理解後續章節中介紹的各種模式奠定了基礎，並有助於開發人員和架構師在 Kubernetes 環境中設計和實作更具彈性和可擴充套件性的分散式應用。