Nos complace anunciar un nuevo desarrollo de código abierto de la compañía Flant para especialistas en DevOps y no solo
kubedog . Esta es una biblioteca escrita por Go y una CLI basada en ella para rastrear eventos de recursos de Kubernetes y recopilar sus registros.
Actualmente, la biblioteca admite el seguimiento de los siguientes recursos: Pod (y Contenedor), Trabajo, Implementación, StatefulSet y DaemonSet. Los eventos y registros se transmiten a través de devoluciones de llamada.
La CLI de kubedog tiene dos modos de operación:
- seguimiento de implementación : seguimiento del recurso hasta alcanzar el estado Listo y salir en caso de error para un uso conveniente en CI / CD;
- follow : imprime eventos y registros en la pantalla sin salir, similar a
tail -f .
El problema
¿Por qué comenzamos a escribir una nueva biblioteca si ya existen proyectos similares
(consulte “Trabajar con registros” en esta revisión ) ? Kubedog se utiliza en nuestra
utilidad dapp DevOps para rastrear
el despliegue de los gráficos Helm. Helm en sí mismo no sabe cómo monitorear el estado de los recursos que agrega, y la transferencia de registros no se proporciona al nivel de interacción GRPC entre Helm y timón. En esta ocasión, está
nuestro problema 3481 , en cuyo marco implementamos el seguimiento de recursos adicionales ... Sin embargo, el proyecto Helm ahora es reacio a agregar nuevas características a Helm 2, ya que todos los esfuerzos se concentran en la nueva versión de
Helm 3 . Por esta razón, decidimos separar kubedog en un proyecto separado.
¿Qué necesita la biblioteca de seguimiento de recursos?
- Obtenga registros de Pods que pertenecen a un recurso, por ejemplo, Implementación.
- Responda a los cambios en la composición de los pods que pertenecen al recurso: agregue registros de recepción de nuevos pods, deshabilite los registros de los pods de viejos ReplicaSets.
- Eventos de seguimiento en los que vienen descifrados de varios errores. Por ejemplo, no se puede crear un Pod debido a una imagen desconocida o se crea un Pod, pero el comando especificado en la plantilla no está en la imagen.
- Y un requisito más es el seguimiento de la transición de un recurso desde el
rollout al modo ready . Y cada recurso tiene sus propias condiciones para esto.
Como puede suponer, en kubedog intentamos
tener en cuenta todo lo anterior .
En el buen sentido, al comienzo del trabajo en algo nuevo, analizan las soluciones existentes. Pero resultó que, aunque hay muchas soluciones en forma de CLI, simplemente no hay una biblioteca Go. Por lo tanto, solo podemos ofrecer una pequeña comparación de las características principales de las utilidades CLI existentes para el seguimiento de los recursos de Kubernetes.
Soluciones existentes
kubespy
→
GitHub- Capaz de monitorear solo la implementación y el servicio, reacciona a los nuevos pods.
- Hay un modo de seguimiento para la descripción del recurso y su estado y la salida de los cambios en forma de json diff.
- Hay una representación tabular en color de los cambios que muestran el estado de ReplicaSets y las condiciones.
- No muestra registros de pod.
- Está escrito en Go, pero no se puede usar como una biblioteca.
kubetail
→
GitHub- Un script bash que llama a kubectl.
- Capaz de mostrar registros de pods existentes.
- No detecta nuevos Pods; si se produce la reversión, se debe reiniciar kubetail.
popa
→
GitHub- Muestra los registros de Pods filtrados por pod-query.
- Descubre nuevas vainas.
- Las líneas de registro están coloreadas para una mejor percepción.
- Muestra los eventos de agregar y quitar Pods con los nombres de los contenedores en ellos.
- No sigue los eventos, por lo tanto, no muestra la causa de los errores de Pod.
- Está escrito en Go, pero no se puede usar como una biblioteca.
kail
→
GitHub- Capaz de mostrar registros simultáneamente de diferentes espacios de nombres para diferentes recursos.
- No supervisa los eventos, no muestra la causa de los errores, por ejemplo, para la implementación.
- No pinta troncos de vainas.
- Está escrito en Go, pero no se puede usar como una biblioteca.
k8stail
→
GitHub- Una selección de Pods por espacio de nombres y etiquetas.
- Realiza un seguimiento de los nuevos, eliminación.
- No sigue los eventos, no mostrará errores.
- On Go, pero no una biblioteca.
kubedog
→
GitHub- La CLI funciona en dos modos: seguimiento sin fin y seguimiento hasta que el recurso cambie al estado LISTO.
- Realiza un seguimiento de un recurso.
- Reacciona a los cambios de recursos, se suscribe a los registros de nuevos Pods.
- Capaz de monitorear la implementación, StatefulSet, DaemonSet, Job o un Pod independiente.
- Escrito en Go, puede usarlo como una biblioteca para agregar recursos a su programa para monitorear el estado de los recursos y recibir registros de los contenedores.
Si observa más de cerca, puede decir que cada utilidad supera de alguna manera a sus rivales y no hay un ganador único que pueda hacer todo lo que hacen los demás.
Entonces kubedog!
La esencia del trabajo de kubedog es la siguiente: para el recurso especificado, ejecute Vigilantes en Eventos y en Pods que pertenezcan al recurso, y cuando aparezca Pod, ejecute su registrador. Todo lo que sucede con el recurso se transmite al cliente mediante devoluciones de llamada.
Veamos un ejemplo de DaemonSet, que está disponible para el código que usa la biblioteca. La interfaz de devolución de llamada para Deployment, StatefulSet y DaemonSet es la misma *: esta es
ControllerFeed :
type ControllerFeed interface { Added(ready bool) error Ready() error Failed(reason string) error EventMsg(msg string) error AddedReplicaSet(ReplicaSet) error AddedPod(ReplicaSetPod) error PodLogChunk(*ReplicaSetPodLogChunk) error PodError(ReplicaSetPodError) error }
* La excepción es
AddedReplicaSet , que tiene sentido solo para la Implementación (no puede definir este método para rastrear DaemonsSet).
Explicaciones para otros métodos de interfaz:
Added corresponde al watch.Added Evento watch.Added del observador para el recurso seleccionado;Ready se llama cuando el recurso ha entrado en el estado Ready (por ejemplo, para DaemonSet este es el momento en que el número de Pods actualizados y disponibles coincide con el número "deseado" de Pods);Failed : este método se llama cuando se elimina un recurso o en el caso de que se reciba un Evento con la descripción de causa y error (por ejemplo, FailedCreate );EventMsg se llama para cada Evento recibido del recurso o sus Pods: estos son eventos sobre la creación del recurso, sobre la carga de imágenes, etc. Incluyendo mensajes de error;AddedPod : un método mediante el cual puede captar los momentos de creación de nuevos Pods;- Se llama a
PodLogChunk cuando otro trozo de registros proviene de la API de Kubernetes; PodError se PodError si Pod falla.
Cada devolución de llamada puede devolver un
StopTrack tipo
StopTrack y se completará el seguimiento. Entonces, por ejemplo, hecho en el rastreador de despliegue:
Ready StopTrack y CLI termina su trabajo.
Para facilitar la definición de devoluciones de llamada, existe una estructura
ControllerFeedProto , al crear un objeto del cual puede determinar el método de devolución de llamada deseado.
Así es como, por ejemplo, la
salida sin fin de los registros de DaemonSet se ve sin información adicional sobre eventos y estado:
La última llamada es de
bloqueo : inicia un ciclo sin fin de recibir eventos de Kubernetes y llama a las devoluciones de llamada correspondientes. Puede interrumpir programáticamente este ciclo devolviendo
StopTrack desde la devolución de llamada.
Ejemplos de aplicación
El uso de kubedog como biblioteca
se puede ver en la utilidad dapp. Aquí es donde se ejecutan los Trackers de implementación listos para verificar los recursos que Helm crea o actualiza.
Kubedog CLI puede
ayudar con el despliegue en el sistema CI / CD , y sin importar si se usa: kubectl, Helm u otra cosa. Después de todo, puede ejecutar
kubectl apply y luego la
kubedog rollout track , y verá un error en los registros de
kubedog rollout track si algo está mal con el recurso. Este uso de kubedog ayudará a reducir el tiempo para diagnosticar problemas de implementación.
Que sigue
Planeamos desarrollar la biblioteca en la dirección de apoyar más recursos; por ejemplo, realmente quiero seguir Servicio e Ingreso. Además, se supone que debe llevar a cabo un trabajo sobre la clasificación de la
reason en Event'ah, para determinar con mayor precisión el momento en que podemos suponer que el despliegue del recurso falló. Otro vector de desarrollo de la biblioteca es el seguimiento de varios recursos a la vez, por ejemplo, por
labelSelector o por nombre de espacio de nombres. También quiero admitir varias anotaciones que pueden cambiar la naturaleza del seguimiento, por ejemplo, para los ganchos Helm, pero esto es aún más relevante para dapp.
En un futuro cercano, la atención se centrará en la biblioteca, pero también se planean mejoras para la CLI: comandos y banderas más convenientes, coloración de registros, mensajes sobre cómo eliminar Pods, como en popa. También estamos considerando la posibilidad de crear un modo interactivo con una tabla de estado de implementación y eventos en una ventana y con registros en otra.
¿Cómo intentarlo?
Las compilaciones de CLI de kubedog para Linux y macOS están disponibles en
bintray .
Realmente espero sus comentarios y problemas en
GitHub !
PS
Lea también en nuestro blog: