Docker Swarm原理大解密

Docker Swarm原理大解密

Docker Swarm是docker公司2014年出品的基于docker的集群管理调度工具，官方文档地址：https://docs.docker.com/swarm/overview/。Swarm能够把多台主机构建成一个docker的集群，用户可以只和swarm api操作来管理多个主机上的docker，再结合上Overlay的网络实现简单的容器调度和互访。

Docker Swarm在设计上遵从了可插拔的设计思想，安装集群只需要启动几个docker就可以完成，安装过程可以参考这里：http://www.tuicool.com/articles/UJJJFjU。

总结下Swarm的特性：
1.工作节点的注册和发现
2.管理节点收集集群中所有的信息
3.管理节点支持HA
4.管理节点能感知集群的变化，在节点挂掉后重新调度上面的container
5.提供filter和scheduler的调度策略调度集群里的容器

下面，本文会从源码层面解密Swarm是如何实现上面的特性的。

首先上一张整体的架构图。
来自daocloud的架构图。

http://blog.daocloud.io/wp-content/uploads/2015/01/swarmarchitecture.jpg

工作节点的注册和发现

在工作节点启动时会在后端的kvstore上注册一个节点，路径是etcd://ip:2376/docker/swarm/nodeip，Worker会把当前集群的eth0
的ip注册上etcd，然后设置上一个ttl时间，比如3秒。然后启一个for循环每隔2秒（配置heartbeat）注册一次，这样，如果etcd上这个节点没了就说明这个worker已经挂了。

for {
        log.WithFields(log.Fields{"addr": addr, "discovery": dflag}).Infof("Registering on the discovery service every %s...", hb)
        if err := d.Register(addr); err != nil {
            log.Error(err)
        }
        time.Sleep(hb)
    }

Manager的leader会启动一个go router watch后端的kvstore上注册上来的ip，如果是新节点注册上来就把节点加入到manager的内存中,开始收集数据，如果是节点挂了就删除

discoveryCh, errCh := cluster.discovery.Watch(nil)
go cluster.monitorDiscovery(discoveryCh, errCh)
go cluster.monitorPendingEngines()


for {
        select {
        case entries := <-ch:
            added, removed := currentEntries.Diff(entries)
            currentEntries = entries

        // Remove engines first. `addEngine` will refuse to add an engine
        // if there's already an engine with the same ID. If an engine
        // changes address, we have to first remove it then add it back.
            for _, entry := range removed {
                c.removeEngine(entry.String())
            }

            for _, entry := range added {
                c.addEngine(entry.String())
            }
        case err := <-errCh:
            log.Errorf("Discovery error: %v", err)
        }
    }

管理节点收集集群中所有的信息

管理节点会收集集群中所有主机的信息放到内存中。当一个主机加入到Swarm中时，首先会对节点上所有的信息都收集一把到内存中，然后会建立一个docker client长链接，通过event API获取这个主机上的更新。

加入主机时的代码，首先做主机的全同步，然后启动eventMonitor，监控主机上的event：

e.eventsMonitor = NewEventsMonitor(e.apiClient, e.handler) // Fetch the engine labels. if err := e.updateSpecs(); err != nil {
    return err
}

e.StartMonitorEvents()

// Force a state update before returning. if err := e.RefreshContainers(true); err != nil {
    return err
}

if err := e.RefreshImages(); err != nil {
    return err
}

// Do not check error as older daemon doesn't support this call. e.RefreshVolumes() e.RefreshNetworks() 

Event的Handler，会根据event的类别更新对应类型的数据。这里由于考虑docker event的兼容性有点长，我就只贴一段：

switch msg.Type {
case "network":
    e.refreshNetwork(msg.Actor.ID)
case "volume":
    e.refreshVolume(msg.Actor.ID)
case "image":
    e.RefreshImages()
case "container":
    action := msg.Action
    // healthcheck events are like 'health_status: unhealthy'
    if strings.HasPrefix(action, "health_status") {
        action = "health_status"
    }
    switch action {
    case "commit":
        // commit a container will generate a new image
        e.RefreshImages()
    case "die", "kill", "oom", "pause", "start", "restart", "stop", "unpause", "rename", "update", "health_status":
        e.refreshContainer(msg.ID, true)
    case "top", "resize", "export", "exec_create", "exec_start", "exec_detach", "attach", "detach", "extract-to-dir", "copy", "archive-path":
        // no action needed
    default:
        e.refreshContainer(msg.ID, false)

管理节点支持HA

同其他很多的分布式的项目一样，Docker Swarm也是利用了raft里选举算法做的HA，我们来看下它的实现。

首先创建好candidata和follower，顺便说下leader election的path是docker/swarm/leader

client := kvDiscovery.Store()
p := path.Join(kvDiscovery.Prefix(), leaderElectionPath)

candidate := leadership.NewCandidate(client, p, addr, leaderTTL)
follower := leadership.NewFollower(client, p)

然后启两个协程，一个进行选举，如果成功了则成为leader，一个监听选举成功的消息，如果监听到别的manager成为leader则把自己设置成candidate，如果API请求到candidate会proxy到真正的manager。

primary := api.NewPrimary(cluster, tlsConfig, &statusHandler{cluster, candidate, follower}, c.GlobalBool("debug"), c.Bool("cors"))
replica := api.NewReplica(primary, tlsConfig)

go func() {
    for {
        run(cluster, candidate, server, primary, replica)
        time.Sleep(defaultRecoverTime)
    }
}()

go func() {
    for {
        follow(follower, replica, addr)
        time.Sleep(defaultRecoverTime)
    }
}()

server.SetHandler(primary)

管理节点能感知集群的变化，在节点挂掉后重新调度上面的container

由于worker会loop往kvstore上发送消息，因此如果节点挂掉时manager能立刻感知到变化，并触发removeEngine的动作，把container重新调度到其他节点上就很容易做到了。

提供filter和scheduler的调度策略调度集群里的容器

其实有了所有集群里的所有节点的信息，调度容器就变得比较简单了。Swarm提供了Filter和scheduler来让用户定义调度的策略。

调度本质上是让用户可以定义Container分配到集群中的策略。
Filter指定了如果满足这样的条件的节点不会（会）被分配上。
Scheduler指定了满足Filter后的节点按照怎样的优先级排序，排在前面的会被有限分配上Container。

Filter和Scheduler的种类我就不赘述了，可以参考官方文档：https://docs.docker.com/swarm/scheduler/rescheduling/#rescheduling-policies （貌似最近又有了新的策略 rescheduler）

调度的代码如下：

accepted, err := filter.ApplyFilters(s.filters, config, nodes, soft)
if err != nil {
    return nil, err
}

if len(accepted) == 0 {
    return nil, errNoNodeAvailable
}

return s.strategy.RankAndSort(config, accepted)

在使用Docker Swarm的时候大家其实可以发现，Swarm的设计还是有一些缺陷的，这会导致Swarm的一些局限性，比如：

1.worker的行为过于简单。只是往kvstore上同步状态，就启动一个Container，不做任何实际的工作，把所有活都交给Manager干，颇为浪费。
2.由于worker”啥也不干“，Manager必须保持所有节点的tcp长链接，扩展性很差。
3.没有加入副本控制。

总结下，Swarm作为一代的Docker调度工具提供了基本的调度能力，可以满足一些内部的CI/CD系统使用，但是由于扩展性较差和没有副本控制，不能直接拿来部署线上系统，这是有的遗憾的。