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.

12345678910111213141516171819
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 label app: hello-kyma. The Pod template has a container with the name hello-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's 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's to spec.template.spec:

12345678910111213
...
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.

So, a good manifest might look like this:

1234567891011121314151617181920212223242526272829
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:

123456789101112131415161718192021222324
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.

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

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

1
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:

1
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.