Red Hat OpenShift en el edge: preparación sin intervención humana

La tecnología de la información está experimentando una evolución notable, ya que los entornos de implementación y mantenimiento cambian día a día. Cada vez es más necesario procesar y gestionar los datos y los dispositivos en el extremo de la red, por lo que las tecnologías deben adaptarse para respaldar y fomentar la adopción de estas estrategias.

Con Red Hat OpenShift puede cubrir necesidades tan variadas como la gestión de una plataforma de aplicaciones que no depende de la infraestructura o la implementación en las instalaciones o en la nube, ya sea privada, pública o híbrida.

Sin embargo, la capacidad de adaptarse a cualquier entorno evolucionó enormemente a lo largo del tiempo. El aprovechamiento de las configuraciones más ligeras, como el modo de implementación compacto de tres nodos o la configuración de un solo nodo, permite obtener las mismas características de flexibilidad y rendimiento, pero con un entorno más pequeño. 

Gracias a esta flexibilidad, OpenShift puede adaptarse a las implementaciones en entornos con capacidad informática reducida y restricciones de uso de los sistemas de hardware, como los sitios remotos, ya sean sucursales o sitios informáticos y de procesamiento individuales.

Imaginemos que tenemos muchos de estos sitios del extremo de la red y que necesitamos llegar a todos ellos con una tecnología que garantice la capacidad informática y la gestión concentradas de nuestras cargas de trabajo. Podemos replicar y propagar las configuraciones y los ajustes que cumplen con las políticas definidas previamente y los entornos relacionados con el sitio y que, sobre todo, están disponibles en poco tiempo, lo que reduce la complejidad y mejora la confiabilidad y la capacidad de repetición.

Este caso práctico puede abordarse con la preparación sin intervención humana (ZTP del inglés zero-touch provisioning), gracias a la flexibilidad del instalador asistido Assisted Installer OpenShift y la versatilidad y sencillez de la gestión de clústeres e infraestructuras desde un solo lugar que ofrece Red Hat Advanced Cluster Management for Kubernetes.

Como su nombre lo indica, la ZTP es un modo de preparación de clústeres de OpenShift en servidores dedicados (bare metal) que nos permite crear varias clases de configuración de clústeres en función de las necesidades de los sitios remotos sin interactuar físicamente con nuestros dispositivos. Para lograr esto, deben declararse las configuraciones deseadas para nuestros clústeres en los recursos específicos, y que los diversos elementos de Red Hat Advanced Cluster Management se ocupen de traducirlos en operaciones de preparación, tanto de los nodos de infraestructura a través del controlador de gestión de la placa base (BMC) como de los clústeres mediante el uso de las funciones del OpenShift Assisted Installer.

Dado que todos los recursos definidos son independientes, se pueden almacenar en un repositorio de Git y aplicarse con el operador OpenShift GitOps, que se basa en ArgoCD y describe nuestros sitios y clústeres como si fueran aplicaciones normales.

A continuación, se muestra un diagrama de algunos de los casos prácticos, en los cuales se puede ver que este modo de preparación involucra solo un clúster, que actuará como un eje en el centro de datos central.

Las funciones que analizaremos están disponibles como versión de prueba en este momento. Sin embargo, podemos ver la manera de crear e implementar configuraciones optimizadas a escala.

Caso práctico: OpenShift de un solo nodo en el extremo de la red con ZTP

Analicemos cada una de las piezas que componen nuestro rompecabezas y la manera de unirlas para obtener una imagen completa.

Estos son los principales elementos de Red Hat Advanced Cluster Management que intervienen en el proceso:

• Operador de servidor dedicado (bare metal) de OpenShift
• Assisted Installer
• Motor para varios clústeres: operador de Hive

Dado que vamos a abordar los problemas relacionados con los dispositivos del extremo de la red, tomaremos como referencia a los servidores dedicados (bare metal). En ellos, los modos de configuración ya están disponibles en función de la infraestructura que brinda el usuario y de las instalaciones en la infraestructura que proporciona el instalador, las cuales aprovecharemos en las diversas etapas de implementación.

Cada dispositivo remoto está asociado con un sitio que corresponde a la definición de los parámetros más importantes que deben tenerse en cuenta durante la etapa de configuración, lo que se traduce en una definición de recursos personalizados (CRD) denominada SiteConfig.

La CRD definirá:

• Detalles sobre el controlador de gestión de la placa base (BMC) que usaremos para administrar nuestros nodos
• Detalles relacionados con los clústeres (nombre del clúster y dominio)
• Configuraciones de red (subred para pods, servicios y máquinas)
• Configuraciones de los nodos (ajustes de red, particiones y cualquier refuerzo necesario mediante la aplicación de políticas)

Esta información se gestiona y se traduce en recursos que los diferentes elementos administran para organizar las distintas etapas de implementación.

En resumen, este es el flujo lógico de la ZTP:

Veamos en detalle los diferentes recursos mencionados y sus funciones.

BareMetalHost

BareMetalHost (BMH) maneja la información del controlador de gestión de la placa base (BMC), que luego interpreta el operador de servidor dedicado (bare metal) de OpenShift para crear el nodo dentro de la plataforma y luego preparar y configurar el nodo remoto. Este es el centro de la preparación de nodos, ya que permite que el operador configure de forma remota los dispositivos de arranque que están adaptados a la configuración que vamos a implementar.

InfraEnv

InfraEnv define los detalles de las redes, los servidores NTP que se usarán en los nodos que alojará, la clave Secure Shell (SSH) que se usará para acceder a los nodos que se conectarán y las credenciales para acceder a las imágenes de contenedor que se requieren para la instalación. Junto con el recurso ClusterDeployment, se usa para compilar la imagen ISO de descubrimiento para el instalador asistido.

AgentClusterInstall

Contiene la información que consumirá el Assisted Installer para generar la imagen de arranque que usarán nuestros nodos para continuar instalando y configurando el clúster, lo cual incluye la versión, el nombre y las configuraciones de red.

ClusterDeployment

Combina la información definida en AgentClusterInstall y agrega otros datos que se requieren para la implementación adecuada del clúster, que se integrará en la imagen ISO de arranque para el nodo.

ManagedCluster y KlusterletAddonConfig

Es posible que los usuarios de Red Hat Advanced Cluster Management ya conozcan estos recursos, los cuales definen la información sobre el clúster para permitir que se importe y se gestione en el centro de la herramienta y se configuren los servicios que se requieren para la comunicación.

Una vez que se complete el proceso de preparación y la configuración del clúster con el instalador de OpenShift, en nuestro centro aparecerá el nuevo nodo único de OpenShift como instalado, integrado y listo para usarse en la implementación de nuestras cargas de trabajo.

Resumen

En este artículo, presentamos el concepto de ZTP para OpenShift en los entornos del extremo de la red y explicamos el modo de lograr que el proceso de preparación de la plataforma sea más sencillo, repetible y adaptable desde un enfoque de infraestructura como código (IaC).

La tecnología está en constante desarrollo y ya progresó lo suficiente como para que pueda experimentar con este método innovador para llevar una plataforma de aplicaciones completa a cualquier entorno.