EndpointSlices is an exciting new API that provides an extensible and extensible alternative to the Endpoints API. EndpointSlice tracks the IP address, port, readiness, and topology information behind the POD service. In Kubernetes (https://www.alauda.cn/product/detail/id/240.html) 1.19, by default through kube – proxy from EndpointSlices read you enable this feature, Instead of Endpoints. While this change may seem minor, it can lead to a significant improvement in scalability in a large cluster. It also enables important new features, such as topology routing awareness, in future versions of Kubernetes. 1 Extensibility of the Eendpoints API restricts the use of the Endpoints API to one Endpoints resource per service. This means that it needs to store the IP address and port (network endpoint) for each POD that supports the corresponding service. This leads to the use of huge API resources. To solve this problem, Kube-Proxy runs on each node and monitors for any updates to the Endpoints resource. If even one network port changes in the Endpoints resource, the entire object must also be sent to Kube-Proxy for each instance. Another limitation of the Endpoints API is that it limits the number of network Endpoints that can be tracked for a service. The default size limit for objects stored in an ETCD is 1.5MB. In some cases, this may limit the Endpoints resource to 5,000 Pod IP. For most users, this is not a problem, but for users with services close to this size, it can become a major problem. To illustrate the seriousness of these problems, it is helpful to take a simple example. Consider a service with 5,000 PODs, which might end up with a 1.5MB Endpoints resource. If every single network Endpoints in the list changes, the full Endpoints resource will need to be assigned to each node in the cluster. In large clusters with 3,000 nodes, this becomes a big problem. Each update will involve sending 4.5GB of data (1.5MB Endpoints * 3,000 nodes) across the cluster. This is almost enough to fill the DVD, and this happens every time the Endpoints change. Imagine if a rolling update caused all 5,000 PODs to be replaced — transferring more than 22TB (or 5,000 DVDs) of data. The EndpointSlice API aims to solve this problem in a shard-like way. Instead of using a single Endpoints resource to track all of the POD IP of the service, we split them into several smaller Endpoint Slices. Consider an example where a service backend has 15 PODs. We end up with a single Endpoints resource that tracks all the Endpoints. If we configured EndpointSlices to store five endpoints each, we would end up with three different endpoints: By default, endpointSlices store up to 100 endpoints each, although they can be configured using the –max-endpoints-per-slice flag on kube-controller-manager. EndpointSlices increase the extensibility by a factor of 10. This API greatly improves network scalability. Now, when a POD is added or removed, only one small EndpointSlice is updated. This difference becomes apparent when a single Service has hundreds or thousands of PODs. Perhaps more importantly, since all of the POD IP of the service does not need to be stored in a single resource, we do not have to worry about the size limit of the objects stored in the ETCD. EndpointSlices have been used to extend the service to more than 100,000 network endpoints. All of this is combined with some significant performance improvements that Kube-Proxy has made. When EndpointSlices are used on a large scale, there will be much less data for endpoint updates, and Kube-Proxy should update iptables or ipvs rules faster. In addition, services can now be extended to at least 10 times any previous limit. 3 EendpointSlices enabling new functions as Kubernetes (https://www.alauda.cn/product/detail/id/240.html) The EndpointSlices introduced by the alpha feature in V1.16 are designed to enable some exciting new features in future versions of Kubernetes. This may include dual stack services, topology routing awareness, and end point setup. Dual stack services are an exciting new feature being developed with EndpointSlices. They will use both IPv4 and IPv6 addresses as services, and rely on the AddressType field on EndpointSlices to track these addresses by IP series. Topology aware routing updates Kube-Proxy to complete routing requests in or within the same region. This leverages the topology fields stored for each endpoint in EndpointSlice. As a further refinement of this, we are exploring the potential of a subset of endpoints. This will allow kube-proxy to view only a subset of EndpointSlices. For example, this can be used in conjunction with topological routing awareness so that Kube-Proxy only monitors EndpointSlice containing endpoints within the same region. This will provide another very important scalability improvement. 4 What does this mean for the Endpoints API? Although the EndpointSlice API provides a newer and more extensible alternative to the Endpoints API, the Endpoints API will continue to be considered universally available and stable. The most important change planned for the Endpoints API will involve starting to truncate Endpoints, or you will run into scalability issues. The Endpoints API is not gone, but many of the new features will rely on the EndpointSlice API. To take advantage of the new scalability and capabilities provided by EndpointSlices, applications that currently use Endpoints might consider supporting EndpointSlices in the future. The original link: Scaling Kubernetes Networking With EndpointSlices https://kubernetes.io/blog/202… ICES/Rob Scott(Google)