容器集群管理 -- Docker Swarm vs Kubernetes

2022-04-04 12:18:39   最后更新: 2022-04-04 12:19:52   访问数量:93




 

此前的文章中,我们介绍了 Docker 的使用以及工作原理:

 

docker 入门 -- 带你全面了解 docker 的概念与使用

 

docker 赖以实现资源隔离与限制的原理

 

我们看到 Docker 的本质其实就是被 linux 系统机制隔离的进程,有了这样的隔离性,我们能够借以实现我们的微服务架构。

 

但是,在微服务架构中,往往会有许许多多的服务,光是将他们一个个以 docker 的形式启动起来并不能解决我们的核心问题 -- 集群管理。

 

那么,如何去管理 Docker 形成的集群呢?目前市面上有着许许多多的容器管理方案,下图就是 2018 年的容器管理技术市场占有率的调查结果:

 

 

 

 

此前的文章中,我们介绍了 Docker Compose 的用法,它让我们可以将多个 Docker 容器链接成一个组合的功能,这个组合中的所有容器可以被一次性全部部署、启动或停止。

 

这对于我们单机部署多个相互有依赖关系的 Docker 镜像时,有着很大的帮助。

 

但对于多个物理机或虚拟主机组成的集群来说,Docker Compose 就力不从心了。我们往往需要一个更高等级的中心化平台去管理和调度整个由 Docker 镜像构成的集群。

 

 

Docker1.12 版本开始,Docker 引擎中原生内建了 Docker Swarm Mode 只要通过 Docker Engine CLI/API 就可以建立并且管理 Docker Swarm 集群,无需额外的安装和设定。

 

Docker Swarm 将集群中不同的设备划分为两种不同的角色:Manager 和 Worker,它们组成了 Docker Overlay Network 网络机制:

 

 

 

Worker 负责业务容器的运行,Manager 则负责集群的管理。

 

基于这样的集群管理模式,我们可以实现:

 

  1. 自动化跨主机 host 的集群搭建;
  2. 集群规模的按需缩放,但目前尚不成熟;
  3. worker 容器宕机后,在冗余的 Worker 主机上自动启动 Worker 来容灾;
  4. 镜像版本的升级和回滚;
  5. 支持 Routing Mesh 复杂均衡。

 

 

4.1 什么是 Kubernetes

 

基于 Docker Compose 我们可以实现单机的多 Docker 镜像的依赖管理,基于 Docker Swarm,我们可以实现集群组建与调度。那么,针对线上微服务场景,Docker 原生的所有工具是否已经完全可以满足我们的一切需要了呢?

 

Google 公司告诉我们说不行,因为:

 

在大规模集群中的各种任务之间运行,实际上存在着各种各样的关系,处理这些关系才是作业编排和管理系统最困难的地方。

 

Kubernetes 的设计思想是以统一的方式抽象底层基础设施(计算、存储、网络等)的能力,定义任务编排的各种关系(亲密关系、访问关系、代理关系等),将这些抽象以声明式 API 的方式对外暴露,从而允许平台构建者基于这些抽象进一步构建自己的 PaaS 集群乃至更上层的平台。于是,Kubernetes 便成为了构建平台的基础平台。

 

相比于 Docker Swarm,Kubernetes 更进一步将平台构建进行了抽象,这深一层的抽象,让 Kubernetes 项目不只是简单地提供编排能力,而是变成了一系列具有普遍意义的、以声明式 API 驱动的容器化作业编排思想。如果将 Docker Swarm 看成是承载了战斗机集群的一架航母,那么 Kubernetes 可以被看作是一个航母设计平台。

 

由于 Kubernetes 在 K 和最后的 s 之间有 8 个字母,于是人们通常将这个长长的名字简化为 K8s,而在中文发音中,K8s 又恰好与 Kubernetes 十分相似,K8s 也就成为了人们十分喜欢的简称。

 

4.2 K8s 的抽象

 

 

 

上图展示了 K8s 核心功能的全景图。

 

4.2.1 Pod

 

位于上面这个全景图最核心地位的就是 Pod。

 

若干需要协同调度的容器被封装为一个 Pod,它们在同一个主机上,通过 localhost 进行通信,通过本地磁盘交换文件,因此,K8s 让这些容器共享同一个 Network Namespace、同一组 Volume,从而实现高效的信息交换。

 

4.2.2 Deployment、Job 与 Cronjob

 

当我们需要针对同一个 Pod 启动它的多个应用实例时,这些应用实例就被封装在一个 Deployment 中,Deployment 就是这个 Pod 的多实例管理器。

 

而 Job 封装了只运行一次的 Pod;Cronjob 则封装了需要周期运行的 Pod。

 

4.2.3 Service

 

Pod 中的容器要想向外提供服务,就需要绑定到一个 Service,由 Service 代理 Pod 的 IP 地址和端口,从而通过 K8s 平台的功能,让调用者无需绑定到随时可能变化的 Pod 的固定 IP 地址和端口,而是通过调用 Service 动态找到其代理的后端 Pod。

 

当一个 Service 代理 Deployment 时,针对 Deployment 中的多个 Pod 实例,Service 会以负载均衡的功能进行调用。

 

4.2.4 ConfigMap 与 Secret

 

在一个集群中,我们经常会需要维护许许多多诸如密钥、密码键值对等信息,这时,我们就需要定义 Secret 节点,当使用该 Secret 的 Pod 启动时,K8s 会自动把 Secret 里的数据以 Volume 的方式挂载到容器中。同理,还有维护 Pod 所需配置信息的 ConfigMap。

 

 

https://sensu.io/blog/kubernetes-vs-docker-swarm

 

 

 

 

欢迎关注微信公众号,以技术为主,涉及历史、人文等多领域的学习与感悟,每周三到七篇推文,只有全部原创,只有干货没有鸡汤

 

linux 使用及配置相关

 






linux      技术贴      docker      虚拟化      沙盒      kubernetes      k8s     


京ICP备2021035038号