OpenShift - how can pods resolve each other names

6/28/2017

I m trying to have cloudera manager and cloudera agents on openshift, in order to run the installation I need to get all the pods communicating with each other.

Manually, I modified the /etc/hosts on the manager and add all the agents and on the agents I added the manager and all the other agents.

Now I wanted to automate this, let suppose I add a new agent, I want it to resolve the manager and the host (I can get a part of it done, by passing the manager name as an env variable and with a shell script add it to the /etc/hosts, not the ideal way but still solution). But the second part would be more difficult, to get the manager to resolve every new agent, and also to resolve every other agent on the same service.

I was wondering if there is a way so every pod on the cluster can resolve the others names ?

I have to services cloudera-manager with one pod, and an other service cloudera-agent with -let's say- 3 agents.

do you have any idea ?

thank you.

-- Mohammed Elmehdi EZ-GHARI
cloudera-cdh
cloudera-manager
kubernetes
kubernetes-pod
openshift

2 Answers

6/29/2017

If you want to get all Pods running under a certain Service, make sure to use a headless Service (i.e. set clusterIP: None). Then, you can query your local DNS-Server for the Service and will receive A-Records for all Pods assigned to it:

---
apiVersion: v1
kind: Service
metadata:
  name: my-sv
  namespace: my-ns
  labels:
    app: my-app
spec:
  clusterIP: None
  selector:
    app: my-app

Then start your Pods (make sure to give app: labels for assignment) and query your DNS-Server from any of them:

kubectl exec -ti my-pod --namespace=my-ns -- /bin/bash
$ nslookup my-sv.my-ns.svc.cluster.local
Server:     10.255.3.10
Address:    10.255.3.10#53

Name:   my-sv.my-ns.svc.cluster.local
Address: 10.254.24.11
Name:   my-sv.my-ns.svc.cluster.local
Address: 10.254.5.73
Name:   my-sv.my-ns.svc.cluster.local
Address: 10.254.87.6
-- jbndlr
Source: StackOverflow

6/28/2017

Not sure, but it looks like you could benefit from StatefulSets.

There are other ways to get the other pods ips (like using a headless service or requesting to the serverAPI directly ) but StatefulSets provide :

  • Stable, unique network identifiers

  • Stable, persistent storage.

  • Lots of other functionality that facilitates the deployment of a special kind of clusters like distributed databases. Not sure my term 'distributed' here is correct, but it helps me remind what they are for :).

-- rod
Source: StackOverflow