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 lav1
. Este enfoque requiere que las aplicaciones sean compatibles con versiones anteriores para que los usuarios que se utilizan la versión de la aplicaciónv2
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úrese de utilizar selectores de etiquetas de servicio (como
version: green
yversion: blue
) para garantizar que las solicitudes se envían a la versión correcta de la aplicación. Puede crear el nuevo despliegueversion: green
, esperar a que esté preparado y, a continuación, suprimir el despliegueversion: blue
. O bien, puede realizar una actualización continua, pero establecer el parámetromaxUnavailable
en0%
y el parámetromaxSurge
en100%
. - 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
yversion: canary
) es crítico. Para gestionar despliegues canarios, podría instalar la malla de servicios complementarios Istio gestionada, configurar Monitoring para su clúster, y luego utilizar la malla de servicios Istio para pruebas A/B como se describe en esta entrada del blog.
Escalado de apps
Con Kubernetes, puede activar el autoescalado horizontal de pods para aumentar o reducir automáticamente el número de instancias de sus 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 más información, consulte lakubectl set resources
documentación.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 especifica5
, 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 en600
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 desea bajar nunca del 100% de capacidad, ajuste este valor a0%
y especifique el parámetrospec.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 especifican10
réplicas y establecemaxSurge
en2
, 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
en100%
. 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
-
Obtenga el nombre del pod.
kubectl get pods
-
Obtener el nombre del contenedor que se ejecuta en el pod.
kubectl describe pod <pod_name>
-
Definir la imagen que utilizará el despliegue.
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>
Sugerencia: Para ver los detalles de una revisión concreta, incluya el número de revisión.
kubectl rollout history deployment/<deployment_name> --revision=<number>
-
Retrotraer a la versión anterior o especificar una revisión. Para retrotraer a la versión anterior, utilice el mandato siguiente.
kubectl rollout undo deployment/<depoyment_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 soportadas y de los pasos a seguir para configurar un conducto de entrega continuo, consulte Configuración de la integración y la entrega continua.
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 como kustomize
o herramientas de entrega continua como Razee en tu clúster, puedes desplegar los archivos de configuración de tu aplicación rápidamente de clúster a clúster. 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, necesita dos clústeres y la función de acceso al servicio de administrador para todos los espacios de nombres de ambos clústeres, de modo que pueda copiar todos los recursos de un clúster y desplegarlos en otro.
-
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. La opción
--export
elimina la información específica del clúster de los archivos de configuración.kubectl get all -o yaml --export > myconfigs.yaml
-
Opcional: Si su clúster utiliza varios espacios de nombres, cree los mismos espacios de nombres en el clúster estándar y copie el secreto de extracción de imágenes en cada espacio de nombres.
-
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