From c7aad1693b41426ca2710388f8f9d96a85b2e9c2 Mon Sep 17 00:00:00 2001 From: Max <16919345+mkorbi@users.noreply.github.com> Date: Wed, 2 Sep 2020 00:38:52 +0200 Subject: [PATCH] fix typo Co-authored-by: Rob Scott --- .../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 e37ceb4882..efc04b806d 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 @@ -43,4 +43,4 @@ Topology aware routing will update kube-proxy to prefer routing requests within ## What does this mean for the Endpoints API? Although the EndpointSlice API is providing a newer and more scalable alternative to the Endpoints API, the Endpoints API will continue to be considered generally available and stable. The most significant change planned for the Endpoints API will involve beginning to truncate Endpoints that would otherwise run into scalability issues. -Although the Endpoints API is not going away, many new features will be enabled by the EndpointSlice API. To take advantage of the new scalability and functionality that EndpointSlices provide, applications that currently consume Endpoints will likely want to consider switching to EndpointSlices in the future. +The Endpoints API is not going away, but many new features will rely on the EndpointSlice API. To take advantage of the new scalability and functionality that EndpointSlices provide, applications that currently consume Endpoints will likely want to consider switching to EndpointSlices in the future.