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. https://docs.openshift.com/container-platform/4.4/rest_api/network_apis/endpointslice-discovery-k8s-io-v1beta1.html
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
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
This is a KEP, at the moment.