OpenShift: escalado de aplicaciones

El ajuste de escala automático es una función de OpenShift en la que las aplicaciones implementadas pueden escalar y hundirse cuando sea necesario según determinadas especificaciones. En la aplicación OpenShift, el ajuste de escala automático también se conoce como ajuste de escala automático de pod. Hay dostypes of application scaling como sigue.

Escala vertical

El escalado vertical se trata de agregar más y más potencia a una sola máquina, lo que significa agregar más CPU y disco duro. Es un método antiguo de OpenShift que ahora no es compatible con las versiones de OpenShift.

Escala horizontal

Este tipo de escalado es útil cuando existe la necesidad de manejar más solicitudes aumentando el número de máquinas.

En OpenShift, hay two methods to enable the scaling feature.

• Usando el archivo de configuración de implementación
• Mientras ejecuta la imagen

Uso del archivo de configuración de implementación

En este método, la función de escalado se habilita mediante un archivo yaml de configuración de implementación. Para ello, se utiliza el comando OC autoscale con un número mínimo y máximo de réplicas, que debe ejecutarse en cualquier momento del clúster. Necesitamos una definición de objeto para la creación del escalador automático. A continuación, se muestra un ejemplo de archivo de definición de escalador automático de pod.

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

Una vez que tenemos el archivo en su lugar, debemos guardarlo con el formato yaml y ejecutar el siguiente comando para la implementación.

$ oc create –f <file name>.yaml

Mientras ejecuta la imagen

También se puede escalar automáticamente sin el archivo yaml, utilizando lo siguiente oc autoscale comando en la línea de comando oc.

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

Este comando también generará un tipo de archivo similar que luego se puede usar como referencia.

Estrategias de implementación en OpenShift

La estrategia de implementación en OpenShift define un flujo de implementación con diferentes métodos disponibles. En OpenShift, los siguientes son losimportant types of deployment strategies.

• Estrategia rodante
• Recrear estrategia
• Estrategia personalizada

A continuación se muestra un ejemplo de archivo de configuración de implementación, que se utiliza principalmente para la implementación en nodos de OpenShift.

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"

En el archivo Deploymentconfig anterior, tenemos la estrategia como Rolling.

Podemos usar el siguiente comando OC para la implementación.

$ oc deploy <deployment_config> --latest

Estrategia rodante

La estrategia progresiva se utiliza para actualizaciones continuas o implementación. Este proceso también admite enlaces de ciclo de vida, que se utilizan para inyectar código en cualquier proceso de implementación.

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

Recrear estrategia

Esta estrategia de implementación tiene algunas de las características básicas de la estrategia de implementación continua y también admite el enlace del ciclo de vida.

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

Estrategia personalizada

Esto es muy útil cuando se desea proporcionar su propio proceso o flujo de implementación. Todas las personalizaciones se pueden hacer según el requisito.

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