（注：本文**自阿里巴巴雲原生課堂理解 pod 和容器設計模式）
在基本了解什麼是pod的基礎上，詳細介紹一下 kubernetes 非常提倡的乙個概念，叫做容器設計模式。
接下來將會用乙個例子來給大家進行講解。
但是這時會發現乙個問題：這種做法一定需要維護一套分布式儲存系統。因為這個容器可能第一次啟動是在宿主機 a 上面，第二次重新啟動就可能跑到 b 上去了，容器它是乙個可遷移的東西，它的狀態是不保持的。所以必須維護一套分布式儲存系統，使容器不管是在 a 還是在 b 上，都可以找到這個 war 包，找到這個資料。
這樣操作帶來的複雜程度還是比較高的，且這個容器本身必須依賴於一套持久化的儲存外掛程式（用來管理 volume 裡的 war 包內容）。
在 kubernetes 裡面，像這樣的組合方式，叫做 init container。
還是同樣乙個例子：在上圖的 yaml 裡，首先定義乙個 init container，它只做一件事情，就是把 war 包從映象裡拷貝到乙個 volume 裡面，它做完這個操作就退出了，所以 init container 會比使用者容器先啟動，並且嚴格按照定義順序來依次執行。
而這個時候，由於前面已經執行過了乙個 init container，已經執行完拷貝操作了，所以這個 volume 裡面已經存在了應用的 war 包：就是 sample.war。等到第二步執行啟動這個 tomcat 容器的時候，去掛這個 volume，一定能在裡面找到前面拷貝來的 sample.war。
像上面這樣的做法，在 kubernetes 裡面就是乙個非常經典的容器設計模式，叫做：「sidecar」。
什麼是 sidecar？就是說在 pod 裡面，可以定義一些專門的容器，來執行主業務容器所需要的一些輔助工作，比如我們前面舉的例子，其實就幹了乙個事兒，這個 init container，它就是乙個 sidecar，它只負責把映象裡的 war 包拷貝到共享目錄裡面，以便被 tomcat 能夠用起來。回顧xx中的infra container，不就是乙個init container嗎？
其它有哪些操作呢？比如說：
這種做法乙個非常明顯的優勢就是將輔助功能從業務容器解耦了，所以能夠獨立發布 sidecar 容器，並且更重要的是這個能力是可以重用的。事實上，任何設計模式的優勢歸結起來不就是解耦和復用嗎！
下面介紹 sidecar 設計模式的幾種常用場景。
業務容器將日誌寫在乙個 volume 裡面，而由於 volume 在 pod 裡面是被共享的，所以日誌容器 —— 即 sidecar 容器一定可以通過共享該 volume，直接把日誌檔案讀出來，然後存到遠端儲存裡面，或者**到其他容器。現在業界常用的 fluentd 日誌程序或日誌元件，基本上都是這樣的工作方式。
假如現在有個 pod 需要訪問乙個外部系統，或者一些外部服務，但是這些外部系統是乙個集群，那麼這個時候如何通過乙個統一的、簡單的方式，用乙個 ip 位址，就把這些集群都訪問到呢？這個時候，就可以通過 sidecar **容器。
現在業務暴露出來的 api，比如說有個 api 的乙個格式是 a，但是現在有乙個外部系統要去訪問我的業務容器，它只知道的一種格式是 api b ,所以要做乙個工作，就是把業務容器怎麼想辦法改掉，要去改業務**。但實際上，你可以通過乙個 adapter 幫你來做這層轉換。
現在有個例子：原先業務容器暴露出來的監控介面是 /metrics，可是現在，這個監控系統公升級了，它訪問的 url 是 /health，新系統只認得暴露出 /health 的 url，才能去做監控，/metrics 不認識。那這個怎麼辦？那就需要改**了，但可以不去改**，而是額外寫乙個 adapter，用來把所有對 /health 的這個請求**給 /metrics 就可以了，所以這個 adapter 對外暴露的是 /health 這樣乙個監控的 url，這就可以了，你的業務就又可以工作了。
本文主要講解的就是容器的設計模式：sidecar。sidecar 模式（或者說sidecar容器）的主要作用就是把業務容器與非業務容器解耦，使得應用的打包、發布工作能夠更加user-friendly。在定義pod的yaml檔案中，我們可以設定相應的initcontainer字段，這就是所謂的sidecar容器，它總是比其他應用容器先啟動。
本文還介紹了幾種常見的使用sidecar設計模式的場景，比如日誌的收集、做**、適配等等。
設計模式詳解 設計模式簡介
乙個模式應該包括的方面 模式的名稱 模式的目的 模式的實現 模式的約束 為什麼要學習設計模式？1.利用解決方案 2.建立通用術語，方便交流 3.對於問題，設計過程和物件導向，模式給你乙個更高層次的視角，這樣的視角將你從過早處理細節中解放出來。4.即使你不使用直接設計模式，避免龐大的繼承體系也會導致改...
詳解設計模式 外觀模式
外觀模式 facade 為子系統中的一組介面提供乙個一致的介面，facade 模式定義了乙個高層介面，這個介面使得這一子系統更加容易使用。隱藏系統的複雜性，並向客戶端提供了乙個客戶端可以訪問系統的介面。降低訪問複雜系統的內部子系統時的複雜度。類圖 在客戶端和複雜系統之間再加一層，將呼叫順序 依賴關係...
設計模式 Builder模式詳解
builder模式也叫做建造者模式,是設計模式的一種,就是將複雜物件的建立變得簡單明瞭,使物件與他的表示進行分離,使得同樣的建立過程,可以建立不同的物件.我們這裡講變種 builder模式 更加簡單,明了 並非真正意義上的builder模式 這種模式的目的用於簡化 不可變 物件的構造 比如 goog...