I have number of statefulsets PODs and they are not replica of each other. My application register service on the hostname of the pod and other services try to reach the service based on hostname. It works fine with headless service but application logic cannot be changed as it reads the hostname of POD and unfortunately I have to use that.
I have following scenario:
[test@shard1-0 ~]$ nslookup shard2
Server: 10.96.5.5
Address: 10.96.5.5#53
Name: shard2.default.svc.cluster.local
Address: 10.244.0.50
[test@shard1-0 ~]$ nslookup shard2-0
Server: 10.96.5.5
Address: 10.96.5.5#53
** server can't find shard2-0: NXDOMAIN
[test@shard1-0 ~]$
Is there a way that shards can resolve using the hostname of POD name ?and can reach each other as application is registered based on pod hostname.
Just to clarify if we are able to resolve this problem, we also need to expose these pods externally. I think for that I can use that and hopefully it will work: How to set hostname for kubernetes pod in statefulset
Since this is directly related to the DNS resolution within the cluster, one possible approach for it would be to change the DNS policy in the pod/deployment of your application that needs to resolve hostnames.
You can change the dnsPolicy
of a pod to set up your custom DNS settings, in which the records of each stateful set pod can be included.
dnsPolicy: "None"
dnsConfig:
nameservers:
- 1.2.3.4
options:
- name: ndots
value: "0"
This solves the issue of non-existent records in the current DNS records within the cluster and allows you to control the unqualified domain names associated with your pods (web-0
, web-1
) by removing the DNS suffixes.
Additionally, is safer since the change is only applied at your pod/deployment instead of the whole cluster, which keeps you out of potential trouble when exposing your stateful pods afterwards.
Finally and regarding the DNS configuration, you can use ALIAS
records pointed to the pod's FQDNs to preserve network identity through their original names. This avoids the operational cost of fetching the IP addresses since you'll be using the hostnames (they never change) instead.
Host: Type: Points to: TTL
web-0 ALIAS web-0.web-svc.namespace.svc.cluster.local 1 Hour
Please note that this approach requires that you setup and maintain your own DNS server (represented as 1.2.3.4
in the definition above).
If in your case is impossible to change the application logic to use the DNS standard within the cluster, this might be a workaround.