Cómo funciona el kernel Linux: la guía que quería leer hace 10 años

El kernel Linux es el programa que controla tu hardware, multiplexa CPU/memoria, expone una interfaz estable a las apps y decide quién corre y cuándo. Esta guía te lo explica desde cero, sin jerga innecesaria, con ejemplos prácticos para que diagnostiques tu propio sistema.

Qué es (y qué no es) el kernel

El kernel es el programa que se ejecuta con todos los privilegios de la CPU (modo kernel o ring 0). Cuando enciendes tu computadora:

1. BIOS/UEFI carga un bootloader (GRUB, systemd-boot).

2. El bootloader descomprime el kernel desde /boot/vmlinuz-... y lo carga en memoria.

3. El kernel inicializa drivers, detecta hardware, monta el root filesystem y lanza el primer proceso (init o systemd con PID 1).

Lo que NO es el kernel: tu shell, tu escritorio, tus apps, ni siquiera glibc. Esas son cosas del userspace. El kernel provee la interfaz (syscalls) para que el userspace pida cosas: abrir un archivo, crear un socket, mapear memoria, mandar una señal.

Arquitectura general

Mental model útil:

• Capa de hardware: CPU, RAM, disco, red, USB, GPU. El kernel habla con cada uno vía drivers específicos.
• Subsistemas del kernel: scheduler (decide qué proceso corre), memory manager (asigna RAM virtual), VFS (interfaz común de archivos), network stack (TCP/IP), device drivers.
• Interfaz con userspace: syscalls (~400 en Linux 6.x). Todo lo que una app puede pedirle al kernel pasa por una syscall.

Una app no toca el hardware directamente. Llama a read(), write(), socket(), clone(). El kernel valida los argumentos, traduce a operaciones del driver correspondiente, y devuelve el resultado.

Syscalls: la API real del sistema

Para ver qué syscalls hace un programa:

Observar estas syscalls muestra la frontera real entre un proceso y el kernel, tanto al adjuntarte a un PID existente como al lanzar un programa nuevo. El filtro acota la captura para que puedas relacionar cada operación de archivos con el comportamiento de la aplicación.

Antes de tocar nada, dejá claro qué quieres ver: -e trace=open,openat filtra solo las syscalls de apertura de archivos (útil para depurar permisos, rutas o problemas de configuración), mientras que strace ls /tmp sin filtro te muestra TODA la conversación entre el binario y el kernel (open, read, write, stat, brk, mmap, exit_group, etc.). Empezar con un PID activo y un filtro chico evita que la salida explote y te permite correlacionar cada línea con un evento concreto.

strace -e trace=open,openat -p   # syscalls específicas
strace ls /tmp  # todas las syscalls de ls

Troubleshooting: Adjuntarte a otro usuario puede fallar por ptrace_scope o permisos; además, un PID puede terminar antes de que te conectes. verifica que la salida muestre entradas y códigos de retorno; una captura vacía suele significar que el filtro no coincide o que el proceso está inactivo.

Syscalls comunes que verás:

• open/openat — abrir un archivo.
• read/write — leer/escribir.
• mmap — mapear memoria (compartir entre procesos, cargar libs).
• clone — crear proceso o thread.
• socket/connect/accept — red.
• ioctl — operación específica del device.
• prctl — opciones del proceso.
• futex — sincronización entre threads.

Cada syscall tiene un número. x86_64 empieza en 0 (read=0, write=1). La lista cambia entre arquitecturas; el kernel expone la tabla en /usr/include/asm/unistd_64.h.

Procesos: la abstracción fundamental

Un proceso es un programa en ejecución con su memoria, sus archivos abiertos, su estado. Lo identifica un PID. Lo crea fork() o clone() (que internamente también usan threads).

Para ver los procesos:

Estas tres vistas responden preguntas distintas: ps da una instantánea, top actualiza el consumo y htop agrega navegación y relaciones entre procesos. Compararlas evita sacar conclusiones de un único instante de CPU o memoria.

El orden importa y vale la pena entenderlo: ps aux lee /proc una sola vez y devuelve una foto estática ordenada por PID (útil para scripts y para no perder tiempo interactuando); top es la versión dinámica que recalcula CPU/RAM cada 2-3 segundos y viene en cualquier Linux; htop es la versión amigable con colores, scrolling vertical y mouse, pero no siempre está instalado. Si vas a monitorear algo en tiempo real, arrancá con top y, si lo tienes, pasate a htop; si vas a parsear o guardar, usa ps.

