您好,登录后才能下订单哦!
原创文章,欢迎转载。转载请注明:转载自IT人故事会,谢谢!
原文链接地址:『高级篇』docker之DockerSwarm的了解(27)这次一起了解下docker Swarm,什么是dockerSwarm。
产品背景
使用docker的流程,ssh到一台服务器,运行docker命令来运行本机的docker服务,随着docker发展,越来越多的服务想要运行在docker容器中,如果在这样挨个的登录在每个ssh主机上管理容器,就非常的吃力了,而且我们的应用也需要高可用,也需要避免单点的故障,docker现有的能力已经很难满足这样的需求了,在这样的背景下,docker社区就产生类的dockerSwarm项目。
概念
什么是swarm,swarm这个名词比较贴切,swarm这个单词的意思就是动物的集群行为,比如我们常见的蜂群,鱼群,大雁南飞都可以成为swarm,swarm项目就是把多个docker 实例聚集在一起形成一个大的docker实例,对外提供集群服务,同时这个集群提供所有的api,用户可以相使用docker实例一样使用docker的集群。
docker swarm在1.12之前是一个独立的项目,需要单独下载,在1.12之后该项目就合并到了docker中,成为docker的子项目,目前docker唯一的一个原生支持docker集群的管理工具。
下面这个图,就可以看到docker swarm管理docker的一个架构图。以前使用docker命令行是针对docker主机的,然后到这台机器上单独的控制这台机器上的主机,有了swarm之后,客户端命令是针对docker集群的。它的命令几乎等同于docker的原生命令,它把命令发送给swarm,swarm选择发送一个节点去真正的执行,swarm是通过docker自带的远程的API,来实现对docker的控制。
下面这个图,这张图跟上面一张图描述的是一个事情,只不过它暴露了更多的的细节,上面的大框和下面的小框都代表了一台服务器,物理机或者虚拟机,我们从上面说,上面是swarm的一个manager节点,管理这个worker节点,可以看到管理了多少个cpu,多少个内存,每个上面运行的服务,每个服务的状况,比如他们的标签,他们的健康状态,Manager管理者每个节点的生命周期,比如加入一个节点,下线一个节点,manager还管理者每个服务的生命周期,服务的部署,更新,停止,删除,Node节点比较单纯他就运行了docker daemon,因为在1.12之后swarm已经融入了docker本身,开发一个远程的api给manager节点调度,运行具体的服务和容器,下面咱们一起看看服务的部署流程是怎样的,在这样的架构上是如何体现的。
想想之前学习的mesos,需要先安装docker,Marathon,zookeeper,加入我们现在有5台liunx服务器,每个上面都装有docker,选择一台作为manager,上面执行下图的第一条命令, 执行完之后会打印出来一个token作为dockerSwarm的凭证,然后在每个worker节点下执行第二条命令,表示要加入集群,只需要token和对应manager节点的ip和端口号,集群环境就搭建完毕了
客户端的发起docker命令,两种方式
docker Client 在manager节点的外边,假如执行了docker service create,先会经过docker Deamon接受这条命令,传给Scheduler模块,Scheduler模块主要实现调度的功能,负责选择出来最优的节点,里面包含了2个子模块,Fiter 和Strategy,Fiter很明显是过滤节点,用来找出满足条件的节点(资源足够多,节点正常的),Strategy是过滤出来后选择出最优的节点(对比选择资源剩余最多的节点,或者找到资源剩余最少的节点),当然Fiter 和Strategy都是用户可以单独定制的,中间的Cluster是抽象的worker节点集群,包含了Swarm节点里面每个节点的信息,右边的Discovery是信息维护的模块,比如Label Health。Cluster最终调用容器的api,完成容器启动的刘而成。
用户在创建服务的时候,选择最优的节点,选择最优节点的管理分为2个阶段。
过滤和策略
Constraints
约束过滤器,根据当前的操作系统的类型,内核版本,存储的类型进行指标上的约束,也可以自定义约束。当前系统启动的时候可以通过label指定当前机器所具有的特性然后通过Constraints把他们过滤出来。
Affinity
亲和性过滤器,支持容器的亲和性和镜像的亲和性,比如一个应用,DB容器和web容器放在一起,就可以通过这个来实现,
Dependency
依赖过滤器,link等等吧Dependency会将这些容器放在同一个节点上,有依赖管理的会将创建的容器和依赖的容器放在同一个节点上。
Health filter
健康过滤器,根据节点的健康状态进行过滤,把有问题的节点去掉。
端口过滤器,根据端口的使用情况进行过滤,比如一个8080端口在某个主机上被占用,某些主机未被占用,会选用未被占用的那些主机。
Binpack
在同等情况下,会使用资源最多的节点,通过这个策略可以让容器聚集起来。
Spread
在同等情况下,会使用资源最少的节点,通过这个策略可以让容器均匀的分布在每个节点上。
随机选择一个节点。
稍微有点复杂,根据场景来说吧
基于物理网络之上的虚拟网络,Swarm的上层应用不在依赖于物理网络,并且能够让下面的物理网络保持不变,老铁就理解到这里就可以了,网络本身涉及到的东西太多了,应该也听过网络工程师,既然有这个职位肯定这个不是那么容易学的,在这里就不会深入的进行详解了。
PS:假定运行了一个nginx服务2个实例,nginx1 和nginx2,容器内的端口是80,主机内的端口是8080, 这2个容器分别运行在node2和node3上,看到了吧node1虽然没有运行实例但是依然有8080端口在监听,一个集群在所有的worker节点上都是可以访问到的,随便选一个节点输入它的ip和8080端口就可以访问到,或者搭建一个负载均衡External LB,负责轮询的方式访问每个上边的8080端口,为什么在每个节点上都可以访问我们的服务呢?每个服务启动后所有的节点都会更新自己的VIP LB,把新的服务端口号和服务的信息建立一个关系,VIP LB是基于虚拟IP的负载均衡,VIP LB可以通过虚拟IP解析到真实IP,然后访问到服务。
就类型docker-compose,可以通过docker-compose.yml文件创建出来一组容器,他们之前通过link的方式进行访问,其实这种就类型docker-compose的link网络。
PS:也就是在Ingress之上多了一个link的场景,可以通过link的方式访问,也不需要主机的网络,link怎么实现的呢,如果让一个容器link到另一个容器很容易毕竟他们在一台主机上,一个服务link到另一个服务其实没有那么简单了,可能包含一个容器,也可能包含很多个容器,可能运行在一台机器上,也可能分布在多台机器上,我们如何实现可以通过名字来访问彼此呢,这用到了容器的dns,这里的nginx服务依赖于tomcat服务,nginx有2个实例,tomcat有一个实例,所有的nginx的容器都会对tomcat的解析,把它解析到tomcat的VIP,VIP负责做负载均衡,原理就是这样的原理,link的方式外部是访问不到的。link只适合swarm集群内部的场景。
使用自定义的网络,首先要创建网络,所有的网络都可以通过名字来连接彼此,而不需要link操作了。只要连接这个网络的彼此,都可以通过名字。底层来说它和link是类型的。通过dns来解析应用的名字。然后通过VIP LB的形式来进行负载均衡。
#创建自定义网络
docker network create --driver=overlay --attachable mynet
#创建服务
docker service create -p 80:80 --network=mynet --name nginx nginx
对外以Docker API 接口呈现
好处直接可以平滑的切换到docker swarm上。基本不需要改变现有的系统
容易上手,学习成本低
之前docker的经验可以完成继承过来。
轻量级,节省资源
专注docker集群的管理。插件的机制swarm的模块都抽象出来对应的API,可以根据自己的特点进行定制实现。
跟docker同步发布,docker的新的特性在dockerSwarm上都可以得到体现。
PS:docker Swarm基本都了解的差不多了。下次开始docker swarm的环境搭建。
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。