Discovering Services 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 group Pods together and provide a stable endpoint to access the Pods. The grouping of Pods is done by a label selector 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

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.

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.

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:

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.

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