趋势：Kubernetes让Docker容器如虎添翼

【编者的话】本文主要讲述作者看好Kubernetes与Docker结合的未来。

一年前，我开始学习Docker容器。几个月下来，我意识到我正在学习的是一项革命性技术，原因如下：

1. 快速学习：对于任何我想学习的工具、框架或者编程语言，按需使用Docker容器可以加快我探索性学习环境的搭建。
2. 按需自助服务环境：Docker容器可以用来搭建按需自助服务的开发和测试环境。对于开发和测试人员来说，这是巨大生产力的助推器。
3. 自动部署：使用Docker容器可以搭建Jenkins、代码仓库等工具，在开发、测试以及UAT（User Acceptance Test，用户验收测试）服务环境中进行自动部署。

对于Docker容器而言，我觉得以下功能是需要的：

1. 管理app集群：规模化多个Docker容器来满足应用程序的需求。例如，一个由Flume、Kafka以及Spark容器组成的数据管道。现在的需求是，通过扩大管道增加更多的Flume、Kafka以及Spark容器来处理更大的数据集。或者说通过集群配置启动更多的应用程序来处理更大的数据集。例如，Flume集群传输数据到Kafka集群。
2. 容器编排：根据按需服务需求管理容器，启动或者停止运行着应用程序的容器。例如，启动或停止Jenkins集群按需进行CI工作。
3. 组件重新打包：有时候想重新打包已有应用程序，然后将他们一起启动来测试不同应用程序的配置。

对于这些需求，使用Kubernetes能够很容易满足。

当我潜心深入Kubernetes的世界时，我发现这是最近一段时间我使用过的最棒的工具之一。毫无疑问它对于使用Docker容器的DevOps专业人员来说是如虎添翼。

以下是Kubernetes的几个关键模块，通过这些模块能够简化我将多个容器配置在一起的过程，并且不论何时当我想将这些容器作为一个统一服务时，都能保持特定数量的副本。

• Pods：Pod可以被看作是一组由一个或者多个同地协作且共同管理的容器，这些容器共享相同的命名空间以及volume。每一个pod都关联了一个IP地址，从而能够让外界访问运行在pod中的应用程序。Pod能够用于同地协作且共同管理多个共享volume的Docker容器。
• Services：Services给pod提供了更高层次的抽象。如果一个或者多个pod需要依赖其他pod，这就需要通过service来完成。设想通过Kubernetes的service来暴露一个Kafka集群。
• Replication controllers： Replication controllers在任何时候都保持着一定数量的pod副本。这意味着如果有一个或者多个pod停止服务，控制器能够合适地启动相同数量的pod。

在原生云应用程序的发展趋势下容器和微服务成为了关键组件，而Kubernetes被认为是在不同层次共同管理原生云应用程序的最关键组件。事实上，CNCF.io也已经意识到Kubernetes是满足原生云应用程序的首选工具。并且，随着目前Docker容器逐步成为最流行的容器化技术，它们的结合只会让彼此变得更加强大，超越其他任何需要容器间协同工作的原生云结构编排工具。