Kubernetes DNS-based service discovery with SRV broken?

Question

I am trying to figure out how the service discovery works in the Kubernetes cluster. Let's say I've got a service running in the cluster, but I don't know the IP or port. I assume the service discovery is the way to go.

Kubernetes DNS specification says that SRV record must be in the following format:

_<port>._<proto>.<service>.<ns>.svc.<zone>. <ttl> IN SRV <weight> <priority> <port-number> <service>.<ns>.svc.<zone>.

Example:

Question:
_https._tcp.kubernetes.default.svc.cluster.local. IN SRV

Answer:
_https._tcp.kubernetes.default.svc.cluster.local. 30 IN SRV 10 100 443 kubernetes.default.svc.cluster.local.

That implies the client needs to know the port (https=443) upfront to query for the port? It seems like it defeats the purpose of the SRV record. Why would the client query for SRV when the port is already known in the question and the only missing piece is the IP?

What am I missing? How to make this work when the discovering client only knows the name of the service and not the port?

Wytrzymały Wiktor Wytrzymały Wiktor · Accepted Answer · 2021-01-12T10:48:33

SRV records facilitate service discovery by describing the protocol/s and address of certain services:

SRV Records are created for named ports that are part of normal or Headless Services. For each named port, the SRV record would have the form _my-port-name._my-port-protocol.my-svc.my-namespace.svc.cluster-domain.example. For a regular service, this resolves to the port number and the domain name: my-svc.my-namespace.svc.cluster-domain.example. For a headless service, this resolves to multiple answers, one for each pod that is backing the service, and contains the port number and the domain name of the pod of the form auto-generated-name.my-svc.my-namespace.svc.cluster-domain.example.

An SRV record usually defines a symbolic name and the transport protocol (e.g., TCP) used as part of the domain name and defines the priority, weight, port, and target for a given service. For example:

_foo._tcp.example.com. 3600 IN SRV 10 100 5060 servicerecord.example.com

_foo is the service's symbolic name
_tcp is the transport protocol used by the service
the record has a priority of 10
the record has a weight of 100
5060 is the port and servicerecord.example.com is the hostname to connect to in order to communicate with the service

That implies the client needs to know the port (https=443) upfront to query for the port?

No, the 443 is the answer and not a part of the question.

How to make this work when the discovering client only knows the name of the service and not the port?

If the client knows the symbolic name of the service and the protocol than the port can be discovered.

Kubernetes DNS-based service discovery with SRV broken?

1 Answers