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