Consejos profesionales para depurar MinIO: superar problemas comunes en Kubernetes y entornos bare metal

Las implementaciones de MinIO vienen en todas las formas y tamaños. Admitimos instalaciones completas en cualquier versión de Linux , instalaciones en contenedores en cualquier versión de Kubernetes (incluido Red Hat OpenShift) e instalaciones prácticamente en cualquier lugar donde pueda implementar un único binario pequeño y liviano. Pero la flexibilidad conlleva la inevitabilidad de que los problemas de los casos extremos requieran depuración.

En esta publicación de blog, le mostraremos cómo depurar una instalación de MinIO que se ejecuta en Kubernetes y también algunos de los problemas comunes que puede encontrar al realizar una instalación completa y cómo rectificarlos.

Módulo depurador de Kubernetes

Hay algunas formas de acceder a la API MinIO que se ejecuta dentro de un clúster de Kubernetes. Podemos usar kubectl port-forwarding o configurar un Service de escucha en NodePort para poder acceder a la API. Ambos métodos ofrecen una forma de acceder al servicio desde fuera de la red, pero tienen un inconveniente importante: solo puede acceder al servicio al que hace referencia NodePort o Port Forwarding en un puerto disponible (no es la configuración habitual para la aplicación). ). Por ejemplo, debe acceder a la API MinIO, que generalmente se encuentra en el puerto 9000 , a través de un puerto 3xxxx asignado aleatoriamente.

¿Qué pasaría si te dijera que hay una manera mejor y que no es novedosa? Al depurar aplicaciones, desea tener acceso completo al entorno de ejecución nativo para poder utilizar varias herramientas para solucionar problemas y depurar el clúster. Una forma de hacerlo es iniciar un módulo estilo "Busybox" e instalar todas las herramientas necesarias para depurar la aplicación.

Primero, inicie un Pod en el mismo espacio de nombres que su instalación de MinIO. Para hacer esto, cree un archivo yaml llamado debugger-pod.yaml con el siguiente yaml.

 apiVersion: v1 kind: Pod metadata: name: mc labels: app: mc spec: containers: - image: minio/mc:latest command: - "sleep" - "604800" imagePullPolicy: IfNotPresent name: mc restartPolicy: Always

La configuración del Pod anterior extrae la imagen de la utilidad MinIO mc . Para garantizar que el módulo no se inicie y luego salga, agregamos un comando sleep .

Una vez guardado el yaml, aplique la configuración al espacio de nombres de Kubernetes donde se ejecuta el clúster MinIO.

kubectl apply -f debugger-pod.yaml

Una vez que el pod esté en funcionamiento, acceda a él a través del shell.

 $ kubectl exec -i -t -n default mc -c mc -- sh -c "(bash || ash || sh)" [root@mc /]#

Luego con mc puedes acceder al cluster MinIO

 [root@mc /]# mc alias set myminio --insecure Added `myminio` successfully.

Ahora que tenemos un módulo de depuración en funcionamiento, puede realizar acciones en el clúster directamente dentro de la misma red. Por ejemplo, si la replicación se interrumpió debido a que un sitio se desconectó o una falla de hardware, puede resincronizar cualquier objeto pendiente para replicar usando el siguiente comando

 [root@mc /]# mc admin replicate resync start minio1 minio2 [root@mc /]# mc admin replicate resync status minio1 minio2 ✔ ✔ ✔ ResyncID: 2248d1d1-633f-4d61-b938-d8ea0b9b2d31 Status: Completed Objects: 2225 Versions: 2225 FailedObjects: 0 Throughput: 5.3 MiB/s IOPs: 124.23 objs/s Transferred: 94 MiB Elapsed: 17.909833202s CurrObjName: testbucket/web-app/tsconfig.json

Otra razón por la que ejecutaría el pod del depurador es que si hay algunos permisos del sistema de archivos o configuraciones de grupos no válidos en su pod, puede actualizarlos usando el pod del depurador.

 [root@mc /]# chgrp -R 1000780050 .minio.sys/

El método de depuración anterior también se puede utilizar en entornos sin sistema operativo. Por ejemplo, puede iniciar un nodo Busybox o Bastion con mc instalado y seguir las mismas instrucciones anteriores.

Depuración de metal desnudo

Las instalaciones de Linux desde cero son las más sencillas. De hecho, solo se necesitan algunos comandos para instalar MinIO y ejecutarlo con SystemD. Para más detalles, consulte Configurando MinIO con SystemD .

De vez en cuando, las instalaciones básicas salen mal. Éstos son algunos de los errores (no tan comunes) sobre los que nos preguntan en SUBRED o Flojo . Estos errores no son específicos del hardware ni del funcionamiento, pero puede ser útil conocerlos en cualquier tipo de entorno.

Permiso de archivo

Uno de los errores más comunes son los permisos de archivo del binario MinIO y el archivo de configuración. Si esto ocurre, cuando inicie MinIO usando SystemD verá

Assertion failed for MinIO. y aquí está el seguimiento de la pila completa

 # systemctl status minio.service ● minio.service - MinIO Loaded: loaded (/etc/systemd/system/minio.service; enabled; vendor preset: enabled) Active: inactive (dead) Assert: start assertion failed at Tue 2023-12-26 18:21:38 PST; 8s ago AssertFileIsExecutable=/usr/local/bin/minio was not met Docs: https://docs.min.io Dec 26 18:13:37 minio1 systemd[1]: minio.service: Starting requested but asserts failed. Dec 26 18:17:50 minio1 systemd[1]: Assertion failed for MinIO. Dec 26 18:21:38 minio1 systemd[1]: minio.service: Starting requested but asserts failed. Dec 26 18:21:38 minio1 systemd[1]: Assertion failed for MinIO.

