Cómo evaluar a un proveedor de Managed Kubernetes en Europa

September 2026 • Comparison

Una página de precios de Managed Kubernetes no te dice qué ocurre cuando algo falla por la noche. Esta checklist reúne las preguntas que lo deciden y, para cada una, muestra lo que varios proveedores europeos publican realmente. Cada dato sobre proveedores procede de la propia documentación o página de precios del proveedor, leída en septiembre de 2026, y está enlazado en la sección Fuentes.

1. Pregunta qué se gestiona realmente

Los proveedores trazan la línea entre su trabajo y el tuyo en puntos distintos. El SLA de Exoscale SKS es explícito: cubre solo la disponibilidad del control plane, no los nodos worker, los pods, los volúmenes, las aplicaciones ni los datos. El cliente sigue siendo responsable de las cargas de trabajo, el control de acceso al clúster, los datos persistentes, los backups, la planificación de la recuperación ante desastres y los procedimientos de restauración.

Otros proveedores describen una mayor automatización. IONOS afirma que su servicio gestionado se encarga automáticamente de las actualizaciones y las correcciones de seguridad, y que tú eliges cuándo se ejecutan. Infomaniak afirma que puedes actualizar el control plane y los nodos worker en cualquier momento y que gestiona todos los componentes de Kubernetes. Sea cual sea la formulación, consigue respuestas por escrito a estas preguntas:

• ¿Quién actualiza el control plane, quién actualiza los nodos worker y quién decide el momento?
• ¿Quién aplica los parches al sistema operativo de los nodos worker?
• ¿A quién corresponden los backups del estado del clúster y de tus volúmenes persistentes?
• ¿Qué complementos (red, ingress, métricas) se suministran y quién los mantiene actualizados?

2. Comprueba qué nivel de control plane compras realmente

Un control plane gratuito no es el mismo producto que uno de pago. Los niveles gratuitos de abajo son compartidos y no tienen SLA, mientras que los niveles de pago añaden réplicas, un datastore dedicado y un objetivo de disponibilidad por escrito.

Esto importa por cómo está construido el propio Kubernetes. Como explica nuestro artículo sobre Kubernetes managed vs. self-hosted, la documentación de Kubernetes recomienda clústeres etcd de varios miembros para producción, y etcd necesita la mayoría de sus miembros para hacer cambios. Una única réplica de API sobre un datastore compartido es una opción razonable para desarrollo y débil para producción.

3. Lee el SLA para saber qué cubre

Dos proveedores pueden anunciar ambos un porcentaje y querer decir cosas muy distintas. Pregunta qué se mide (disponibilidad de la API del control plane, disponibilidad de los nodos o ambas), durante qué periodo, qué se excluye y qué recibes si no se cumple el objetivo. Exoscale, por ejemplo, abona el 50 % de las cuotas mensuales de los recursos afectados cuando la disponibilidad se sitúa entre el 99,95 % y el 98,3 %, y el 100 % por debajo de esa cifra. Excluye además los fallos de nodos, volúmenes y pods, porque su SLA se aplica al control plane.

También ayuda traducir el porcentaje a tiempo. En un mes de 30 días:

Scaleway indica el 99,5 % para sus control planes Kapsule dedicados, Infomaniak indica el 99,9 % para sus niveles dedicados y Exoscale indica al menos el 99,95 % para su plan Pro. Esas cifras solo son comparables si las definiciones coinciden, así que lee las definiciones antes de comparar los números.

4. Pregunta si las vCPU son dedicadas

Las vCPU compartidas se planifican en núcleos físicos que varias máquinas virtuales usan a la vez. La documentación de Scaleway describe la consecuencia con claridad: durante los picos de demanda de las cargas de trabajo vecinas, tus cargas pueden ralentizarse por contención de CPU, conocida como CPU steal. Las vCPU dedicadas dan acceso exclusivo a núcleos físicos y un rendimiento constante. Las propias indicaciones de Scaleway incluyen los nodos worker de los clústeres de Kubernetes entre los usos típicos de las instancias compartidas, lo cual es una opción razonable para desarrollo y un compromiso real para producción.

