容器编排工具与 Kuberneters
1. 什么是容器编排
试想这样的场景:
我们使用 Docker 运行一个服务应用,当负载增加,单一实例无法满足需要时,我们就得增加这个实例部署的数量,并配置容器间负载均衡,而所有这些操作都需要我们手动处理,并且这些操作也仅仅被限制在这一台 Docker 宿主机中,如果宿主机故障,那么整套应用就会崩溃。
为了避免这种情况发生,我们需要耗费大量的精力去依次配置这些容器和主机的监控系统,以便实时掌握宿主机的运行状况,及时处理出现故障的容器。当运行的容器随着业务量逐步增加,生产环境中可能会有成千上万个容器需要被监控和管理,这时就需要容器编排工具出马了。
使用容器编排工具可以自动化和管理任务,例如:
Tips:
编排这一术语来源于音乐领域,根据作曲家的作品,编曲决定音乐作品的某一部分由某种乐器以某种方式在某个时机来演奏,这一过程称为编排。编排这一术语被借用到了IT领域。容器编排负责容器的启停调度,同时通过管理容器集群来提升容器使用率。
2. 容器编排工具概览
目前,主流的容器编排工具有:
- Docker Compose:单一主机上部署多个容器;
- Docker Swarm:多台机器上部署容器。开箱即用,快速部署容器;
- Mesos:大数据组件部署。双层调度,任务调度需自己实现;
- Kubernetes(k8s):社区活跃度高,微服务化,组件丰富。
Docker Compose 已经是老朋友了,它不太适用与多宿主机场景, 下面我们介绍后三个用于集群部署的容器编排工具。
2.1 Docker Swarm
Docker Swarm 是一个由 Docker 开发的调度框架。它的使用方式接近 Docker 本身,加之 Docker Machine 可以快速创建部署 Docker 宿主机,使得 Swarm 整体部署和使用非常简单,易于上手。
2.1.1 功能特性
-
集群管理集成进 Docker Engine;
-
去中心化设计;
-
声明式服务模型;
-
服务扩容缩容;
-
协调预期状态与实际状态的一致性;
-
多主机网络;
-
服务发现;
-
负载均衡;
-
安全策略;
-
滚动更新。
2.2 Mesos
Mesos 是一个开源的集群管理框架,它可以将数据中心放在一台电脑里运行,从数据中心、操作系统的角度提供资源视图。对外提供简单的 API,同时隐藏内部的很多复杂架构。它由 UC Berkeley 的Benjemin Hinderman,Andy Konwinski 和 Matei Zaharia 开发,早于 Docker 产生,Mesos 作为资源管理器,后来在 Twitter 里发展成熟,并很快成为 Apache 基金会的顶级项目。
2.2.1 功能特性
- 可扩展到 10000 个节点;
- 使用 ZooKeeper 实现 Master 和 Slave 的容错;
- 使用 Linux 容器实现本地任务隔离;
- 基于多资源(内存,cpu、磁盘、端口)调度;
- 提供 Java,Python,C++ 等多种语言 API。
2.3 Kubernetes
Kubernetes 是一个最初由 Google 工程师开发和设计的开源容器编排工具。2015 年,Google 将 Kubernetes 项目捐赠给新成立的云原生计算基金会。Kubernetes是目前最流行的开源容器编排解决方案框架,基于 Google 庞大的生态圈及 RedHat(OpenShift)的企业支持。 如果加上 OpenShift(可以看作基于Kubernetes构建的发行版产品),Kubernetes 占有容器调度编排市场的份额高达 9 成,因而Kubernetes 社区也成为了容器编排工具中最大的社区。
2.3.1 功能特性
2.3.2 Kubernetes 组件
Kubernetes官网展示了它的基本结构示意图,如下所示:
其中:
- Master 负责管理整个集群。 Master 协调集群中的所有活动,例如调度应用、维护应用的所需状态、应用扩容以及推出新的更新;
- Node 是一个虚拟机或者物理机,上面具有用于处理容器操作的容器引擎。它在 Kubernetes 集群中充当工作机器的角色 每个Node都有 Kubelet , 它管理 Node 同时也充当 Node 与 Master 通信的代理;
在 Kubernetes 上部署应用时,Master 启动应用容器。 Master 就编排容器在群集的 Node 上运行。 Node 使用 Master 暴露的 Kubernetes API 与 Master 通信。终端用户也可以使用 Kubernetes API 与集群交互。
Tips:
Kubernetes 最初只支持 docker 作为运行时,为了能够让 Kubernetes 变得更具有可扩展性,在 1.5 版本增加了 容器运行时接口 CRI(the Container Runtime Interface),在随后的演进中,CRI 被抽出来做成了独立的项目。Kubelet 作为 CRI 的客户端,而容器运行时则需要实现 CRI 的服务端。只要某个容器引擎实现了 CRI 约定的接口,就能接入 k8s 作为 Container Runtime。