本文发表于一年多前。旧文章可能包含过时内容。请检查页面中的信息自发布以来是否已变得不正确。
容器设计模式
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。