ps aux
top
htop

Troubleshooting: Si htop no está instalado, no confundas su ausencia con un problema del scheduler; instalalo o usa la vista dinámica disponible. Un proceso que aparece y desaparece puede ser un worker corto, así que repetí la observación y revisa su PID antes de investigarlo.

Cada proceso en /proc// tiene:

• status — estado, memoria, señales pendientes.
• cmdline — comando con que arrancó.
• fd/ — file descriptors abiertos (sockets, archivos, pipes).
• maps — mapeo de memoria (qué direcciones, con qué permisos).
• io — bytes leídos/escritos.

El kernel mantiene un task_struct por proceso. El scheduler elige uno y le da CPU. Cuando se acaba su time slice (típicamente 1-10 ms), se interrumpe y se elige otro.

Scheduler: cómo decide quién corre

Linux usa el scheduler EEVDF (Earliest Eligible Virtual Deadline First) desde 6.6 (reemplazó a CFS como default de SCHED_NORMAL). Cada tarea tiene un virtual deadline calculado a partir de su peso (nice) y su vruntime; EEVDF elige la tarea con el menor deadline elegible. A diferencia de CFS clásico, EEVDF no usa heurísticas explícitas de “sleep average / interactivo”: favorece tareas latency-sensitive (audio, gaming) ajustando /proc/sys/kernel/sched_latency_ns y sched_min_granularity_ns.

Para ver el scheduler en acción:

Leer la estructura de scheduling de un PID muestra cuántas veces fue conmutado y cuánto tiempo de CPU acumuló; la consulta de chrt agrega política y prioridad. Juntas permiten distinguir una demora por prioridad de una espera por I/O o bloqueo.

/proc//sched te muestra los counters internos que el scheduler mantiene por proceso: nr_switches (cuántas veces lo pusieron en CPU), sum_exec_runtime (cuánto tiempo total corrió), nvcsw/nivcsw (cambios voluntarios vs involuntarios de contexto). Un proceso con muchos nivcsw está siendo preempted por el scheduler — señal típica de que compite por CPU con algo más pesado. chrt -p complementa leyendo la política activa (SCHED_OTHER, SCHED_FIFO, SCHED_RR, SCHED_BATCH, SCHED_IDLE) y la prioridad tiempo real. Sin esa política activa no se aplica prioridad real, aunque uses nice.

cat /proc//sched
# nr_switches, sum_exec_runtime, etc.
chrt -p   # política y prioridad tiempo real

Troubleshooting: El acceso a /proc//sched puede estar restringido y un PID terminado devuelve error; elegí un proceso activo y respetá sus permisos. No cambies políticas de tiempo real a ciegas: una prioridad mal asignada puede impedir que servicios críticos reciban CPU; verifica los valores antes de tocar nada.

Si quieres forzar afinidad CPU (que un proceso corra solo en ciertos cores):

Fijar la afinidad limita el proceso a un conjunto concreto de cores y sirve para aislar una carga, reducir interferencia o reproducir un problema de rendimiento. Es una intervención sobre un PID que ya está corriendo, no una configuración global del scheduler.

El formato 0-3 significa “cores 0, 1, 2 y 3” como máscara; alternativas útiles son 0 (solo el primer core), 0,2 (cores 0 y 2 saltando el 1), o 0-1,4-5 (rango con gap). Conviene correr el comando antes de tocar nada si quieres medir baseline: taskset -cp 0-3 aplica el cambio sobre el proceso vivo, así que su efecto es inmediato pero se pierde si el proceso se reinicia — para hacerlo persistente hay que lanzarlo desde el inicio con taskset -c 0-3 ./miapp.

taskset -cp 0-3   # solo cores 0,1,2,3

Troubleshooting: Si el rango de CPU no existe, el comando lo rechaza; en contenedores además solo puedes usar los CPUs permitidos por el cgroup. Confirmá que la lista de afinidad cambió y que el proceso sigue vivo, porque un worker que se reinicia puede perder el ajuste.

Memoria: virtual, física, y el truco de la traducción

