Hace tiempo yo cambié al otro proyecto, que está funcionando en Kubernetes compleramente en Azure AKS. Honestamente, yo traté a usar el Azure Monitor para monitorear la infraestructura y aplicación, pero no tuve éxito.

Pués, yo decidí volver a mi amado Zabbix, ejecutarlo en Kubernetes, enviar email y notificaciones a Microsoft Teams y mostrar gráficos y paneles en Grafana.

Naturalmente, la pregunta apareció, ¿cómo instalarlo en Kubernetes, cómo configurarlo, cómo subir mi scriptos customizados?

Cuando crees un clúster de Azure Kubernetes Service (AKS), puedes especificar el recurso de Log Analytics para el registro y la supervisión de los recursos de Kubernetes: pods, servicios, mapas de configuración, etc. Esta cosa en realidad está instalando el agente de Log Analytics dentre de tu clúster (habrá varios pods y recursos relacionados como configmaps), qual luego van a enviar las salidas de stdout y stderr desde los pods a Log Analytics.

Desafortunadamente, el esquema de estos registros dentro Log Analytics es bastante complejo, principalmente por el registro se proviene del contenedor, pero no del pod. Así que  hay tablas diferentes en Log Analytics, quales nosotros tenemos que conectar para obtener datos de registro legibles por humanos.

Yo uso el 'boky/postfix' docker imagen para enviar Email en mi clúster Kubernetes. Recientemente nuestra sistema de escaneo de seguridad empezó a alertarme sobre el vulnerabilidad en el paquete 'py3-setuptools' (Alpine Linux), como puedo mitigar actualizando ese paquete a la última versión.

Como siempre, voy a mi Dockerfile personalizado y actualizo la cadena para la actualización explícita del paquete...

Cuando estáis trabajando con las muchas applicaciones en contenedores, especialmente si no las estáis creando mismo, no siempre está claro qué tipo de sistema operativo base vosotros estáis utilizando.

Hay los dos comandos a continuación para verificar rapidamente la versión de Alpine Linux (van a trabajar en la mayoría de los distributivos, en realidad) desde la consola:

Si tu clúster de Kubernetes Azure AKS es lo suficientemente antiguo, especialmente en entornos de desarrollo, definitivamente se quedará sin espacio en disco, porque AKS almacenará todas las imágenes de contenedor (y en entornos DEV cambian con bastante frecuencia) en el disco.

No pude encontrar la frecuencia con la que el motor AKS ejecuta alguna operación de limpieza (pero lo hace, absolutamente). Sin embargo, en mi caso, el uso del espacio llegó a ese ya críticos 80% y siguió creciendo. Así es como se puede ejecutar la limpieza manualmente.