IONOS te permite elegir entre núcleos dedicados y vCPU para los nodos worker de su Kubernetes gestionado. Muchos proveedores no indican cuál obtienes en un plan determinado. Si la documentación calla, pregunta por escrito, porque cambia tanto el rendimiento como el precio que debes esperar.

5. Comprueba la replicación del almacenamiento y dónde están las copias

Los volúmenes persistentes son donde un clúster de Kubernetes guarda los datos que no puedes reconstruir, así que pregunta cómo están protegidos:

• El almacenamiento en bloques de Exoscale conserva dos copias de los datos en servidores distintos, replicadas dentro de la misma zona, con 5.000 IOPS por volumen.
• El almacenamiento en bloques de Scaleway (volúmenes NVMe) se replica tres veces con un SLA del 99,99 %, y sus FAQ señalan que los IOPS pueden fluctuar durante los picos de carga.
• El almacenamiento en bloques de Infomaniak funciona sobre un clúster Ceph cifrado con tres réplicas en NVMe e indica hasta 4.000 IOPS garantizados.
• Hikube afirma replicar los datos de forma síncrona entre tres centros de datos suizos.

La replicación protege frente a la pérdida de un disco o de un servidor. No es un backup, porque un borrado por error también se replica, y las copias dentro de una zona o de un sitio no te protegen de perder esa zona o ese sitio. Pregunta dónde está cada copia y planifica un backup aparte, fuera del sitio, para todo lo que no puedas permitirte perder.

6. Lee las condiciones de soporte, no el titular

«Soporte 24/7» puede significar cosas muy distintas. La tabla muestra qué dice cada proveedor que está incluido sin coste adicional y cuánto cuesta la cobertura más rápida o las 24 horas.

Fíjate en qué son estas cifras. Son objetivos de primera respuesta, no de resolución. OVHcloud lo dice expresamente: su tiempo de gestión termina cuando el equipo empieza a procesar el ticket, no cuando se resuelve el incidente, y no ofrece ninguna garantía de cumplir los objetivos. Cuando compares proveedores, pide el objetivo de resolución, la vía de escalado, los canales y los idiomas, y comprueba si el soporte se factura como un porcentaje de tu gasto.

7. Busca costes de tráfico y partidas ocultas

El precio mensual de un nodo rara vez es toda la factura. Pregunta por el tráfico saliente, las direcciones IPv4 públicas, los balanceadores de carga, los snapshots, las solicitudes de almacenamiento de objetos y los costes de soporte. Infomaniak afirma que el ancho de banda es gratuito, salvo en el almacenamiento de objetos por encima de 10 TB de ancho de banda consumido, y UpCloud afirma que no tiene costes de tráfico saliente. Varios proveedores tarifican sus niveles de soporte más rápidos como un porcentaje de tu gasto mensual, como muestra la tabla anterior, de modo que esa partida crece con tu uso.

8. Pregunta dónde residen los datos, incluidos backups y logs

La ubicación de los datos abarca más que la base de datos principal. Pregunta dónde se almacenan los backups, los logs y los datos de monitorización, qué entidad opera la infraestructura y la ley de qué país se aplica a esa entidad. Hikube ofrece un ejemplo de respuesta concreta: afirma que ningún dato pasa por servidores extranjeros, incluidos backups, logs y métricas de monitorización, y que hay atestaciones de residencia de datos disponibles bajo petición para los auditores. Pide a cualquier proveedor el mismo nivel de detalle por escrito.

9. Comprueba la salida antes de entrar