Cada proceso ve un espacio de direcciones virtual propio (típicamente 0 a 128 TB en x86_64). El kernel traduce cada dirección virtual a una física vía la MMU del CPU. Cuando se agota la RAM física, entra swap (disco) o el OOM killer mata un proceso.

Para ver la memoria:

Estas consultas separan RAM disponible, caché, swap y contadores detallados del administrador de memoria. Mirarlas antes de culpar al OOM killer evita confundir memoria reutilizable con una fuga real.

free -h lee /proc/meminfo y lo resume en una tabla humana (totales, usado, libre, disponible, swap), ideal para una vista rápida en terminal. cat /proc/meminfo te da el detalle completo campo por campo: MemTotal, MemFree, MemAvailable, Buffers, Cached, SwapTotal, SwapFree, Dirty, Writeback, CommitLimit, etc. La diferencia clave es MemAvailable vs MemFree: la primera estima cuánta RAM pueden usar las apps sin swap (considera caché recuperable), y suele ser el número correcto para decidir si “hay memoria”.

free -h
cat /proc/meminfo

Troubleshooting: free puede mostrar poca memoria libre aunque haya mucha disponible en caché; prestá atención a available y a la actividad de swap. verifica unidades y tomá dos muestras separadas: un valor aislado de /proc/meminfo no explica una tendencia.

Para ver qué usa cada proceso:

Ordenar procesos por porcentaje de memoria y consultar su estado permite comparar el consumo visible con VmRSS, VmSize y el máximo histórico. El objetivo es encontrar candidatos y distinguir memoria residente de mapeos virtuales que todavía no ocupan RAM.

ps aux --sort=-%mem te da el ranking descendente: el header muestra %CPU, %MEM, VSZ (virtual), RSS (residente real), STAT y START; con head limitás a los top N. Para el sospechoso, cat /proc//status tiene el bloque Vm* con VmRSS (RAM física usada ahora mismo), VmSize (total de espacio virtual reservado), VmPeak (máximo histórico desde que arrancó) y VmSwap (cuánto está paginado a disco). Comparar VmSize >> VmRSS es normal — significa que mapeó mucho pero no lo tocó.

ps aux --sort=-%mem | head
cat /proc//status | grep -i vm  # VmRSS, VmSize, VmPeak

Troubleshooting: La lista puede cambiar mientras la lees y algunos campos no están disponibles para procesos ajenos; si aparece No such process, el PID terminó. Confirmá el candidato en varias muestras y revisa VmRSS junto con swap antes de concluir que es el responsable.

VmRSS es la RAM real que ocupa. VmSize es el total virtual (incluye mapped pero no necesariamente usado). VmPeak es el máximo histórico.

Módulos: drivers que se cargan a demanda

El kernel base tiene lo mínimo. El resto (drivers de Wi-Fi, GPU, sistema de archivos exótico) son módulos que se cargan con modprobe:

Este bloque inventaría módulos cargados, muestra metadatos y permite cargar o retirar un driver bajo demanda. Es útil para verificar dependencias de hardware sin recompilar el kernel, pero descargar un módulo en uso puede dejar el dispositivo inutilizable.

El flujo de trabajo correcto es leer antes de modificar: lsmod lista todos los módulos cargados con su tamaño y la columna Used by que muestra qué módulos dependen de él. modinfo te dice versión, alias, parmeters y qué firmware necesita el módulo antes de tocarlo. Recién después de saber qué es y quién lo usa, modprobe lo carga (resolviendo dependencias), y modprobe -r lo descarga — pero solo si su Used by count está en cero. Forzar la descarga de un driver activo (rmmod -f) puede dejar el dispositivo en estado inconsistente y suele requerir un reinicio.

lsmod                          # módulos cargados
modinfo                # info de un módulo
sudo modprobe          # cargar
sudo modprobe -r       # descargar

Troubleshooting: modprobe puede fallar por dependencias, firma no válida o porque el módulo fue compilado para otra versión (uname -r); no fuerces la descarga de un driver activo. verifica el estado en lsmod y revisa dmesg si el dispositivo desaparece o cambia de comportamiento.

Los módulos viven en /lib/modules/$(uname -r)/kernel/.... Cada kernel tiene sus módulos. Si actualizas el kernel, hay que reinstalar los DKMS (drivers externos como NVIDIA, VirtualBox).

Para ver qué módulos están en uso por un device:

