Kubernetes juega un papel importante en Microsoft. El sistema de gestión de contenedores es una pieza fundamental de las numerosas nubes de la empresa, desde Microsoft 365 y Xbox hasta Azure y socios como OpenAI que utilizan Kubernetes de Microsoft para alojar sus propios servicios.
Como resultado, Microsoft ha inventado muchos de sus propias herramientas de gestión de Kubernetes. Éstas incluyen kaito para implementar cargas de trabajo de inferencia de IA y Flota para la gestión a gran escala de clústeres de Kubernetes. Todas las diversas herramientas de Microsoft se encuentran debajo de sus dos servicios administrados de Kubernetes, Azure Kubernetes Service y Azure Container Service, lo que le permite implementar y orquestar sus aplicaciones basadas en contenedores sin necesidad de crear el marco de administración necesario. Todo es gratuito, con API, portales e interfaces de línea de comandos.
En los viejos tiempos, eso habría sido todo. Microsoft habría utilizado estas características para diferenciarse de sus competidores y sus nubes Kubernetes. Pero Microsoft ha tomado la modelo de código abierto en serio, y muchos de los líderes de sus iniciativas de Kubernetes provienen de una experiencia de código abierto. En lugar de guardar sus herramientas de Kubernetes para sí mismo, Microsoft las lanza como proyectos de código abierto, donde cualquiera puede utilizarlas y donde cualquiera puede contribuir con código nuevo.
Presentamos la plataforma de observabilidad Retina
Una de las últimas herramientas de Azure en convertirse un proyecto de código abierto es Retina, una herramienta de observabilidad de red diseñada para ayudarlo a comprender el tráfico de red en todos sus clústeres, sin importar cómo estén configurados o qué sistema operativo utilicen. Tampoco existe ningún vínculo con la funcionalidad de Azure. Puede ejecutar Retina en cualquier instancia de Kubernetes, local o en AWS, Azure o GCP.
En el corazón de Retina, muy parecido a la herramienta de seguridad Falcoson Filtros de paquetes Berkeley extendidos (eBPF). Estos le permiten ejecutar código en el kernel del sistema operativo host, fuera de los contenedores de su aplicación, para que pueda usar sondas eBPF sin afectar significativamente el código que está ejecutando. No es necesario agregar agentes a sus contenedores ni agregar bibliotecas de monitoreo a su código, y una sonda eBPF puede monitorear todos los nodos que se ejecutan en un host, ya sea una máquina virtual en la nube o hardware físico local.
La ejecución de sondas Retina en el kernel simplifica el monitoreo de la red. No necesita saber qué tarjetas de red están instaladas en el servidor host ni cómo su instalación de Kubernetes utiliza una malla de servicios. En su lugar, podrá ver cómo la pila de red del sistema operativo host maneja los paquetes. Puede realizar un seguimiento de los tipos de paquetes, la latencia y la pérdida de paquetes, aprovechando las funciones TCP/IP de bajo nivel a las que es posible que no se pueda acceder en un nivel superior.
Al centrarse en hacer observables las redes nativas de la nube, Retina está diseñada para adaptarse a cualquier conjunto de herramientas de monitoreo y cualquier instalación de Kubernetes. Hay soporte tanto para Linux como para Windows, lo que debería ayudarle a monitorear y depurar aplicaciones híbridas que combinan servicios de Linux y Windows. Como las sondas eBPF son código, puede considerarlas como complementos personalizables, lo que permite que Retina evolucione con nuevas funciones de Kubernetes y admita las métricas que necesita para sus requisitos de monitoreo.
Los datos se entregan al conocido servicio de registro de Prometheus a nivel de nodo. Los datos recopilados incluyen DNS, operaciones de capa 4 y capturas de paquetes. Debido a que los datos están etiquetados, puede crear un mapa de operaciones en su entorno de Kubernetes, lo que ayuda a rastrear problemas como un microservicio de bloqueo mientras Retina registra el patrón de flujos dentro y alrededor de sus instancias de Kubernetes.
Empezando con Retina
Comienza por clonando el repositorio Retina GitHub, luego use los gráficos de Helm incluidos para instalar. Es posible que también deba configurar Prometheus para asegurarse de que Retina registre datos. Si quieres utilizar la CLI de Retina, debe ejecutarse en un Kubernetes alojado en Linux. La CLI se ejecuta en kubectl, por lo que será fácil de usar junto con otras herramientas CLI de Kubernetes. Como alternativa, puede utilizar definiciones de recursos personalizados de YAML para configurar y ejecutar una captura de red.
En Linux, el complemento de captura de red eBPF es una versión de la herramienta de código abierto Inspektor Gadget. Esto fue desarrollado originalmente por el equipo de Kinvolk, ahora parte de Azure y todavía centrado en la ingeniería de contenedores. Inspector Gadget es una biblioteca de herramientas Kubernetes eBPF que funciona con aplicaciones Kubernetes de cualquier tamaño, desde nodos únicos hasta grandes clústeres. Retina utiliza dispositivos de seguimiento de Inspektor Gadget para observar eventos del sistema de red.
Observando redes de contenedores
El sitio web de retina proporciona instrucciones detalladas para trabajar con la herramienta. Retina ofrece tres modos de funcionamiento diferentes: métricas básicas a nivel de nodo, métricas de «contexto remoto» más detalladas con soporte para agregar por pod de origen y destino, y una opción de «contexto local» que le permite elegir qué pods monitorear.
Es importante tener en cuenta que no ve todo de forma predeterminada, ya que podría resultar abrumador. En cambio, diferentes complementos habilitan diferentes métricas. Por ejemplo, si desea realizar un seguimiento de las llamadas DNS, comience habilitando el complemento DNS. Todas las métricas incluyen metadatos de instancias y clústeres, por lo que puede filtrar e informar utilizando etiquetas para identificar nodos y pods de destino específicos. Las opciones de contexto local y remoto agregan etiquetas que rastrean el origen y el destino.
Configurar Retina también requiere estableciendo un objetivo Prometheus para los datos, junto con un panel de Grafana apropiado. Microsoft proporciona configuraciones de muestra para ambos en GitHub en el repositorio Retina. Los valores predeterminados muestran datos de redes y DNS para su clúster. Tener los datos en Prometheus le permite utilizar otras herramientas para trabajar con datos de Retina, por ejemplo, introducir datos en un motor de políticas para activar alertas o automatizar operaciones específicas.
Con Retina instalada y Prometheus y Grafana configurados, ahora puede ir más allá de los valores predeterminados y configurar el agente Retina y los complementos a través de YAML. La configuración de métricas adicionales se realiza a través de definiciones de recursos personalizados de Kubernetes.
Medición de las operaciones de la red Kubernetes
Retina no es realmente una herramienta para el monitoreo continuo a nivel de paquetes, ya que generará una gran cantidad de datos en un clúster ocupado, a menos, por supuesto, que la use con una herramienta basada en políticas para identificar excepciones del funcionamiento normal. En la práctica, quizás sea mejor utilizar Retina para identificar las causas fundamentales de problemas con un clúster en ejecución. Quizás los nodos no puedan comunicarse entre sí o sospeche que los errores pueden deberse a la latencia en una interacción de servicio específica. Aquí puede activar la captura de paquetes requerida con un solo comando que recopila todos los datos que necesita para ejecutar un diagnóstico.
El funcionamiento continuo se informa a través de métricas que le brindan información estadística sobre problemas clave de la red. Estos se pueden administrar utilizando Prometheus para generar alertas, con paneles de Grafana para brindarle una descripción general del rendimiento general de su clúster, junto con datos de otras herramientas de observabilidad.
Una métrica útil que ofrece Retina es una que a menudo se ignora: la latencia de API. Sin embargo, en el desarrollo nativo de la nube, a menudo se trabaja con API de terceros. Algunos podrían ser servicios de plataforma de un proveedor de nube, mientras que otros podrían ser fuentes de datos esenciales de línea de negocio, como Salesforce o SAP Hana. Aquí puede utilizar la latencia del servidor API de Retina para obtener métricas que ayuden a realizar un seguimiento de los tiempos de respuesta del servidor.
Tener estos datos le permite iniciar un proceso de diagnóstico con su proveedor de API, lo que le ayudará a rastrear el origen de cualquier latencia. Los retrasos en el acceso a la API pueden ser un obstáculo importante para sus aplicaciones, por lo que tener estos datos puede ayudarle a ofrecer una aplicación más confiable y con mayor capacidad de respuesta.
Un ecosistema de Kubernetes en proceso de maduración
Microsoft ha creado una versión preliminar de una herramienta de observabilidad basada en Retina disponible para Azure Kubernetes Service como complemento de observabilidad de red. Esto funciona con Prometheus y Grafana administrados por Azure. Puede encontrar una lista de métricas preconfiguradas en su documentación, pero actualmente ofrece solo un subconjunto de las capacidades de Retina, y solo ofrece métricas a nivel de nodo.
Un punto clave a considerar con Retina es que se basa en la experiencia de Azure con Kubernetes. Las métricas capturadas de inmediato son las que el equipo de Azure considera importantes, y usted está aprovechando el conocimiento que respalda uno de los entornos de Kubernetes más grandes y activos del mundo. Si necesita métricas alternativas, puede crear sus propias sondas eBPF para Retina, que luego pueden compartirse con la comunidad de Kubernetes en general.
El código abierto requiere experiencia compartida para tener éxito. Al abrir la base del código, Microsoft anima a los desarrolladores de Retina a aportar sus conocimientos a la plataforma, con la esperanza de que AWS, GCP y otros operadores de Kubernetes a escala compartan las lecciones de redes que han aprendido con el mundo. A medida que Kubernetes madure, las herramientas basadas en eBPF como Retina y Falco serán cada vez más importantes, ya que proporcionarán los datos que necesitamos para ofrecer aplicaciones nativas de la nube seguras y confiables a escala.
Copyright © 2024 IDG Communications, Inc.