Documentación de SUSE Edge 3.3.1 #

SUSE Edge está formado por componentes de SUSE y de Rancher, junto con funciones y componentes adicionales creados por el equipo de Edge para permitirnos abordar las limitaciones y complejidades que requiere la edge computing. En el diagrama simplificado siguiente se explican los componentes usados tanto en los clústeres de gestión como en los clústeres descendentes. Sin ser una lista exhaustiva, muestra la arquitectura general:

3.1.1 Clúster de gestión #

 

• Gestión: esta es la parte centralizada de SUSE Edge que se usa para gestionar el aprovisionamiento y el ciclo de vida de los clústeres descendentes. El clúster de gestión suele incluir los componentes siguientes:

  • Gestión de varios clústeres con Rancher Prime (Capítulo 5, Rancher), que incluye un panel de control común para incorporar clústeres descendentes y para la gestión continua del ciclo de vida de la infraestructura y las aplicaciones, además de proporcionar un aislamiento completo de los inquilinos e integraciones de IDP (proveedores de identidad), un amplio mercado de integraciones y extensiones de terceros, y una API independiente del proveedor.

  • Gestión de sistemas Linux con SUSE Multi-Linux Manager, que permite la gestión automatizada de parches y configuraciones de Linux del sistema operativo Linux subyacente (*SUSE Linux Micro, Capítulo 9, SUSE Linux Micro) que se ejecuta en los clústeres descendentes. Tenga en cuenta que aunque este componente está en contenedores, actualmente debe ejecutarse en un sistema independiente del resto de los componentes de gestión, por lo que se etiqueta como "Gestión de Linux" en el diagrama anterior.

  • Un controlador dedicado de gestión del ciclo de vida (Capítulo 23, Upgrade Controller) que se encarga de la actualización de los componentes del clúster de gestión a una versión determinada de SUSE Edge.

  • Incorporación remota del sistema a Rancher Prime con Elemental (Capítulo 13, Elemental), lo que permite la vinculación posterior de los nodos periféricos conectados a los clústeres de Kubernetes deseados y el despliegue de aplicaciones, por ejemplo, a través de GitOps.

  • Compatibilidad opcional completa del ciclo de vida y la gestión física (bare metal) con los proveedores de infraestructura Metal3 (Capítulo 10, Metal³), MetalLB (Capítulo 19, MetalLB) y CAPI (Cluster API), lo que permite el aprovisionamiento completo de extremo a extremo de sistemas físicos con capacidades de gestión remota.

  • Un motor GitOps opcional llamado Fleet (Capítulo 8, Fleet) para gestionar el aprovisionamiento y el ciclo de vida de los clústeres descendentes y las aplicaciones que residen en ellos.

  • El clúster de gestión tiene SUSE Linux Micro (Capítulo 9, SUSE Linux Micro) como sistema operativo base y RKE2 (Capítulo 16, RKE2) como distribución de Kubernetes que aporta compatibilidad con las aplicaciones del clúster de gestión.

3.1.2 Clústeres descendentes #

 

• Descendentes: esta es la parte distribuida de SUSE Edge que se utiliza para ejecutar las cargas de trabajo del usuario en el perímetro; es decir, el software que se ejecuta en la propia ubicación perimetral y que, normalmente, se compone de los siguientes componentes:

  • Una selección de distribuciones de Kubernetes, con distribuciones seguras y ligeras como K3s (Capítulo 15, K3s) y RKE2 (Capítulo 16, RKE2) (RKE2 está reforzada, certificada y optimizada para su uso en el sector público y en industrias reguladas).

  • SUSE Security (Capítulo 18, SUSE Security) para habilitar funciones de seguridad como el análisis de vulnerabilidades de imágenes, la inspección profunda de paquetes y la protección en tiempo real contra amenazas y vulnerabilidades.

  • Software de almacenamiento en bloques con SUSE Storage (Capítulo 17, SUSE Storage) que permite un sistema de almacenamiento en bloques ligero, persistente, resistente y escalable.

  • Un sistema operativo Linux ligero, optimizado para contenedores y reforzado con SUSE Linux Micro (Capítulo 9, SUSE Linux Micro), que proporciona un sistema operativo inmutable y altamente resiliente para ejecutar contenedores y máquinas virtuales en el perímetro. SUSE Linux Micro está disponible para las arquitecturas AArch64 y AMD64/Intel 64, y también admite kernel en tiempo real para aplicaciones sensibles a la latencia (por ejemplo, para usos en telecomunicaciones).

  • Para los clústeres conectados (los que tienen conectividad con el clúster de gestión), se despliegan dos agentes: Rancher System Agent, para gestionar la conectividad con Rancher Prime, y venv-salt-minion, para recibir instrucciones de SUSE Multi-Linux Manager y aplicar las actualizaciones de software de Linux. Estos agentes no son necesarios para la gestión de clústeres desconectados.

La imagen anterior ofrece una descripción general de la arquitectura de los clústeres descendentes conectados y sus conexiones con el clúster de gestión. El clúster de gestión se puede desplegar en una amplia variedad de plataformas de infraestructura subyacentes, tanto en instalaciones locales como en la nube, dependiendo de la disponibilidad de red entre los clústeres descendentes y el clúster de gestión de destino. El único requisito para que funcione es que sea posible acceder a las API y las URL de redirección a través de la red que conecta los nodos del clúster descendente con la infraestructura de gestión.

Es importante entender que existen mecanismos distintos en los que se establece esta conectividad en relación con el mecanismo de despliegue del clúster descendente. Esto se explica con mucho más detalle en la siguiente sección. Como descripción general: existen tres mecanismos principales para que los clústeres descendentes conectados se establezcan como un clúster "gestionado":

