Gestión del ciclo de vida de la app

Utilice herramientas nativas de Kubernetes o de terceros para realizar actualizaciones y retrotracciones continuadas de apps sin interrumpir la actividad de los usuarios.

Estrategias de actualización

Para actualizar la app, puede elegir entre diversas estrategias como las siguientes. Puede empezar con un despliegue continuo o un conmutador instantáneo antes de avanzar hacia un despliegue de prueba más complicado.

Despliegue: Puede utilizar las funciones nativas de Kubernetes para crear un despliegue de la v2 y sustituir gradualmente el despliegue anterior de la v1. Este enfoque requiere que las aplicaciones sean compatibles con versiones anteriores para que los usuarios que se utilizan la versión de la aplicación v2 no experimenten cambios de última hora. Para obtener más información, consulte Gestión de despliegues continuos para actualizar las apps.
Conmutación instantánea: También conocido como un despliegue de azul-verde, una conmutación instantánea requiere el doble de recursos informáticos para tener dos versiones de una app en ejecución a la vez. Con este enfoque, puede conmutar a los usuarios a la versión más reciente en tiempo real. Asegúrate de utilizar selectores de etiquetas de servicio (como version: green y version: blue) para garantizar que las solicitudes se envíen a la versión correcta de la aplicación. Puede crear el nuevo despliegue version: green, esperar a que esté preparado y, a continuación, suprimir el despliegue version: blue. O bien, puede realizar una actualización continua, pero establecer el parámetro maxUnavailable en 0% y el parámetro maxSurge en 100%.
Despliegue de prueba o despliegue A/B: Una estrategia de actualización más compleja, un despliegue de prueba es cuando se elige un porcentaje de usuarios como, por ejemplo, el 5% y se les envía la nueva versión de la app. Se recopilan métricas en las herramientas de registro y supervisión sobre cómo se funciona la nueva versión de la app, se hacen pruebas A/B y, a continuación, se implanta la actualización a más usuarios. Al igual que con todos los despliegues, el etiquetado de la app (como por ejemplo version: stable y version: canary) es crítico. Para gestionar las implementaciones «canary», puedes instalar la malla de servicios gestionada Istio, configurar Monitoring para tu clúster y, a continuación, utilizar la malla de servicios Istio para realizar pruebas A/B, tal y como se describe en esta entrada del blog.

Escalado de apps

Con « Kubernetes », puedes activar el autoescalado horizontal de pods para aumentar o reducir automáticamente el número de instancias de tus aplicaciones en función de la CPU.

¿Desea escalar los nodos trabajadores en lugar de los pods? Consulte el apartado sobre el programa de escalado automático de clúster.

Antes de empezar:

Inicie una sesión en la cuenta. If applicable, target the appropriate resource group. Establezca el contexto para el clúster.
Asegúrese de que tiene asignado un rol de acceso al servicio que otorgue el rol de RBAC de Kubernetes adecuado para que pueda trabajar con los recursos de Kubernetes en el espacio de nombres.

Para escalar tus aplicaciones:

Despliegue su app en un clúster desde la CLI. Para despliegues más complejos, es posible que tenga que crear un archivo de configuración.
```
kubectl create deployment <app_name> --image=<image>
```
Establezca los límites de recursos de CPU en millicores para los contenedores que se ejecutan en el despliegue, como por ejemplo 100m. También puede establecer límites de memoria, pero el programa de escalado automático de pod horizontal solo tiene en cuenta los límites de recursos de CPU para fines de escalado. Para obtener más información, consulta la documentación de « kubectl set resources ».
```
kubectl set resources deployment <app_name> --limits=cpu=100m
```

Cree un programa de escalado automático de pod horizontal y defina la política. Para obtener más información, consulte el apartado kubectl autoscale Documentación de .

kubectl autoscale deployment <deployment_name> --cpu-percent=<percentage> --min=<min_value> --max=<max_value>

Comprender las opciones de mando
Opciones	Descripción
`--cpu-percent`	Utilización media de CPU que mantiene el componente Horizontal Pod Autoscaler, que se especifica como un porcentaje.
`--min`	El número mínimo de pods desplegados que se utilizan para mantener el porcentaje especificado de utilización de CPU.
`--max`	El número máximo de pods desplegados que se utilizan para mantener el porcentaje especificado de utilización de CPU.

