大家好，DCOS中的服务发现和负载均衡相信很多的网友都不是很明白，包括也是一样，不过没有关系，接下来就来为大家分享关于DCOS中的服务发现和负载均衡和的一些知识点，大家可以关注收藏，免得下次来找不到哦，下面我们开始吧！

应用集群都是内部TCP服务调用负载均衡，不需要七层特性。

应用集群需要提供外部TCP和/或HTTP服务调用。

应用集群需要七层负载均衡功能，例如：TLS终止、零停机部署、HTTP粘性会话、负载均衡算法定制、网络ACL、HTTP基本身份验证、gzip压缩等。

应用集群的其他服务发现和负载均衡需求。

针对上述场景，DC/OS提供了VIP（Minuteman）、Marathon-LB、Mesos-DNS等服务组件和策略。

VIP (Minuteman) 是第4 层负载平衡实现，用于对DC/OS 集群内Mesos 任务之间的大多数TCP 流量进行负载平衡。

Marathon-LB (MLB) 是基于HAProxy 的实现，为Marathon 提供轻量级TCP/HTTP 路由和负载均衡服务。

Mesos-DNS 是一个简单的基于DNS 的服务发现工具，可用于Mesos 任务之间的服务发现。

VIPs

DC/OS 在内部微服务之间提供服务器端东西向（不同于Client-Server 的南北向）4 层负载均衡，称为Minuteman。为了促进服务配置和发现，DC/OS 使用基于名称的VIP 来定位服务。因此，当客户端访问服务时，它连接的是服务地址而不是特定的IP地址。同时，DC/OS可以轻松地将针对指定VIP的呼叫请求映射到多个特定的IP地址和端口，从而实现负载调度。使用命名VIP 的另一个好处是可以避免与基于IP 的VIP 发生冲突，并且可以在安装服务时自动创建冲突。

VIP的基本概念请参考文章《DCOS中的容器网络负载均衡与服务端口配置策略》。

基于VIPs的负载调度

将VIP_$IDX 标记添加到应用程序的端口定义中，允许应用程序服务启用第4 层负载（先决条件之一是应用程序通过运行状况检查）。当应用程序启动时，DC/OS会将VIP配置分发到集群中的所有节点，这些节点都充当负载均衡过程中的决策者。集群中的所有节点上都有一个进程在运行。当标有此VIP 的数据包到达时，此进程会跟踪这些应用程序服务的可用性和可访问性，以尝试将请求发送到正确的后端。

警告

不要为节点之间的流量添加防火墙过滤。

不要更改ip_local_port_range。

必须安装ipset 软件包。

需要支持的操作系统。

持久连接

建议在使用VIP 解决方案时保持长连接，否则TCP 套接字表可能会很快填满。 Linux 上默认允许的源连接使用范围从32768 到61000 的本地端口，这意味着给定的源IP 和目标地址端口对之间可以建立28232 个连接。 TCP 连接在被回收之前必须经过等待时间状态。 Linux内核默认的TCP时间等待周期是120秒。考虑到这一点，只要每秒创建235 个新连接，连接表就会在120 秒左右被耗尽。

健康检查

应用程序必须正常运行并通过健康检查才能使用VIP负载调度。不建议进行TCP 检查，因为它仅检查端口是否可用，并不能真正确认服务是否可用。

注意：在Docker 容器应用程序中使用命令运行状况检查时，命令命令在容器内运行。如果使用类似curl的命令，该命令必须在挂载的节点上或以RW模式挂载/opt/mesosphere路径。

潜在问题

IP覆盖

如果指定的VIP 地址在网络中的其他地方使用，则可能会出现问题。虽然VIP 是一个3 元组，但最好确保专用于VIP 的IP 仅用于负载均衡，而不会在网络中配置用于其他用途。因此，应选择RFC1918范围内的IP。

IP集

系统中必须安装IPset。如果没有，您可能会看到以下错误：

[错误] 未知响应： {ok，’iptables v1.4.21: 设置分钟人不存在。\n\n尝试“iptables -h”或“iptables –help”了解更多信息。\n’}端口

