本文发布时间已超过一年。较旧的文章可能包含过时的内容。请检查页面上的信息自发布以来是否已变得不正确。
容器设计模式
Kubernetes 可自动化应用程序的部署、操作和扩展，但我们在 Kubernetes 项目中的目标不仅限于系统管理 —— 我们还希望 Kubernetes 也能帮助开发人员。Kubernetes 应该使他们能够轻松编写在云和数据中心环境中运行的分布式应用程序和服务。为了实现这一点，Kubernetes 不仅定义了供管理员执行管理操作的 API，还定义了供容器化应用程序与管理平台交互的 API。
我们关于后者的工作才刚刚开始，但您已经可以在 Kubernetes 的一些功能中看到它的体现。例如
- “优雅终止”机制在容器被终止（由于滚动更新、节点维护等原因）之前，提供一个可配置的时间量回调到容器中。这允许应用程序干净地关闭，例如，持久化内存状态并干净地结束打开的连接。
- 存活度和就绪度探测检查可配置的应用程序 HTTP 端点（也支持其他探测类型）以确定容器是否存活和/或准备好接收流量。响应决定了 Kubernetes 是否会重新启动容器，将其包含在其服务的负载均衡池中等等。
- ConfigMap 允许应用程序从 Kubernetes 资源读取其配置，而不是使用命令行标志。
更广泛地说，我们看到 Kubernetes 正在启用新一代的设计模式，类似于 面向对象的设计模式，但这次是针对容器化应用程序。从容器化架构中出现设计模式并不奇怪 —— 容器在模块化/打包、抽象和重用方面提供了与软件对象相同的好处。更好的是，由于容器通常通过 HTTP 和广泛可用的数据格式（如 JSON）相互交互，因此可以以独立于语言的方式提供这些好处。
本周，Kubernetes 联合创始人 Brendan Burns 将在 论文中概述我们在 第八届 Usenix 云计算热点研讨会 (HotCloud ‘16) 上关于该主题的想法，该研讨会是学术研究人员和行业从业者聚在一起讨论私有和公共云技术前沿想法的场所。该论文描述了三类模式：管理模式（如上所述）、涉及在同一节点上运行的多个协作容器的模式以及涉及跨多个节点运行的容器的模式。我们不想破坏阅读论文的乐趣，但我们会说您会看到 Pod 抽象是后两种模式的关键推动因素。
随着 Kubernetes 项目继续将我们十年来在 Borg 方面的经验带给开源社区，我们的目标不仅是要使大规模应用程序部署和操作变得简单可靠，而且还要使创建“云原生”应用程序变得容易。我们在记录有关基于容器的服务的设计模式以及 Kubernetes 如何启用此类模式的想法方面的工作，是朝着这个方向迈出的第一步。我们期待与学术界和实践者社区合作，以识别和编纂更多模式，目标是帮助容器实现简化和提高整个软件生命周期（从开发到部署再到操作）的可靠性的承诺。
要了解有关 Kubernetes 项目的更多信息，请访问 kubernetes.io 或在 Slack 上与我们聊天 slack.kubernetes.io。