Docker Swarm(三)Service(服务)分配策略

Service的分配原則

  • 預設分散至多個nodes上
  • 使用率較低的node優先配置
  • 使用者可自行定義此分配模式

Service分配的3種方式

  • Service Constraints (服务约束)

   参考:https://www.cnblogs.com/caoweixiong/p/12382282.html

  • Service Modes(服务模式)

    • 默认是replicated(副本),例如replica=10,docker swarm會執行10個container並盡可能分散到各個node上,但不能確保每個node都會配置到該task
    • Global(全局)是replica的相反,能確保每个节点都有一个任务
    • Global適用於host agents(monitoring, backup, proxy…)
    • 目前僅限於 service create 時設定
docker service create --mode=global portiner
  • Placement Preferences(安置偏好)

    • 目前只有spread這個策略

      • spread tasks among all values of a Label
      • 適用availablility zones, datacenters, racks, subnets > things where you want to spread workload out amongst various type of infrastructure
    • 可用於service create/update

      示例:Lable all nodes with availability zone

docker node update --label-add=azone=1 node1
docker node update --label-add=azone=2 node2
docker node update --label-add=azone=3 node3

根據這個Label加以分散:

docker service create --placement-pref spread=node.labels.azone --replicas 3 masl

 

原文地址:https://www.cnblogs.com/caoweixiong/p/12431510.html

时间: 2024-08-30 16:07:42

Docker Swarm(三)Service(服务)分配策略的相关文章

Docker入门 三 用服务来扩展和负载均衡你的应用

我们希望扩展和负载均衡自己的应用,为了达到这个目的,需要要分布式应用中使用更高一级的服务. 关于服务 对于分布式系统而言,不同的组成部分叫做"服务".例如,对于一个视频分享网站,它可能包含了一个往数据库存储的服务,一个在后台格式转换用户上传的东西的服务,一个负责前端展示的服务. 服务实际上就是生成中的容器,就从业务方面而言.一个服务只能运行一个镜像,但是它能控制容器运行的方式,比如使用什么网络端口,使用多少个容器副本等等.扩展一个服务,可以通过改变应用的每部分实例的数量,还可以通过在服

33. docker swarm 集群服务通信 之 RoutingMesh - Ingress 网络

1.作用 当在 任何 一个 swarm 节点去访问 端口服务的时候 会通过 本节点 的 IPVS ( ip virtual service ) 到 真正的 swarm 节点上 当访问 docker host 3 的 端口 8080 时, 会把 请求转发到 另外两台host 上去 , 然后把 响应返回给用户 2. 功能 外部访问的均衡负载 服务端口被暴露到哥哥swarm节点 内部通过 IPVS 进行均衡负载 3. 实验 创建 一个 名为 demo 的 overlay 网络 另外 创建 client

Docker swarm 获取service的container信息

我们可以通过docker service create创建服务,例如: docker service create --name mysql mysql:latest 服务创建好后,如何来获取该service包含的容器信息呢?比如获取刚才创建的mysql服务的容器.我们可以通过docker service ps命令来获取, 命令行方式 ~# docker service ps mysql ID NAME IMAGE NODE DESIRED STATE CURRENT STATE ERROR P

程序运行时三种内存分配策略

按照编译原理的观点,程序运行时的内存分配有三种策略,分别是静态的,栈式的,和堆式的. 静态存储分配是指在编译时就能确定每个数据目标在运行时刻的存储空间需求,因而在编译时就可以给他们分配固定的内存空间.这种分配策略要求程序代码中不允许有可变数据结构(比如可变数组)的存在,也不允许有嵌套或者递归的结构出现,因为它们都会导致编译程序无法计算准确的存储空间需求. 栈式存储分配也可称为动态存储分配,是由一个类似于堆栈的运行栈来实现的.和静态存储分配相反,在栈式存储方案中,程序对数据区的需求在编译时是完全未

docker swarm yaml

https://www.cnblogs.com/bigberg/p/8867326.html 一.简介 Docker有个编排工具docker-compose,可以将组成某个应该的多个docker容器编排在一起,同时管理.同样在Swarm集群中,可以使用docker stack 将一组相关联的服务进行编排管理. Docker stack 也是一个yaml文件,和一份docker-compose.yml文件差不多,指令也基本一致.但是与compose相比其不支持build.links和network

如何调用docker swarm service的API来创建及更新服务

平衡的推进,先作一个原型吧. #!/usr/bin/env python # -*- coding: utf-8 -*- import requests import json #定义docker swarm的管理节点ip,端口号,API版本,服务名, 服务URL #在后期集成到自动化部署时,需要精简数据结构,完善data, 增加精准判断及空间回收 #API更多用途参考: https://docs.docker.com/engine/api/v1.29/ docker_swarm_ip_port

docker swarm:执行 service update 过程中服务短暂不能访问的问题

这是我们使用自建 docker swarm 集群后在部署时遇到的一个问题,使用 docker service update 命令更新服务时, docker service update -d=false --force service_name 在更新的过程中服务有短暂的时间不能访问. 该服务中运行的是 asp.net core web api ,所使用的 Dockerfile 如下: FROM microsoft/aspnetcore:1.1.2 ARG PROJECT WORKDIR /ap

docker swarm英文文档学习-8-在集群中部署服务

Deploy services to a swarm在集群中部署服务 集群服务使用声明式模型,这意味着你需要定义服务的所需状态,并依赖Docker来维护该状态.该状态包括以下信息(但不限于): 应该运行服务容器的镜像名称和标记有多少容器参与服务是否有任何端口暴露给集群之外的客户端当Docker启动时,服务是否应该自动启动重启服务时发生的特定行为(例如是否使用滚动重启)服务可以运行的节点的特征(例如资源约束和位置首选项)有关群模式的概述,请参见 Swarm mode key concepts.有关

docker深入2-基于 swarm mode 的服务发现和注册

2017/9/4 注:[未完待续]标签,表明现在没空继续研究,后续再补上,现在先分享出来,或许有朋友正需要思路和帮助. 一.前言 1.目的 1)研究基于 swarm mode 的服务发现和注册 2)熟悉使用 go 和 python 来写 agent 调用 docker api/sdk 来达到上述目的. 3)docker api/sdk 参考  * docker api and sdk exp  * api ref: https://docs.docker.com/engine/api/v1.3