DC/OS 域名服务

了解 DC/OS 域名服务发现

DC/OS 提供基于 DNS 的分布式容错性服务发现机制。

DNS 由 DC/OS 中的两个不同组件 mesos-dns 和 dcos-dns 提供。这些组件支持两个顶级域 (TLD) 名，即 .mesos 和 .directory。请阅读 建议 部分和 Mesos-DNS，更好地了解这两个 TLD 的使用。

每个 TLD 均由多个区域组成。每个 DC/OS 服务从这些不同区域获取多个 FQDN 条目。通过 Marathon 在 DC/OS 上启动的每个服务都以下列形式获得 FQDN，即 <service-name>.mesos。此外，在 DC/OS 上启动的所有运行服务都基于启动它的服务获得 FQDN，格式为 <service-name>.<group-name>.<framework-name>.mesos。

假设以下 UCR 容器在 DC/OS 上启动：

  1. {
  2.   "id": "/mygroup/myapp",
  3.   "instances": 1,
  4.   "container": {
  5.     "type": "MESOS",
  6.     "docker": {
  7.       "image": "nginx"
  8.     },
  9.     "portMappings": [
  10.       {
  11.         "containerPort": 80,
  12.         "labels": {
  13.           "VIP_0": "/mygroup/myapp:80"
  14.         },
  15.         "name": "http"
  16.       }
  17.     ]
  18.   },
  19.   "cpus": 0.1,
  20.   "mem": 32,
  21.   "networks": [
  22.     {
  23.       "name": "dcos",
  24.       "mode": "container"
  25.     }
  26.   ],
  27. }

示例 1：在 DC/OS 上启动的 UCR 容器

不同的区域以及与这些区域有关的 FQDN 如下所述，连同服务从特定区域使用 FQDN 访问时接收的网络连接类型。

myapp.mygroup.marathon.mesos

此 FQDN 由 mesos-dns 展示为 A 记录。请阅读 建议 部分，了解使用此 FQDN 和从 *.directory TLD 使用 FQDN 之间的区别。此 FQDN 映射到的实际 IP 地址将取决于容器正在使用的网络模式。对于 host 和 bridge 模式网络，此 FQDN 将解析到启动容器的代理 IP 地址；对于 container 模式网络，它将解析到容器的 IP 地址。在 示例 1 中，FQDN 将解析到容器的 IP 地址，因为它正在使用 container 网络模式。

myapp-mygroup.marathon.containerip.dcos.thisdcos.directory

此 FQDN 由 dcos-dns 展示为 A 记录。对于 container 和 bridge 模式网络，此 FQDN 将解析到容器的代理 IP 地址；对于 host 模式网络，它将解析到启动容器的代理 IP 地址。在当前示例中，framework-name 为 marathon。FQDN 将解析到容器的 IP 地址，因为它正在使用 container 网络模式。

myapp-mygroup.marathon.agentip.dcos.thisdcos.directory

此 FQDN 由 dcos-dns 展示为 A 记录。此 FQDN 将始终解析到运行容器的代理 IP，无论网络模式如何。

myapp-mygroup.marathon.autoip.dcos.thisdcos.directory

此 FQDN 由 dcos-dns 展示为 A 记录。顾名思议，autoip FQDN 可以解析到最有可能到达容器的 IP 地址。例如，如果容器可通过代理 IP 到达，正如在主机和网桥模式网络中一样，autoip FQDN 将解析到代理 IP。同样，在容器模式网络中，它将解析到容器的 IP 地址。

mygroupmyapp.marathon.l4lb.thisdcos.directory

如果某个服务明确定义 VIP 标签作为其应用定义的一部分，它将获得 FQDN <group-name><service-name>.<framework-name>.l4lb.thisdcos.directory

在上面的示例 1 中，标签类似于：

  1. "labels": {
  2.     "VIP_0": "/mygroup/myapp:80"
  3. }

此 FQDN 由 dcos-dns 展示为 A 记录。它主要用于第 4 层负载均衡。它解析到 dcos-l4lb 在 11.x.x.x 范围内分配的虚拟 IP，然后映射到与此服务对应的所有实例。

SRV 记录

有关 Mesos DNS SRV 记录的完整描述，请参阅 SRV 记录。

  • 对于由名为 myservice 的服务启动的名为 mytask 的任务，Mesos-DNS 生成一个 SRV 记录 _mytask._protocol.myservice.mesos，其中 protocol 为 udp 或 tcp。

  • 有关 Mesos-DNS 中命名任务和服务的更多信息，请参阅 任务和服务命名约定。

myapp.mygroup./_tcp.marathon.mesos:

如果某个服务在应用定义中明确为其端口分配名称，则它会获得 FQDN _<service-name>.<group-name>._<protocol>.<framework-name>.mesos。

此 FQDN 由 mesos-dns 展示为 SRV 记录。

除用于 Marathon 以外其他框架的 FQDN

示例 1 使用 Marathon，这是 DC/OS 中的默认框架。但还有其他框架也可以在 DC/OS 之上运行，如 Kafka、Cassandra、Spark 等。DC/OS 中的 DNS 基础架构也生成上面所述的 FQDN，用于这些框架启动的服务。唯一的区别就是名称 marathon 被该框架的名称替换，以建立 FQDN。例如，由框架启动的服务 kafka 具有 FQDN，例如：

  • <taskname>.kafka.l4lb.thisdcos.directory
  • <taskname>.kafka.containerip.dcos.thisdcos.directory
  • <taskname>.kafka.agentip.dcos.thisdcos.directory
  • <taskname>.kafka.autoip.dcos.thisdcos.directory
  • <taskname>.kafka.mesos

建议

.mesos TLD 先于 .directory TLD，主要是为了向后兼容。虽然在 DC/OS 上启动的任何服务都将在 .mesos TLD 和 .directory TLD 中获取 FQDN，但建议使用 .directory TLD 来访问服务，因为在设计上，dcos-dns 比 mesos-dns 的反应性和容错性要好。也就是说，mesos-dns 确实提供 RESTful 界面用于访问其记录，使得 .mesos TLD 可通过 HTTP 接口而不只是通过 DNS 来获取。

[

Mesos-DNS

了解 Mesos DNS…

]($ba0aae13384b252f.md)