Con un sistema tan grande y complicado como Kubernetes, la supervisión a menudo puede volverse problemática.El monitoreo siempre es un negocio complicado porque, por un lado, no quiere perderse errores y fallas críticas, y por otro lado, no desea ahogarse en un océano de errores triviales que se desencadenan no debido a su aplicación ni a de todos modos.

Con su propia pila de programadores y controladores, Kubernetes puede recuperarse de fallas menores, fallas de nodos o fallas de aplicaciones desde el interior de sus pods. Sin embargo, si ocurren muchos fallos, es posible que no tenga nada que ver con la infraestructura, sino con su aplicación, que Kubernetes puede intentar reiniciar una y otra vez, pero como el código tiene la falla, la falla persistirá e incluso puede pasar desapercibida.

El tipo de errores que pasan desapercibidos la mayoría de las veces son aquellos en los que las aplicaciones no se bloquean, pero terminan utilizando los recursos del sistema y dañando a los clústeres en general. Estos son los casos especialmente desagradables y Kubernetes Metrics Server puede ser una herramienta útil para vigilarlos.

El proyecto es oficialmente parte del proyecto de Kubernetes, pero no viene pre-habilitado en la mayoría de las distribuciones certificadas por Kubernetes. Tiene dos partes importantes que vale la pena discutir sobre la API de métricas y el servidor de métricas en sí. Pero primero aprovisionémoslo en nuestro clúster de Kubernetes (K8).

Una configuración experimental de Kubernetes

A partir de julio de 2018, Docker para Mac y Windows vienen con una implementación certificada de Kubernetes de K8. Haciéndolo tan fácil como instalar K8 en una distribución de Linux. Puede ir a la configuración de Docker y si la instancia de Docker está actualizada, encontrará una pestaña de Kubernetes en el menú. Simplemente habilite Kubernetes en lugar de Docker Swarm y tendrá un clúster de un solo nodo en funcionamiento listo para la experimentación.

A continuación, necesitamos un conjunto simple de aplicaciones en funcionamiento para nuestro caso de uso. Cree una carpeta llamada Implementaciones y dentro de ella creemos una nginx-deployment.yaml archivos que desplegarían pods Nginx sin estado.

apiVersion: apps / v1 # para versiones anteriores a la 1.9.0 usar aplicaciones / v1beta2
tipo: Despliegue
metadatos:
nombre: nginx-deployment
Especificaciones:
selector:
matchLabels:
aplicación: nginx
réplicas: 2 # indica a la implementación que ejecute 2 pods que coincidan con la plantilla
plantilla:
metadatos:
etiquetas:
aplicación: nginx
Especificaciones:
contenedores:
- nombre: nginx
imagen: nginx: 1.7.9
puertos:
- contenedorPuerto: 80

Guarde el archivo y en el mismo directorio donde está este archivo, ejecute el comando:

$ kubectl crear -f nginx-deployment.yaml

Es posible que tengamos que esperar unos minutos para permitir que Kubernetes descargue las imágenes del contenedor, aprovisione los contenedores y realice una pequeña contabilidad. Una vez hecho esto, puede ver la lista de pods como:

$ kubectl obtener vainas

Como puede ver, tenemos dos instancias del pod, ya que el .yaml file había prescrito.

Ahora que tenemos algo que monitorear, necesitamos habilitar Metrics Server. Primero, verifique la versión de Kubernetes que está ejecutando. Si la versión es 1.8 o superior, entonces ejecutaríamos una implementación diferente y si es 1.7 luego recurrimos al legado:

$ versión kubectl

Puede obtener la imagen oficial y comenzar clonando este repositorio de GitHub y luego, dentro de la raíz del repositorio, ejecute el kubectl create -f con el apropiado .yaml dependiendo de la versión de K8 que esté ejecutando.

$ git clon https: // github.com / kubernetes-incubator / metrics-server.git
 
$ cd metrics-server
# Si está ejecutando Kubernetes versión 1.8 o más
$ kubectl crear -f implementar / 1.8 + /
# Si la versión es 1.7, luego
$ kubectl crear -f implementar / 1.7 /

Dale a los kubernetes un tiempo para descargar las imágenes y poner en marcha el servidor de métricas. Puede que tarde unos minutos. Una vez hecho esto, estará listo para ejecutar el servidor de métricas. El comando básico está inspirado en el cima comando que a menudo se ejecuta para monitorear un sistema Linux. Pero tiene dos variantes, una para comprobar el utilizaciones de recursos en la computación nodos y segundo para medir el recurso consumido por los desplegados vainas y el. A continuación, le mostramos cómo ver esos dos detalles:

$ kubectl nodo superior
$ kubectl vaina superior

Puede ver cuánto exige un pod a su sistema en términos de memoria o tiempo de CPU y, al usar la API de métricas, también puede configurar alertas de acuerdo.

Adónde irá desde aquí?

Los casos de uso emergentes del servidor de métricas serán cruciales en el futuro de Kubernetes. Este proyecto todavía está en la versión 0.2.x, una vez que madure y se integre en la arquitectura principal de Kubernetes, recopilará datos importantes para el programador, lo que lo ayudará a asignar de manera eficiente los pods a los nodos de una manera mucho más eficiente.

De manera similar, Horizontal Pod Autoscaler se beneficiará enormemente del proyecto y lo ayudará a escalar hacia arriba o hacia abajo para que las aplicaciones utilicen los recursos de manera óptima.

Referencias

1. Implementaciones de Nginx
2. Servidor de métricas de Kubernetes
3. Los documentos de diseño para la API de métricas se pueden encontrar aquí y similares. Puede encontrar información sobre el servidor de métricas aquí.