> 作者：João Miranda 译者：丛一 通过借鉴他们在这一技术领域十年的经验，谷歌云平台团队[撰写了一系列的文章](http://googlecloudplatform.blogspot.pt/2015/01/in-coming-weeks-we-will-be-publishing.html)分享其对容器的看法。谷歌的前两篇文章提供了关于这个主题的总览。这两篇文章解释了容器集群和他们所[定义特征](http://googlecloudplatform.blogspot.pt/2015/01/what-makes-a-container-cluster.html)背后的逻辑。之后又向读者展示了如何在[Kubernetes](http://kubernetes.io/)上应用这一切。 容器能够带来一系列的好处。包括更简单的部署模型，快速可用性和[微服务](http://www.infoq.com/minibooks/emag-microservices)架构理想的基础设施层。像Docker之类的容器产品更关注于在单一计算机上操作。这就产生了协调多个容器的需求。或者用高级资深工程师和Kubernetes联合创始人Joe Beda[更喜欢的说法](http://googlecloudplatform.blogspot.pt/2015/01/what-makes-a-container-cluster.html)，“即兴爵士乐表演”的管理需求，这个说法能够更好地反映出容器管理对“实时条件和输入”的反应。 像Kubernetes这样的容器集群提供了与集群管理、网络和命名有关的服务。他们“创建了一个抽象的层次，让开发人员和管理员可以将需要改进的服务作为一个整体，改进其行为和性能，而不是服务的某个容器组件或基础设施资源”。 随着容器数量的迅速增加，容器协调的需求也随之迅速地变得显而易见。谷歌就是个极端的例子，每秒要启动7000个容器，或每周要启动20亿个。这就是对容器集群的需求。 除了其他的要求之外，谷歌构建的容器集群还必须能够做到在保持可用的状态下完成更新，可扩展并且便于操控和监控。通过满足这些要求，谷歌收益匪浅。首先，可以构建有清晰的合约和边界的微服务。然后，清晰的边界让小型工程团队能够保持软件的可管理和可扩展。容器集群具有自愈能力和无摩擦的水平扩展能力，并且有着高效的资源利用率。“集群运维团队和应用运维团队角色” 的专业化能力是另一个隐含的好处。Joe Beda举例提到，“GMail的运维和开发团队很少需要与集群运维团队直接对话”。开发人员可以将注意力集中在构建服务上，而不需要考虑底层的基础设施问题。 **“****优秀容器集群的要素”** Joe还分享了“优秀的容器集群管理器所需的要素”。包括动态的容器配置，以集合方式思考以及集群内的连接。 动态容器配置就是在考虑容器应该如何运行以和运行在何处的公开意向的前提下，找到一个可以运行给定载荷的位置。这是一个[背包](http://en.wikipedia.org/wiki/Knapsack_problem)问题的实例。每个容器都有其自身的限制，如何在有限的可用计算资源内匹配各个容器呢？在安排给定的载荷时，集群必须要考虑可用容量（如CPU、RAM等），特殊的硬件需求以及实时变化的条件（如故障、自动扩展等）。Kubernetes用[Pod](https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/pods.md)解决了这个问题： > Pod（和一群鲸鱼（a pod of whales）或豌豆荚（pea pod）里的含义一样）由一组相互关联的共享容量的Docker容器构成。Pod模型化为容器化环境下，特定于应用程序的一个“逻辑宿主”。其中可能包含一个或多个相互关联并紧密耦合的容器——在前容器（pre-container）世界，他们会执行在同一个物理或虚拟主机上。 第二个要素是提供以集合方式思考的可能性。Kubernetes通过提供[标签](https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/labels.md)和[复制控制器](https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/replication-controller.md)使其成为可能。每个Pod可以有一系列的标签，每个标签是一个键值对。Pod通过标签分组，例如根据应用层级或地理位置。之后标签的使用可以有多种方式，例如由[服务](https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/services.md)或复制控制器使用。复制控制器，顾名思义，用于保证大量的Pod拷贝能够一直保持活动，从而为横向扩展活动提供帮助。  Kubernetes标签，来自于文章[“是什么造就了容器集群？”](http://googlecloudplatform.blogspot.pt/2015/01/what-makes-a-container-cluster.html) 成功的容器集群的第三个要素是通信。当有多个容器，进而有多个微服务存在时，通信就成为了一个关键的组件。为了在无需知道它们各自的容器实际运行位置的情况下，微服务之间也可以互相通信，好的容器集群应该提供一个命名解析系统。命名解析系统在容器启动或迁移之后能够立即了解到全部变化是十分重要的。Kubernetes在标签和Watch API模式的帮助下，提供了轻量级的服务发现方案。受[Google Chubby论文](http://static.googleusercontent.com/media/research.google.com/en/us/archive/chubby-osdi06.pdf)的启发，该模式提供了一种从服务传递异步事件的方式。Kubernetes团队意识到并不是所有的客户端都会为了使用这个API而重写。因此Kubernetes提供服务代理的概念来处理这类场景。 > [服务代理]是一个简单的网络负载均衡器/代理，以单一稳定的IP/端口形式暴露在网络中，可以帮助完成命名查询。 简而言之，谷歌云平台团队将容器集群定义为： > 一个动态配置和管理容器的系统，以Pod的形式组合在一起，连同所有的相互连接和通信渠道，运行在节点之上。 谷歌向容器化的转移开始于将[cgroups](http://en.wikipedia.org/wiki/Cgroups)（控制群组的简写）加入Linux内核，以隔离一个进程集合的资源使用。通过简化容器技术，[Docker](https://www.docker.com/whatisdocker/)让更大范围的社区采用了容器技术，从而使这种技术得以推广。 InfoQ一直在[跟进](http://www.infoq.com/news/2014/07/google-kubernetes)Kubernetes的发展，其中包括一篇由[Carlos Sanchez](http://www.infoq.com/author/Carlos-Sanchez)执笔的深度[文章](http://www.infoq.com/articles/scaling-docker-with-kubernetes)。 查看英文原文：[Google Shares its Views on Containers](http://www.infoq.com/news/2015/01/google-series-containers)