From 032c9a51a0baa6d41f26c2180c2c9e0af86f818a Mon Sep 17 00:00:00 2001 From: Tim Bannister Date: Mon, 19 Dec 2022 21:23:51 +0000 Subject: [PATCH] Revise introduction to Service page Co-authored-by: divya-mohan0209 --- .../concepts/services-networking/service.md | 63 +++++++++++++------ 1 file changed, 43 insertions(+), 20 deletions(-) diff --git a/content/en/docs/concepts/services-networking/service.md b/content/en/docs/concepts/services-networking/service.md index c98d344b8dedd..f327303a0ee65 100644 --- a/content/en/docs/concepts/services-networking/service.md +++ b/content/en/docs/concepts/services-networking/service.md @@ -18,22 +18,23 @@ weight: 10 {{< glossary_definition term_id="service" length="short" >}} -With Kubernetes you don't need to modify your application to use an unfamiliar service discovery mechanism. -Kubernetes gives Pods their own IP addresses and a single DNS name for a set of Pods, -and can load-balance across them. +A key aim of Services in Kubernetes is that you don't need to modify your existing +application to use an unfamiliar service discovery mechanism. +You can run code in Pods, whether this is a code designed for a cloud-native world, or +an older app you've containerized. You use a Service to make that set of Pods available +on the network so that clients can interact with it. - - -## Motivation - -Kubernetes {{< glossary_tooltip term_id="pod" text="Pods" >}} are created and destroyed -to match the desired state of your cluster. Pods are nonpermanent resources. If you use a {{< glossary_tooltip term_id="deployment" >}} to run your app, -it can create and destroy Pods dynamically. +that Deployment can create and destroy Pods dynamically. From one moment to the next, +you don't know how many of those Pods are working and healthy; you might not even know +what those healthy Pods are named. +Kubernetes {{< glossary_tooltip term_id="pod" text="Pods" >}} are created and destroyed +to match the desired state of your cluster. Pods are emphemeral resources (you should not +expect that an individual Pod is reliable and durable). -Each Pod gets its own IP address, however in a Deployment, the set of Pods -running in one moment in time could be different from -the set of Pods running that application a moment later. +Each Pod gets its own IP address (Kubernetes expects network plugins to ensure this). +For a given Deployment in your cluster, the set of Pods running in one moment in +time could be different from the set of Pods running that application a moment later. This leads to a problem: if some set of Pods (call them "backends") provides functionality to other Pods (call them "frontends") inside your cluster, @@ -42,14 +43,13 @@ to, so that the frontend can use the backend part of the workload? Enter _Services_. -## Service resources {#service-resource} + -In Kubernetes, a Service is an abstraction which defines a logical set of Pods -and a policy by which to access them (sometimes this pattern is called -a micro-service). The set of Pods targeted by a Service is usually determined -by a {{< glossary_tooltip text="selector" term_id="selector" >}}. -To learn about other ways to define Service endpoints, -see [Services _without_ selectors](#services-without-selectors). +## Services in Kubernetes + +The Service API, part of Kubernetes, is an abstraction to help you expose groups of +Pods over a network. Each Service object defines a logical set of endpoints (usually +these endpoints are Pods) along with a policy about how to make those pods accessible. For example, consider a stateless image-processing backend which is running with 3 replicas. Those replicas are fungible—frontends do not care which backend @@ -59,6 +59,26 @@ track of the set of backends themselves. The Service abstraction enables this decoupling. +The set of Pods targeted by a Service is usually determined +by a {{< glossary_tooltip text="selector" term_id="selector" >}} that you +define. +To learn about other ways to define Service endpoints, +see [Services _without_ selectors](#services-without-selectors). + +If your workload speaks HTTP, you might choose to use an +[Ingress](/docs/concepts/services-networking/ingress/) to control how web traffic +reaches that workload. +Ingress is not a Service type, but it acts as the entry point for your +cluster. An Ingress lets you consolidate your routing rules into a single resource, so +that you can expose multiple components of your workload, running separately in your +cluster, behind a single listener. + +The [Gateway](https://gateway-api.sigs.k8s.io/#what-is-the-gateway-api) API for Kubernetes +provides extra capabilities beyond Ingress and Service. You can add Gateway to your cluster - +it is a family of extension APIs, implemented using +{{< glossary_tooltip term_id="CustomResourceDefinition" text="CustomResourceDefinitions" >}} - +and then use these to configure access to network services that are running in your cluster. + ### Cloud-native service discovery If you're able to use Kubernetes APIs for service discovery in your application, @@ -69,6 +89,9 @@ whenever the set of Pods in a Service changes. For non-native applications, Kubernetes offers ways to place a network port or load balancer in between your application and the backend Pods. +Either way, your workload can use these [service discovery](#discovering-services) +mechanisms to find the target it wants to connect to. + ## Defining a Service A Service in Kubernetes is a REST object, similar to a Pod. Like all of the