Services

Pods that are created by ReplicaSets or Deployments have a finite life cycle. At some point, you can expect them to be terminated and new Pod replicas with new IP addresses will be created in their place. So, what if you have a Deployment running web server Pods that need to communicate with Pods that have been created as a part of another Deployment, for example, backend Pods?  Web server Pods cannot assume anything about IP addresses or the DNS names of backend Pods, as they may change over time. This issue is resolved with Service API objects, which provide reliable networking for a set of Pods.

In general, Services target a set of Pods, and this is determined by label selectors. The most common scenario is exposing a Service for an existing Deployment by using exactly the same label selector. The Service is responsible for providing a reliable DNS name and IP address, as well as for monitoring selector results and updating the associated Endpoint Object with the current IP addresses of matching Pods.

For internal clients (Pods in the cluster), the communication to Pods behind a service is transparent – they use the Cluster IP or DNS name of the Service and the traffic is routed to one of the destination Pods. Routing capabilities are provided by kube-proxy, but it is important to know that the traffic is not routed through any master components – kube-proxy implements routing at the operating system kernel level and directly routes this to an appropriate Pod's IP address. In its simplest form, the destination Pod will be chosen randomly, but with IP Virtual Server (IPVS) proxy mode, you can have more complex strategies, such as least connection or shortest expected delay.

The principle of how Service works can be seen in the following diagram:

Let's expose an example service for our nginx Deployment:

1. If you don't have a running Deployment on the Katacoda playground, you can create one using the following command:

kubectl apply -f https://raw.githubusercontent.com/PacktPublishing/Hands-On-Kubernetes-on-Windows/master/Chapter04/03_deployment-example/nginx-deployment.yaml --record

2. Expose the Service for a deployment using the following kubectl expose command:

kubectl expose deployment nginx-deployment-example

3. This command is imperative and should be avoided in favor of the declarative manifest. This command is equivalent to applying the following Service manifest:

apiVersion: v1
kind: Service
metadata:
  name: nginx-deployment-example
spec:
  selector:
    environment: test
  type: ClusterIP
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80

4. Now, after the Service has been exposed, create an interactive busybox Pod and start the Bourne shell process:

kubectl run --generator=run-pod/v1 -i --tty busybox --image=busybox --rm --restart=Never -- sh

5. When the container shell prompt appears, download the default web page served by nginx Pods while using the nginx-deployment-example Service name as the DNS name:

wget http://nginx-deployment-example && cat index.html

Next, let's take a quick look at objects that provide storage in Kubernetes.