Nota de traducción.: El autor del material original es Henning Jacobs de Zalando. Ha creado una nueva interfaz web para trabajar con Kubernetes, que se presenta como «kubectl para la web». ¿Por qué apareció este nuevo proyecto de código abierto y qué criterios no cumplían las soluciones existentes? Lee más en su artículo.
En esta publicación, analizo diversas interfaces web de Kubernetes de código abierto, presento mis requisitos para una UI universal y explico por qué la desarrollé. — una interfaz destinada a facilitar el soporte y la resolución de problemas en múltiples clusters.
Casos de uso
En Zalando atendemos a un gran número de usuarios de Kubernetes (más de 900) y clusters (más de 100). Hay un par de casos de uso típicos en los que sería muy útil contar con la ayuda de una herramienta web especializada:
- comunicación con colegas dentro del soporte;
- respuesta a incidentes e investigación de sus causas.
Soporte
Desde mi experiencia, la comunicación en soporte a menudo se ve así:
— ¡Ayuda, nuestro servicio XYZ no está disponible!
— ¿Qué ves cuando ejecutas kubectl describe ingress ...?
O algo similar para CRD:
— Tengo un problema con el servicio de identidad…
— ¿Qué devuelve el comando kubectl describe platformcredentialsset ...?
Esta comunicación generalmente se reduce a ingresar varias variaciones del comando kubectl con el fin de identificar el problema. Como resultado, ambas partes de la conversación se ven obligadas a cambiar constantemente entre la terminal y el chat web, además de observar diferentes situaciones.
Por lo tanto, quiero que el frontend web de Kubernetes permita lo siguiente:
- los usuarios podrían intercambiar enlaces y ver lo mismo;
- ayudara a evitar errores humanos en el soporte: por ejemplo, acceder al cluster incorrecto desde la línea de comandos, errores tipográficos en los comandos de la CLI, etc.;
- permitiría generar vistas personalizadas para enviar a colegas, es decir, agregar columnas de etiquetas, mostrar múltiples tipos de recursos en una misma página;
- idealmente, esta herramienta web debería permitir establecer enlaces 'profundos' a secciones específicas de YAML (por ejemplo, apuntar a un parámetro incorrecto que cause fallos).
Respuesta a incidentes y análisis
La respuesta a incidentes en la infraestructura requiere conciencia situacional, capacidad para evaluar el impacto y búsqueda de patrones en los clústeres. Algunos ejemplos de la vida real:
- un servicio de producción crítico tiene problemas y necesitas encontrar todos los recursos de Kubernetes por nombre en todos los clústeres, para solucionar el problema;
- los nodos comienzan a fallar al escalar, y necesitas encontrar todos los pods con estado «Pending» en todos los clústeres, para evaluar la magnitud del problema;
- usuarios individuales informan de un problema con un DaemonSet desplegado en todos los clústeres, y es necesario averiguar si el problema es generalizado.
Mi solución estándar en tales casos es algo como for i in $clusters; do kubectl ...; done. Evidentemente, se puede desarrollar una herramienta que proporcione capacidades similares.
Las interfaces web existentes de Kubernetes
El mundo de las interfaces web de código abierto para Kubernetes no es muy grande*, así que traté de recopilar información adicional mediante :
* Mi explicación sobre el número limitado de interfaces web para Kubernetes: los servicios en la nube y los proveedores de Kubernetes generalmente ofrecen sus propias interfaces frontales, por lo que el mercado de UI «buenas» libres para Kubernetes es relativamente pequeño.
A través de un tweet, supe de , y . Veamos estas y otras soluciones de código abierto existentes, intentemos entender qué son.
K8Dash
«K8Dash es la forma más sencilla de gestionar un clúster de Kubernetes».
se ve bien y parece funcionar rápido, pero tiene varias desventajas para los escenarios de uso mencionados anteriormente:
- Funciona solo dentro de un clúster.
- La clasificación y filtrado son posibles, pero no tienen enlaces permanentes.
- Falta el soporte para Custom Resource Definitions (CRDs).
Kubernator
«Kubernator es una UI alternativa para Kubernetes. A diferencia del panel de alto nivel del Kubernetes Dashboard, proporciona un control de bajo nivel y una excelente visión de todos los objetos en el clúster con la posibilidad de crear nuevos, editarlos y resolver conflictos. Siendo completamente una aplicación cliente (como kubectl), no requiere ningún backend excepto el propio servidor API de Kubernetes, y también toma en cuenta las reglas de acceso al clúster».
Es una descripción bastante precisa de . Lamentablemente, le faltan algunas capacidades:
- Solo admite un clúster.
- No hay un modo de vista en lista (es decir, no se pueden mostrar todos los pods con estado 'Pending').
Kubernetes Dashboard
«Kubernetes Dashboard es una interfaz web universal para clústeres de Kubernetes. Permite a los usuarios gestionar las aplicaciones que funcionan en el clúster y solucionar problemas, así como gestionar el clúster en sí».
Desafortunadamente, no ayuda mucho en mis actividades de soporte y respuesta a incidentes, porque en él:
- no hay enlaces permanentes, por ejemplo, cuando filtro recursos o cambio el orden de clasificación;
- no hay una forma sencilla de filtrar por estado, por ejemplo, ver todos los pods con estado 'Pending';
- solo se admite un clúster;
- no se admiten CRD (esta función está en desarrollo);
- no hay columnas personalizadas (por ejemplo, columnas con etiquetas como
kubectl -L).
Kubernetes Operational View (kube-ops-view)
«Panel de observación del espacio de clústeres K8s».
En se adopta un enfoque completamente diferente: esta herramienta solo muestra los nodos del clúster y los pods mediante WebGL, sin detalles textuales sobre los objetos. Es ideal para una visión operativa del estado del clúster ('¿los pods están cayendo?')*, pero no es adecuada para los casos de uso descritos anteriormente en soporte y respuesta a incidentes.
* Nota de traducción.: En este sentido, también puede interesarte nuestro complemento , del que hablamos en detalle en .
Kubernetes Resource Report (kube-resource-report)
«Reúne información sobre las solicitudes de recursos de los pods y del clúster de Kubernetes, compárala con el consumo de recursos y genera un HTML estático».
genera informes HTML estáticos sobre el uso de recursos y la distribución de costos por equipos/aplicaciones en los clústeres. El informe es útil en cierta medida para soporte y respuesta a incidentes, ya que permite encontrar más rápidamente el clúster donde se desplegó la aplicación.
Nota de traducción.: En la visualización de la distribución de recursos y su costo, el servicio y herramienta , cuyo resumen publicamos .
Octant
«Una plataforma web extensible para desarrolladores destinada a proporcionar una mejor comprensión de la complejidad de los clústeres de Kubernetes».
, creado en VMware, es un nuevo producto del cual supe relativamente hace poco. Con él, es conveniente explorar el clúster en una máquina local (incluso hay visualizaciones), sin embargo, aborda la problemática del soporte y la respuesta a incidentes solo en una medida limitada. Desventajas de Octant:
- No hay búsqueda en los clústeres.
- Funciona solo en la máquina local (no se implementa en el clúster).
- No se pueden ordenar/filtrar objetos (solo se admite el selector de etiquetas).
- No se pueden establecer columnas personalizadas.
- No se puede listar objetos por espacios de nombres.
Además, tuve problemas con la estabilidad de Octant con los clústeres de Zalando: en algunos CRD .
Presento Kubernetes Web View
"kubectl para la web."
Tras analizar las opciones de interfaces disponibles para Kubernetes, decidí crear una nueva: . En esencia, solo necesito todo el poder kubectl en la web, es decir:
- disponibilidad de todas las operaciones (de solo lectura) en las que los usuarios prefieren usar kubectl;
- todas las URL deben ser permanentes y representar la página en su forma original, para que los colegas puedan compartirlas y usarlas en otras herramientas;
- soporte para todos los objetos de Kubernetes, lo que permitirá resolver problemas de cualquier tipo;
- las listas de recursos deben poder descargarse para el trabajo posterior (en hojas de cálculo, herramientas de CLI como
grep) y almacenamiento (por ejemplo, para postmortems); - soporte para filtrar recursos por etiquetas (de manera similar a
kubectl get .. -l); - posibilidad de crear listas combinadas de diferentes tipos de recursos (de manera similar a
kubectl get all) para obtener una visión general operativa entre colegas (por ejemplo, durante la respuesta a un incidente); - posibilidad de agregar "enlaces profundos inteligentes" personalizables a otras herramientas, como paneles de control, registradores, registros de aplicaciones, etc., para facilitar la búsqueda/solución de problemas y la respuesta ante incidentes;
- el frontend debe ser lo más simple posible (HTML limpio), para evitar problemas accidentales, por ejemplo, un JavaScript que se bloquee;
- soporte para múltiples clústeres para facilitar la interacción durante la consultoría remota (por ejemplo, para recordar solo una URL);
- si es posible, debe simplificar el análisis situacional (por ejemplo, con enlaces para descargar recursos en todos los clústeres/espacios de nombres);
- más opciones para crear enlaces flexibles y resaltar información textual, por ejemplo, para poder señalar a los colegas una sección específica en la descripción del recurso (línea en YAML);
- posibilidad de personalización según las necesidades de un cliente específico, por ejemplo, permitiendo crear plantillas de visualización especiales para CRD, vistas tabulares personalizadas, modificar estilos CSS;
- herramientas para un estudio más profundo en la línea de comandos (por ejemplo, mostrando comandos completos
kubectl, listos para ser copiados);
Fuera de las tareas abordadas en Kubernetes Web View (no objetivos) quedaron:
- abstracción de objetos de Kubernetes;
- gestión de aplicaciones (por ejemplo, gestión de despliegues, gráficos de Helm, etc.);
- operaciones de escritura (deben realizarse a través de herramientas de CI/CD seguras y/o GitOps);
- interfaz atractiva (JavaScript, temas, etc.);
- visualizaciones (ver );
- análisis de costos (ver ).
¿Cómo ayuda Kubernetes Web View en la gestión y respuesta a incidentes?
Soporte
- Todos los enlaces son permanentes, lo que facilita el intercambio de información con colegas.
- Se pueden crear vistas personalizadas, por ejemplo, para mostrar todos los despliegues y pods con una etiqueta específica en dos clústeres concretos (pueden especificarse varios nombres de clústeres y tipos de recursos en el enlace, separándolos por comas).
- Se puede hacer referencia a líneas específicas en el archivo YAML del objeto, señalando problemas potenciales en la especificación del objeto.
Búsqueda en clústeres en Kubernetes Web View
Respuesta a incidentes
- Búsqueda global (búsqueda global) permite buscar objetos en todos los clústeres.
- Las vistas en forma de listas pueden mostrar todos los objetos con un estado/columna específicos en todos los clústeres (por ejemplo, necesitamos encontrar todos los pods con estado "Pending").
- Las listas de objetos se pueden descargar en formato de valores separados por tabulaciones (TSV) para un análisis posterior.
- permiten alternar entre paneles de monitoreo y otras herramientas.
Kubernetes Web View: lista de pods con estado "Pending" en todos los clústeres
Si desea probar Kubernetes Web View, recomiendo revisar la o ver una .
Por supuesto, la interfaz podría ser mejor, pero mientras tanto, Kubernetes Web View es una herramienta para "usuarios avanzados" que no temen manipular manualmente las rutas URL si es necesario. Si tienes comentarios/adiciones/sugerencias, por favor contáctame !
Este artículo es un breve relato sobre las premisas que llevaron a la creación de Kubernetes Web View. ¡Le seguirán otros! (Nota de traducción.: Se esperan en .)
P.D. del traductor
También puedes leer en nuestro blog:
- «»;
- «»;
- «»;
- «».
Fuente: habr.com