Nota

Se recomienda desplegar varios clústeres de gestión para adaptarse a la escala de los despliegues de gran tamaño, optimizar el ancho de banda y la latencia en entornos geográficamente dispersos, y minimizar las interrupciones en caso de una caída del servicio o una actualización del clúster de gestión. Encontrará los límites actuales de escalabilidad del clúster de gestión y los requisitos del sistema aquí.

En el aprovisionamiento de red dirigida se conocen los detalles del hardware en el que se desea realizar el despliegue y se tiene acceso directo a la interfaz de gestión fuera de banda para orquestar y automatizar todo el proceso de aprovisionamiento. En este caso, nuestros clientes esperan una solución que permita aprovisionar los sitios periféricos de forma totalmente automatizada desde una ubicación centralizada, lo que va mucho más allá de la simple creación de una imagen de arranque al minimizar las operaciones manuales en la ubicación periférica; basta con montar, alimentar y conectar las redes necesarias al hardware físico y el proceso de automatización enciende el equipo mediante la gestión fuera de banda (por ejemplo, a través de la API Redfish) y se encarga del aprovisionamiento, la incorporación y la implantación de la infraestructura sin intervención del usuario. La clave para que este modelo funcione es que los administradores conozcan los sistemas y que sepan qué hardware hay en cada ubicación y que el despliegue se gestionará de forma centralizada.

Esta solución es la más robusta, ya que interactúa directamente con la interfaz de gestión del hardware, trabaja con hardware conocido y tiene menos restricciones en cuanto a la disponibilidad de la red. En cuanto a la funcionalidad, esta solución utiliza ampliamente Cluster API y Metal³ para el aprovisionamiento automatizado, desde bare metal, pasando por el sistema operativo y Kubernetes hasta las aplicaciones en capas; y ofrece la posibilidad de vincularse al resto de las capacidades comunes de gestión del ciclo de vida de SUSE Edge tras el despliegue. La guía de inicio rápido para esta solución se puede encontrar en el Capítulo 1, Despliegues automatizados de BMC con Metal³.

A veces, se trabaja en un entorno en el que el clúster de gestión central no puede gestionar el hardware directamente (por ejemplo, si la red remota está protegida por un cortafuegos o no hay una interfaz de gestión fuera de banda, algo habitual en el hardware de tipo "PC" que suele encontrarse en el perímetro). En este caso, proporcionamos herramientas para aprovisionar de forma remota los clústeres y sus cargas de trabajo sin necesidad de saber dónde se envía el hardware cuando se arranca. Este sistema es en el que la mayoría de la gente piensa al hablar de la edge computing: son los miles de sistemas algo desconocidos que se arrancan en ubicaciones periféricas y se comunican de forma segura con la central, validando quiénes son y recibiendo instrucciones sobre lo que deben hacer. Aquí se espera un aprovisionamiento y una gestión del ciclo de vida con muy poca intervención del usuario, aparte de la creación previa de imágenes del equipo en fábrica o de simplemente conectar una imagen de arranque, por ejemplo, a través de USB, y encender el sistema. Los principales retos en este modelo son cómo abordar la escala, la coherencia, la seguridad y el ciclo de vida de estos dispositivos en el mundo real.

Esta solución ofrece una gran flexibilidad y coherencia en la forma en que se aprovisionan e incorporan los sistemas, independientemente de su ubicación, tipo o especificaciones, o de cuándo se encienden por primera vez. SUSE Edge permite una flexibilidad y personalización totales del sistema a través de Edge Image Builder y aprovecha las capacidades de registro que ofrece Elemental para la incorporación de nodos y el aprovisionamiento de Kubernetes, junto con SUSE Multi-Linux Manager para la aplicación de parches al sistema operativo. La guía de inicio rápido de esta solución se puede encontrar en el Capítulo 2, Incorporación de hosts remotos con Elemental.

Para los clientes que necesitan operar en entornos independientes, aislados o con limitaciones de red, SUSE Edge ofrece una solución que permite generar medios de instalación totalmente personalizados con todos los artefactos de despliegue necesarios para habilitar clústeres de Kubernetes de alta disponibilidad en el perímetro, tanto de un solo nodo como de múltiples nodos, incluyendo cualquier carga de trabajo o los componentes adicionales en capas que se requieran. Todo ello sin necesidad de conectividad de red con el mundo exterior y sin la intervención de una plataforma de gestión centralizada. La experiencia del usuario se asemeja mucho a la solución "phone home", en la que se proporcionan medios de instalación a los sistemas de destino, pero la solución se "arranca in situ". En este escenario, es posible conectar los clústeres resultantes a Rancher para su gestión continua (es decir, pasar de un modo de funcionamiento "desconectado" a "conectado" sin necesidad de realizar una reconfiguración o un redespliegue importantes), o bien seguir funcionando de forma aislada. Tenga en cuenta que, en ambos casos, se puede aplicar el mismo mecanismo unificado para automatizar las operaciones del ciclo de vida.

Además, esta solución se puede utilizar para crear rápidamente clústeres de gestión que puedan alojar la infraestructura centralizada que admite tanto el modelo de "aprovisionamiento de red dirigida" como el de "aprovisionamiento de red 'phone home'", ya que puede ser la forma más rápida y sencilla de aprovisionar todo tipo de infraestructura periférica. Esta solución utiliza en gran medida las capacidades de SUSE Edge Image Builder para crear medios de instalación totalmente personalizados y desatendidos. La guía de inicio rápido se puede encontrar en el Capítulo 3, Clústeres independientes con Edge Image Builder.