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
评论