Consultar PCI y USB relaciona cada dispositivo físico con el driver que el kernel eligió, algo clave cuando una interfaz o periférico no responde. La salida de lspci -k y el árbol de lsusb también revela si el problema está antes de userspace.

lspci -k enumera los dispositivos PCI (GPU, NIC, storage controller, USB host) y, clave, debajo de cada uno muestra Kernel driver in use: y Kernel modules: — eso te dice exactamente qué módulo cargó el kernel para ese hardware y cuál es la alternativa. lsusb -t dibuja el árbol USB como jerarquía: hub raíz → hubs → dispositivos, con el driver entre corchetes. La vista -t (tree) es la que sirve para entender topología; lsusb plano solo te da vendor:product IDs. Si un dispositivo no aparece acá, no existe desde el punto de vista del kernel.

lspci -k       # qué driver usa cada dispositivo PCI
lsusb -t       # árbol USB

Troubleshooting: En una VM el hardware puede estar oculto o presentado por passthrough, y las herramientas pueden no venir instaladas; no interpretes una lista incompleta como ausencia física. verifica que figure Kernel driver in use para PCI y el driver esperado en el árbol USB.

Dispositivos: cómo el kernel habla con hardware

Los drivers exponen dispositivos como archivos en /dev. La convención:

• /dev/sda — disco SATA/NVMe.
• /dev/nvme0n1 — disco NVMe.
• /dev/ttyUSB0 — puerto serial USB.
• /dev/null, /dev/zero, /dev/random — dispositivos virtuales.

Para interactuar con hardware específico:

Estas herramientas hacen un inventario del almacenamiento, muestran qué procesos mantienen abierta una partición y consultan las capacidades del disco. El orden ayuda a pasar de la topología a la causa de un bloqueo sin modificar datos.

lsblk lee /sys/block y dibuja el árbol de discos y particiones con sus puntos de montaje — es no-destructivo y seguro para correr en cualquier momento. lsof /dev/sda1 lista los procesos que tienen file descriptors abiertos sobre esa partición específica: si te aparece una fila con DEL o FD en modo write, ese proceso está bloqueando un unmount o sostiene espacio borrado que no se libera. hdparm -I /dev/sda interroga al disco por sus capacidades: tamaño, sectores, caché, comandos soportados (NCQ, TRIM, etc.) y modo de transferencia. Ojo: hdparm tiene flags destructivos (--security-erase, -TT) que NO se usan acá — solo -I (mayúscula, info) es lectura.

lsblk                    # discos y particiones
lsof /dev/sda1           # qué procesos usan una partición
hdparm -I /dev/sda       # info del disco

Troubleshooting: Si lsof no muestra todo, ejecutalo con permisos suficientes y tené en cuenta que un dispositivo desmontado no tendrá procesos asociados; hdparm -I también depende del soporte del controlador. verifica el nombre real del dispositivo en lsblk antes de consultar una ruta, porque equivocarte de disco en otra operación sí puede ser destructivo.

Cuando algo no anda, lo primero es mirar dmesg:

Leer el buffer del kernel y seguirlo en vivo permite correlacionar desconexiones USB, fallos de drivers, OOM y errores de firmware con el momento exacto del problema. journalctl agrega la vista persistente de systemd cuando el buffer circular ya descartó eventos viejos.

dmesg | tail -50 lee el ring buffer del kernel (típicamente ~512 KB, circular: cuando se llena, los mensajes viejos se descartan). Filtrá las últimas 50 líneas porque los problemas dejan rastro cerca del momento del fallo. dmesg -w se queda esperando nuevos eventos en vivo, como tail -f pero del buffer del kernel — útil mientras reproducís el bug (enchufás un USB, ejecutas un comando, etc.). journalctl -k -f es la variante con journald: lee del log persistente de systemd (sobrevive reboots), -k filtra solo kernel y -f hace follow. Si el sistema viene reiniciándose, -k es mejor que dmesg porque el buffer se pierde en cada boot.

dmesg | tail -50
dmesg -w  # live, espera nuevos eventos
journalctl -k -f  # lo mismo con journald

Troubleshooting: Si dmesg devuelve Permission denied, revisa kernel.dmesg_restrict o usa una cuenta con permisos; el modo en vivo puede inundar la terminal durante una tormenta de eventos. verifica timestamps, niveles err/warn y el contexto del dispositivo antes de atribuir cada mensaje a la causa raíz.

