Ya
escribimos sobre "asistentes de consola" para Kubernetes hace un año, e incluso antes
hicimos una descripción general de otras utilidades útiles. Sin embargo, con el desarrollo de K8 y su comunidad, el ecosistema asociado también sufre cambios. Por lo tanto, nuevamente tenemos algo que decirles a los fanáticos de la consola. Vamos!
kubebox
- GitHub (más de 400 estrellas)
- Idioma: JavaScript (Node.js)
- Licencia: MIT
Este proyecto fue la razón para escribir la reseña. Por un lado, es un brillante representante de la categoría de software "geeks do for geeks", pero por otro lado, ha crecido hasta el punto de que no solo agrada a la vista, sino que también brinda beneficios prácticos ...
Entonces, el propósito de kubebox es trabajar completamente con Kubernetes dentro del marco de una interfaz de consola conveniente presentada en el estilo pseudo-gráfico:
Trabajo significa características tales como la navegación a través de pods a través de espacios de nombres, visualización de registros e incluso gráficos de consumo de recursos clave (CPU, memoria, red), ejecución remota de comandos en contenedores. La configuración para conectarse a los clústeres se puede tomar de la variable de entorno
KUBECONFIG o las configuraciones en
$HOME/.kube .
Los planes adicionales de los desarrolladores incluyen soporte para editar configuraciones y realizar operaciones CRUD, así como un
rediseño significativo
de la interfaz para admitir nuevos tipos de primitivas (Servicios, Implementaciones, etc.) y una navegación conveniente en ellos con la salida de información adicional (en particular,
kubectl describe pod ).
Una característica importante es la disponibilidad de una
versión en línea (para conectarse al servidor API de Kubernetes, necesitará
cors-allowed-origins permitidos
cors-allowed-origins ). Además, kubebox se puede iniciar como un archivo ejecutable separado, como un cliente
dentro del clúster (a través de kubectl), así como desde un servicio implementado en un clúster Kubernetes o OpenShift (
Xterm.js se usa para emular el terminal).
Durante casi 2 años, un empleado de Red Hat de Francia ha estado desarrollando kubebox (para ser exactos, incluso menos del 10% de los compromisos fueron realizados por su colega). El proyecto recibió suficiente publicidad el mes pasado (en
Reddit y otros recursos), por lo que se puede esperar que esto dé un nuevo impulso a su desarrollo.
kube-shell y kube-prompt
kube-shell
- GitHub (más de 950 estrellas)
- Lenguaje: Python
- Licencia: Apache 2.0
(¡Atención, este ~ 2 Mb GIF!)kube-prompt
- GitHub (más de 700 estrellas)
- Idioma: ir
- Licencia: MIT
Ya
escribimos sobre estos proyectos hace un año, y en ese momento eran los favoritos incondicionales entre las consolas de consola completas para trabajar con Kubernetes. Ambos se posicionan como interfaces mejoradas (más convenientes de usar) para kubectl. En kube-shell, usan la biblioteca
prompt-toolkit para Python, y para kube-prompt tomaron y desarrollaron una biblioteca similar en Go (
go-prompt ).
Si los compara con kubebox, entonces la interfaz no se basa en pseudografías, sino en la consola habitual para ingresar comandos
(ver capturas de pantalla más arriba) , que, sin embargo, se acompaña de interesantes "efectos especiales": información sobre herramientas con comandos, conveniente adición automática y etc.
A pesar de la amplia gama de características compatibles (incluido el sistema de sugerencias y autocompletado desarrollado ya mencionado, una búsqueda del historial de comandos y un modo de edición similar a vi), el
historial de confirmaciones en kube-shell indica una clara desaceleración en el proyecto. Este año solo se registraron siete confirmaciones, dos de las cuales son modificaciones
README . Aunque hubo algunos útiles, por ejemplo, el
tan esperado soporte para la variable
KUBECONFIG . De una forma u otra, la continua falta de reacción de los desarrolladores a las consultas relevantes para el usuario (ver
problemas ) no inspira perspectivas adecuadas.
La situación con el desarrollo de kube-prompt se ve un poco mejor. Aunque este proyecto obtuvo menos estrellas en GitHub (si hace un año estaba ligeramente por delante de su competidor de Python, ahora está notablemente atrasado), las confirmaciones aparecen más o menos regularmente, y la última versión (
1.0.5 ) está fechada el 18 de octubre. Sin embargo, no hay tantos cambios significativos durante el año pasado: observamos el soporte para Kubernetes versión 1.11 y la posibilidad de autocompletar el espacio de nombres. Lo principal es que el propio autor
admite la imposibilidad de dedicar suficiente tiempo al desarrollo de kube-prompt y está buscando ayudantes.
Resumiendo los resultados de estos dos proyectos, podemos decir que kube-shell retuvo su liderazgo en términos de capacidades compatibles y se adelantó en popularidad, pero con las perspectivas de ambos shells, no todo está claro. Sin embargo, si se siente cómodo con la forma en que funcionan ahora, no hay razón para no ponerlos en servicio, ya que otras alternativas en un diseño similar no aparecieron.
Haga clic en
- GitHub (más de 750 estrellas)
- Idioma: óxido
- Licencia: Apache 2.0
Click es un proyecto bastante joven: en forma beta, se
presentó a fines de marzo, y muy interesante a su manera. Su concepto se reduce a usar kubectl en un
bucle REPL , lo que facilita la vida al mantener un entorno constante. La última es que Click "recuerda" el contexto actual, el espacio de nombres, debajo, etc., lo que lleva al usuario a ejecutar el comando deseado para el recurso dado sin tener que volver a especificar esta "ruta" completa.
La idea del proyecto se originó en la empresa Databricks, donde utilizan activamente Kubernetes y están cansados de observar el mismo escenario de trabajo con kubectl, que requiere la introducción constante de datos anteriores. Al mismo tiempo, la propia utilidad kubectl, como la consola en general, es muy popular entre los ingenieros. Así que este complemento apareció, no reclamando reemplazar kubectl, sino solo ayudando a trabajar con él. Un ejemplo de caso de uso para Click es:
pods //
2 //
describe //
events //
logs -c foo > /tmp/podfoo.log //
delete // ( )Si está interesado, vea también un
pequeño screencast que demuestra el trabajo de Click con comentarios de texto.
Trabajar con troncos
Como beneficio adicional, no shells, sino herramientas de consola para trabajar con registros en Kubernetes. Hace un año, mencionamos solo
k8stail como tal, pero el tiempo pasado ha demostrado que el problema es relevante, y hay otras soluciones dignas de atención para resolverlo.
Popa
- GitHub (~ 1300 estrellas)
- Idioma: ir
- Licencia: Apache 2.0
Stern es el favorito indiscutible de la cola para la categoría Kubernetes. Para mayor claridad, cuando se muestran registros, se utilizan diferentes códigos de color:
Otra característica importante es el uso de expresiones regulares para el filtrado conveniente de hogares sin la necesidad de conocer identificadores específicos (por ejemplo, seleccione todo con el nombre
web-\w+ ). De manera similar (es decir, regexpams), puede filtrar contenedores específicos para los pods solicitados. Entre otras características de popa:
- soporte para plantillas Go personalizadas para registros de salida (hay varias predefinidas por defecto);
- soporte para selectores de etiquetas;
- restricción de la salida del registro a un valor de tiempo específico -
--since y / o un número específico de líneas; - soporte para autocompletar bash y zsh, así como sustitución dinámica de valores para espacios de nombres y contextos.
Kubetail
- GitHub (~ 950 estrellas)
- Idioma: Shell
- Licencia: Apache 2.0
Una solución similar, escrita en Bash regular y un poco más desarrollada activamente en el último año. Al igual que Stern, admite resaltar los nombres de los hogares (o la línea completa que se puede personalizar):
También le permite filtrar pods y contenedores por nombres completos y expresiones regulares, así como usar selectores, limitar la salida al tiempo y al número de líneas, y admite la finalización automática para Bash, zsh y fish. Entre otras características:
- modo de desactivación:
--follow para actualizar los datos de los registros en tiempo real (como en la tail -f ); --dry-run en --dry-run para mostrar una lista de pods y contenedores adecuados sin realizar ninguna otra acción;- Soporte de selector jq para analizar la salida en JSON.
Kail
- GitHub (~ 500 estrellas)
- Idioma: ir
- Licencia: MIT
Otra implementación que ha experimentado la menor actividad en la base de código durante el año pasado. Sin embargo, tiene características funcionales interesantes que difieren de sus competidores, a saber:
- restricción a petición de los pods por los nombres de su Servicio, ReplicationController, ReplicaSet, Deployment, Node y / o Ingress (es decir, pods pertenecientes a los servicios a los que conduce el Ingress especificado) ;
- la capacidad no solo de seleccionar por selectores, sino también de excluirlos;
- determinación del nivel de registro (
--log-level ).
Pero también hay desventajas: kail no resalta las vainas con colores, no admite expresiones regulares para filtros.
PS
¡Gracias por su interés y, por supuesto, estaremos encantados de escuchar sus hallazgos en los comentarios!
Lea también en nuestro blog: