谷歌发布 Kubernetes 1.3 加速了容器之战

2016-07-21 00:27:00

在容器之战中，谷歌宣布了最新开源容器编排引擎Kubernetes1.3版本。此次的发布是在 Docker 公司发布 Docker 1.12 版本之后，该版本带有内置的 Swarm 编排功能。

虽然 Kubernetes 是一个由社区驱动，Linux 基金支持的项目，不过谷歌还是它最杰出的项目贡献者之一。有了像混合部署，更好的扩容，运行传统工作负载这些功能，谷歌旨在对用 Kubernetes 的企业更加友好。这次的版本通过早期的 Kubernetes 尝试者来处理一些最受期待的功能。

以下是 Kubernetes 优于其他编排引擎的一些原因。

性能和可扩展性

说到可扩展性，谷歌很有经验。首先，它正在带着一些最佳实践给 Kubernetes。这些贡献者与从社区的贡献者耦合，使得Kubernetes成为拥有最佳伸缩性的容器平台之一。
随着最近的这次发布，Kubernetes 被再次推到极限：在有2000个节点的集群上运行它，这些节点上最多有60000个 pod。集群是由名为节点的单个机器构成的。Pod 在 Kubernetes 中主要就是一个配置的单元，配置可以类比为虚拟机。一般来说，每个 pod 的启动时间都是在2秒之内。这对商业来说意味着什么？如果在通信过程中，出现意外的大流量或者遇到冲突，你可能需要发布更多应用程序的实例。在典型的公有云配置中，在虚拟机上工作负载运行的地方需要花费5-15分钟来使新的实例变得可用。同一个应用程序，在容器内运行的时候，能够快速扩容来确保给出更好的回应。

虽然不是每个商务都需要那种水平的扩容性和性能，但是对于电子商务和其它在线公司来说这个功能是很有利的。它同时还能够帮助服务提供者和测量响应时间、可用性的应用程序的开发运维团队来管理服务。

支持混合场景

企业当然不希望将所有的工作都移动到公有云上。一些已经存在的应用程序会在移动用户和合作伙伴的时候保留内部部署，将应用程序面向云端。混合云在企业IT战略中起着很关键的作用。

Kubernetes 之前的版本都运行在隔离的环境中。每个环境都都由管理员和开发运维团队独立管理。这个集群的应用程序无法访问运行在另一个集群的应用程序。

有了 Kubernetes 1.3，应用程序即使配置在不同的集群和环境中，也能够互相交流。这个性能给工作负载带来互操作性和高可用性。这个功能最大的一个好处就是，能够用运行在公有云上的应用程序无缝集成配置在内部部署上的集群。

企业利用同级和专门的网络连接到公有云基础设施，在数据中心和公有云上管理联合 Kubernetes 集群。这样的优化启动了先进的混合多云配置场景。外部IT能够使用一组工具链来管理在数据中心和多个公有云环境中的 Kubernetes集群。

传统和现代应用程序的统一平台

今天的企业IT环境处理传统商业线应用程序和新兴当代云原生应用程序。虽然容器加速了大家对微服务和云原生应用程序的接受度，但是运行传统和当代工作的基础平台仍然是隔离的。随着为运行云原生应用程序的 Silos 的出现，对于企业来说，存在着一股阻碍转移到容器化基础设施的阻力。

运行容器化应用程序面临的挑战就是处理持久性和有状态。用容器中的临时性存储来配置，管理和扩容无状态应用程序是十分容易的。但是，任何有意义的应用程序需要一个数据中心来存储和检索数据。在容器中运行相关的数据库和 NoSQL 数据库需要持续状态。容器并没有以优雅的方式来处理有状态的问题。用户只能从过剩的选择中选择正确的持久性战略。这是容器在企业接受容器的道路上的一个主要的障碍。

有了 Kubernetes 1.3，运行像数据库和键值存储这样有状态的工作就很轻松，不需要任何的应变方案。PetSet 带来的是有状态，以及一些其它功能，比如永久主机名和初始化容器。

轻松开发和测试

设置 Kubernetes 集群，需要彻底了解计算、网络和存储的概念。这种复杂性让开发人员不愿意尝试在他们的工作站和笔记本上使用 Kubernetes。

Kubernetes 1.3有个叫做 Minikube 的强大测试工具，可以在任意笔记本上运行单节点的小型集群。它借鉴了 Docker 中的一些概念，比如 docker－machine driver，用单个命令来设置本地环境。如果应用程序运行在 Minikube 上，那么肯定也会运行在由数千个节点驱动的生产集群上。

这个是谷歌对抗 Docker 计划将 Swarm 和核心引擎结合在一起的举动。从技术层面上来讲，部署微服务到支持 Minikube 十分简单，就好比把应用部署到运行在开发者机器上部署 Docker Swarm 环境一样。这对于将 Kubernetes 变得对开发者更友好，更易获取，更易实用的，又是一大步。