Consul实践指导-DNS接口

最新推荐文章于 2024-08-29 13:11:19 发布

weixin_34259559

最新推荐文章于 2024-08-29 13:11:19 发布

阅读量430

点赞数

文章标签：运维数据库大数据

DNS是consul提供的主要查询接口之一。DNS接口允许应用程序在没有与consul高度集成的情况下使用服务发现。

例如：替代consul的HTTP API请求，主机能够通过名字查找直接使用DNS服务器，类似"redis.service.east-aws.consul"，此查询自动转换为查找位于数据中心"east-aws"节点提供的redis服务——没有故障的redis健康检查。它是如此简单！

如果要使用DNS接口，必须配置一些重要的参数client_addr, ports.dns, recursors, dns_config等。

默认情况下，Consul监听127.0.0.1:8600,使用.consul域提供DNS查询服务，但不支持进一步的DNS递归。

相关参数请参考https://www.consul.io/docs/agent/options.html

使用DNS接口的方法有多种。

一种方法是在consul中自定义DNS解析器动态库。另一个方法是为节点设置Consul的DNS服务器，并提供recursors配置，也可以解决non-Consul查询。最后一种方法是将所有的关于"consul."域的查询都从现有的DNS服务器转移consul Agent。

可以尝试使用的Consul DNS服务器的命令行工具dig：

$ dig @127.0.0.1 -p8600 redis.service.dc1.consul. ANY

注：在DNS中，都是不区分大小写的。比如PostgreSQL.node.dc1.consul会查询所有节点中名字为postgresql的节点。

1.1.1 节点查找

要解决名称，Consul依赖于非常具体的查询格式。基本上有两种类型的查询：节点查找和服务查找。

节点查找，类似如下：包含节点的address

<node>.node[.datacenter].<domain>

例如，如果有默认节点“foo”，可以查找“foo.node.dc1.consul.”其中数据中心名称dc1是可选参数，如果不提供，Agent将选择默认数据中心——agent肯定属于一个数据中心。可以采用"foo.node.consul."进行查找，本约束可以在适当的地方使用，同时支持在远程数据中心得节点查询。

节点查找，唯一的返回记录——包含节点IP地址的A记录。

$ dig @127.0.0.1 -p8600 foo.node.consul ANY
; <<>>DiG 9.8.3-P1 <<>> @127.0.0.1 -p 8600 foo.node.consul ANY
; (1 server found)
;; global options:+cmd
;; Got answer:
;;->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24355
;; flags: qr aa rd;QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0
;; WARNING: recursionrequested but not available

;; QUESTION SECTION:
;foo.node.consul. IN ANY
;; ANSWER SECTION:
foo.node.consul. 0 IN A 10.1.10.12

;; AUTHORITYSECTION:
consul. 0 IN SOA ns.consul.postmaster.consul. 1392836399 3600 600 86400 0

1.1.2 服务查询

服务查找用于查询服务提供者。服务查询支持两种查找方法：标准和严格RFC 2782。

1.1.2.1 标准查找

格式如下：

[tag.]<service>.service[.datacenter].<domain>

Tag是可选的，而且与节点查找一样，数据中心也是可选。如果没有提供Tag，就不会有过滤，如果没有数据中心，就会选择默认的数据中心。

在本地数据中心，如果想查找redis服务提供商，可以通过命令"redis.service.consul.",如果想在指定的数据中心中查找PostgreSQL master，命令如下"master.postgresql.service.dc2.consul."

DNS查询系统利用健康检查以防止不良节点路由信息。当服务查询时，如果服务健康检查失败或者系统检查失败，服务信息将会从查询结果中删除。为了实现简单的负载平衡，返回的节点集合每次都是随机的。这种机制使得利用DNS接口基于应用级重试实现面向auto-healing服务体现架构变得更加容易。

标准服务查询，不但支持A record，还支持SRV record。。SRV reconds提供服务注册的端口，使客户能够避免依赖于众所周知的端口。只有client端指定时，SRV record才会提供服务。命令如下：

$ dig @127.0.0.1 -p8600 consul.service.consul SRV
 
 
 
; <<>>DiG 9.8.3-P1 <<>> @127.0.0.1 -p 8600 consul.service.consul ANY
 
; (1 server found)
 
;; global options:+cmd
 
;; Got answer:
 
;;->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50483
 
;; flags: qr aa rd;QUERY: 1, ANSWER: 3, AUTHORITY: 1, ADDITIONAL: 1
 
;; WARNING:recursion requested but not available
 
 
 
;; QUESTION SECTION:
 
;consul.service.consul. IN SRV
 
 
 
;; ANSWER SECTION:
 
consul.service.consul. 0 IN SRV 1 1 8300foobar.node.dc1.consul.
 
 
 
;; ADDITIONALSECTION:
 
foobar.node.dc1.consul.0 IN A 10.1.10.12

1.1.2.2 RFC2782 查找

格式如下：

_<service>._<protocol>.service[.datacenter][.domain]

根据RFC 2782， SRV请求都应该在service和protocol前使用(_)作为前缀。避免发生DNS冲突。Protocol可以是service任何一个tag，如果service没有tag，使用tcp作为protocol。如果一旦设置了tcp，那么查询时将不会执行任何标签过滤。

处理查询格式和默认的tcp外， RFC查找方式与标准查找是相同的。

假设通过port5672和Tag “amqp”注册服务"rabbitmq"，可以发现RFC2782的SRV查询，如"_rabbitmq._amqp.service.consul":

$ dig @127.0.0.1 -p8600 _rabbitmq._amqp.service.consul SRV
 
 
 
; <<>>DiG 9.8.3-P1 <<>> @127.0.0.1 -p 8600 _rabbitmq._amqp.service.consulANY
 
; (1 server found)
 
;; global options:+cmd
 
;; Got answer:
 
;;->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52838
 
;; flags: qr aa rd;QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
 
;; WARNING:recursion requested but not available
 
 
 
;; QUESTION SECTION:
 
;_rabbitmq._amqp.service.consul. IN SRV
 
 
 
;; ANSWER SECTION:
 
_rabbitmq._amqp.service.consul.0 IN SRV 1 1 5672 rabbitmq.node1.dc1.consul.
 
 
 
;; ADDITIONALSECTION:
 
rabbitmq.node1.dc1.consul. 0 IN A 10.1.11.20