Bare metal para contenedores
Kubernetes sobre bare metal significa que cada nodo de tu clúster es un servidor dedicado completo, sin hipervisor entre tus pods y el hardware. Primcast alquila esos servidores por meses con acceso root y un puerto sin límite de tráfico, para que puedas instalar Docker, k3s, RKE2 o kubeadm y ejecutar el clúster a tu manera.
Un servidor que ya está en el rack se entrega unos 30 minutos después de que se apruebe tu pedido. Sin permanencia: pagas un mes cada vez.
01Por qué bare metal
Los contenedores ya comparten un kernel, así que una máquina virtual por debajo añade una segunda capa que no te aporta nada. En un servidor dedicado, tus cargas de trabajo acceden directamente al procesador, la memoria, los discos y la tarjeta de red.
ASin capa virtual
Ningún hipervisor se lleva una parte del procesador ni se interpone en el camino del disco y la red. Lo que mides en el nodo es lo que reciben tus contenedores, lo que facilita definir requests y limits.
BUn solo inquilino
Nadie más ejecuta nada en tu servidor. Un desconocido con mucha actividad no puede consumir la cola del disco ni el ancho de banda de memoria que esperaba tu pod de base de datos, así que la latencia se mantiene donde la dejaste.
CFactura plana
Cada servidor incluye un puerto sin límite de tráfico que no se comparte, de 1 Gbps o 500 Mbps según la línea. Las descargas de imágenes, la replicación entre nodos y el tráfico hacia tus usuarios nunca aparecen como un cargo por gigabyte.
DControl total
Tienes root en cada servidor y puedes reinstalar el sistema desde el panel de control sin coste. Los servidores en rack y los blades también incluyen una consola en el navegador con control de energía, para el día en que un cambio de red te deje fuera.
02Elige tu ruta
Empieza por el trabajo. Un puñado de servicios en una máquina solo necesita Docker y nada más. Varias máquinas que deben recuperarse solas necesitan Kubernetes, y entonces la pregunta es quién se ocupa del plano de control.
| Ruta | Ideal para | Plano de control | Dónde ir |
|---|---|---|---|
| Docker en un servidor dedicado | Unas pocas aplicaciones con Docker Compose, un runner de builds, una copia de staging de producción | No hace falta | Cualquier servidor de abajo |
| Tu propio clúster de Kubernetes | Equipos que quieren elegir la distribución, el plugin de red y las fechas de actualización | Lo gestionas tú, en tus propios servidores | Esta página |
| Kubernetes gestionado | Equipos que quieren kubectl y sus propios workers, sin ocuparse de etcd | Lo gestionamos nosotros; tus servidores son los workers | Kubernetes gestionado |
¿Solo necesitas una máquina pequeña? Un Cloud VPS también ejecuta Docker. ¿Quieres máquinas virtuales y contenedores lado a lado en tu propio hardware? Mira los servidores Proxmox.
03Dimensionamiento
La documentación de kubeadm fija el mínimo: 2 GB de memoria en cada máquina y al menos 2 núcleos de procesador en un nodo del plano de control. Cualquier servidor dedicado supera eso con facilidad, así que dimensione según sus cargas de trabajo y planifique tres nodos de plano de control si el clúster debe sobrevivir a la pérdida de uno.
| Rol | Mínimo | Puertos que abrir entre sus nodos |
|---|---|---|
| Plano de control | 2 núcleos, 2 GB de memoria | 6443, 2379-2380, 10250, 10257, 10259 |
| Worker | 2 GB de memoria | 10250, 10256, 30000-32767 |
| Cada nodo | Un nombre de host, una dirección MAC y un UUID de producto únicos | Alcance de red completo hacia los demás nodos |
Un nodo de plano de control y dos workers bastan para aprender y para ejecutar staging. Coloque etcd en servidores con unidades de estado sólido: es sensible a la latencia de escritura en disco, y un disco lento ralentiza cada cambio en el clúster.
Tres nodos de plano de control mantienen a etcd en cuórum cuando uno de ellos se cae. Añada workers para tener capacidad y coloque servidores GPU en el mismo clúster para trabajos de inferencia o codificación, separados de los demás pods con etiquetas y taints.
04Configuración
Este es el orden habitual de trabajo con kubeadm. k3s y RKE2 condensan los pasos 2 y 3 en un único script de instalación, y el resto se mantiene igual.
Elija servidores de la lista siguiente y seleccione una imagen actual de Ubuntu o Debian al pagar. Los servidores en rack llegan unos 30 minutos después de la aprobación; un servidor construido según sus especificaciones tarda de 4 a 24 horas cuando las piezas están disponibles.
Instale un runtime de contenedores como containerd, mantenga los relojes sincronizados y desactive el swap salvo que haya configurado el kubelet para usarlo. Luego instale kubeadm, kubelet y kubectl desde el repositorio de paquetes de Kubernetes.
Ejecute kubeadm init en el primer servidor del plano de control y después la línea kubeadm join que imprime en cada worker. Su kubeconfig está en ese primer servidor.
Los pods no pueden comunicarse hasta que haya un plugin de red. Cilium, Calico y Flannel son las opciones habituales; Cilium y Calico también aplican NetworkPolicy.
Permita los puertos de la tabla anterior solo desde las direcciones de sus propios nodos y mantenga el puerto de la API abierto únicamente para quienes administran el clúster.
El bare metal no tiene balanceador de carga en la nube, así que una herramienta como MetalLB asigna a los Services de tipo LoadBalancer direcciones IPv4 adicionales contratadas con sus servidores. Un controlador de ingress sirve entonces sus sitios en los puertos 80 y 443.
¿Solo necesita Docker? Instale Docker Engine desde el repositorio propio de Docker para su distribución, compruébelo con docker run hello-world y ejecute su stack con Docker Compose. Esa es toda la configuración.
05Servidores
Cada servidor de abajo puede ser un host de Docker o un nodo de un clúster Kubernetes autogestionado. Los precios y las especificaciones provienen directamente del catálogo; abra uno para ver sus opciones y encargarlo.
06Antes de contratar
En esta modalidad nos ocupamos del hardware y de la red, y tú te encargas de todo lo que va del sistema operativo hacia arriba. Aquí es donde está esa línea.
07Preguntas
Normalmente sí, porque no hay nada entre tus pods y el hardware. Una máquina virtual añade un hipervisor en la ruta del procesador, el disco y la red, y a menudo comparte el host con otros clientes. En un servidor dedicado tus contenedores disponen de toda la máquina, y su rendimiento no cambia cuando otra persona se pone a trabajar a fondo.
Sí. Tienes root, así que instalas Docker Engine desde el repositorio de Docker para tu distribución y pones en marcha tus contenedores o una pila de Docker Compose de inmediato. Mucha gente empieza así y añade Kubernetes cuando ya tiene más de un servidor.
No en los servidores de esta página: tú eliges la distribución y administras el clúster. Si prefieres no ocuparte del plano de control, nuestro Kubernetes gestionado lo ejecuta por ti en Nueva York mientras tus servidores dedicados siguen siendo los workers, con root en cada uno.
Un solo servidor puede ejecutar un clúster de un nodo con k3s o kubeadm, lo cual está bien para desarrollo. Para un clúster que siga funcionando cuando falla una máquina, usa tres nodos de plano de control para que etcd mantenga su quórum, más tantos workers como necesiten tus cargas de trabajo.
No hay un balanceador de carga en la nube al que llamar, así que instalas uno dentro del clúster. MetalLB es la opción habitual: asigna a cada Service de tipo LoadBalancer una de las direcciones IPv4 adicionales que contrataste con tus servidores y la anuncia en la red.
No. Nada cuenta el tráfico de un servidor dedicado. Cada uno tiene su propio puerto, de 1 Gbps o 500 Mbps según la línea, y las descargas de imágenes, la replicación y el tráfico de usuarios pasan por él por el mismo precio mensual.
Un servidor que ya está en el rack está listo unos 30 minutos después de que se apruebe tu pedido, con el sistema operativo que elegiste. Un servidor montado según tus especificaciones tarda de 4 a 24 horas cuando tenemos las piezas. La aprobación en sí, el pago y las comprobaciones antifraude van primero y es la parte que varía.
Nuestro chat con IA responde en segundos y puede revisar tu cuenta y tus servidores, y una persona toma el relevo cuando lo pidas. Nosotros arreglamos los problemas de hardware y de red; las cuestiones dentro de tu clúster son tuyas, aunque estaremos encantados de orientarte.
Alquila los servidores por meses, conserva root en cada uno y ejecuta Docker o Kubernetes a tu manera. Sin permanencia y sin tráfico contabilizado.