Kubernetes DNS-based service discovery with SRV broken? - kubernetes

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?

Answer 1

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.