Discovering Services in Kubernetes

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

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

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

Services group Pods together and provide a stable endpoint to access the Pods. A label selector groups Pods defined in the Service manifest.

A simple Service manifest looks like this:

1234567891011
apiVersion: v1
kind: Service
metadata:
  name: hello-kyma-svc
spec:
  selector:
    app: 'hello-kyma'
  ports:
    - protocol: 'TCP'
      port: 80
      targetPort: 8080

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

A Service provides a set of Pods as a network service, and other Pods in the cluster can access it. You will find out how to access a Service from outside the cluster in the lesson Using the API Gateway Module to Expose Services.

Inside the cluster, you can reach a Service by simply providing its name 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.

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.

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 must ensure that the application is fully started before sending traffic to it.

Kubernetes provides two mechanisms to check the health of an application before sending traffic 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 doesn't 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:

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 not ready. If the readiness probe succeeds one time in a row, the Pod is considered to be ready. To learn more, see Define readiness probes.

Kyma dashboard offers a simple way to manage Services. You can use it to create, edit, and delete Services. Furthermore, in Kyma dashboard, you can create APIRules to expose the Service to the outside world or subscribe to an event using a Subscription.