Gestión de despliegues continuos para actualizar las apps

Puede gestionar el despliegue de cambios en una app de forma automática y controlada para las cargas de trabajo con una plantilla de pod como, por ejemplo los despliegues. Si el despliegue no va según lo planificado, puede retrotraerlo a la revisión anterior.

¿Desea evitar el tiempo de inactividad durante una actualización continua? Asegúrese de especificar un sondeo de preparación en el despliegue para que el despliegue continúe en el siguiente pod de la app cuando esté listo el pod actualizado más recientemente.

Antes de empezar:

Inicie una sesión en la cuenta. If applicable, target the appropriate resource group. Establezca el contexto para el clúster.
Cree un despliegue.
Asegúrese de que tiene un rol de acceso al servicio que otorgue el rol de RBAC de Kubernetes adecuado para que pueda trabajar con los recursos de Kubernetes en el espacio de nombres.

Para gestionar las actualizaciones continuas en las apps:

Para asegurarse de que los despliegues estén marcados como preparados sólo cuando el contenedor esté en ejecución y preparado para las solicitudes de servicio, añada sondeos de actividad y de preparación a su despliegue.
Actualice el despliegue para incluir una estrategia de actualización continua que especifique el número máximo de pods no disponibles o el porcentaje de pods durante la actualización.
```
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-test
spec:
  replicas: 10
  selector:
    matchLabels:
      service: http-server
  minReadySeconds: 5
  progressDeadlineSeconds: 600
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 50%
      maxSurge: 2
...
```
spec.minReadySeconds

De forma predeterminada, los despliegues esperan hasta que el pod esté marcado como ready para continuar con el despliegue. Si observa que el despliegue continúa creando pods aunque la app del pod más reciente aún no está preparada, utilice este campo para ralentizar el despliegue. Por ejemplo, si especifica 5, el despliegue espera 5 segundos desde que el pod está ready para crear el siguiente pod.

spec.progressDeadlineSeconds

Establezca un tiempo de espera en segundos hasta que un despliegue se considere fallido. Por ejemplo, sin un tiempo de espera, si la nueva versión de la aplicación tiene un error y se cuelga inmediatamente, el despliegue no puede continuar porque el pod nunca llega a un estado ready. Si establece este tiempo de espera en 600 segundos, si cualquier fase del despliegue falla durante 10 minutos, el despliegue se marca como fallido y se detiene.

spec.strategy.type

Especifique aquí el tipo de estrategia de RollingUpdate.

spec.strategy.rollingUpdate.maxUnavailable

Establezca el número máximo de pods que puede haber no disponibles durante una actualización, en forma de número (2) o de porcentaje (50%). En general, es mejor utilizar un porcentaje, de forma que si más tarde se cambia el número de réplicas, no tenga que acordarse de actualizar este número, a menos que desee limitar el despliegue para que admita sólo un pod inactivo a la vez. Si no quieres que la capacidad baje nunca por debajo del 100 %, establece este valor en « 0% » y especifica el parámetro « spec.strategy.type.rollingUpdate.maxSurge ».

spec.strategy.rollingUpdate.maxSurge

Establezca cuántos recursos adicionales el despliegue puede utilizar durante la puesta en marcha, en forma de número (2) o de porcentaje (50%). Por ejemplo, si en su despliegue se especifican 10 réplicas y establece maxSurge en 2, durante la puesta en marcha se crean dos nuevas réplicas. Ahora tiene 12 réplicas (10 existentes, 2 nuevas). Una vez las dos nuevas réplicas están listas, el despliegue reduce las réplicas antiguas a 8 para ajustarse a las 10 réplicas especificadas. Este proceso continúa hasta que se completa la puesta en marcha y las 10 réplicas ejecutan la nueva versión.

Si desea realizar una actualización de estilo de conmutador instantáneo blue-green, establezca maxSurge en 100%. El despliegue crea todas las nuevas réplicas necesarias y, a continuación, escala las réplicas de versión antigua a 0.

Desplegar un cambio. Por ejemplo, supongamos que desea cambiar la imagen que ha utilizado en el despliegue inicial.

