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