Errores de driver, USB desconectado, OOM, panic: todo aparece aquí.

Sistema de archivos: VFS y abajo

El Virtual File System (VFS) es la capa que unifica ext4, btrfs, xfs, zfs, NTFS, NFS, etc. Una app abre /home/user/file.txt sin saber qué filesystem hay debajo. El VFS traduce a operaciones del driver específico.

Para ver qué filesystem tiene cada partición:

Comparar tipo, espacio y puntos de montaje te muestra qué filesystem respalda cada ruta y cómo lo ve el sistema ahora. Usar las tres vistas juntas detecta montajes inesperados, discos en solo lectura y diferencias entre el dispositivo y el punto servido a la aplicación.

df -hT te da tamaño, usado, disponible y porcentaje, con la columna -T que agrega el tipo de filesystem (ext4, btrfs, xfs, tmpfs, overlay, vfat). Es lectura rápida de /proc/mounts o statvfs. mount | grep "^/dev" filtra solo los montajes que vienen de dispositivos de bloque reales (excluye tmpfs, cgroup, proc, sysfs). findmnt lee /proc/self/mountinfo y es la vista más limpia para debugging: jerárquica, con TARGET, SOURCE, FSTYPE, OPTIONS. Si necesitas ver opciones (rw/ro, noexec, nosuid), findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS es la combinación más útil.

df -hT
mount | grep "^/dev"
findmnt

Troubleshooting: En contenedores o sistemas con overlay, df puede mostrar un filesystem distinto del que esperas y mount puede omitir detalles que findmnt sí conserva. verifica la ruta problemática y confirmá si está montada en modo rw; un ro inesperado explica muchos errores de escritura.

Si un disco se está llenando:

Medir el tamaño de cada directorio de primer nivel ordena rápidamente la investigación cuando el disco se llena. Ocultar errores de permisos deja la salida legible, pero significa que el total puede ser incompleto.

sudo du -sh / 2>/dev/null recorre solo el primer nivel (/bin, /etc, /home, /var, /usr, /opt, /tmp, etc.), resume con -sh (tamaño total legible) y manda errores a /dev/null. El 2>/dev/null es clave: sin él, vas a ver muchos Permission denied por sockets, pipes y archivos protegidos. sort -h ordena por tamaño humano (entiende K, M, G) y tail te muestra los más grandes. Si quieres ver el detalle, cambiá por /var/ o /home/ y profundizá un nivel — pero ojo, -sh recursivo sobre / puede tardar minutos y escanear pseudo-filesystems.

