The network service is an application that receives requests and provides a solution. Clients access the service by a network connection. They don't have to know the architecture of the service or how it runs. The only thing that clients have to verify is whether the endpoint of the service can be accessed, and then follow its usage policy to get the response of the server. The Kubernetes Service has similar ideas. It is not necessary to understand every Pod before reaching their functionalities. For components outside the Kubernetes system, they just access the Kubernetes Service with an exposed network port to communicate with running Pods. It is not necessary to be aware of the containers' IPs and ports. Behind Kubernetes Services, we can fulfill a zero-downtime update for our container programs without struggling:

The preceding diagram shows the basic structure of the Service and realizes the following concepts:

• As with the Deployment, the Service directs requests to Pods that have labels containing the Service's selector. In other words, the Pods selected by the Service are based on their labels.
• The load of requests sent to the Services will distribute to three Pods.
• The Deployment, along with ReplicaSet, ensures that the number of running Pods meets its desired state. It monitors the Pods for the Service, making sure they will be healthy for taking over duties from the Service.
• Service is an abstraction layer for grouping Pods, which allows for Pods scaling across nodes.

In this recipe, you will learn how to create Services in front of your Pods for the requests.