摘要:后续将其他节点加入集群都会用到这个值将节点加入集群查看节点信息相关命令创建服务更新服务删除服务减少服务实例增加服务实例查看所有服务查看服务的容器状态查看服务的详细信息。
本篇是Docker第十三篇,Docker的使用至此就介绍完成,接下来继续Kubernetes。
我们从Docker到Docker Compose都是在单机上完成,这样会带来一个很现实的问题就是高可用的问题,如果只部署到一台机器是无法做到高可用的,这样就不具备生产的条件;
Docker Compose只是简单做了单机服务的编排、扩容,对于多机器的管理、发布、服务发现、负载均衡都没有很好的解决;
目前我们所有的容器都是在单个宿主机上进行网络通信,多机情况的网络通信也没有解决方案;
针对以上三点,Docker给出了Docker Swarm的解决方案,Docker swarm可以让用户轻松在多个机器上发布和管理应用,并且我们不需要关注每个容器实例具体落在哪一个节点,Docker swarm把我们的应用以服务的形式暴露出去,并内置服务发现和负载均衡,让运行在多个节点上的容器集群感觉就像只有一个应用在跑一样简单,可以轻松实现扩容和自动容错。Docker swarm集群通常有几个工作程序节点和至少一个管理程序节点,负责高效地处理工作程序节点的资源并确保集群有效地运行,提高了应用可用性。
Manger 节点是负责管理工作的,从名字就可以看出,注意负责以下事情:
维护集群的状态;
对 Services 进行调度;
为 Swarm 集群提供外部可调用的 API 接口;
提供服务注册发现、负责均衡等功能;
Manager 节点需要时刻维护和保存当前 Swarm 集群中各个节点的一致性状态,在保证一致性上,Manager 节点采用 Raft 协议来保证分布式场景下的数据一致性;
Worker 节点是用来执行 Task 的;默认情况下 Manager 节点也同样是 Worker 节点,同样可以执行 Task;
Services 是指一组任务的集合,服务定义了任务的属性,比如任务的个数、服务策略、镜像的版本号等等,服务有两种模式:
Task是 Swarm 集群中的最小的调度单位,任务包含一个Docker容器和在容器内运行的命令,如果某一个任务奔溃,那么协调器将创建一个新的副本任务,该任务将生成一个新的容器;
Task调度主要分为两部分: Manager节点的任务分配和Worker节点的任务执行;
Manager节点的任务分配主要有以下四步:
用户通过 Docker Engine Client 使用命令 docker service create 提交 Service 定义;
Manager节点根据定义创建相应的 Task,并分配IP地址;
将Task分发到对应的节点上;
节点进行相应的初始化使得它可以执行Task;
Worker节点的任务执行主要有两步:
注意,上述 Task 的执行过程是一种单向机制,比如它会按顺序的依次经历 assigned, prepared 和 running 等执行状态,不过在某些特殊情况下,在执行过程中,某个 Task 执行失败了,Manager 的编排器会直接将该 Task 以及它的 Container 给删除掉,然后在其它节点上另外创建并执行该 Task;
Overlay Network:管理 Swarm 中 Docker 守护进程间的通信。你可以将服务附加到一个或多个已存在的 overlay 网络上,使得服务与服务之间能够通信;
Ingress Network:一个特殊的 overlay 网络,用于服务节点间的负载均衡。当任何 Swarm 节点在发布的端口上接收到请求时,它将该请求交给一个名为 IPVS 的模块。IPVS 跟踪参与该服务的所有IP地址,选择其中的一个,并通过 ingress 网络将请求路由到它。初始化或加入 Swarm 集群时会自动创建 ingress 网络,大多数情况下,用户不需要自定义配置,但是 docker 17.05 和更高版本允许你自定义;
Docker Gwbridge Network:一种桥接网络,将 overlay 网络连接到一个多带带的 Docker 守护进程的物理网络。默认情况下,服务正在运行的每个容器都连接到本地 Docker 守护进程主机的 docker_gwbridge 网络,一种桥接网络,将 overlay 网络(包括 ingress 网络)连接到一个多带带的 Docker 守护进程的物理网络。默认情况下,服务正在运行的每个容器都连接到本地 Docker 守护进程主机的 docker_gwbridge 网络;
Docker Swarm 数据流量分为两个层面:
节点全部使用CentOS8.2版, 这边准备了两个node节点和一个master节点:
保证每个主机之间都能相互ping通并且2377端口可以telnet保持畅通, 每个节点都安装了Docker。
docker swarm init --advertise-addr 172.16.0.191
docker swarm join --token SWMTKN-1-3cap7omkvmyuf0q1ybm868880eo5reoil8pcbovmejfzw6pil8-73hc367s4gitudqivrdirvu63 172.16.0.191:2377
docker node ls
# 创建服务 docker service create / --image nginx / --replicas 2 / nginx # 更新服务 docker service update / --image nginx:alpine / nginx # 删除服务 docker service rm nginx # 减少服务实例 docker service scale nginx=0 # 增加服务实例 docker service scale nginx=5 # 查看所有服务 docker service ls # 查看服务的容器状态 docker service ps nginx # 查看服务的详细信息。 docker service inspect nginx
docker service create --replicas 2 --name nginx --publish 8080:80 nginx
docker service ps swarm-nginx
curl 172.16.0.45:8080 curl 192.168.0.231:8080
Internal容器与容器之间通过overlay网络进行访问,通过service name进行通信,但是service name所对应的ip不是真实ip而是VIP,我们可以下面这个案例进行验证:
docker network create --driver overlay swarm-overlay #查看网络状况 docker network ls
docker service create --name nginx -p 8080:80 --network swarm-overlay -d nginx
docker service create --name busybox -d --network swarm-overlay busybox:1.28.3 sh -c while true; do sleep 7200; done
docker service ls
docker exec -it 2f55d73adfb4 sh ping nginx
当在任何一个Swarm节点去访问端口服务的时候会通过本节点的IPVS ( ip virtual service )到真正的Swarm节点上。提供以下三种功能:
外部访问的均衡负载;
服务端口暴露到各个Swarm节点;
内部通过IPVS进行均衡负载;
接着Internal案例继续进行探索,Swarm节点内部是如何进行转发的;
iptables -nL -t nat
brctl show
docker network inspect docker_gwbridge
#查找ingress_sbox位置 ls /var/run/docker/netns #进入ingress_sbox nsenter --net=/var/run/docker/netns/ingress_sbox #查看ingress_sbox iptables iptables -nL -t mangle
文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。
转载请注明本文地址:https://www.ucloud.cn/yun/125378.html
摘要:不要用百度搜索中文资料,一定要看最新的英文资料。感谢感谢能容忍我无数次搞挂生产环境的老板。群蜗牛大神所建中文交流群,基本配置过程中遇到的问题都能得到解决。 前言 最近花了将近一个月的时间研究了 Docker 在生产环境中的使用,作为新手,期间走了无数的弯路,这里纪录一下,希望给别人带来微小的帮助。 前面几部分,介绍了在搭建集群之前需要做的一些工作,后面 一块结合实际应用,介绍如何架构...
摘要:译者按实践中会发现,生产环境中使用单个节点是远远不够的,搭建集群势在必行。集群的网络通信服务发现,负载均衡以及容器间通信非常可靠。负载均衡也是由提供的。 译者按: 实践中会发现,生产环境中使用单个Docker节点是远远不够的,搭建Docker集群势在必行。然而,面对Kubernetes, Mesos以及Swarm等众多容器集群系统,我们该如何选择呢?它们之中,Swarm是Docker原...
摘要:由于没有了中心化的负载均衡器,集群不会因某台机器异常而导致整个服务对外不可用,很好的避免了单点问题,同时也带了可扩展性。 Mesos/Marathon 折腾久了,我们一直希望有机会深入到 Swarm 内部一探究竟。 另外, Mesos 这一套东西虽然是久经企业级考验的, 但是安装、部署和使用相对复杂,上手有门槛。同时,在今年的 DockerCon 上,内置了Swarm 功能的 Dock...
摘要:首先启动该命令。这项机制在实际生产当中无疑非常重要。那么下面我们回顾一下之前了解到的信息我们创建了一款小型动态微服务应用,完全由构成。在多数情况下,这能够为应用后端服务建立起独立的代理机制。 这次数人云与大家分享的文章里,主要介绍了Docker Swarm如何凭借革新对整体场景进一步加以简化。事实上,如今我们已经可以轻松且直观地构建起一套Docker Swarm集群,快来一起体验一下吧...
阅读 681·2023-04-25 19:43
阅读 3853·2021-11-30 14:52
阅读 3725·2021-11-30 14:52
阅读 3793·2021-11-29 11:00
阅读 3745·2021-11-29 11:00
阅读 3810·2021-11-29 11:00
阅读 3528·2021-11-29 11:00
阅读 6007·2021-11-29 11:00