Kubernetes en sí es portable, así que la dependencia nace de todo lo que lo rodea. Pregunta si el clúster es Kubernetes upstream estándar con un kubeconfig normal, si Terraform, Helm y las herramientas GitOps funcionan sobre él, cómo exportas tus datos y volúmenes y durante cuánto tiempo se conservan los recursos tras la baja. Un proveedor que responde a esto con claridad es uno al que puedes dejar, y eso hace más fácil confiar en él mientras te quedas.

10. Haz una prueba de dos semanas antes de comprometerte

Pide una prueba o un plan de bajo compromiso y prueba lo que importa, no la demo de la consola:

• Tiempo hasta el primer clúster. Crea un clúster y mide el tiempo.
• Datos stateful. Despliega una aplicación con un volumen persistente, elimina el pod y comprueba que los datos sobreviven.
• Una actualización. Actualiza el clúster una versión minor y anota lo que has tenido que hacer por tu cuenta.
• Una restauración. Restaura a partir de un backup o de un snapshot en un clúster nuevo. Un backup del que no has restaurado es una suposición.
• Soporte. Abre un ticket por la noche, clasifícalo como urgente y registra tanto el tiempo de primera respuesta como el tiempo hasta la resolución.
• Rendimiento bajo carga. Ejecuta un trabajo intensivo de CPU en un nodo worker y comprueba si hay CPU steal, y prueba el disco con un benchmark intensivo de fsync.

Dos comandos cubren el último punto. En un nodo worker, vmstat 1 10 imprime una columna llamada st con el tiempo de steal; los valores distintos de cero sostenidos mientras se ejecuta tu trabajo indican que otros tenants te están quitando CPU. Para los discos, la documentación de rendimiento de etcd explica que la latencia de una solicitud está limitada por el tiempo de ida y vuelta de la red más el tiempo que fdatasync necesita para volcar los datos al almacenamiento permanente, y sitúa la latencia típica de fdatasync en unos 10 ms para un disco giratorio y a menudo por debajo de 1 ms para un SSD. Una forma habitual de medirla es fio con escrituras síncronas y fdatasync:

fio --name=disk-latency --directory=/mnt/test --rw=write --ioengine=sync --fdatasync=1 --size=22m --bs=2300

El informe incluye percentiles de latencia de fdatasync. Las indicaciones de Red Hat sobre etcd consideran una latencia de fsync en el percentil 99 inferior a 10 ms como el listón para un disco capaz de alojar etcd, así que úsalo como punto de referencia al comparar proveedores.

Dónde se sitúa Kube-DC

Así responde Cloud Acropolis Kube-DC a las mismas preguntas. Enumeramos lo que está documentado y lo que no, para que puedas contrastarlo con tu propia checklist.

Fuentes (leídas en septiembre de 2026)

• Exoscale: SKS service-level agreement
• Exoscale: support plans
• Exoscale: SKS product page
• Exoscale: block storage
• Infomaniak: managed Kubernetes service
• Infomaniak: Public Cloud
• Infomaniak: premium support guide
• Scaleway: containers pricing (Kapsule)
• Scaleway: support plans
• Scaleway: shared vs dedicated vCPUs
• Scaleway: block storage FAQ
• OVHcloud: support levels
• OVHcloud: Standard support
• OVHcloud: Business support
• IONOS: Managed Kubernetes
• UpCloud
• Hikube by Hidora
• etcd: performance
• Red Hat: recommended etcd practices
• Kube-DC platform datasheet

Lecturas relacionadas

• Kubernetes managed vs. self-hosted: la realidad técnica

Somete Kube-DC a la checklist

Todos los puntos anteriores pueden probarse en un paquete Kube-DC: vCPU dedicadas, almacenamiento NVMe respaldado por Ceph, una IPv4 pública dedicada, almacenamiento de objetos compatible con S3, tus propios clústeres de Kubernetes administrados por el tenant y soporte 24/7 con un objetivo de resolución de 4 horas. Pide en un portal de autoservicio, haz la prueba de dos semanas y júzganos por los resultados.