[jboss-jira] [JBoss JIRA] (JGRP-2316) DNS_PING is not using correct ports with SRV based service discovery
Sebastian Łaskawiec (Jira)
issues at jboss.org
Tue Dec 4 05:47:00 EST 2018
[ https://issues.jboss.org/browse/JGRP-2316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13669871#comment-13669871 ]
Sebastian Łaskawiec commented on JGRP-2316:
-------------------------------------------
h2. Experiments
I did some tests with my [DNS_PING example repo|https://github.com/slaskawi/jgroups-dns-ping-example] and I managed to confirm a couple of things.
Kubernetes populates DNS entries based on Services. If we want to use DNS-based discovery, we need to specify a Service for our {{Deployment}} or {{DeploymentConfig}}. [~belaban] Please note, that with your Service definition, you specified a port - it's {{8888}}.
{code}
publishNotReadyAddresses: true
clusterIP: None
ports:
- name: ping
port: 8888
protocol: TCP
targetPort: 8888
selector:
deploymentConfig: jgrp
{code}
Kubernetes uses that port ({{8888}}) to populate {{SRV}} entries in DNS. I ran a similar example to yours but based on my repo. Here are the results:
*Dig for A Entries*
{code}
$ dig +search jgroups-dns-ping.myproject.svc.cluster.local
; <<>> DiG 9.9.4-RedHat-9.9.4-72.el7 <<>> +search jgroups-dns-ping.myproject.svc.cluster.local
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30214
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;jgroups-dns-ping.myproject.svc.cluster.local. IN A
;; ANSWER SECTION:
jgroups-dns-ping.myproject.svc.cluster.local. 30 IN A 172.17.0.11
jgroups-dns-ping.myproject.svc.cluster.local. 30 IN A 172.17.0.9
;; Query time: 0 msec
;; SERVER: 172.30.0.2#53(172.30.0.2)
;; WHEN: Tue Dec 04 09:58:17 UTC 2018
;; MSG SIZE rcvd: 94
{code}
*Dig for SRV Entries*
{code}
$ dig +search SRV _ping._tcp.jgroups-dns-ping.myproject.svc.cluster.local
; <<>> DiG 9.9.4-RedHat-9.9.4-72.el7 <<>> +search SRV _ping._tcp.jgroups-dns-ping.myproject.svc.cluster.local
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38422
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2
;; QUESTION SECTION:
;_ping._tcp.jgroups-dns-ping.myproject.svc.cluster.local. IN SRV
;; ANSWER SECTION:
_ping._tcp.jgroups-dns-ping.myproject.svc.cluster.local. 30 IN SRV 10 50 8888 c1fc9dd.jgroups-dns-ping.myproject.svc.cluster.local.
_ping._tcp.jgroups-dns-ping.myproject.svc.cluster.local. 30 IN SRV 10 50 8888 8489e066.jgroups-dns-ping.myproject.svc.cluster.local.
;; ADDITIONAL SECTION:
c1fc9dd.jgroups-dns-ping.myproject.svc.cluster.local. 30 IN A 172.17.0.11
8489e066.jgroups-dns-ping.myproject.svc.cluster.local. 30 IN A 172.17.0.9
;; Query time: 1 msec
;; SERVER: 172.30.0.2#53(172.30.0.2)
;; WHEN: Tue Dec 04 09:58:53 UTC 2018
;; MSG SIZE rcvd: 250
{code}
Note, that SRV entries contain port {{8888}} (as I expected in my previous comment). So there's no dynamic remapping in Kubernetes (!!!).
h2. Answering comments
So based on experiment above, let me answer your comments:
{quote}
I do not want to define the ports in multiple locations; the authoritative location for JGroups ports is the JGroups config file. Having to define the same port in multiple files is error-prone and unmaintainable
{quote}
In Kubernetes, that's not doable. Note, that you need to specify a port in Service definition. However, it is possible to use a transport port on the service and then iterate over a well-known port range. That should work without any problems. But the bottom line is, that you need to put something into the Service definition. Perhaps, we should always put a transport port there?
{quote}
A lot of protocols (UDP/TCP, FD_SOCK, STATE_SOCK) do not define a static port; the default is 0, which means the OS picks an ephemeral port.
{quote}
That should be fine as long as you know how to discover this port and how to connect to it. In this use case, it's not really different from on-prem solutions.
h2. Conclusions
I think your concerns are valid to some extent, Bela. So far we've been usually using port {{8888}} in our examples but it hasn't been actively used in our implementation (it's ignored by DNS A records by definition, and due to the previous implementation, it was also ignored by DNS SRV records resolution). I think we should be using transport port in our Service definition and introduce a property to DNS_PING that would indicate, whether or not ports obtained from DNS shall be used or ignored.
> DNS_PING is not using correct ports with SRV based service discovery
> --------------------------------------------------------------------
>
> Key: JGRP-2316
> URL: https://issues.jboss.org/browse/JGRP-2316
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.15
> Reporter: dmcnair
> Assignee: Bela Ban
> Priority: Major
>
> This is a follow-up to JGRP-2296 - which changed `DefaultDNSResolver.java` to preserve the port for SRV records. While that change is working as desired, `DNS_PING.java` is not using the port when doing member discovery.
> Here are the log entries using *4.0.15*
> {noformat}
> 2018-11-29 21:37:41,561 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-4,null,null) Entries collected from DNS (in 5 ms): [172.29.11.50:27106, 172.29.11.50:27105]
> 2018-11-29 21:37:41,562 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-4,null,null) 982d38761cba: sending discovery requests to hosts [172.29.11.50:27106, 172.29.11.50:27105] on ports [7600 .. 7600]
> {noformat}
> Since the port was found via the SRV record, it should be used instead of the *transportPort* port.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
More information about the jboss-jira
mailing list