Does ETCD have the IP addresses of all the Pods that belong to a service?

General Discussions
1

Hi all,

Do you know where in ETCD (which key) stores the IP addresses of a service Pods? I want to get access to the all IP addresses of the Pods that belong to a given service name at any time, so I thought ETCD should have it, where do you think I can find it?

Thanks

2

If by ETCD you mean “the kubernetes API”, take a look at EndpointSlice
(or Endpoints on a back-rev cluster).

If you meant to go straight to etcd yourself, please don’t :slight_smile:

1 Like
3

Thanks @thockin for pointing out the EndpointSlice. Would you please tell me where can I find the list of APIs that the EndpointSlice exposes? I find this, but it is for openshift, I am not sure if it is the good reference. EndpointSlice [discovery.k8s.io/v1beta1] - Network APIs | API reference | OpenShift Container Platform 4.4

4

by the way, should I look into EndpointSlice in each node in the cluster to get the IP addresses of the Pods of a service or I can do it directly from the master node?

5

Thanks @thockin for pointing out the EndpointSlice. Would you please tell me where can I find the list of APIs that the EndpointSlice exposes? I find this, but it is for openshift, I am not sure if it is the good reference. EndpointSlice [discovery.k8s.io/v1beta1] - Network APIs | API reference | OpenShift Container Platform 4.4

EndpointSlice is currently Beta - that is right. For many purposes
the older “Endpoints” object is simpler to consume, but new
functionality (e.g. dual-stack) will be delivered through
EndpointSlice.

by the way, I have to look into EndpointSlice from each node in the cluster to get the IP addresses of the Pods of a service? I mean, I can not do it from the master node, right?

You can do it anywhere you can read the API. There’s no
context-awareness to it, yet.

I said “yet”. One thing to consider is the evolution of
endpoint-slice. It’s primary reason for existence is to answer the
question “Which endpoints should I use for this purpose”, where the
most common purpose is “a service”. Today we answer that by listing
ALL endpoints, which is imperfect at small scale and a disaster at
large scale. At the low end, we’re sending traffic between zones when
we don’t have to. At the high end, we’re propagating literal
gigabytes of information across the network when we don’t have to.

The current hand-wavy plan is to use some amount of centext to provide
different answers to the question. The question will be mutated
somewhat: “Which endpoints should I use for this purpose, given this
context”. Again, the most common purpose is “a service” and the most
common context is “from this zone”.

Given a service S which has endpoints in 3 zones, we may
(heuristically determined) provide a different answer to the question
for clients who ask about zone A than clients who ask about zone B.
If a client asks for all zones, they may find endpoints in more than
one subset.

This is a KEP, at the moment.

1 Like