Obtener el nombre del despliegue.

    kubectl get deployments
    ```
2. Obtenga el nombre del pod.

```sh {: pre}
    kubectl get pods
    ```
3. Obtener el nombre del contenedor que se ejecuta en el pod.

```sh {: pre}
    kubectl describe pod <pod_name>
    ```
4. Definir la imagen que utilizará el despliegue.

```sh {: pre}
    kubectl set image deployment/<deployment_name> <container_name>=<image_name>
    ```
Al ejecutar estos mandatos, el cambio se aplica de inmediato y se registra en el historial de implantaciones.

Comprobar el estado del despliegue.
```
kubectl rollout status deployments/<deployment_name>
```
Si observa algo y que desea tiempo para hacer un seguimiento, puede hacer una pausa y reanudar el despliegue con los mandatos siguientes.
```
kubectl rollout pause deployment <deployment_name>
```
```
kubectl rollout resume deployment <deployment_name>
```

Retrotraer un cambio.

Ver el historial de implantaciones del despliegue e identificar el número de revisión del último despliegue.

    kubectl rollout history deployment/<deployment_name>
    ```
    Para ver los detalles de una revisión concreta, incluya el número de revisión.
    {: tip}

    ```sh {: pre}
    kubectl rollout history deployment/<deployment_name> --revision=<number>
    ```
2. Retrotraer a la versión anterior o especificar una revisión. Para retrotraer a la versión anterior, utilice el mandato siguiente.

```sh {: pre}
    kubectl rollout undo deployment/<deployment_name> --to-revision=<number>
    ```

Configuración de la integración y entrega continua

Con IBM Cloud y otras herramientas de código abierto, puede configurar la integración y entrega continua (CI/CD), el control de versiones, las cadenas de herramientas y más para ayudar a automatizar el desarrollo y el despliegue de apps.

Para ver una lista de las integraciones compatibles y los pasos para configurar una canalización de entrega continua, revise las integraciones disponibles en la consola IBM Cloud y la documentación relacionada con el clúster.

Copia de despliegues en otro clúster

Cuando utilizas un sistema de control de versiones como Git, proyectos de gestión de la configuración o herramientas de entrega continua en tu clúster, puedes implementar rápidamente los archivos de configuración de tu aplicación de un clúster a otro. A veces solo tiene unos pocos despliegues que ha probado en un clúster y prefiere copiar estos despliegues y volver a desplegarlos en otro clúster.

Antes de empezar, necesitarás dos clústeres y el rol de acceso al servicio Manager para todos los espacios de nombres de ambos clústeres, de modo que puedas copiar todos los recursos de un clúster e implementarlos en otro.

Inicie una sesión en la cuenta. If applicable, target the appropriate resource group. Establezca el contexto para el clúster.

Obtenga una lista de todos los archivos de configuración del clúster y verifique que desea copiar estas configuraciones.

kubectl get all

Salida de ejemplo

NAME                                   READY   STATUS             RESTARTS   AGE
pod/java-web-6955bdbcdf-l756b          1/1     Running            0          59d
NAME                                   TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
service/java-web                       NodePort    172.21.xxx.xxx   <none>        8080:30889/TCP   59d
NAME                                   READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/java-web               1/1     1            1           59d
NAME                                   DESIRED   CURRENT   READY   AGE
replicaset.apps/java-web-6955bdbcdf    1         1         1       59d

Copie los archivos de configuración del clúster en un directorio local. A continuación, elimina manualmente los campos específicos del clúster, como resourceVersion, uid, creationTimestamp y status, del archivo YAML exportado antes de aplicar los archivos a otro clúster.
```
kubectl get all -o yaml > myconfigs.yaml
```
Inicie una sesión en la cuenta. If applicable, target the appropriate resource group. Establezca el contexto para el clúster.
Opcional: Si tu clúster utilizaba varios espacios de nombres, crea los mismos espacios de nombres en el clúster estándar y copia el secreto de descarga de imágenes en cada uno de ellos.
Despliegue los archivos de configuración que ha copiado en el clúster. Si un archivo de configuración tiene información específica que no se puede aplicar, es posible que tenga que actualizar el archivo de configuración y repetir la aplicación.
```
kubectl apply -f myconfigs.yaml
```
Salida de ejemplo
```
pod/java-web-6955bdbcdf-l756b created
service/java-web created
deployment.apps/java-web created
replicaset.apps/java-web-6955bdbcdf created
```
Verifique que los archivos de configuración se han aplicado.
```
kubectl get all
```