Clústeres en el edge
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 vídeo, dispositivos de tipo IoT y varios sensores y actuadores. Esta publicación analizará los contenedores implementados en pequeños clústeres edge que actúan como nodos edge — sí, ejecutando clústeres Kubernetes en máquinas de clase Raspberry Pi o en factores de forma pequeños como Intel NUC con suficiente computación y almacenamiento. Concretamente, 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 de Edge en una ubicación en las instalaciones, lejos de un centro de datos.
Las aplicaciones de computación intensiva requieren una alta capacidad informática para el proceso 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 edge 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 en las instalaciones de alta disponibilidad pueden requerir la escalabilidad que los clústeres de Kubernetes están diseñados para proporcionar, como las implementaciones de edge en la nube.
Un clúster de edge a menudo puede ser un límite lógico de recursos para una empresa. Los dispositivos edge de gama alta también son caros para que las empresas inviertan. Es posible que ya se hayan implementado y presupuestado numerosos dispositivos heredados de función fija o dedicados. La tecnología de clúster de edge ofrece a las empresas una forma de modernizar y preparar sus aplicaciones para el futuro utilizando un enfoque nativo del edge. Se realiza conectando dichos dispositivos con un clúster de edge de pequeña huella que ejecuta una solución de gestión de dispositivos o plataforma IoT. El clúster de edge se gestionaría y operaría como un dispositivo edge.
Los clústeres en el edge ofrecen los siguientes beneficios clave:
- Escalable: proporcione a los clientes la facilidad y la capacidad de añadir capacidad adicional al clúster en función de la demanda. Se puede configurar para que se escale automáticamente, lo que reduce el tiempo y el esfuerzo del equipo de operaciones.
- Distribuido: conocimiento y acción más rápidos a medida que el clúster de edge procesa y analiza más datos, lo que evita el gasto y el tiempo de enviar datos a la nube.
- Cumplimiento: el procesamiento de datos en el clúster de 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 de que la aplicación funcione sin problemas proporcionan una mayor fiabilidad.
Veamos un ejemplo en el sector minorista. Un minorista quiere retirar un producto específico del estante de la tienda o hacer que no esté disponible para su compra debido a una retirada por seguridad. Tendría que actualizar su inventario central y enviar esa actualización para que surta efecto en varias tiendas.
Un clúster de edge en la tienda, junto con dispositivos IoT, cámaras y sensores, es muy adecuado para dar soporte a este escenario. Mientras que el sistema de inventario de la tienda marca la SKU (unidad de mantenimiento de existencias) en particular como retirada, también se notifica al gerente de la tienda para retirar 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 de 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 de edge implementado en una tienda típica 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 una conectividad limitada a la red transporta cientos de contenedores frigoríficos. Los contenedores son, en pocas palabras, grandes frigoríficos transportados por buques portacontenedores para mover mercancías sensibles a la temperatura, como carne, verduras y productos farmacéuticos, sin que se echen a perder. El contenido determina la temperatura que se debe mantener 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. La monitorización y gestión de los termostatos, ventiladores y otros componentes vitales del frigorífico se realiza mejor mediante un clúster de edge, incluso en el escenario de conectividad limitada a bordo del barco. Esta configuración también permitirá la monitorización 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 de edge se vuelve a conectar con el edge hub en el muelle de envío o en la nube. La gestión de estos contenedores frigoríficos 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 de edge bien diseñada.
Un clúster 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 implementar cargas de trabajo relevantes para ese entorno. Estas podrían ser aplicaciones de detección de vídeo, aplicaciones de detección de temperatura, aplicaciones de emisión de tickets, 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 utilizar distribuciones de Kubernetes similares, como minikube o microk8s. La siguiente lista muestra una configuración básica de clúster K3s (https://k3s.io/) con 1 nodo maestro y 2 de trabajadores. Mostramos el conjunto mínimo de comandos que se necesitan para ejecutarse 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 containerd y no Docker.
Master
$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 de edge es similar a un dispositivo de edge porque ambos tienen un agente de edge instalado. La Figura 2 muestra los componentes de alto nivel de un clúster de edge:
Los clústeres de edge son básicamente nodos edge que son clústeres basados en Kubernetes. Entonces, ¿cuál es la justificación para configurar un pequeño clúster como un nodo edge? Cada nodo edge (en este caso, el clúster de edge) se registra en el intercambio bajo la organización del propietario del clúster de edge. El registro consta de un identificador y un token que se aplica solo a ese clúster de edge. Un proceso de agente autónomo se ejecuta en ese clúster de edge y aplica las políticas establecidas por el propietario del clúster de edge. Al mismo tiempo, a los bots autónomos (o bots) se les asignan políticas de implementación para implementar servicios en estos clústeres de edge.
Lo anterior describe los pasos del producto IBM Edge Application Manager, que permite la implementación de los servicios edge en un clúster, a través de un operador de Kubernetes, lo que permite los mismos mecanismos de implementación autónomos que se utilizan con los dispositivos edge. Esto significa que toda la potencia de Kubernetes como plataforma de gestión de contenedores está disponible para los servicios edge.
Este enlace en el centro de conocimiento del producto detalla los pasos para instalar un agente edge en un clúster de edge. Después de lo cual, las aplicaciones pertinentes se pueden instalar en ese clúster de edge. Como habrá adivinado, IEAM es compatible con Kubernetes, K3s, MiniKube, Microk8s y Red Hat OpenShift.
Este blog describió el valor empresarial único que proporciona la implementación de clústeres en el edge , no necesariamente en el edge lejano, pero no obstante en nodos edge en ubicaciones remotas on-premises. Para reiterar, las capacidades de agrupación de nodos edge en clústeres ayudan a gestionar e implementar 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 de dge permite casos de uso en el edge que requieren la co-localización de la computación con las operaciones o que requieren más escalabilidad, disponibilidad y capacidades de computación de las que puede admitir un dispositivo de edge. Además, no es raro que los clústeres de edge proporcionen los servicios de aplicación necesarios para respaldar 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 reciente para desarrollar, gestionar y ejecutar contenedores de Open Container Initiative (OCI). Llamada Podman (abreviatura de pod Manager), es una opción muy adecuada para clústeres de edge. Podman se proporciona como parte de la biblioteca libpod y se puede utilizar para crear y mantener contenedores. Aunque puede ejecutar contenedores Docker, actualmente solo se ejecuta en sistemas operativos basados en Linux. Puede obtener más información 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 de automoción 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 de blog sobre edge computing:
- Parte 3: "Arquitectura en el 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 cloud en el edge"
- Parte 20: "Soberanía de los datos en el edge"
- Parte 22: "Productos conectados en el edge"
- Parte 23: "Modelos fundacionales en el edge"