Answers: <p>Yes you can by doing a DNS SRV lookup. Here's an example:</p>
  
  <pre><code>$ kubectl run -it srvlookup --image=tutum/dnsutils --rm --restart=Never -- dig SRV jira-headless.default.svc.cluster.local
  
  ; &lt;&lt;&gt;&gt; DiG 9.9.5-3ubuntu0.2-Ubuntu &lt;&lt;&gt;&gt; SRV jira-headless.default.svc.cluster.local
  ;; global options: +cmd
  ;; Got answer:
  ;; -&gt;&gt;HEADER&lt;&lt;- opcode: QUERY, status: NOERROR, id: 56846
  ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2
  
  ;; QUESTION SECTION:
  ;jira-headless.default.svc.cluster.local. IN SRV
  
  ;; ANSWER SECTION:
  jira-headless.default.svc.cluster.local. 30 IN SRV 10 50 0 jira-0.jira-headless.default.svc.cluster.local.
  jira-headless.default.svc.cluster.local. 30 IN SRV 10 50 0 jira-1.jira-headless.default.svc.cluster.local.
  
  ;; ADDITIONAL SECTION:
  jira-0.jira-headless.default.svc.cluster.local. 30 IN A 10.244.11.152
  jira-1.jira-headless.default.svc.cluster.local. 30 IN A 10.244.0.188
  
  ;; Query time: 6 msec
  ;; SERVER: 10.233.0.3#53(10.233.0.3)
  ;; WHEN: Fri Jun 28 00:18:14 UTC 2019
  ;; MSG SIZE  rcvd: 143
  </code></pre>
  
  <p>In the example above I have a headless Service called <code>jira-headless.</code> If you pay attention to <code>ADDITIONAL SECTION:</code> you'll notice it provides the SRV record in the following format:</p>
  
  <p><code>_service._proto.name. TTL class SRV priority weight port target.</code></p>
  
  <p>Which maps to the Pods (along with their IPs) backing the Service:</p>
  
  <pre><code>jira-0.jira-headless.default.svc.cluster.local. 30 IN A 10.244.11.152
  jira-1.jira-headless.default.svc.cluster.local. 30 IN A 10.244.0.188
  </code></pre>
  
Answers: CC BY-SA 4.0
Answers: 2019-06-28T00:23:38.533Z
Answers: 2019-06-28T00:23:38.533Z
Answers: kaizenCoder
Body: <p>Is there some metadata that I can apply, or some DNS that I can query, such that when a pod is started, the addreses of all the other pods in that statefulset will be somehow made available to the newly started pod?</p>
  
  <p>I want to run a stateful application (Riak) where every node (pod) in the Riak cluster needs to be aware of the addresses of every other node (pod).</p>
  
  <p>Using the kubernetes statefulset controller, pods are started one by one.</p>
  
  <p>I also wonder how I can somehow listen for some event in each Riak pod so that as instances are started, all the preceeding instances will be made aware of the new instance?</p>
  
  <hr>
  
  <p>Following on from the information provided by @kaizenCoder - I modified the service so it had a configuration of :</p>
  
  <pre><code>spec:
    clusterIP: None
  </code></pre>
  
  <p>I then scaled up to two replicas, exec'd to one of the containers and ran <code>dig</code> again as mentioned.</p>
  
  <pre><code>root@grafana-0:/usr/share/grafana# dig SRV grafana.default.svc.cluster.local
  
  ; &lt;&lt;&gt;&gt; DiG 9.10.3-P4-Debian &lt;&lt;&gt;&gt; SRV grafana.default.svc.cluster.local
  ;; global options: +cmd
  ;; Got answer:
  ;; -&gt;&gt;HEADER&lt;&lt;- opcode: QUERY, status: NOERROR, id: 27002
  ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 3
  ;; WARNING: recursion requested but not available
  
  ;; OPT PSEUDOSECTION:
  ; EDNS: version: 0, flags:; udp: 4096
  ;; QUESTION SECTION:
  ;grafana.default.svc.cluster.local. IN  SRV
  
  ;; ANSWER SECTION:
  grafana.default.svc.cluster.local. 5 IN SRV     0 50 55555 10-1-0-77.grafana.default.svc.cluster.local.
  grafana.default.svc.cluster.local. 5 IN SRV     0 50 55555 10-1-0-78.grafana.default.svc.cluster.local.
  
  ;; ADDITIONAL SECTION:
  10-1-0-78.grafana.default.svc.cluster.local. 5 IN A 10.1.0.78
  10-1-0-77.grafana.default.svc.cluster.local. 5 IN A 10.1.0.77
  
  ;; Query time: 0 msec
  ;; SERVER: 10.96.0.10#53(10.96.0.10)
  ;; WHEN: Fri Jun 28 12:12:32 UTC 2019
  ;; MSG SIZE  rcvd: 372
  </code></pre>
  
  <p>Much better - but unlike @kaizenCoder - I don't get back a name for each of the pods - it just uses the IP address - the names don't match - I would have expected the first pod to have had a name of <code>grafana-0.grafana.default.svc.cluster.local</code> - that nodes hostname is correct though - <code>grafana-0</code>.</p>
  
  <p>Any suggestions on how to get the DNS to match the hostname ?</p>
  
  <hr>
  
  <p>Update again - more weirdness - the other pods don't seem to be resolvable by hostname.</p>
  
  <pre><code>root@grafana-0:/usr/share/grafana# ping grafana-1
  ping: unknown host
  </code></pre>
  
  <p>Presumably hostname only resolves in the pod as hostname resolves to 127.0.0.1 ... Which makes it a bit worthless tbh.</p>
  
  <p>I feel like I've made some progress but still missing a piece. When a container starts up, how can software within it resolve : </p>
  
  <ol>
  <li>It's own fully qualified name </li>
  <li>The fully qualified names of all the other statefulset pods</li>
  </ol>
  
  <p>I could do something like this to determine the node name and the other node names but it feels ugly.</p>
  
  <pre><code>root@grafana-0:/usr/share/grafana# dig SRV *.default.svc.cluster.local | grep 0-77 
  *.default.svc.cluster.local. 5  IN      SRV     0 11 55555 10-1-0-77.grafana.default.svc.cluster.local.
  10-1-0-77.grafana.default.svc.cluster.local. 5 IN A 10.1.0.77
  root@grafana-0:/usr/share/grafana# ip addr | grep eth0 | grep inet
      inet 10.1.0.77/16 scope global eth0
  </code></pre>
  
