From 2cbba6feeb9eeab9745d91fbf7fe25edfe4e1c87 Mon Sep 17 00:00:00 2001
From: Max <16919345+mkorbi@users.noreply.github.com>
Date: Wed, 2 Sep 2020 17:07:38 +0200
Subject: [PATCH] update mean for Endpoint API

---
 .../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 9da8695a8c..eebf88a1f1 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.
 
-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.
+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 supporting EndpointSlices in the future.