Orquestación de contenedores: Kubernetes en bare metal

Todos los servicios gestionados de Kubernetes, EKS, GKE y AKS, se ejecutan en hardware físico. El plano de control se ejecuta en hardware físico. Tus nodos de trabajo son máquinas virtuales que alquilan porciones de servidores físicos o instancias de hardware físico que eliminan por completo la capa de máquinas virtuales. El valor del servicio gestionado reside en la automatización del plano de control y en las integraciones del ecosistema, no en ninguna ventaja fundamental de la infraestructura.

Ejecutar K8s en servidores dedicados o bare metal de InMotion significa que tus pods se ejecutan directamente en hardware físico sin sobrecarga de hipervisor, con NVMe predecible para volúmenes persistentes y un coste mensual fijo que no varía en función de las horas de nodo o el volumen de llamadas a la API.

El problema de la sobrecarga del hipervisor en Cloud K8s

Los nodos de trabajo de Cloud Kubernetes son máquinas virtuales. KVM, Xen o Hyper-V se sitúan entre tus contenedores y el hardware físico. Esto introduce dos penalizaciones de rendimiento que el hardware físico elimina:

• Sobrecarga de la CPU: los hipervisores suelen añadir entre un 5 % y un 15 % de sobrecarga de la CPU para las llamadas al sistema y los cambios de contexto. Para las cargas de trabajo que realizan una gran actividad de llamadas al sistema (servicios que hacen un uso intensivo de la red, aplicaciones vinculadas a E/S), esto supone una latencia apreciable.
• Sobrecarga de memoria: los hipervisores mantienen sus propias estructuras de memoria junto con la memoria de la máquina virtual. Un nodo de trabajo en la nube de 16 GB tiene menos de 16 GB disponibles para los componentes del sistema Kubernetes y los pods después de la sobrecarga del hipervisor y el sistema operativo invitado.

En metal desnudo, un servidor de 192 GB proporciona a Kubernetes los 192 GB completos menos la sobrecarga del kernel del sistema operativo (aproximadamente entre 2 y 4 GB). Cada GB de capacidad del nodo es real, no nominal.

Opciones de arquitectura de clúster

K8s de un solo nodo para desarrollo y puesta en escena

Un único servidor InMotion Hosting que ejecute k3s o kubeadm con funciones maestras y de trabajo combinadas es un entorno de ensayo práctico. k3s es especialmente adecuado en este caso: ejecuta una distribución de Kubernetes de nivel de producción con un único binario, SQLite (o etcd externo para HA) y un espacio mínimo que deja más recursos para las cargas de trabajo.

K8s de un solo nodo no es adecuado para la producción en cargas de trabajo que requieren alta disponibilidad (el fallo de un nodo lo deja todo inoperativo), pero es ideal para duplicar configuraciones de producción en entornos de prueba sin tener que pagar por varios servidores.

Clústeres de producción multinodo

Un clúster de producción de Kubernetes necesita como mínimo tres nodos de plano de control para el quórum de etcd. En la práctica, muchos equipos ejecutan un servidor de plano de control dedicado más dos o tres nodos de trabajo. Con los servidores dedicados de InMotion:

• Plano de control: Nivel avanzado (149,99 $ al mes), 64 GB de RAM son suficientes para los componentes del plano de control de K8s en clústeres de menos de 100 nodos.
• Nodos de trabajo: Nivel Extreme (349,99 $ al mes) por nodo para cargas de trabajo que requieren mucho uso de memoria; Essential o Advanced para perfiles de pod más ligeros.
• Red: puerto de 10 Gbps en nodos de trabajo para el tráfico entre pods en mallas de servicio de alto rendimiento.

Planificación de la densidad de pods en hardware de 192 GB y 16 núcleos

La densidad de los pods de Kubernetes depende de las solicitudes de recursos y los límites definidos en las especificaciones de los pods. Un marco de planificación aproximado:

Perfil de Pod	Solicitud de CPU	Solicitud de memoria	Pods por nodo de 192 GB
Microservicio (típico)	100m	256 MB	~600 cápsulas (limitado por la memoria)
Pod de aplicación web	250m	512 MB	~300 cápsulas (limitado por la memoria)
Pod de servicio API	500m	1GB	~160 pods (limitado por la memoria)
Sidecar/operador de base de datos	1 núcleo	4 GB	~40 pods (limitado por la memoria)