Comments: CC BY-SA 4.0
Comments: 2019-06-29T01:30:51.270Z
Comments: "I then scaled up to two replicas". Is grafana a StatefulSet, Deployment or something else?
Comments: kaizenCoder
Comments: CC BY-SA 4.0
Comments: 2019-06-29T01:56:24.007Z
Comments: To clarify further, from what I've seen you will get the IPs if you are using a Deployment (by default). Only StatefulSets will provide a Pod name with the ordinal index.
Comments: kaizenCoder
Comments: CC BY-SA 4.0
Comments: 2019-06-30T16:19:39.630Z
Comments: @kaizenCoder - grafana is just something I happened to have laying around. The real reason I'm looking for this metadata is for distributed Elixir or Riak nodes. Each node that starts up needs to be aware of its own FQDN and that of the other nodes currently active in the set
Comments: bryan hunt
Comments: CC BY-SA 4.0
Comments: 2019-06-30T16:27:44.413Z
Comments: Maybe this is a bug - I've just been reading https://github.com/kubernetes/kubernetes/issues/57671 and it seems people have had similar issues.
Comments: bryan hunt
Tags: <kubernetes><dns>
Title: kubernetes statefulset - communicate addresses of other pods when pod launches?
UserDisplayName: bryan hunt
ThreadText: # kubernetes statefulset - communicate addresses of other pods when pod launches?
  
  (Asked by: username_0 on 2019-06-27)
  
  Is there some metadata that I can apply, or some DNS that I can query, such that when a pod is started, the addreses of all the other pods in that statefulset will be somehow made available to the newly started pod?
  
  I want to run a stateful application (Riak) where every node (pod) in the Riak cluster needs to be aware of the addresses of every other node (pod).
  
  Using the kubernetes statefulset controller, pods are started one by one.
  
  I also wonder how I can somehow listen for some event in each Riak pod so that as instances are started, all the preceeding instances will be made aware of the new instance?
  
  ---
  
  Following on from the information provided by @username_1 - I modified the service so it had a configuration of :
  
  ```
  spec:
    clusterIP: None
  
  ```
  
  I then scaled up to two replicas, exec'd to one of the containers and ran `dig` again as mentioned.
  
  ```
  root@grafana-0:/usr/share/grafana# dig SRV grafana.default.svc.cluster.local
  
  ; <<>> DiG 9.10.3-P4-Debian <<>> SRV grafana.default.svc.cluster.local
  ;; global options: +cmd
  ;; Got answer:
  ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27002
  ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 3
  ;; WARNING: recursion requested but not available
  
  ;; OPT PSEUDOSECTION:
  ; EDNS: version: 0, flags:; udp: 4096
  ;; QUESTION SECTION:
  ;grafana.default.svc.cluster.local. IN  SRV
  
  ;; ANSWER SECTION:
  grafana.default.svc.cluster.local. 5 IN SRV     0 50 55555 10-1-0-77.grafana.default.svc.cluster.local.
  grafana.default.svc.cluster.local. 5 IN SRV     0 50 55555 10-1-0-78.grafana.default.svc.cluster.local.
  
  ;; ADDITIONAL SECTION:
  10-1-0-78.grafana.default.svc.cluster.local. 5 IN A 10.1.0.78
  10-1-0-77.grafana.default.svc.cluster.local. 5 IN A 10.1.0.77
  
  ;; Query time: 0 msec
  ;; SERVER: 10.96.0.10#53(10.96.0.10)
  ;; WHEN: Fri Jun 28 12:12:32 UTC 2019
  ;; MSG SIZE  rcvd: 372
  
  ```
  
  Much better - but unlike @username_1 - I don't get back a name for each of the pods - it just uses the IP address - the names don't match - I would have expected the first pod to have had a name of `grafana-0.grafana.default.svc.cluster.local` - that nodes hostname is correct though - `grafana-0`.
  
  Any suggestions on how to get the DNS to match the hostname ?
  
  ---
  
  Update again - more weirdness - the other pods don't seem to be resolvable by hostname.
  
  ```
  root@grafana-0:/usr/share/grafana# ping grafana-1
  ping: unknown host
  
  ```
  
  Presumably hostname only resolves in the pod as hostname resolves to 127.0.0.1 ... Which makes it a bit worthless tbh.
  
  I feel like I've made some progress but still missing a piece. When a container starts up, how can software within it resolve :
  
  1. It's own fully qualified name
  2. The fully qualified names of all the other statefulset pods
  
  I could do something like this to determine the node name and the other node names but it feels ugly.
  
  ```
  root@grafana-0:/usr/share/grafana# dig SRV *.default.svc.cluster.local | grep 0-77 
  *.default.svc.cluster.local. 5  IN      SRV     0 11 55555 10-1-0-77.grafana.default.svc.cluster.local.
  10-1-0-77.grafana.default.svc.cluster.local. 5 IN A 10.1.0.77
  root@grafana-0:/usr/share/grafana# ip addr | grep eth0 | grep inet
      inet 10.1.0.77/16 scope global eth0
  
  ```
  
  **Tags:** kubernetes, dns
  
  > **Comments:**
  > **username_1**: "I then scaled up to two replicas". Is grafana a StatefulSet, Deployment or something else?  
  > **username_1**: To clarify further, from what I've seen you will get the IPs if you are using a Deployment (by default). Only StatefulSets will provide a Pod name with the ordinal index.  
  > **username_0**: @username_1 - grafana is just something I happened to have laying around. The real reason I'm looking for this metadata is for distributed Elixir or Riak nodes. Each node that starts up needs to be aware of its own FQDN and that of the other nodes currently active in the set  
  > **username_0**: Maybe this is a bug - I've just been reading https://github.com/kubernetes/kubernetes/issues/57671 and it seems people have had similar issues.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2019-06-28. Score: 1 | Accepted answer
  
  Yes you can by doing a DNS SRV lookup. Here's an example:
  
  ```
  $ kubectl run -it srvlookup --image=tutum/dnsutils --rm --restart=Never -- dig SRV jira-headless.default.svc.cluster.local
  
  ; <<>> DiG 9.9.5-3ubuntu0.2-Ubuntu <<>> SRV jira-headless.default.svc.cluster.local
  ;; global options: +cmd
  ;; Got answer:
  ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56846
  ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2
  
  ;; QUESTION SECTION:
  ;jira-headless.default.svc.cluster.local. IN SRV
  
  ;; ANSWER SECTION:
  jira-headless.default.svc.cluster.local. 30 IN SRV 10 50 0 jira-0.jira-headless.default.svc.cluster.local.
  jira-headless.default.svc.cluster.local. 30 IN SRV 10 50 0 jira-1.jira-headless.default.svc.cluster.local.
  
  ;; ADDITIONAL SECTION:
  jira-0.jira-headless.default.svc.cluster.local. 30 IN A 10.244.11.152
  jira-1.jira-headless.default.svc.cluster.local. 30 IN A 10.244.0.188
  
  ;; Query time: 6 msec
  ;; SERVER: 10.233.0.3#53(10.233.0.3)
  ;; WHEN: Fri Jun 28 00:18:14 UTC 2019
  ;; MSG SIZE  rcvd: 143
  
  ```
  
  In the example above I have a headless Service called `jira-headless.` If you pay attention to `ADDITIONAL SECTION:` you'll notice it provides the SRV record in the following format:
  
  `_service._proto.name. TTL class SRV priority weight port target.`
  
  Which maps to the Pods (along with their IPs) backing the Service:
  
  ```
  jira-0.jira-headless.default.svc.cluster.local. 30 IN A 10.244.11.152
  jira-1.jira-headless.default.svc.cluster.local. 30 IN A 10.244.0.188
  
  ```
  
  
  ---
  
  