El incidente en Netflix fue provocado por una contención severa de locks a nivel de kernel, específicamente el mount_lock del VFS de Linux, durante el escalado rápido de contenedores. La causa raíz técnica fue la adopción de un nuevo runtime de contenedores (kubelet + containerd) que, para mejorar la seguridad al asignar rangos de usuario únicos a cada contenedor, utilizaba la función idmap del kernel. Esta función, para cada capa de una imagen de contenedor, requería múltiples syscalls de mount (open_tree, mount_setattr, move_mount), lo que resultaba en un número masivo de operaciones de mount/umount (20200 para 100 contenedores con 50 capas cada uno).
La contención se amplificó significativamente en ciertas arquitecturas de CPU, particularmente las instancias r5.metal de AWS (Intel de 5ª generación, dual-socket, múltiples dominios NUMA). El análisis reveló que los efectos NUMA (mayor latencia para accesos remotos), Hyperthreading (hilos compitiendo por recursos de ejecución compartidos) y las arquitecturas de caché centralizadas (donde las operaciones atómicas para un lock global se canalizan a través de una única cola como el 'Table of Requests' o TOR) exacerbaban la contención del lock. Esto causaba que los CPUs pasaran la mayor parte del tiempo en un spin loop (pause instruction) esperando el lock, resultando en stalls de pipeline y latencias elevadas.
Las salvaguardas existentes, como los health checks, fallaron al detectar la causa raíz de manera proactiva, solo indicando el síntoma de los nodos "stalling". La naturaleza del problema, profundamente arraigada en la interacción entre el software del runtime, el kernel de Linux y la microarquitectura de la CPU, hizo que la detección y el diagnóstico fueran complejos. La migración a un nuevo runtime, aunque beneficiosa para la seguridad, introdujo un patrón de acceso al kernel que no escalaba bien con la arquitectura de hardware predominante para cargas de trabajo de alta densidad de contenedores y muchas capas.