容器的设计模式

[lingrel]

社区有对容器感兴趣的小伙伴么？ 奉上热乎的翻译~~（仓促翻译，求轻吐槽~）

Kubernetes 使应用的部署、运维和伸缩实现自动化，但我们 Kubernetes 的项目目标不仅仅是系统管理——我们也希望 Kubernetes 能帮助到应用开发者。 Kubernetes 应该使他们编写在云环境和数据中心环境中运行的分布式应用服务更容易。要实现这个目标， Kubernetes 不仅要定义让管理员执行管理操作的 API ，也要定义让容器化应用与管理平台进行交互的 API 。

我们针对后一项的工作才刚刚开始，但你已经可以从 Kubernetes 几个功能中看出这方面的特性。例如：

“优雅终止”机制提供给容器一个回调，允许容器配置被杀死（由于滚动更新或者节点维护）之前的等待时间。这允许应用程序干净关闭，例如将内存状态持久化和干净地关闭打开的连接。

活性和就绪性探查（其他探查类型也可以支持）是去检查一个可配置的应用 HTTP 端点来确定容器是否活着以及准备好接收数据。 Kubernetes 根据（对探查的）响应结果来确定是否重启容器，是否把它放到负载均衡池里来提供服务等等。

Configmap 允许应用程序从 Kubernetes 资源而不是使用命令行标记参数来读取其配置。

更一般的，我们看到 Kubernetes 带来新一代的设计模式，与面向对象的设计模式类似，但这一次是针对容器化应用（的设计模式）。这种设计模式能从容器化架构出现并不令人奇怪，容器提供了许多与软件对象相同的好处，包括模块化 /打包、抽象和重用。甚至更好的是，因为容器一般通过 HTTP 和广泛使用的 JSON 数据格式相互交互，这些（模块化 /打包、抽象和重用的）好处能够以独立于编程语言的方式提供。

本周 Kubernetes 联合创始人 Brendan Burns 在 8th Usenix Workshop on Hot Topics in Cloud Computing (HotCloud ‘ 16)会议上演讲了一片文章，就这个话题概述了我们的思想。 HotCloud 是一个学术研究人员和行业从业者一起探讨私有云和公有云技术前沿研究想法的地方。文章介绍了三种类型的模式：管理模式（如以上所述），涉及多个合作容器运行在同一个节点上的多容器模式，以及涉及跨多个节点的跨节点模式。我们不想破坏大家阅读文章的乐趣，但我们得说，你会发现，抽象出来 POD 概念是支持后面两种类型模式的关键。

随着 Kubernetes 项目继续将我们运行 Borg 系统十年来的经验带到开源社区，我们的目标不仅是让规模化地部署和运维应用更加的简单、可靠，也同时把“让创建云原生应用更容易”当做我们的第一目标。今天只是我们向这个方向努力的第一步，我们谈到容器服务的设计模式，以及 Kubernetes 如何支持这些模式。我们期待着与学术界和实践社区的共同合作，进一步识别和实现出更多模式，力求帮助容器实现它承诺的目标，让容器技术从开发、部署到运维，提升整个软件生命周期的简便性和可靠性。

轻元科技翻译整理自： http://blog.kubernetes.io/2016/06/container-design-patterns.html