From c1f1bcf99b17df552d1860f2bfc811bdc61a186e Mon Sep 17 00:00:00 2001 From: Max <16919345+mkorbi@users.noreply.github.com> Date: Tue, 1 Sep 2020 16:59:38 +0200 Subject: [PATCH] update link Co-authored-by: Bob Killen --- .../2020-09-02-scaling-kubernetes-networking-endpointslices.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/blog/_posts/2020-09-02-scaling-kubernetes-networking-endpointslices.md b/content/en/blog/_posts/2020-09-02-scaling-kubernetes-networking-endpointslices.md index b8e4cc186c..03736c5150 100644 --- a/content/en/blog/_posts/2020-09-02-scaling-kubernetes-networking-endpointslices.md +++ b/content/en/blog/_posts/2020-09-02-scaling-kubernetes-networking-endpointslices.md @@ -9,7 +9,7 @@ slug: scaling-kubernetes-networking-with-endpointslices EndpointSlices are an exciting new API that provides a scalable and extensible alternative to the Endpoints API. EndpointSlices track IP addresses, ports, readiness, and topology information for Pods backing a Service. -In Kubernetes 1.19 this feature is be enabled by default with kube-proxy reading from [EndpointSlices](/docs/concepts/services-networking/endpoint-slices/) instead of Endpoints. Although this will mostly be an invisible change, it should result in noticeable scalability improvements in large clusters. It also enables significant new features in future Kubernetes releases like Topology Aware Routing. +In Kubernetes 1.19 this feature is be enabled by default with kube-proxy reading from [EndpointSlices](/docs/concepts/services-networking/endpoint-slices/) instead of Endpoints. Although this will mostly be an invisible change, it should result in noticeable scalability improvements in large clusters. It also enables significant new features in future Kubernetes releases like [Topology Aware Routing](/docs/concepts/services-networking/service-topology/). ## Scalability Limitations of the Endpoints API With the Endpoints API, there was only one Endpoints resource for a Service. That meant that it needed to be able to store IP addresses and ports (network endpoints) for every Pod that was backing the corresponding Service. This resulted in huge API resources. To compound this problem, kube-proxy was running on every node and watching for any updates to Endpoints resources. If even a single network endpoint changed in an Endpoints resource, the whole object would have to be sent to each of those instances of kube-proxy.