Kubernetes1.3上线可期待的新功能-优快云博客

本文探讨了Kubernetes 1.3版本中引入的Petsets和Ubernetes两大特性。Petsets为有状态应用提供稳定的身份识别，解决重启后数据和ID丢失的问题，特别适用于数据库节点等场景。Ubernetes则提升了Kubernetes集群的故障转移能力，支持跨云提供商的集群联盟，增强了服务的弹性和可用性。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

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版本中也需要设置相同东西的手工作业。