Una aplicación funciona. Después llega una actualización, falla un servidor o varios departamentos necesitan más capacidad a la vez. Kubernetes organiza dónde se ejecutan los contenedores y cómo se recupera el estado operativo acordado. Que eso haga más fiable la aplicación depende de la arquitectura completa.
Pensemos en un portal interno de pedidos: el personal introduce pedidos, una interfaz los transfiere al sistema de gestión de inventario y un proceso en segundo plano genera documentos. Estas tareas pueden ejecutarse en contenedores separados. Quien los inicia individualmente también debe coordinar actualizaciones, reinicios y ubicación en las máquinas. Ahí interviene la orquestación.
El estado deseado se convierte en la base de la operación
En Kubernetes se puede indicar, por ejemplo, que deben ejecutarse dos instancias de una aplicación web con una versión concreta. La plataforma compara continuamente ese estado deseado con el real. Un Deployment describe el despliegue y utiliza un controlador ReplicaSet para gestionar sus Pods. Si falta una instancia, el sistema de control intenta proporcionar otra.
También ayuda con las actualizaciones: una nueva versión puede desplegarse gradualmente. Los recursos, el comportamiento de arranque y la estrategia elegida deben permitirlo. Un despliegue técnicamente correcto no demuestra que un pedido se haya procesado bien. Esa comprobación sigue formando parte de la aplicación y de sus pruebas.
Conceptos clave a través del portal de pedidos
- Imagen de contenedor
- La base empaquetada de una aplicación, con los archivos y componentes de ejecución necesarios. A partir de ella se inician los contenedores.
- Pod
- La unidad desplegable más pequeña de Kubernetes. Normalmente contiene un contenedor de aplicación; varios contenedores estrechamente relacionados pueden compartir un Pod y, entre otras cosas, su espacio de red. Dos copias de la aplicación web suelen significar dos Pods.
- Nodo
- Una máquina que ejecuta Pods. Puede ser una máquina virtual o un servidor físico. Por tanto, Kubernetes puede complementar una capa de virtualización sin sustituirla necesariamente.
- Clúster y plano de control
- El clúster conecta el sistema de control con los nodos que ejecutan las cargas. El plano de control incluye el servidor API, la base de estado, el planificador y los controladores. En los nodos, kubelet y el entorno de ejecución de contenedores se encargan de ejecutar las cargas.
- Service
- Un punto de acceso lógico estable a un grupo de Pods. Sus direcciones pueden cambiar al sustituirlos. El Service separa el acceso de cada instancia efímera.
Qué ocurre realmente ante un fallo
Si falla un nodo, los Pods gestionados pueden desplegarse de nuevo en otros nodos adecuados. Para ello hacen falta detección del fallo, capacidad de reserva suficiente y acceso a los datos necesarios. Una segunda instancia en el mismo host físico no protege contra el fallo de ese host. Varios servidores en el mismo dominio eléctrico o de red también pueden compartir un punto de fallo.
Para el portal, la interfaz web puede sustituirse rápidamente. Sin embargo, un trabajo de documentos ya iniciado debe estar diseñado para que repetirlo no genere una factura o pedido duplicados. Las sesiones no deben perderse sin control al sustituir una instancia. Estas propiedades dependen de la arquitectura del software y de los sistemas conectados.
Por ello, disponer de tres servidores no constituye por sí solo un plan de disponibilidad. Deben considerarse conjuntamente el control, las aplicaciones, la red, el almacenamiento y la capacidad restante tras un fallo. Lo mismo ocurre en la nube o con Kubernetes gestionado: el alcance real del servicio determina las responsabilidades del proveedor y las que conserva la empresa.
Los datos persistentes necesitan su propio plan
Los Pods son sustituibles. Por tanto, los datos empresariales no deben existir solo en el sistema de archivos escribible de un contenedor. Kubernetes conecta almacenamiento persistente mediante Persistent Volumes y sus solicitudes, llamadas Persistent Volume Claims. Una StorageClass describe cómo puede proporcionarse almacenamiento adecuado.
Estos objetos no hacen resistente automáticamente el almacenamiento subyacente. Un disco local sigue ligado a su infraestructura; un servicio externo tiene sus propias características de rendimiento y fallo. Una base de datos fuera del clúster también puede ser apropiada. Deciden el soporte de la aplicación, la coherencia de los datos, las vías de acceso y el proceso de recuperación acordado.
Para el portal definimos por separado el tiempo de indisponibilidad admisible, la pérdida de datos aceptable y cómo se probará la restauración. Un clúster que propaga de forma fiable un borrado accidental a todas las instancias no sustituye una copia de seguridad. Más información sobre copias de seguridad y recuperación.
Cuándo compensa la infraestructura adicional
Kubernetes interesa cuando varias aplicaciones se actualizan regularmente, se necesitan despliegues repetibles o se busca asignar conscientemente las cargas y máquinas disponibles. También genera tareas de actualización de la plataforma, gestión de accesos, red, almacenamiento y monitorización.
Para una sola aplicación estable, un servidor bien mantenido con Docker Compose o una máquina virtual convencional puede resultar más económico. La decisión debe empezar por la operación requerida: ¿qué interrupciones son aceptables? ¿Con qué frecuencia hay cambios? ¿Quién comprende el entorno y puede recuperarlo si algo falla?
Un piloto útil tiene objetivos verificables
- Probar un proceso empresarial representativo con volúmenes de datos realistas y sin datos de clientes de producción.
- Ensayar una actualización con el retorno previsto. Evaluar por separado los cambios de esquema de la base de datos.
- Probar de forma controlada el fallo de una instancia y de un componente de infraestructura previsto.
- Restaurar una copia en un entorno de prueba separado y abrirla para comprobar que los datos empresariales son utilizables.
- Asignar responsables concretos de alertas, mantenimiento de la plataforma y aplicación.
DAXS ayuda a evaluar la aplicación y elegir infraestructura adecuada así como a implementar y operar el alcance acordado. Un primer análisis con un caso concreto y criterios de aceptación claros es un comienzo práctico.
Fuentes: Kubernetes: función y límites de la plataforma · Componentes del clúster · Pods y su ciclo de vida · Deployments y actualizaciones · Services · Almacenamiento persistente · Planificación de entornos de producción
