Desarrollo y pruebas de aplicaciones para garantizar su resiliencia

Descubre cómo gestiona Red Hat OpenShift on IBM Cloud el mantenimiento del plano de control, cómo afectan las actualizaciones de mantenimiento a las cargas de trabajo en ejecución y cómo probar y diseñar tus aplicaciones para que tengan una alta resiliencia.

Descripción general de la arquitectura del clúster y las responsabilidades

Red Hat OpenShift on IBM Cloud es un servicio de Kubernetes gestionado. En cada clúster, la arquitectura se divide en dos planos con [responsabilidades de gestión diferenciadas](/docs/openshift?topic=openshift-responsibilities_Kubernetes Service):

Plano de control
Gestionado por IBM. Incluye el servidor de la API de Kubernetes, etcd, el gestor de controladores y el programador.
Plano de datos
Gestionados por ti. Incluye nodos de trabajo, pods de aplicaciones, configuraciones de almacenamiento y complementos de red.
Responsabilidades de gestión del plano de control y del plano de datos del clúster
Plano Gestionado por Componentes
Plano de control IBM Servidor de API, etcd, gestor de controladores, programador
Plano de datos Usted Nodos de trabajo, pods de aplicaciones, almacenamiento y complementos de red

IBM Aplica periódicamente actualizaciones de versiones de parches al plano de control. Estos parches solucionan vulnerabilidades de seguridad, aplican correcciones críticas de errores y garantizan que los clústeres sigan cumpliendo con los requisitos de seguridad de IBM. Comprender cómo se aplican estos parches te ayuda a tomar decisiones informadas sobre la arquitectura de tu aplicación.

Las aplicaciones que se ejecutan en entornos en la nube están expuestas a condiciones dinámicas, entre las que se incluyen interrupciones transitorias de la red, tareas de mantenimiento de la infraestructura de alojamiento y latencia de los servicios de terceros. El diseño y las pruebas de resiliencia en todas las condiciones garantizan la fiabilidad de las cargas de trabajo en producción.

Cómo aplica IBM los parches del plano de control

Los componentes del plano de control de todos los clústeres de Red Hat OpenShift on IBM Cloud se ejecutan en una configuración de alta disponibilidad (HA). Se distribuyen múltiples réplicas de cada componente a lo largo de zonas de disponibilidad independientes, de modo que no exista ningún punto único de fallo dentro del plano de control.

Cuando se aplica una actualización de parches, IBM utiliza una estrategia de recreación progresiva. Las réplicas se actualizan de forma secuencial:

  • El servidor de la API Kubernetes seguirá estando disponible durante toda la actualización.
  • Las operaciones del clúster, como la programación, el autoescalado y las comprobaciones de estado, continúan sin interrupciones.
  • IBM Proporciona un retraso de apagado progresivo para permitir que las conexiones en curso se completen antes de que se elimine un pod.

Las actualizaciones de parches del plano de control están diseñadas para que no afecten a las aplicaciones de los usuarios que se ejecutan en el plano de datos. Tus pods, servicios y cargas de trabajo siguen funcionando con normalidad en los nodos de trabajo durante todo el proceso.

Repercusión en las cargas de trabajo durante las actualizaciones del plano de control

Dado que el plano de datos lo gestiona el usuario, los parches del plano de control de IBM no reinician, reprograman ni modifican los nodos de trabajo ni los pods de aplicaciones en ejecución.

Sin embargo, las aplicaciones o herramientas que realizan llamadas frecuentes y directas a la API de Kubernetes (como controladores personalizados, operadores, procesos de CI/CD o agentes de supervisión que vigilan el estado del clúster) deben gestionar adecuadamente los errores transitorios de la API. Sigue las prácticas recomendadas generales de Kubernetes:

  • Implementa una lógica de reintento con retroceso exponencial para todas las llamadas a la API.
  • Evita recurrir a conexiones abiertas persistentes con el servidor de la API sin una lógica de reconexión.

Simulación de escenarios para probar la resiliencia de las aplicaciones

Para generar confianza en la resiliencia de las aplicaciones, simule condiciones de fallo de producción en un entorno que no sea de producción antes de que se produzcan mantenimientos programados o interrupciones inesperadas.

Durante cualquier simulación, supervisa tus aplicaciones en busca de indicios de interrupciones: reinicios inesperados de pods, picos en los registros de errores, empeoramiento de los tiempos de respuesta o pérdida de solicitudes de los clientes. Utilice estas observaciones para perfeccionar la lógica de reintentos, ajustar las pruebas de estado o adaptar la topología de las réplicas.

Para ejecutar comandos de gestión de clústeres (como master refresh o worker pool resize) se requiere acceso a la plataforma como administrador u operador, así como permisos para el servicio de gestión de clústeres. Si eres desarrollador de aplicaciones y no tienes acceso a la infraestructura de clústeres, ponte en contacto con el administrador de clústeres para ejecutar estas simulaciones.

Simulación de un parche del plano de control mediante una actualización del plano de control

Al activar una actualización del plano de control, se inicia el proceso de actualización progresiva que utiliza IBM durante las actualizaciones de parches. Esta prueba comprueba que su aplicación y sus herramientas gestionen sin problemas las transiciones de réplicas del plano de control.

  1. Inicia una actualización del plano de control en tu clúster.

    ibmcloud oc cluster master refresh --cluster CLUSTER_NAME_OR_ID

  2. Comprueba que tus aplicaciones sigan procesando el tráfico sin interrupciones y que los puntos finales orientados al cliente sigan respondiendo correctamente.