En la práctica, Kubernetes reserva recursos para los pods del sistema (espacio de nombres kube-system), el sistema operativo del nodo y el margen de desalojo. La memoria asignable en un nodo de 192 GB suele ser de entre 175 y 180 GB después de estas reservas. Las cifras anteriores representan máximos teóricos; los clústeres reales funcionan al 60-70 % de la densidad máxima para mantener el margen de programación.

La CPU EPYC de 16 núcleos gestiona cómodamente la programación de pods hasta unos 500 pods en ejecución activa antes de que la CPU se convierta en la limitación. La mayoría de los clústeres reales con entre 100 y 300 pods no se acercan ni de lejos a este límite.

Almacenamiento: volúmenes persistentes en NVMe

Proveedor de rutas locales

La configuración de volumen persistente más sencilla para el almacenamiento de un solo nodo o por nodo utiliza el proveedor de ruta local (mantenido por Rancher, incluido en k3s de forma predeterminada). Esto crea PersistentVolumeClaims respaldados por directorios en el NVMe del nodo.

Para cargas de trabajo que no necesitan almacenamiento para sobrevivir a fallos de nodos (aplicaciones sin estado con bases de datos externas, trabajos que utilizan espacio temporal), la ruta local en NVMe el máximo rendimiento de almacenamiento posible sin sobrecarga de red. Un PostgreSQL en la ruta local NVMe de forma idéntica a PostgreSQL directamente en el mismo NVMe .

Longhorn para almacenamiento replicado

Longhorn (también de Rancher) es una solución de almacenamiento nativo en la nube que replica volúmenes en varios nodos de clúster. Para clústeres de varios nodos en los que la programación de pods debe ser independiente de la ubicación del almacenamiento, Longhorn replica los datos PVC en dos o tres nodos.

La sobrecarga de replicación en NVMe aceptable: la ruta de datos de Longhorn añade aproximadamente un 10-20 % de latencia en comparación con la ruta local, lo que sigue siendo más rápido que el almacenamiento en bloques en la nube conectado a través de la red. Para las bases de datos de producción en Kubernetes, Longhorn proporciona la resiliencia que la ruta local no puede ofrecer.

Selección de clase de almacenamiento por carga de trabajo

• local-path: Pods sin estado , cachés de compilación CI/CD, volúmenes temporales para trabajos por lotes. Máximo rendimiento, sin replicación.
• Longhorn (1 réplica): implementaciones de un solo nodo que requieren gestión de PVC sin fijación de afinidad de nodos.
• Longhorn (2-3 réplicas): bases de datos de producción , servicios con estado que requieren alta disponibilidad ante fallos de nodos.

Selección de complementos CNI para Bare Metal

Cloud Kubernetes utiliza complementos CNI específicos del proveedor (VPC CNI para EKS, etc.) que se integran con primitivas de red en la nube que no están disponibles en bare metal. Para K8s bare metal, tres complementos cubren la mayoría de los casos de uso:

• Flanela: Superposición VXLAN simple , más fácil de manejar, rendimiento aceptable para la mayoría de las cargas de trabajo. Predeterminado en k3s. Carece de aplicación de políticas de red.
• Calico: redes basadas en BGP con compatibilidad total con NetworkPolicy. Recomendado para clústeres de producción que necesitan aislamiento del tráfico entre pods en diferentes espacios de nombres.
• Cilium: basado en eBPF , el menor overhead de los tres, sustituye iptables por el procesamiento de paquetes a nivel del kernel. El mejor rendimiento para mallas de servicios de alto rendimiento. Más complejo desde el punto de vista operativo.

Para la mayoría de los equipos que empiezan con K8s bare metal, Calico ofrece el equilibrio perfecto: compatibilidad total con NetworkPolicy para la segmentación de la seguridad, funcionamiento estable y buena documentación. Vale la pena evaluar Cilium cuando el clúster sirve tráfico este-oeste de alto rendimiento, en el que la sobrecarga de iptables en Calico se vuelve apreciable.

Servicios de equilibrador de carga sin proveedor de nube: MetalLB

