这篇文章发布已超过一年。较早的文章可能包含过时的内容。请检查页面信息自发布以来是否仍是准确的。
容器设计模式
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。