Índice8
Kubernetes está en todas partes: en las ofertas de empleo, en las propuestas de arquitectura, en las plataformas de los grandes proveedores de nube. Se ha convertido en el estándar de los sistemas que ejecutan cientos de servicios, y con razón. Para una empresa de 20 a 500 personas que ejecuta un puñado de herramientas, la pregunta no es si Kubernetes es una buena herramienta (lo es), sino si resuelve un problema que la empresa tiene.
Este artículo de nuestra sección Infraestructura y nube explica lo que aporta Kubernetes, lo que cuesta mantenerlo y las señales que indican que puede prescindir de él, por ahora o de forma duradera.
En resumen
- Kubernetes reparte contenedores entre varias máquinas y los mantiene en el estado descrito: es su punto fuerte cuando hay muchos servicios y varias máquinas.
- No proporciona ni base de datos, ni supervisión, ni copias de seguridad: esos frentes siguen enteros.
- Requiere mantenimiento: cada versión menor recibe alrededor de un año de correcciones, y una versión atrasada puede salir más cara con un proveedor.
- Unos pocos servicios en uno o dos servidores se gestionan de forma más sencilla con contenedores descritos en un archivo, copias de seguridad probadas y un plan de recuperación.
Lo que hace Kubernetes, en una frase
La documentación de Kubernetes lo presenta como una plataforma de código abierto, portátil y extensible, que gestiona cargas de trabajo en contenedores. En la práctica, usted le describe el estado deseado (tal servicio, en tres copias, con tal memoria) y él trabaja de forma continua para alcanzar ese estado en un conjunto de máquinas: reinicia lo que cae, reparte la carga y despliega las nuevas versiones de forma progresiva.
de los usuarios de contenedores ejecutan Kubernetes en producción, frente al 66 % en 2023
de los encuestados citan los cambios culturales en el equipo como primer freno
citan la complejidad
La primera cifra indica que Kubernetes se ha convertido en la norma entre quienes ya usan contenedores a gran escala. Las dos siguientes recuerdan que no se adopta como un software que se instala: cambia la forma de trabajar de un equipo.
Lo que Kubernetes no hace
Es la parte menos conocida, y la documentación oficial es muy clara. En su sección sobre lo que Kubernetes no es, precisa que:
- no proporciona servicios de aplicación integrados, como una base de datos, una caché o un sistema de almacenamiento compartido;
- no impone ni proporciona una solución de registro, supervisión o alertas, más allá de mecanismos para recopilar y exportar métricas;
- no compila su aplicación ni despliega su código fuente;
- no proporciona un sistema completo de configuración, mantenimiento o gestión de las máquinas.
Dicho de otro modo, adoptar Kubernetes no resuelve ni las copias de seguridad, ni la supervisión, ni la base de datos: esos frentes siguen enteros y, además, hay que hacerlos encajar en Kubernetes. Para un equipo pequeño, este es el punto que cuenta: se añade una capa que operar, no se quita ninguna.
Lo que cuesta mantenerlo
Kubernetes evoluciona rápido. La página de versiones del proyecto indica que solo se mantienen las tres últimas versiones menores y que cada una recibe alrededor de un año de correcciones. Un clúster debe actualizarse, por tanto, al menos una vez al año, comprobando cada vez que todo lo que se ejecuta en él sigue funcionando.
Con un proveedor, este ritmo tiene un precio explícito. En AWS, por ejemplo, un clúster gestionado cuesta 0,10 dólares por hora en soporte estándar y 0,60 dólares en soporte extendido, cuando su versión ha superado el periodo estándar. Los demás proveedores tienen sus propias tarifas; el principio es el mismo: el mantenimiento atrasado se paga. Este coste se suma a las propias máquinas, y lo hemos incluido entre las cinco partidas que inflan una factura de nube.
El coste principal sigue siendo humano: hace falta alguien que entienda el funcionamiento del clúster, sus redes, sus permisos y sus actualizaciones, y que esté localizable cuando se comporta mal. Kubernetes no elimina el trabajo de los administradores de sistemas: lo desplaza hacia competencias más especializadas.
Las señales de que no lo necesita
Bastan contenedores en uno o dos servidores cuando
Ejecuta menos de una veintena de servicios, a menudo herramientas del mercado
La carga es estable y cabe en una máquina
Una interrupción de unos minutos, durante una actualización o una restauración, es aceptable
Nadie en su equipo ni en su proveedor opera Kubernetes a diario
Kubernetes se justifica cuando
Varios equipos despliegan cada uno sus servicios, varias veces al día
La carga varía mucho y debe adaptarse sola, al alza y a la baja
Un servicio no debe detenerse si cae una máquina entera
Un equipo ya sabe operarlo, o su proveedor lo hace por usted
El umbral de una veintena de servicios no es una norma: es un orden de magnitud que conviene contrastar con su propia situación. El criterio más fiable sigue siendo el último de cada columna: la competencia disponible para operarlo.
Lo que basta en su lugar
Para la mayoría de las empresas medianas, un montaje más sencillo cubre la necesidad:
- contenedores descritos en un archivo, con Docker Compose, que su documentación presenta como una herramienta para definir y ejecutar aplicaciones de varios contenedores; la descripción de los servicios vive en un repositorio versionado y se puede reproducir en otra máquina;
- un enrutador delante de los servicios, que gestiona las direcciones y los certificados;
- copias de seguridad fuera del servidor, restauradas de verdad, y una lista escrita de los servicios y sus volúmenes;
- una supervisión externa, que avisa cuando un servicio deja de responder;
- un plan de recuperación escrito, con el tiempo real de restauración medido.
Sobre el terreno
Es el montaje de nuestras propias herramientas: una docena de servicios en contenedores Docker, detrás de un enrutador Traefik, en un único VPS, para cinco empresas clientes. Sin Kubernetes. El 5 de julio de 2026, un comando de limpieza mal dirigido destruyó de golpe los contenedores de diez de esos servicios. Los datos, guardados en volúmenes, se salvaron, y respondimos con reglas de operación escritas, no con un orquestador: el problema era un comando, no la ausencia de un clúster.
El límite de este montaje es conocido: un servidor único es un punto único de fallo. Si su actividad no soporta la parada durante una restauración, el primer escalón no es necesariamente Kubernetes: un segundo servidor listo para tomar el relevo, o servicios gestionados en un proveedor, suelen cubrir la necesidad con menos complejidad. Las decisiones entre servidor y nube se detallan en servidor dedicado, VPS o nube: elegir según el uso.
Si aun así da el paso
Hay buenas razones para hacerlo: un equipo que ya lo domina, una aplicación que debe escalar, un editor que solo entrega su software en esa forma. En ese caso, tres precauciones:
- Preferir un servicio gestionado si nadie en su empresa opera un clúster: el proveedor se encarga de la parte más delicada.
- Planificar las actualizaciones desde el principio, al menos una al año, con un entorno de pruebas.
- Mantener fuera del clúster lo que no necesita estar dentro, por ejemplo una base de datos gestionada, en lugar de meterlo todo.
El clúster se suma entonces a la base de infraestructura común a sus proyectos: mismas reglas de acceso, de copias de seguridad y de presupuesto.
Por dónde empezar
Cuente sus servicios y, para cada uno, anote quién lo opera y qué interrupción es aceptable. Si la lista es corta y unos minutos de parada no ponen en peligro la actividad, empiece por contenedores bien descritos, copias de seguridad que se restauran de verdad, una supervisión que avisa antes que los clientes y un plan de recuperación ante desastres escrito. Un ejemplo concreto de este montaje está en n8n autoalojado en producción.
Los demás artículos de la sección tratan las etapas cercanas: las herramientas que conviene sacar primero del SaaS, el coste real de salir del SaaS a tres años, la migración a la nube sin romperlo todo, la dependencia de Europa de la nube estadounidense y lo que NIS2 exigirá a las empresas francesas.
Si quiere este montaje para sus herramientas de gestión, nuestra salida del SaaS lo instala en un servidor suyo, hasta cinco servicios, con copias de seguridad probadas y documentación incluidas. Si un equipo le propone Kubernetes y quiere una segunda opinión, descríbanos el proyecto.
Preguntas frecuentes
¿Es Kubernetes adecuado para una pyme?
Lo es cuando la pyme ejecuta numerosos servicios, desplegados a menudo por varios equipos, o cuando debe absorber fuertes variaciones de carga sin interrupción. Para unas pocas herramientas internas en uno o dos servidores, suelen bastar contenedores descritos en un archivo, copias de seguridad probadas y una supervisión externa, con mucha menos operación.
¿Cuál es la diferencia entre Docker Compose y Kubernetes?
Docker Compose describe y lanza varios contenedores en una máquina, a partir de un archivo. Kubernetes reparte contenedores entre un conjunto de máquinas y los mantiene de forma continua en el estado descrito: reinicio, reparto de carga, despliegue progresivo. Compose es más sencillo de operar; Kubernetes resulta útil cuando una sola máquina ya no basta o no debe ser un punto único de fallo.
¿Cuánto cuesta un clúster de Kubernetes gestionado?
Depende del proveedor. En AWS, el plano de control de un clúster gestionado se factura a 0,10 dólares por hora en soporte estándar y 0,60 dólares en soporte extendido, además de las máquinas que ejecutan los servicios. Sin embargo, el coste principal siguen siendo las horas de operación: actualizaciones, supervisión, permisos y red del clúster.
¿Hace falta Kubernetes para tener alta disponibilidad?
No. Kubernetes es una forma de lograrlo, no la única. Un segundo servidor listo para tomar el relevo, una base de datos gestionada con replicación o un servicio de contenedores gestionado en un proveedor suelen cubrir la necesidad de una empresa mediana. Empiece por cuantificar la interrupción aceptable: es ella la que indica qué nivel de redundancia pagar.
Fuentes
- Kubernetes, Overview (nueva pestaña)kubernetes.io
- Kubernetes, Releases (nueva pestaña)kubernetes.io
- AWS, precios de Amazon EKS (nueva pestaña)aws.amazon.com
- Docker, Docker Compose (nueva pestaña)docs.docker.com
Jim · fundador de Brain Plus AI
Más artículos sobre infraestructura y nube
Guía práctica14 min La guía del tema
Infraestructura en la nube: la base común de todos sus proyectos
Antes del primer proyecto, una base de infraestructura en la nube resuelve de una vez por todas las cuentas, los accesos, las copias de seguridad y el presupuesto, y cada proyecto siguiente la hereda. Qué contiene, dónde montarla, cuánto cuesta y por qué su explotación cuenta más que su instalación.
Guía práctica8 min
Contraseñas: un gestor para todo el equipo
Una hoja de cálculo «Accesos», contraseñas enviadas por mensajería, una cuenta compartida que nadie se atreve a cambiar: un gestor de contraseñas de equipo lo resuelve todo de una vez. Lo que cambia en la llegada y la salida de un empleado, cómo elegirlo y por dónde empezar.
Entender9 min
Claves de API robadas: el riesgo olvidado de los proyectos de IA
Un proyecto de IA multiplica las claves de API, y cada una, si la roban, se convierte en una factura que otra persona consume a su costa. Dónde se filtran, cómo limitar los daños antes de la filtración y qué hacer en la primera hora.