sudo du -sh /* 2>/dev/null | sort -h | tail

Troubleshooting: Si el resultado no explica el consumo, revisa directorios sin permiso, snapshots, archivos borrados pero todavía abiertos y otros mounts; du no siempre coincide con df. Confirmá el candidato dentro del mismo filesystem antes de borrar, especialmente en /var, /home y directorios de contenedores.

Red: stack TCP/IP dentro del kernel

La pila de red es enorme: drivers de NIC, bridging, routing, Netfilter (iptables/nftables), TCP, UDP, sockets, etc. Para diagnosticar:

Este diagnóstico recorre las capas principales de red: direcciones, routing, sockets, captura de paquetes y firewall. El conjunto te permite ubicar si la falla está en la interfaz, la ruta, el proceso que escucha o una regla que descarta tráfico.

El orden importa porque refleja el camino que sigue un paquete: primero ip addr para confirmar que la interfaz tiene IP asignada y está UP (no state DOWN); después ip route para verificar que hay default gateway y que la ruta al destino pasa por la interfaz correcta; después ss -tulnp para confirmar que el proceso escucha en la IP:puerto que esperas (TCP -t, UDP -u, listening -l, no resuelve nombres -n, muestra PID -p); después tcpdump para capturar tráfico real si la falla persiste; y al final nft list ruleset para descartar drops de firewall. Saltarse el orden y arrancar por tcpdump suele terminar en “no veo nada” porque el problema estaba en una capa anterior.

ip addr           # interfaces y sus IPs
ip route          # tabla de routing
ss -tulnp         # sockets abiertos
tcpdump -i eth0   # capturar tráfico
nft list ruleset  # firewall

Troubleshooting: El nombre de interfaz puede no ser eth0, la captura puede requerir permisos y ss puede ocultar procesos sin privilegios; adaptá el filtro al sistema real. verifica primero que exista una ruta válida y un listener, y recién después buscá drops en Netfilter o en el tráfico capturado.

Si una app no conecta, este cuarteto resuelve el 80% de los casos.

Diagnóstico práctico: el “está roto, ¿ahora qué?”

Caso típico: el sistema va lento.

1. CPU: top, htop. ¿Algún proceso al 100%? pidstat -p 1.

2. RAM: free -h. ¿Swap lleno? El sistema está paginando.

3. I/O disco: iostat -xz 1 o iotop. ¿Disco al 100%? iotop muestra qué proceso.

4. Red: iftop o nethogs. ¿Interfaz saturada?

5. Logs: journalctl -p err -b (errores desde el último boot).

6. Kernel: dmesg | tail.

Si el sistema no responde al teclado, el kernel puede tener un hung_task. Mira:

Consultar el timeout de tareas bloqueadas te dice si el kernel está configurado para advertir cuando una tarea permanece demasiado tiempo sin avanzar. Es un dato de diagnóstico, no una cura: sirve para interpretar el mensaje posterior y su umbral.

/proc/sys/kernel/hung_task_timeout_secs es el sysctl expuesto como archivo, lectura instantánea desde userspace. sysctl kernel.hung_task_timeout_secs consulta el mismo valor a través del comando sysctl, útil desde scripts y devuelve el valor efectivo (no el default si fue override). El default suele ser 120 segundos: si una tarea en estado D (uninterruptible sleep, típicamente esperando I/O) supera ese umbral, el kernel loguea un warning en dmesg con el backtrace de la tarea. Ajustar este valor cambia la sensibilidad del detector, no la causa del bloqueo.

cat /proc/sys/kernel/hung_task_timeout_secs
sysctl kernel.hung_task_timeout_secs

Troubleshooting: Un valor 0 desactiva el aviso y un valor muy bajo puede generar falsos positivos durante I/O pesado; no lo cambies sin entender el workload. verifica el valor efectivo y correlacioná cualquier alerta de tarea bloqueada con dmesg, storage y estado del proceso.

Y dmesg para “blocked for more than N seconds”.

Cómo contribuir al kernel (si te pica el bicho)

El kernel acepta parches vía mailing list (lore.kernel.org) o git send-email. El proceso:

1. Encuentra un subsistema que te interese en MAINTAINERS (en la raíz del source).

2. Lee el Documentation/process/ del kernel.

3. Haz un parche pequeño, sign-off con git commit -s.

4. Envíalo al maintainer del subsistema y a la lista de Linux Kernel.

No es trivial empezar, pero los maintainers son accesibles y la barrera de entrada es más baja de lo que parece.

Conclusión

El kernel Linux no es magia. Es un programa enorme (40+ millones de líneas) con arquitectura clara: drivers abajo, subsistemas en el medio, syscalls arriba. Con strace, /proc, dmesg y journalctl puedes diagnosticar casi cualquier problema sin recompilar nada.

FAQ

¿Cómo sé qué versión de kernel tengo?

uname -r. Para más detalle: uname -a y cat /proc/version.

¿El kernel se actualiza solo?

En Ubuntu y Fedora sí, vía paquetes. En otras distros necesitas hacerlo manual o con linux-image packages.

¿Puedo cambiar parámetros del kernel sin reiniciar?

Sí, con sysctl. sysctl -w net.core.somaxconn=1024 cambia el valor hasta el próximo boot. Para hacerlo permanente: /etc/sysctl.d/.

¿Por qué mi distro tiene kernels “tweak”?

Distribuciones como XanMod, Liquorix o Zen compilan el kernel con flags diferentes (BORE scheduler, Btrfs optimizado, etc.). Pueden mejorar rendimiento en algunos casos pero rompen soporte oficial.

Preguntas frecuentes

Lee también

• Guía Fedora 44: Novedades, Instalación y Upgrade para Sysadmins Linux
• Configura VLANs en Linux con nmcli: Guía paso a paso para sysadmins
• Protege tu SSH: Guía esencial para configurar Fail2ban en Linux
• Guía Definitiva: Configura Kubernetes con kubeadm en Ubuntu para Sysadmins Linux
• Configura Prometheus y Grafana: Guía DevOps para SysAdmins Linux