本文發表於一年多前。舊文章可能包含過時內容。請檢查頁面中的資訊自發布以來是否已變得不正確。
容器設計模式
Kubernetes 自動化部署、操作和擴充套件應用程式，但我們在 Kubernetes 專案中的目標不僅限於系統管理，我們還希望 Kubernetes 也能幫助開發人員。Kubernetes 應該讓他們能夠輕鬆編寫在雲和資料中心環境中執行的分散式應用程式和服務。為了實現這一目標，Kubernetes 不僅定義了管理員執行管理操作的 API，還定義了容器化應用程式與管理平臺互動的 API。
我們對後者的工作才剛剛開始，但您已經可以在 Kubernetes 的一些功能中看到它的體現。例如：
- “優雅終止”機制在容器被終止（由於滾動更新、維護節點排出等）之前提供了一個可配置時間的回撥。這允許應用程式乾淨地關閉，例如持久化記憶體狀態並乾淨地結束開放連線。
- 存活和就緒探針檢查可配置的應用程式 HTTP 端點（也支援其他探針型別），以確定容器是否存活和/或準備好接收流量。響應決定 Kubernetes 是否會重新啟動容器，將其包含在其服務的負載均衡池中等。
- ConfigMap 允許應用程式從 Kubernetes 資源而不是命令列標誌讀取其配置。
更廣泛地說，我們認為 Kubernetes 正在催生新一代設計模式，類似於面向物件設計模式，但這次是針對容器化應用程式的。容器化架構會催生設計模式並不奇怪——容器在模組化/封裝、抽象和重用方面提供了與軟體物件相同的許多好處。更好的是，由於容器通常透過 HTTP 和 JSON 等廣泛可用的資料格式相互互動，因此這些好處可以以語言無關的方式提供。
本週，Kubernetes 聯合創始人 Brendan Burns 在第 8 屆 Usenix 熱點雲技術研討會 (HotCloud ‘16) 上發表了一篇論文，闡述了我們對此主題的看法。該研討會是一個學術研究人員和行業從業者齊聚一堂，討論私有和公共雲技術前沿思想的場所。該論文描述了三類模式：管理模式（如上所述）、涉及在同一節點上執行的多個協作容器的模式，以及涉及在多個節點上執行的容器的模式。我們不想劇透閱讀論文的樂趣，但我們會說您會看到 Pod 抽象是後兩種模式的關鍵推動者。
隨著 Kubernetes 專案不斷將我們十年來使用 Borg 的經驗帶給開源社群，我們的目標不僅是使應用程式的大規模部署和操作變得簡單可靠，而且還要使其易於從一開始就建立“雲原生”應用程式。我們關於基於容器服務的設計模式以及 Kubernetes 啟用此類模式的想法的文件工作是朝著這個方向邁出的第一步。我們期待與學術界和實踐者社群合作，識別和編纂更多模式，旨在幫助容器兌現承諾，為整個軟體生命週期（從開發到部署再到操作）帶來更高的簡單性和可靠性。
要了解有關 Kubernetes 專案的更多資訊，請訪問 kubernetes.io 或在 Slack 上與我們聊天：slack.kubernetes.io。