Discovering Deployments

We have already introduced Deployments as higher-level abstractions of ReplicaSets. You can use Deployments 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 to automate this process. You can use Deployments to declaratively define the new desired state of your application and roll out the new version reliably, without causing any downtime of the currently running application.

Click on the buttons below to discover the main benefits of Deployments.

Since a Deployment manages the ReplicaSet, which, in turn, manages the Pods, the Deployment manifest is very similar to the ReplicaSet manifest. However, the Deployment manifest uses Deployment-specific fields and objects, for example, the strategy object.

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 uses the label app: hello-kyma. The Pod template has a container with the name hello-kyma and the image hello-kyma:1.0.0 pulled 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 spec.template.spec field:

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

Concerning the containers object of the Pod template, 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 always pull the image, you can set the ImagePullPolicy to Always.

See an example Deployment manifest:

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: [ ]
        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, see the Kubernetes Deployment documentation.

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, it's the focus of this lesson.

As mentioned, the RollingUpdate strategy 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. To do this, use 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

To roll back to a previous version of your application, you can use kubectl rollout undo command:

1
kubectl rollout undo deployment hello-kyma

Deployments in Kubernetes are high-level abstractions of Pods and ReplicaSets, allowing you to declaratively define the desired state of your application. Deployments automate processes like updates and rollbacks, reducing manual work and potential errors. They support two main deployment strategies: Rolling Update for zero-downtime updates and Recreate for updates that tolerate downtime. Additionally, Deployments maintain a history of changes, allowing you to easily roll back to a previous version if needed, and can be scaled seamlessly by adjusting the number of replicas.