Discovering deployments

You have heard of deployments as a high-level abstraction of Pods and ReplicaSets. Now, you want to learn more about deployments and how to use them to manage your applications.

We have already introduced deployments as higher-level abstractions of ReplicaSets. Deployments can be used to define the desired state of your application declaratively. This includes the number of replicas, the container images, and further configuration. Deployments manage ReplicaSets, and ReplicaSets manage Pods.

This is where deployments come into play. Deployments can be used to declaratively define the new desired state of your application to roll out the new version reliably and with zero downtime of the currently running application.

Click on the four buttons below to discover the main benefits of deployments.

Since a deployment manages the ReplicaSet, which is, in turn, managing the Pods, the deployment manifest is very similar to the ReplicaSet manifest. The only difference is that the deployment manifest has deployment-specific fields and objects, for example, the strategyobject.

apiVersion: apps/v1
kind: Deployment
metadata:
   name: hello-kyma
spec:
   replicas: 3
   selector:
     matchLabels:
       app: hello-kyma
   template: # Pod 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
           ports:
           - containerPort: 8080

This example shows a deployment manifest with the name hello-kyma.

The deployment has three replicas and the pod template has the labelapp: hello-kyma. The pod template has a container with the namehello-kymaand the image hello-kyma:1.0.0 from the GitHub Container Registry (ghcr.io). The container exposes the port: 8080

Let's have a look at the deployment manifest spec section in detail:.

If you want to pull the image from a private registry, you can do so by providing the credentials in the deployment manifest to spec.template.spec:

...
spec:
...
  template:
  ... 
    spec:
      imagePullSecrets:
        - name: myregistrykey
      containers:
        - name: hello-kyma
          image: ghcr.io/sap-samples/kyma-runtime-learning-journey/hello-kyma:1.0.0
          ports:
            - containerPort: 8080

We cover secrets later in this course.

Concerning the containers object in the manifest, the following attributes are recommended:

The ImagePullPolicy is set to IfNotPresent by default. This means that the image is pulled only if it is not present locally on the cluster node. If you want to pull the image always, you can set the ImagePullPolicy to Always.

Note

If you specify an image with the latest tag and you or the system creates a new pod, Kubernetes always downloads the most recent latest version. This can lead to unexpected behavior, since other pods can still use the old image. Therefore, it is recommended to use a specific version of the image, for example, 'hello-kyma:1.0.0'.

So, a good manifest might look like this:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-kyma
  labels:
    app.kubernetes.io/name: hello-kyma
spec:
   replicas: 3
   selector:
     matchLabels:
       app: hello-kyma
   template:
     metadata:
       labels:
         app: hello-kyma
     spec:
        imagePullSecrets: [ ] # optional
        containers:
         - name: hello-kyma
           image: 'ghcr.io/sap-samples/kyma-runtime-learning-journey/hello-kyma:1.0.0'
           resources:
            requests:
              memory: 64Mi # 64MiB (2^26 bytes)
              cpu: 50m # 50 millicores (1/20th of a core), 500m = 0.5 cores
            limits:
              memory: 128Mi
              cpu: 100m # 100 millicores (1/10th of a core), 1000m = 1 core
           ports:
           - containerPort: 8080

For all other fields, please refer to the official documentation.

The Kubernetes deployment object also comes with different deployment strategies. Kubernetes supports the following two deployment strategies:

You can specify the deployment strategy in the deployment manifest:

apiVersion: apps/v1
kind: Deployment
metadata:
   name: hello-kyma
spec:
   replicas: 3
   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
           ports:
           - containerPort: 8080 
     strategy:
       type: RollingUpdate
       rollingUpdate:
          maxSurge: 25%
          maxUnavailable: 25%

For the strategy.type field, you can either specify RollingUpdate or Recreate. Since, the `RollingUpdate' is the default and recommended strategy, we will focus on this one.

As mentioned, the RollingUpdate doesn't delete the old pods before creating the new ones. Instead, it performs the update in a rolling fashion. You can define exactly the percentage of pods that can be updated at the same time. This is done by the maxSurge and maxUnavailable fields:

• The maxSurge field defines the maximum number of pods that can be created above the desired number of pods.
• The maxUnavailable field defines the maximum number of pods that can be unavailable during the update.

The default values for both fields are 25%. With this, the old pods still retrieve traffic, while you are already creating and serving the new pods.

Note

Serving two versions of an application simultaneously, behind the same service, also comes with some challenges. For example, you have to make sure that the new version of the application is compatible with the old one, also known as API Compatibility. It is highly recommended to have a versioning concept for your APIs to be both forward and backward compatible.

Each deployment also contains an entire deployment history. This allows you to roll back to a previous version of your application if something went wrong.

You can use kubectl to check the deployment history of a deployment:

kubectl rollout history deployment hello-kyma

You can simply roll back to a previous version of your application by using the kubectl rollout undo command:

kubectl rollout undo deployment hello-kyma

This lesson taught you how to deploy your application to Kubernetes based on a Deployment manifest. You also learned about the different deployment strategies and how to scale your deployment and roll it back.