对以上代码进行分析，比如，你想要使用三个pod来运行一个php前端，你可能会使用一个合适的pod模板（指向你的php容器镜像）创建一个replication controller。其中的 num_replicas的值为3。你可能会通过一个label查询 env=prod、tier=fe 来定位到一系列pod集合，之后这个replication controller对象就会对你找到的这些pod集合进行操作。通过这种方式replication controller将会很容易理解集群进行收缩/扩展之后预期的状态，它会不断对集群进行调整直至实现最后的状态。如果你希望缩小或者扩大你的服务规模，所有你需要做的仅仅是改变预期的replicaiton count，replication controller将会处理其余的问题。通过将注意力集中在系统的预期状态，我们使这个问题变得易于处理。
你已经可用上面列出的几个特性做一些很有趣的事了。任何高度并行的任务分发系统（持续集成系统，视频解码等等）在工作的时候，它们的pod之间不需要做很多的交互。然而，大多数复杂的服务更多的是小型（微型）的网络服务构成的，它们的pod之间需要进行很多的交互，按照传统的应用层级划分，每一层就像是图中的一个结点。
一个集群管理系统需要一个命名解析系统，这个解析系统可以与上面所描述的几个要素一同进行工作。就像DNS提供的域名到IP地址的解析一样，这个命名服务可以将服务名称解析成一个目标，以及一些额外的需求。特别地，系统的运行状态发生变化的时候，这种变化应该很快地被系统所捕获，一个“服务名称”应该能解析一系列的targets，可能还有额外的关于这些target的元信息（比如 碎片任务shard assignment）。对于Kubernets API ，这个工作通过 label selector 以及watch API（注释2）模式来完成。这为服务发现提供了一个很轻量级的形式。
大多数的客户端将不会因为仅仅想利用新的命名API的优势就立即重写（或者从来不会被重写）大多数项目希望有一个单独的地址以及一个端口以此可以和其他层的服务进行通信，为了弥补这个不足，Kubernetse引入了服务代理的理念。这是一个简单的网络负载均衡/代理，可以为你进行名字查询并且可以以一个单独的稳定的IP/端口的形式（通过DNS）在网络上暴露给用户。当前，这个代理做简单的轮询式负载均衡跨越所有的通过label selector识别出来的后端。按照计划，Kubernets希望允许custom proxies/ambassadors ，这样可以进行更灵活的指定域的决策（关注Kubernetes roadmap来了解更多的细节）。事实上，MySQL也开始意识到ambassador的作用，它可以知道如何发送写信息流到master结点，并且将信息流读入read slave结点。
现在你已经了解了以上三个关于集群管理系统的关键的要素即：动态的容器配置，容器集合的方式进行思考，集群内部服务之间的连接，是如何在一起发挥作用的。
在这个文章的开始我们提出了这样一个问题：“到底如何构建一个容器集群？”希望通过我们在上面文章中提出的信息和相关细节，你已经有了答案：简而言之，一个容器集群是一个动态的系统，这个系统可以存放和管理容器，容器以pod的形式组合在一起，在结点上运行，同时还包括内部用于相互连接和通信的信道。
当我们开始构建Kubernetes 的时候，我们的目标是 ：使得Google对于容器的使用经验具体化。我们最初仅仅关注容器的调度以及动态配置，然而，当我们彻底明白在构建一个真正的服务时，不同的系统是完全必要的。我们立即发现，把其他的额外的要素加入进来是完全有必要的，比如：pods，labels以及replication controller。在我看来，这些绝对是构建一个可用的容器集群管理系统的最少的需要的模块。
Kubernetes仍然在在不断发展，但目前的发展状态还算不错，我们刚刚推出了v0.8的版本，你可以从这里下载，我们仍然在添加新的功能并且重新构建那些我们已有的功能。我们还推出了roadmap v1.0， 这个项目已经开始启动，并且一个很大的正在不断成长的社区作为合作伙伴在做贡献（就像ReaHat 、VMWare、Microsoft、IBM、CoreOS等等）还有许多用户，他们在不同的环境中来使用Kubernetes。
虽然我们在这个领域有很多实践经验，但是又很多问题Google也没有答案，可能在集群使用过程中有一些特殊的要求和特别需要考虑的地方我们在目前还没有意识到，考虑到这一点，请参与到我们正在建设的一些项目中来：Try it out、file bug reports、 or send a pull request (PR)。
-Posted by Joe Beda, Senior Staff Engineer and Kubernetes Cofounder
注释1：这是一个传统的背包问题，在通常情况下这是一个NP难问题。
注释2：“Watch API 模式”是这样一种方法: 它可以从一个服务中来分发异步事件，在通常的锁服务系统中这个很常见（zookeeper等等），这个方法最初源于 Google Chubby 的论文。客户端本质上发送并且“挂起”一个请求，直到有变化发生。客户端的请求这通常会加上版本号信息，所以客户端会对任何变化保持最新的状态。
原文链接：What makes a container cluster? （翻译：王哲 ）