Cloud Kubernetes aprovisiona automáticamente un equilibrador de carga en la nube cuando creas un servicio con el tipo: LoadBalancer. En bare metal, no hay ningún proveedor de nube que aprovisione ese equilibrador de carga. Los servicios quedan bloqueados en estado Pendiente indefinidamente.

MetalLB resuelve este problema. Funciona como un controlador en el clúster y asigna direcciones IP de un grupo configurado a los servicios LoadBalancer. En modo L2 (más sencillo), MetalLB responde a las solicitudes ARP de direcciones IP de servicio desde el nodo donde se encuentra el punto final del servicio. En modo BGP, anuncia rutas directamente a los enrutadores ascendentes para una distribución adecuada de la carga.

Para la mayoría de las implementaciones de servidores dedicados InMotion que ejecutan K8s, MetalLB en modo L2 con un pequeño grupo de direcciones IP (incluso una subred /30 de direcciones IP adicionales) es suficiente para exponer los servicios externamente. Añade un controlador Nginx sobre MetalLB para gestionar el enrutamiento HTTP/HTTPS sin consumir una dirección IP dedicada por servicio.

K8s bare metal frente a K8s en la nube gestionada: cuándo gana cada uno

Factor	K8s sobre hardware desnudo	EKS / GKE / AKS
Coste mensual por nodo de trabajo	99-350 $ (dedicado)	100-800 $+ (nodos VM)
Coste del plano de control	Autogestionado (gratuito)	72-150 $ al mes (comisión de gestión)
Latencia de almacenamiento	NVMe (~0,1 ms)	Bloque de red (~1-5 ms)
Autoescalado	Autoescalador manual o por clúster	Autoescalador nativo en la nube
Regiones globales	Los Ángeles, Ámsterdam	Más de 30 regiones de todo el mundo
Gastos generales de gestión	Medio (kubeadm/k3s)	Bajo (plano de control gestionado)
Coste mensual predecible	Sí	Variable (basada en el uso)

K8s sin metal gana en cuanto a coste y rendimiento de almacenamiento para cargas de trabajo estables. K8s gestionado en la nube gana en cuanto a simplicidad operativa y distribución global. La elección correcta depende de si tus cargas de trabajo tienen requisitos de distribución geográfica y de si tu equipo puede gestionar un plano de control.

Docker Swarm como alternativa más sencilla

No todas las cargas de trabajo en contenedores necesitan Kubernetes. Docker Swarm en un único servidor dedicado gestiona docenas de servicios en contenedores con una fracción de la complejidad operativa de K8s. Si tu arquitectura tiene menos de 10-15 servicios distintos y no requiere funciones específicas de K8s (definiciones de recursos personalizados, restricciones de programación complejas, herramientas del ecosistema Helm), Swarm en un servidor dedicado de InMotion se implementa en una tarde.

El modelo de red de Docker Swarm en un solo nodo es más sencillo que el de K8s: redes superpuestas para la detección de servicios, puertos publicados para acceso externo, Traefik o Nginx la entrada. Sin complementos CNI. Sin MetalLB. Para los equipos que consideran que la sobrecarga operativa de K8s supera las ventajas arquitectónicas de vuestra carga de trabajo, Swarm es una opción válida para la producción.

Cómo empezar

• Solicita un servidor físico o dedicado, nivel Extreme para nodos de trabajo K8s de producción.
• Instala k3s para clústeres de un solo nodo o clústeres ligeros de varios nodos; kubeadm para tener un control total sobre la configuración del clúster.
• Configura Calico CNI para que sea compatible con NetworkPolicy desde el primer día.
• Instala MetalLB en modo L2 para que sea compatible con el servicio LoadBalancer.
• Configura el proveedor de rutas locales para los PVC de desarrollo; Longhorn para las cargas de trabajo con estado de producción.
• Añade Premier Care para la gestión a nivel del sistema operativo del host bare metal.

Los equipos que actualmente pagan 800 dólares o más al mes por nodos de trabajo gestionados de Kubernetes suelen recuperar ese coste en el primer ciclo de facturación tras migrar las cargas de trabajo en estado estable a bare metal. La inversión operativa en la gestión de un plano de control es real, pero se trata de un coste de configuración único, no de un gasto general continuo proporcional a tu gasto en computación.