Esto podría deberse a varias razones, revisemos la lista y verifiquemos cada una de ellas.

Binario MinIO : el binario, en este ejemplo ubicado en /usr/local/bin/minio debe tener permiso root:root para el usuario y el grupo, respectivamente.

 # ll /usr/local/bin/minio total 93804 -rwxr-xr-x 1 root root 96018432 Nov 15 16:35 minio*

Usuario y grupo del servicio MinIO : el servicio MinIO debe ejecutarse bajo un usuario y grupo de Linux únicos por motivos de seguridad, nunca ejecutarse como usuario root . De forma predeterminada utilizamos minio-user para los nombres de usuarios y grupos. En el archivo de configuración del servicio SystemD debería ver algo como esto

 User=minio-user Group=minio-user

Directorio de datos MinIO : el directorio donde se almacenarán los datos MinIO debe ser propiedad de minio-user:minio-user o cualquier usuario que decida ejecutar el servicio MinIO como se indicó anteriormente.

 # ls -l /mnt total 4 drwxrwxr-x 2 minio-user minio-user 4096 Dec 27 09:58 data

Configuración de SystemD y MinIO : ambos archivos de configuración deben tener permisos root:root para el usuario y el grupo, así

 # ls -l /etc/default/minio -rw-r--r-- 1 root root 1330 Dec 27 09:52 /etc/default/minio # ls -l /etc/systemd/system/minio.service -rw-r--r-- 1 root root 941 Dec 26 17:13 /etc/systemd/system/minio.service

Ejecutar como root : todo el proceso de instalación debe ejecutarse como root . También puede probar sudo si su usuario tiene permisos, pero la recomendación es ejecutarlo como root ya que la instalación necesita colocar archivos en varios lugares a los que solo el usuario root puede acceder. Su indicador de bash debería tener un # y no un $ así

# frente a $

Si nada de lo anterior funciona, el mejor enfoque es eliminar la aplicación, los directorios y las configuraciones e iniciar una nueva instalación como usuario root.

Conflicto portuario

Otro problema común relacionado con archivos eliminados que aún permanecen en el proceso, lo que provoca conflictos de puertos. Incluso cuando un servicio no se está ejecutando, es posible que no pueda iniciar un nuevo servicio en el puerto existente o que el servicio que se está ejecutando se comporte mal (por ejemplo, no le permitirá iniciar sesión).

 # lsof -n | grep (deleted) COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME nginx 13423 root 5u REG 253,3 42949672960 17 (deleted) minio 13423 minio 6u REG 253,3 0 18 (deleted) minio 13423 minio 7u REG 253,3 0 19 (deleted)

Es posible que vea errores como los siguientes en una instalación de MinIO

• Error de inicio de sesión net::ERR_FAILED
• Error interno de servidor 500
• 401 No autorizado

La captura de pantalla anterior muestra un error interno del servidor y un error no autorizado. Si bien miramos la superficie, no parece claro qué ha causado este error, podemos depurar con un poco de conocimiento de Linux qué buscar que podría causar esto, echemos un vistazo.

Hay varias formas de depurar este problema. Primero verifiquemos si se están ejecutando varios procesos MinIO en el mismo nodo.

 # ps aux | grep -i minio minio-u+ 5048 0.3 1.7 1594008 144384 ? Ssl 11:03 0:01 /usr/local/bin/minio server --console-address :9001 /mnt/data/disk1/minio minio-u+ 9276 0.3 1.7 1594208 144301 ? Ssl 11:25 0:01 /usr/local/bin/minio server --console-address :9001 /mnt/data/disk1/minio

Como podemos ver arriba, hay 2 procesos MinIO en ejecución. Comience eliminando el proceso más antiguo o que lleva más tiempo ejecutándose; en este caso parece ser el ID de proceso 5048 .

kill -9 5048

A veces, incluso después de finalizar el proceso, es posible que el servicio aún no se inicie o se cuelgue porque ha reservado un número de proceso pero no lo ha dejado ir. Esto puede deberse a archivos que se han eliminado pero que el sistema operativo todavía está rastreando. Puede encontrar los archivos eliminados a través de LSOF

lsof -n | grep '(deleted)'

Por último, pero no menos importante, si no quedan archivos eliminados ni procesos colgados y si todo parece absolutamente limpio, el último recurso es reiniciar rápidamente el nodo. Este es un método sensato que cierra y borra todos los archivos y procesos pendientes para que pueda iniciar una instalación nueva.

SUBRED al rescate

Aunque son raros, siempre existirán casos extremos de instalación. Los clientes de MinIO saben que no tienen nada de qué preocuparse porque pueden enviar mensajes rápidamente a nuestros ingenieros, que escribieron el código, a través del SUBRED portal. Hemos visto casi todo lo que hay bajo el sol, por lo que, si bien el problema puede parecer críptico o alucinante a primera vista, pondremos a trabajar nuestros años de experiencia en la depuración de instalaciones en muchos entornos variados y lo ayudaremos en un santiamén.