Clústeres en el borde
La mayoría de los blogs anteriores de esta serie en curso sobre edge computing hablaban de dispositivos.
Dispositivos de todo tipo: dispositivos de audio, dispositivos de video, dispositivos de tipo IoT y varios sensores y actuadores. Esta publicación analizará los contenedores desplegados en pequeños clústeres edge que actúan como nodos edge; sí, ejecutar clústeres de Kubernetes en máquinas de clase Raspberry Pi o en factores de forma pequeños como Intel NUC con suficiente computación y almacenamiento. Específicamente, clústeres que ejecutan una distribución descendente basada en Kubernetes, como K3S o MicroK8S, o una Red Hat OpenShift Container Platform (OCP) reducida de tres nodos en un clúster pequeño como un nodo en una ubicación on premises, lejos de un centro de datos.
Las aplicaciones intensivas de cómputo requieren una alta capacidad de cómputo para el procesamiento de datos y el almacenamiento que los dispositivos IoT no pueden satisfacer, dado que a menudo tienen recursos limitados. Por lo tanto, las empresas pueden utilizar clústeres en el borde como entornos dinámicos y robustos donde los equipos de operaciones pueden cumplir con el almacenamiento, el cálculo, la baja latencia, el alto rendimiento y el ancho de banda requeridos. Además, algunos servicios compartidos on premises de alta disponibilidad pueden requerir la escalabilidad que los clústeres de Kubernetes están diseñados para proporcionar, como los despliegues en la nube.
Un clúster edge a menudo puede ser un límite lógico de recursos para una empresa. Los dispositivos edge de alta gama también son costosos para que las empresas inviertan. Es posible que ya se hayan desplegado y presupuestado numerosos dispositivos heredados de función fija o dedicados. La tecnología de clústeres edge ofrece a las empresas una forma de modernizar y preparar sus aplicaciones para el futuro mediante un enfoque nativo del edge. Se realiza conectando dichos dispositivos con un clúster edge de pequeña huella que ejecuta una solución de plataforma de gestión de dispositivos o IoT. El clúster edge se gestionaría y operaría como un dispositivo edge.
Los clústeres en el borde ofrecen los siguientes beneficios clave:
- Escalable: proporcione a los clientes la facilidad y la capacidad de agregar capacidad adicional al clúster en función de la demanda. Se puede configurar para escalar automáticamente, lo que reduce el tiempo y el esfuerzo del equipo de operaciones.
- Distribuido: insight y acción más rápidas a medida que el clúster procesa y analiza más datos, evitando así el gasto y el tiempo para enviar datos a la nube.
- Cumplimiento: el procesamiento de datos en el clúster edge también ayuda con las necesidades de cumplimiento normativo, la residencia de datos y el aislamiento de datos.
- Seguro: comunicación segura entre todos los servidores de aplicaciones alojados en el clúster.
- Alta disponibilidad: las opciones de conmutación por recuperación en el clúster y la capacidad de crear nuevos nodos a medida que surge la necesidad proporcionan una mayor confiabilidad para el funcionamiento continuo y sin problemas de la aplicación.
Veamos un ejemplo en la industria de venta minorista. Un minorista quiere retirar un producto específico de la tienda o hacer que no esté disponible para comprar debido a un retiro de seguridad. Tendrían que actualizar su sistema de inventario central y enviar esa actualización para que surta efecto en varias tiendas.
Un clúster en el almacenar, junto con dispositivos IoT, cámaras y sensores, es muy adecuado para dar soporte a este escenario. Mientras que el sistema de inventario del almacenar marca el SKU (unidad de mantenimiento de existencias) particular como retirado, también se notifica al gerente del almacenar que retire los productos físicos de los estantes. Al mismo tiempo, el sistema de punto de venta (POS) se actualiza para invalidar el código de barras de ese producto en particular. Una solución de clúster edge bien diseñada permitiría una acción tan rápida, a escala, sin costosos retrasos ni errores humanos.
La figura 1 muestra el clúster desplegado en una tienda con diseño de cuadrícula con cámaras de seguridad e inventario, sistemas de punto de venta (POS), un sensor de entrada y sensores de temperatura en congeladores:
Veamos otro ejemplo, este en el sector del transporte. Un buque de carga que tiene conectividad limitada a la red transporta cientos de contenedores frigoríficos. Los contenedores refrigerados son, en pocas palabras, grandes refrigeradores transportados por buques portacontenedores para mover contenedores sensibles a la temperatura, como carne, verduras y productos farmacéuticos, sin que se echen a perder. El contenido determina la temperatura que se mantendrá dentro de estos contenedores frigoríficos.
Los contenedores refrigerados no solo tienen que mantener una temperatura estable en el interior, sino también controlar la humedad y promover un flujo de aire adecuado. El monitoreo y la gestión de los termostatos, ventiladores y otros componentes vitales del frigorífico se realizan mejor mediante un clúster edge, incluso en el escenario de conectividad limitada a bordo del barco. Esta configuración también permitirá el monitoreo y las alertas en el buque sin necesidad de una infraestructura basada en la nube. Cuando el barco llega a un puerto, el clúster edge se vuelve a conectar con el centro edge en el muelle de envío o en la nube. La gestión de estos reefers y otros dispositivos a escala, con poca o ninguna intervención humana, solo es posible a través de una solución de clúster edge bien diseñada.
Un clúster edge puede ser lo suficientemente pequeño como para caber en un estante disponible en un espacio confinado como un QSR (restaurante de servicio rápido), un tren, una ambulancia, un quiosco, tiendas, almacenes y plantas de producción. Podemos desplegar cargas de trabajo relevantes para ese entorno. Estas podrían ser aplicaciones de detección de video, aplicaciones de detección de temperatura, aplicaciones de emisión de boletos, servicios de voz de misión crítica o incluso aplicaciones de RA/RV.
Como ejemplo representativo de una modesta instalación de clúster de Kubernetes para los escenarios anteriores, aquí hay algunos detalles sobre cómo implementar el uso de K3s. Tenga en cuenta que también podría usar distribuciones de Kubernetes similares, como minikube o microk8s. La siguiente lista muestra la configuración del clúster de un nodo K3 básico de 1 maestro y 2 trabajadores (https://k3s.io/). Mostramos el conjunto mínimo de comandos que se necesitan para ejecutar en cada componente. La topología de 3 nodos se muestra en la siguiente tabla:
K3S_URL es la dirección IP del nodo maestro junto con el puerto, donde 6443 es el puerto de escucha HTTPS. Tenga en cuenta que, de forma predeterminada, K3s utiliza contenedores en contenedores y no Docker.
Maestro
$export K3S_URL="https://192.168.0.248:6443" $curl -sfL https://get.k3s.io | sh - $sudo cat /var/lib/rancher/k3s/server/node-token K10e1d3513c6e47d402450465d7726ee6ac1240d62dc11521726aba73461e230bbe::server:79917a97f717e29d5858a6d45b5adccd
Trabajador 1
$export K3S_KUBECONFIG_MODE="644" $export K3S_URL="https://192.168.0.248:6443" $export K3S_TOKEN="K10e1d3513c6e47d402450465d7726ee6ac1240d62dc11521726aba73461e230bbe::server:79917a97f717e29d5858a6d45b5adccd"
Trabajador 2
$export K3S_KUBECONFIG_MODE="644" $export K3S_URL="https://192.168.0.248:6443" $export K3S_TOKEN="K10e1d3513c6e47d402450465d7726ee6ac1240d62dc11521726aba73461e230bbe::server:79917a97f717e29d585
Desde la perspectiva de IBM Edge Application Manager (IEAM), un clúster edge es similar a un dispositivo edge porque ambos tienen un agente edge instalado. La figura 2 muestra los componentes de alto nivel de un clúster edge:
Los clústeres edge son básicamente nodos edge que son clústeres basados en Kubernetes. Entonces, ¿cuál es la razón para configurar un pequeño clúster como nodo edge? Cada nodo edge, en este caso, el clúster edge, se registra en el intercambio bajo la organización del propietario del clúster edge. El registro consta de un ID y un token de seguridad que se aplica solo a ese clúster edge. Un proceso de agente autónomo se ejecuta en ese clúster edge y aplica las políticas establecidas por el propietario del clúster edge. Al mismo tiempo, a los bots de acuerdos autónomos (o agbots) se les asignan políticas de despliegue para desplegar servicios en estos clústeres edge.
Lo anterior describe los pasos en el producto IBM Edge Application Manager, que permite el despliegue de servicios edge en un clúster edge a través de un operador de Kubernetes, habilitando así los mismos mecanismos de despliegue autónomos que se utilizan con dispositivos edge. Esto significa que toda la potencia de Kubernetes como plataforma de gestión de contenedores está disponible para los servicios de edge.
Este enlace en el centro de conocimiento del producto detalla los pasos para instalar un agente edge en un clúster edge. Después de lo cual, las aplicaciones pertinentes se pueden instalar en ese clúster edge. Como habrá adivinado, IEAM admite Kubernetes, K3s, MiniKube, Microk8s y Red Hat OpenShift.
Este blog describió el valor comercial único que proporciona el despliegue de clústeres en el edge, no necesariamente en el borde lejano, pero nodos en ubicaciones remotas on premises. Para reiterar, las capacidades de agrupación en clústeres de nodos edge le ayudan a gestionar y desplegar cargas de trabajo desde un clúster de centro de gestión a instancias remotas de OCP u otros clústeres basados en Kubernetes.
Un clúster edge permite casos de uso en el perímetro que requieren la coubicación de la computación con las operaciones comerciales o que requieren más escalabilidad, disponibilidad y capacidad informática de las que puede admitir un dispositivo edge. Además, no es raro que los clústeres edge proporcionen los servicios de aplicaciones necesarios para admitir los servicios que se ejecutan en dispositivos edge debido a su proximidad a esos dispositivos.
Existe una herramienta de gestión de contenedores de código abierto más nueva para desarrollar, gestionar y ejecutar contenedores de Open Container Initiative (OCI). Llamado Podman (abreviatura de Pod Manager), es una opción muy adecuada para clústeres edge. Podman se proporciona como parte de la biblioteca libpod y se puede utilizar para crear y mantener contenedores. Si bien puede ejecutar contenedores Docker, actualmente solo se ejecuta en sistemas operativos basados en Linux. Puede aprender más sobre Podman aquí.
El centro de arquitectura de IBM Cloud ofrece muchas arquitecturas de referencia híbridas y multinube.
También puede ver la arquitectura de referencia automotriz relacionada con el edge recientemente publicada.
Un agradecimiento especial a Joe Pearson y David Booz por revisar el artículo.
Asegúrese de consultar otras entregas de esta serie de entradas en el blog sobre computación edge:
- Parte 3: “Arquitectura en edge”
- Parte 4: “DevOps en el edge”
- Parte 7: “Seguridad en el edge”
- Parte 8: “Análisis en el edge”
- Parte 9: “5G en el edge”
- Parte 10: “Clústeres en el edge”
- Parte 11: “Automatización en el edge”
- Parte 12: “Corte de red en el edge”
- Parte 13: “Datos en el edge”
- Parte 14: “Decisiones arquitectónicas en el edge”
- Parte 15: “GitOps en el edge”
- Parte 17: “Servicios de almacenamiento en el edge”
- Parte 18: “Servicios en la nube en el edge”
- Parte 20: “Soberanía de datos en el edge”
- Parte 22: “Productos conectados en el edge”
- Parte 23: “Modelos fundacionales en el edge”