Discovering Services in Kubernetes

Objectives

After completing this lesson, you will be able to:

  • Identify the features of services.
  • Explain the service discovery mechanism in Kubernetes.

Service in Kubernetes

Services are an essential concept in Kubernetes. When you create a Deployment, the Deployment will manage a ReplicaSet, which manages the underlying Pods.

However, the Pods are ephemeral and can be terminated and replaced at anytime. Unlike Pods managed by StatefulSets, Pods managed by Deployments do not have a stable name. They are assigned a random hash suffix as part of their name. So, when a pod is terminated and replaced by a new one, the name of the new Pod will be different from the name of the old Pod, and also its IP address will be different.

If you want to access your application, you need a stable endpoint for your underlying Pods. This is where Services come into play.

Services groups Pods together and provides a stable endpoint to access the Pods. The grouping of Pods is done by a label selector defined in the Service manifest.

Defining a Service

A simple Service manifest looks like this:

Code Snippet
Copy code
Switch to dark mode
1234567891011
apiVersion: v1 kind: Service metadata: name: hello-kyma-svc spec: selector: app: 'hello-kyma' ports: - protocol: 'TCP' port: 80 targetPort: 8080

The Service manifest defines a Service named hello-kyma-svc that groups Pods with the label app: hello-kyma together. The Service exposes port 80 and forwards all traffic to port 8080 of the Pods.

Service Access

A service provides a set of pods as a network service. The Service can be accessed by other Pods in the cluster. You will find out how to access a Service from outside the cluster in a later lesson.

Inside the cluster, a service can be reached by simply providing the name of the Service as a DNS name. The following pattern constructs the DNS name:

<service-name>.<namespace>.svc.cluster.local.

So, if you have a Service named hello-kyma-svc in the default namespace, you can access it by using the DNS name hello-kyma-svc.default.svc.cluster.local.

However, inside the same namespace, you can access the Service using the short name hello-kyma-svc. You can also access the Service by using the short term hello-kyma-svc.default from other namespaces in the cluster.

Exposing Pods when Fully Ready

For some applications, it is essential to know if the application is ready to accept traffic or is still starting up. For example, if you have a web application, you should ensure that the application is fully started before sending traffic to it.

Kubernetes provides two mechanisms to check the health of an application before enabling traffic to be sent to it. These mechanisms are called readiness and liveness probes.

With readiness probes, you can check if the application is ready to accept traffic. If the readiness probe fails, the Pod will not receive any traffic from the Service. The Service only sends traffic to ready Pods.

The following example shows a deployment manifest that defines a readiness probe:

Code Snippet
Copy code
Switch to dark mode
123456789101112131415161718192021222324
apiVersion: apps/v1 kind: Deployment metadata: name: hello-kyma spec: replicas: 1 selector: matchLabels: app: hello-kyma template: metadata: labels: app: hello-kyma spec: containers: - name: hello-kyma image: ghcr.io/sap-samples/kyma-runtime-learning-journey/hello-kyma:1.0.0 readinessProbe: httpGet: path: /ready port: 8080 periodSeconds: 5 failureThreshold: 3 successThreshold: 1

The readiness probe is defined in the readinessProbe section. The readiness probe is an HTTP GET request to the path /ready on port 8080. The readiness probe is executed every 5 seconds. If the readiness probe fails three times in a row, the Pod is considered to be not ready. If the readiness probe succeeds one time in a row, the Pod is considered to be ready. Read more about readiness and liveness probes here.

Service Management in the Kyma dashboard

The Kyma Dashboard offers a simple way to manage Services. You can create, edit, and delete Services in the Kyma Dashboard. Furthermore, you can use the Service to expose it to the outside world via an API Rule or to subscribe to an event via a Subscription.

Further usage of Services

Services are not only used to group Pods together and provide a stable endpoint to access the Pods. Services can also be used to expose Pods to the outside world. In Kyma, a few ways to expose a Service to the outside world exist. Both require a Service object. You will discover these concepts later in this course.

Summary

In this lesson, you have learned how to define and use services to expose a single endpoint to access a set of Pods. You have also learned how to use readiness probes to check if an application is ready to accept traffic.

Further Reading

Read more about services in Kubernetes here:Kubernetes Services.

Log in to track your progress & complete quizzes