OpenShift - Application Scaling

---

Autoscaling is a feature in OpenShift where the applications deployned can scale and sink as and when requierd as per certain specifications. In OpenShift application, autoscaling is also known as pod autoscaling. There are two types of application scaling as follows.

Vertical Scaling

Vertical scaling is all about adding more and more power to a single machine which means adding more CPU and hard disk. The is an old method of OpenShift which is now not supported by OpenShift releases.

Horizontal Scaling

This type of scaling is useful when there is a need of handling more request by increasing the number of machines.

In OpenShift, there are two methods to enable the scaling feature.

• Using the deployment configuration file
• While running the image

Using Deployment Configuration File

In this method, the scaling feature is enabled via a deploymant configuration yaml file. For this, OC autoscale command is used with minimum and maximum number of replicas, which needs to run at any given point of time in the cluster. We need an object definition for the creation of autoscaler. Following is an example of pod autoscaler definition file.

apiVersion: extensions/v1beta1
kind: HorizontalPodAutoscaler
metadata:
   name: database
spec:
   scaleRef:
      kind: DeploymentConfig
      name: database
      apiVersion: v1
      subresource: scale
   minReplicas: 1
   maxReplicas: 10
   cpuUtilization:
      targetPercentage: 80

Once we have the file in place, we need to save it with yaml format and run the following command for deployment.

$ oc create –f <file name>.yaml

While Running the Image

One can also autoscale without the yaml file, by using the following oc autoscale command in oc command line.

$ oc autoscale dc/database --min 1 --max 5 --cpu-percent = 75
deploymentconfig "database" autoscaled

This command will also generate a similar kind of file that can later be used for reference.

Deployment Strategies in OpenShift

Deployment strategy in OpenShift defines a flow of deployment with different available methods. In OpenShift, following are the important types of deployment strategies.

• Rolling strategy
• Recreate strategy
• Custom strategy

Following is an example of deployment configuration file, which is used mainly for deployment on OpenShift nodes.

kind: "DeploymentConfig"
apiVersion: "v1"
metadata:
   name: "database"
spec:
   template:
      metadata:
         labels:
            name: "Database1"
spec:
   containers:
      - name: "vipinopenshifttest"
         image: "openshift/mongoDB"
         ports:
            - containerPort: 8080
               protocol: "TCP"
replicas: 5
selector:
   name: "database"
triggers:
- type: "ConfigChange"
- type: "ImageChange"
   imageChangeParams:
      automatic: true
      containerNames:
         - "vipinopenshifttest"
      from:
         kind: "ImageStreamTag"
         name: "mongoDB:latest"
   strategy:
      type: "Rolling"

In the above Deploymentconfig file, we have the strategy as Rolling.

We can use the following OC command for deployment.

$ oc deploy <deployment_config> --latest

Rolling Strategy

Rolling strategy is used for rolling updates or deployment. This process also supports life-cycle hooks, which are used for injecting code into any deployment process.

strategy:
   type: Rolling
   rollingParams:
      timeoutSeconds: <time in seconds>
      maxSurge: "<definition in %>"
      maxUnavailable: "<Defintion in %>"
      pre: {}
      post: {}

Recreate Strategy

This deployment strategy has some of the basic features of rolling deployment strategy and it also supports life-cycle hook.

strategy:
   type: Recreate
   recreateParams:
      pre: {}
      mid: {}
      post: {}

Custom Strategy

This is very helpful when one wishes to provide his own deployment process or flow. All the customizations can be done as per the requirement.

strategy:
   type: Custom
   customParams:
      image: organization/mongoDB
      command: [ "ls -l", "$HOME" ]
      environment:
         - name: VipinOpenshiftteat
         value: Dev1