All documentation I see explain that labeling is useful for defining logical sets of pods, and that this is used by services to select pods.
But services seem to be the interface over which you avoid the dynamic resolution of the IPs of the pods instances.
So as I understand it, a Service can only (or it's meant to) be composed of pods replicas (what's the point if not?). If so, what's the point on labeling and logical division? Can't we simply indicate the pod id? Or does it make sense to have some replicas responding under a service and others under another?
In fact, services have nothing to do with Deployments, ReplicaSets or ReplicationControllers and so on directly. Services are an abstract defining criteria that Pod labels must meet to be considered an endpoint for given service. This makes perfect sense, as you can ie. have multiple Deployments/ReplicaSets (each with 0 or more pods) as backends for some service. Think about concepts like canary release. Furthermore, pods are volatile by design, they can come and go, and selector defines a "query" that at any given time returns all pods that serve as backend for this svc. Imagine what would happen if your pod is replaced by a new one and you referenced it in service by pod id.