Kubernetes1.3

在Meta Broadcast我们最近正忙于将我们的基础设施从AWS上的虚拟机搬到虚拟机上的Kuberentes上。我们在等待Kubernetes1.3版本发布，这个版本将在6月24日上线。
现在，我们根据K8S在Github上的进展来展望下Kubernetes1.3新版本会带来的两个主要功能。

petsets

petsets用有状态应用程序和服务解决问题。在Kubernetes中最小的配置单元就是pod。Pods寿命比较短，类似于正在运行的容器镜像实例，然后在它停止的时候杀死它。当pod终止的时候，这个实例就消失了，被一个新的实例替代，这个实例用的是新的文件系统、新的网络身份。
这总体上来说没什么问题，但是要你的应用程序想要在重启和停止之后还幸存下来，同时还保持它的文件系统和ID完整，这个是做不到的。参考数据库节点这个例子。
Petsets解决了这个问题，通过给pod一个独特的、稳定的身份识别的方法。这对集群化服务来说十分重要，当创建一个集群，或者添加额外的节点的时候，集群化服务需要稳定的身份来参考。稳定的ID允许pods检索跟特定身份有关的数据（数据卷），这也就意味着db.node1在重新启动之间拥有相同的数据。

Ubernetes（也就是Kubernetes集群联盟）

Kubernetes从1.2官方版本起只支持单个master，多个从属部署。虽然这样运行是挺不错，但是会在master节点上留下运行失败的单个点，这个来处理集群状态并且作为Kubernetes API的网络节点。
Ubernetes就是为了在单个Kubernetes集群上替代控制面板来支持failover，就是运行在不同可用区内集群间的failover。好在，在实践中，这就意味着service的自动、动态地再度弹性扩容，来回应集群或者可用区（或者两者都有）运行失败的。
Ubernetes其实走得更快一步。它就是为了支持宿主在不同云提供商（比如GCE和AWS）上的多个Kubernetes集群使用案例，并且选择性地预置裸机。这的确是蛮不错的，但是我们目前只需要亚马逊上做这些就可以了。
还有就是，修改过的脚本会被用来创建一个kubernetes集群。名为kube-up.sh，它负责处理配置master和minion节点，和他们的网络配置等等。在AWS这个例子中，这也就意味着挑选一个AMI，设置VPC，网关，分支网络以及更多其他的东西。这在1.3版本中都被修改过，使之支持Ubernetes，应该删除在1.2版本中也需要设置相同东西的手工作业。

结语

我们在这里写的东西都是从Github的issue和讨论中解析得到的结论。Petsets和Ubernetes对于Kubernetes团队来说是1.3版本中非常重要的部分。它们的实施和特定细节可能在发布之前还不断发生变化，大家可以自己去Github上进一步关注研究下。
我们期待从Kubernetes中看到更多。我们使用Kubernetes1.2版本，期待它可以在我们用不同或者特殊的方法痛苦地处理异构基础设施和应用程序的时候避免掉很多麻烦。你在使用Kubernetes吗？你在考虑将Kubernetes投入生产使用中吗？欢迎将过程中遇到的细节告知我们。

本文转载自才云Caicloud公众号。

原文链接：https://mp.weixin.qq.com/s/JGA0PUy40iQCk6rN283AGw

创作场景

Kubernetes1.3 上线可期待的新功能