PerfectScale
Arquitectura de Kubernetes: las 7 capas que todo Engineer debe dominar
¿Te cuesta depurar Kubernetes? Conoce las 7 capas de su arquitectura —nodos, redes, almacenamiento y más— que necesitas para resolver problemas en cualquier clúster de forma efectiva.
Esta página también está disponible en English, Deutsch, Français, Italiano, 日本語 y Português.
Kubernetes es muy bueno ocultando la complejidad. Esa es una de las principales razones por las que a la gente le gusta usarlo. Interactúas con una API limpia, defines lo que quieres y todo funciona, sin más.
Hasta que deja de funcionar.
Cuando algo se rompe, toda esa complejidad oculta se vuelve muy real de un momento a otro. Y arreglar el problema implica ir quitando capas una por una para entender qué está pasando en realidad.
Pregúntales a distintos Engineers qué opinan de Kubernetes y escucharás opiniones encontradas. Algunos lo adoran y lo consideran esencial para las aplicaciones modernas. Otros piensan que es demasiado complicado. Y algunos lo tratan como una herramienta más: útil en las situaciones correctas, innecesaria en otras.
Todas esas posturas tienen algo de razón.
Pero una cosa está clara: si trabajas con infraestructura moderna, es muy probable que Kubernetes sea parte de tu stack. Y cuando las cosas salen mal, necesitas un modelo mental de cómo funciona por dentro.
Esta guía busca darte exactamente eso: una forma sencilla de entender las distintas capas de Kubernetes para que puedas resolver problemas con mayor efectividad.
Si quieres una guía detallada de resolución de problemas para cada capa, también creamos un ebook llamado The Ultimate Kubernetes Troubleshooting Handbook. Es algo que puedes tener a la mano para problemas del mundo real.
Capa 1: Nodos
Todo en Kubernetes corre sobre máquinas reales. Estas máquinas pueden ser servidores físicos, instancias en la nube o máquinas virtuales. Sea como sea, son la base de todo.
Cada nodo ejecuta un componente llamado kubelet, que recibe instrucciones del plano de control y se asegura de que los contenedores estén corriendo correctamente. Si kubelet tiene problemas, los pods pueden quedarse atascados y las aplicaciones empiezan a fallar. Puede que veas alertas de distintas herramientas, pero ninguna muestra con claridad la causa raíz.
Aquí es donde suele empezar la depuración más profunda. Te conectas a la máquina, revisas los logs de kubelet, miras el uso de disco, el comportamiento del CPU y la configuración del sistema. Incluso diferencias pequeñas, como el runtime de contenedores o el sistema operativo, pueden afectar el comportamiento.
Los servicios administrados de Kubernetes facilitan la gestión de nodos, pero también limitan tu control cuando algo se rompe a ese nivel.
Los nodos también controlan las decisiones de scheduling mediante labels y taints. Cuando un nodo deja de estar sano, todos los pods que corren en él se ven afectados. Por eso los nodos son una de las partes más críticas de un clúster.
Capa 2: Redes
Si has trabajado con Kubernetes durante un tiempo, es probable que hayas batallado con las redes al menos una vez.
Cada pod recibe una dirección IP. Los pods pueden comunicarse entre sí directamente. Los services ofrecen puntos de acceso estables.
Pero la implementación real depende de plugins CNI como Flannel, Calico o Cilium. Cada uno se comporta de forma distinta y tiene sus propias limitaciones.
Además, kube-proxy se encarga de cómo se enruta el tráfico. Si las reglas de enrutamiento se rompen o quedan desactualizadas, el tráfico puede dejar de llegar a los pods correctos. Puede parecer que tu aplicación está rota, aunque en realidad funcione bien.
El DNS es otro problema común. CoreDNS corre dentro del clúster, así que si el clúster está bajo presión, el DNS puede fallar. Los pods no podrán encontrar los services, y los errores no señalarán claramente al DNS como el problema.
El Ingress añade otra capa para el tráfico externo, y configurarlo puede ser confuso. Si agregas un service mesh, todo se vuelve aún más complejo.
Cuando las redes fallan, terminas rastreando solicitudes a través de múltiples componentes solo para encontrar dónde se rompió algo.
Capa 3: Almacenamiento
Kubernetes se construyó originalmente para aplicaciones sin estado. El soporte de almacenamiento llegó después, y todavía se nota.
El sistema usa Persistent Volumes y Persistent Volume Claims para gestionar el almacenamiento. Pero el almacenamiento real puede venir de muchas fuentes, como discos en la nube, NFS o sistemas distribuidos.
Cada tipo de almacenamiento se comporta de forma distinta y tiene sus propios problemas.
El Container Storage Interface ayudó a estandarizar las cosas, pero también añadió más componentes que hay que gestionar. Si algo sale mal, los volúmenes pueden fallar al montarse y las aplicaciones pueden no arrancar.
Los workloads con estado, como las bases de datos, agregan más complejidad. Necesitan identidad y datos estables, lo que hace los despliegues más lentos y sensibles.
Muchos problemas de almacenamiento solo aparecen durante las fallas, especialmente cuando los workloads se mueven a otro nodo. Y ese suele ser el peor momento para que algo se rompa.
Capa 4: Seguridad
La seguridad en Kubernetes no es solo una configuración. Está compuesta por múltiples partes que trabajan en conjunto.
RBAC controla quién puede acceder a qué. Si está mal configurado, puedes bloquear el acceso o crear riesgos de seguridad.
Los service accounts les dan identidades a las aplicaciones. Se usan para acceder a otros servicios de forma segura.
Los Secrets almacenan datos sensibles, pero no son completamente seguros por defecto. Muchos equipos usan herramientas adicionales para gestionarlos correctamente.
También hay reglas que controlan cómo corren los pods, como impedir el acceso root o restringir privilegios. Son importantes, pero pueden romper los workloads si no se configuran con cuidado.
Las network policies controlan la comunicación entre pods, pero solo funcionan si tu plugin de red las soporta.
Como hay tantas piezas, gestionar la seguridad en Kubernetes puede resultar abrumador.
Capa 5: Asignación de recursos
Esta capa decide cuánto CPU y memoria usan tus aplicaciones.
Tú defines requests y limits. Los requests ayudan a Kubernetes a decidir dónde ubicar los pods. Los limits controlan cuánto pueden usar.
Si solicitas demasiado, malgastas recursos y aumentas los costos. Si solicitas muy poco, tu aplicación puede volverse lenta o fallar.
Aquí hay una diferencia importante. El CPU se puede limitar y ralentizar. Pero la memoria no. Si un contenedor supera sus límites de memoria, se elimina de inmediato.
Configuraciones como ResourceQuotas y LimitRanges ayudan a controlar el uso a un nivel más alto. Kubernetes también asigna priority classes que deciden qué pods se eliminan primero bajo presión.
La asignación de recursos afecta directamente tanto el rendimiento como el costo, y por eso es tan importante.
Capa 6: Orquestación
Esta es la función por la que Kubernetes es más conocido.
Defines lo que quieres, y Kubernetes intenta mantener ese estado de forma constante. Revisa y corrige las diferencias todo el tiempo.
Distintos tipos de workloads, como Deployments, StatefulSets y Jobs, cubren distintos casos de uso.
El scheduler decide dónde corren los pods según muchos factores, como recursos, reglas y restricciones.
Las rolling updates funcionan bien para aplicaciones simples, pero los workloads más complejos requieren un manejo cuidadoso.
Los custom resources y los operators extienden Kubernetes aún más. Permiten gestionar sistemas complejos, pero también agregan más componentes que mantener.
Para depurar problemas en esta capa, necesitas entender qué está intentando hacer Kubernetes, no solo lo que ves.
Capa 7: Autoescalado
El autoescalado ayuda a Kubernetes a ajustar los recursos según la demanda.
El Horizontal Pod Autoscaler aumenta o reduce los pods. El Vertical Pod Autoscaler modifica la configuración de recursos. El Cluster Autoscaler gestiona los nodos.
Estas herramientas son potentes, pero no son perfectas.
Escalar toma tiempo, especialmente cuando se necesitan nodos nuevos. Los picos repentinos de tráfico igual pueden causar problemas.
Las distintas herramientas de escalado también pueden entrar en conflicto entre sí si se usan juntas.
Existen enfoques más nuevos, como el escalado basado en eventos y el escalado predictivo, pero también traen sus propios desafíos.
Para que el autoescalado funcione bien, necesitas buenas métricas y una comprensión clara de tu workload.
Conclusión
Estas capas —nodos, redes, almacenamiento, seguridad, asignación de recursos, orquestación y autoescalado— ayudan a explicar cómo funciona Kubernetes.
Pero en la práctica no están separadas. Se superponen todo el tiempo. Por eso los problemas son difíciles de depurar.
Un problema de red puede parecer un problema de almacenamiento. Un problema de recursos puede desencadenar problemas de escalado. Un cambio de seguridad puede romper la comunicación.
No puedes enfocarte en una sola capa. Necesitas una comprensión general de todo el sistema.
Incluso con herramientas modernas, esa comprensión es importante. De lo contrario, perderás tiempo arreglando síntomas en lugar de resolver el problema real.
Hemos reunido todo lo que aprendimos en The Ultimate Kubernetes Troubleshooting Handbook. Cubre problemas del mundo real, pasos de depuración y ejemplos prácticos.
Si te ayuda a resolver aunque sea un problema más rápido, ya valió la pena. Y ojalá tus clústeres funcionen sin contratiempos.