From f16c446d0a71d790b927e76dd67021e490e66354 Mon Sep 17 00:00:00 2001 From: Tim Rosenblatt Date: Thu, 31 Mar 2022 22:40:37 -0700 Subject: [PATCH] Explain Service without selector is for non-Pod backends (#32602) * Minor edit for clarity The previous phrasing didn't emphasize the point that the reason you define a Service with no selectors is to point to a backend that's not a Pod, and the emphasis on the external nature of the backend * Add note that Services w/o selectors, but +Endpoints is the technique to use for abstracting external backends Co-authored-by: Rey Lejano Co-authored-by: Rey Lejano --- content/en/docs/concepts/services-networking/service.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/en/docs/concepts/services-networking/service.md b/content/en/docs/concepts/services-networking/service.md index af56668579..85c222498e 100644 --- a/content/en/docs/concepts/services-networking/service.md +++ b/content/en/docs/concepts/services-networking/service.md @@ -158,9 +158,9 @@ Each port definition can have the same `protocol`, or a different one. ### Services without selectors -Services most commonly abstract access to Kubernetes Pods, but they can also -abstract other kinds of backends. -For example: +Services most commonly abstract access to Kubernetes Pods thanks to the selector, +but when used with a corresponding Endpoints object and without a selector, the Service can abstract other kinds of backends, +including ones that run outside the cluster. For example: * You want to have an external database cluster in production, but in your test environment you use your own databases.