Simulación de actualizaciones de enrutamiento de red mediante la adición y eliminación de nodos de trabajo

Al añadir o eliminar nodos de trabajo, Kubernetes actualiza la lógica de enrutamiento de la red interna en todo el clúster, simulando las condiciones que se producen cuando los nodos se reinician durante el mantenimiento de la infraestructura.

  1. Cambia el tamaño de tu grupo de trabajadores para añadir un nodo de trabajador temporal.

    ibmcloud oc worker-pool resize --cluster CLUSTER_NAME_OR_ID --worker-pool WORKER_POOL_NAME --size-per-zone NEW_SIZE

  2. Supervisa los registros de tu aplicación y la latencia de respuesta mientras el nuevo nodo de trabajo se inicializa y se une a la red del clúster.

  3. Cuando haya finalizado la prueba, elimine el nodo de trabajo de prueba.

    Para eliminar de forma selectiva el nodo de trabajo específico creado en el paso 1:

    1. Aísla y vacía el nodo de trabajo antes de eliminarlo para garantizar que las cargas de trabajo se reprogramen correctamente.
       oc cordon NODE_NAME
   oc drain NODE_NAME --ignore-daemonsets --delete-emptydir-data
    1. Elimina el nodo de trabajo del clúster.
       ibmcloud oc worker rm --cluster CLUSTER_NAME_OR_ID --worker WORKER_ID
    1. Vuelve a ajustar el tamaño del grupo de trabajadores a su capacidad original utilizando el comando ibmcloud oc worker-pool resize con tu valor --size-per-zone original.

    Como alternativa, con un enfoque menos específico, puede simplemente restablecer el tamaño original del grupo de trabajadores utilizando el comando ibmcloud oc worker-pool resize del paso 1 sin eliminar explícitamente ningún nodo concreto.

Prácticas recomendadas para la resiliencia de las cargas de trabajo

La resiliencia de su aplicación durante los incidentes en el clúster depende de cómo estén diseñadas y configuradas sus cargas de trabajo. Aplica las siguientes prácticas recomendadas a las especificaciones de tus cargas de trabajo de Kubernetes:

Ejecuta varias réplicas para cada carga de trabajo

Una implementación con una sola réplica no admite interrupciones. Establece como mínimo en spec.replicas ( 2 preferiblemente o 3 más para cargas de trabajo en producción) para que la pérdida o la reprogramación de un solo pod no provoque tiempo de inactividad.

Distribuir réplicas entre zonas y nodos de trabajo

Configura las reglas de anti-afinidad de topologySpreadConstraints pod en la configuración de tu despliegue. La distribución de pods entre varias zonas de disponibilidad y nodos de trabajo evita que una interrupción en una sola zona o una operación de mantenimiento en un nodo provoque la caída simultánea de todas las réplicas.

Configurar los presupuestos de interrupción de pods (PDB)

Un recurso PodDisruptionBudget especifica el número o porcentaje mínimo de pods que deben permanecer disponibles durante interrupciones voluntarias, como el vaciado de nodos o las actualizaciones de clústeres. Define un PDB para cada carga de trabajo crítica con el fin de evitar que las operaciones administrativas expulsen más pods de los que tu aplicación puede tolerar.

Definir pruebas de disponibilidad y de funcionamiento

Configura las pruebas de disponibilidad y de actividad en las especificaciones de tus contenedores:

  • Pruebas de disponibilidad: Asegúrate de que Kubernetes redirija el tráfico únicamente a los pods que estén inicializados y listos para atender solicitudes.
  • Pruebas de actividad: Habilita Kubernetes para que reinicie automáticamente los contenedores que entren en un estado de interbloqueo o de mal funcionamiento.

Establecer solicitudes y límites de recursos adecuados

Especifique requisitos y límites realistas de CPU y memoria para cada contenedor. Las solicitudes garantizan que el programador de la Kubernetes coloque los pods en nodos con capacidad suficiente. Los límites evitan que un único contenedor consuma recursos excesivos y afecte negativamente a las cargas de trabajo ubicadas en el mismo nodo de trabajo.

Implementar la gestión de un apagado ordenado

Cuando se cierra un pod, Kubernetes envía una señal SIGTERM antes de enviar SIGKILL. Diseña tu aplicación para detectar el error SIGTERM, dejar de aceptar nuevas conexiones, completar las transacciones en curso y cerrarse correctamente. Establece un valor adecuado en terminationGracePeriodSeconds la especificación de tu pod para que tu aplicación disponga de tiempo suficiente para evacuar el tráfico.

Evita depender de conexiones de larga duración con el servidor de la API

Kubernetes Las solicitudes de vigilancia y las conexiones de streaming (como los oc exec reenvíos de puertos o las vigilancias de clientes de API personalizadas) se conectan directamente a una réplica específica del plano de control. Cuando esa réplica realiza un ciclo durante una actualización de parches, la conexión se cierra. Las cargas de trabajo y las herramientas deben implementar una lógica de reconexión automática con retroceso exponencial.

Utilizar la lógica de reintento y los cortacircuitos

Cuando tu aplicación interactúe con la API de Kubernetes, bases de datos externas o microservicios posteriores, implementa una lógica de reintento con retroceso exponencial y jitter. Utilice patrones de circuit breaker para evitar fallos en cadena cuando una dependencia anterior o posterior no esté disponible temporalmente.

Próximos pasos