端口61420 和61421 必须打开，负载平衡才能正常工作。由于负载均衡维护了网格的一部分，因此需要确保节点之间的连接畅通。

连接表已耗尽

如果前面描述的行为耗尽了连接表，您将在日志中看到各种错误。可以通过设置两个sysctl 来缓解此问题，但不会抑制警告。

net.netfilter.nf_conntrack_tcp_timeout_time_wait=0 – 可以设置为0，但time_wait 状态可能会中断其他应用程序对连接的跟踪。

net.ipv4.tcp_tw_reuse=1 – 这个sysctl 可能很危险，它可以破坏防火墙以及NAT。虽然，如果防火墙正确实现了TCP 时间戳的跟踪，则不会存在此问题，但不要设置net.ipv4.tcp_tw_recycle sysctl，因为它不符合RFC，并且会破坏防火墙的连接跟踪。

更多信息请参考：https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt。

调试

负载平衡在DC/OS 集群中的每个节点上提供多个接口，用于收集统计信息。接口URI为：http://localhost:61421/metrics。

完成

本地进程大约每5 秒轮询一次主节点，并且主节点还将该节点缓存5 秒，因此更新的传播时间被限制在大约11 秒。这种情况仅适用于新的VIP，不适用于故障节点。

Marathon-LB

关于Marathon-LB的详细信息，请参考之前的文章《微服务弹性计算平台DCOS的服务入口—Marathon-LB》。作为对比，这里再次提到，Marathon-LB的应用场景非常灵活，比如：

Marathon-LB 可用于边缘节点，提供负载均衡和服务发现。在DCOS中，它可以部署在公共节点上，为入口流量提供路由负载。此时，Public节点的IP可以通过A记录与内部或外部DNS记录绑定。

Marathon-LB 可用于内部负载均衡和服务发现。外部流量的入口路由负载可以使用F5等硬件设备，也可以使用AWS的弹性负载均衡器（ELB）等云负载。

Marathon-LB 仅用于内部负载均衡和服务发现。

Marathon-LB可以同时用于内部LB和外部LB，根据需要对不同的Marathon-LB开放不同的服务。

Mesos-DNS

Mesos-DNS 为DC/OS 集群中的应用程序提供服务发现功能，允许DC/OS 上运行的应用程序和服务通过域名系统(DNS) 找到彼此。例如，可以为Marathon 或Aurora 启动的应用程序指定名称：search.marathon.mesos 或log-aggregator.aurora.mesos，Mesos-DNS 将这些名称转换为当前运行相应应用程序的主机上的IP 地址和端口。应用。要连接到DC\/OS 中的应用程序，您必须知道应用程序的名称。每次启动连接时，DNS 转换都会将这些连接指向数据中心中的正确主机。

Mesos-DNS 被设计为一种简化的、无状态的服务，易于部署和维护。下图描述了它的工作原理：

Mesos-DNS 会定期（默认30 秒）查询Master 节点，从所有正在运行的框架中检索所有正在运行的任务的状态，并为这些任务生成DNS 记录（A 和SRV 记录）。当任务在DC/OS 集群上启动、完成、失败或重新启动时，Mesos-DNS 会同时更新DNS 记录以反映应用程序的最新状态。

该框架不需要直接与Mesos-DNS 通信。 Agent节点上运行的应用程序和服务可以通过发出DNS查找请求或通过REST API发出HTTP请求来发现它们所依赖的其他应用程序的IP地址和端口，Mesos-DNS将直接回复这些请求。如果Agent 节点需要向DC\/OS 集群外部的主机名发出DNS 请求，Mesos-DNS 将直接查询外部DNS 服务器。仅当DC/OS 群集上的节点必须解析群集网络外部或Internet 上其他位置的系统的主机名时，才需要外部DNS 服务器。

当通过多个框架（而不仅仅是Marathon）加载应用程序时，Mesos-DNS 非常有用。每个容器都有一个IP，类似于Project Calico的解决方案。