Disponible para pedir ahora · Nueva York
Kubernetes upstream, construido con RKE2, donde el API server, el scheduler y etcd los operamos nosotros y cada nodo worker es un servidor dedicado que alquilas con nosotros. Sin hipervisor bajo tus pods, sin vecinos en tus núcleos, y conservas SSH root, la consola y el modo de rescate en cada nodo.
¿Dudas antes de pedir? . Nuestra IA responde en segundos y puede consultar tu cuenta y tus servidores; un ingeniero toma el relevo cuando lo pidas. ¿Sin chat? Escríbenos desde la página de contacto.
La división del trabajo
Muchos servicios gestionados de Kubernetes mantienen los nodos fuera de su alcance. Aquí la línea se traza en el plano de control: todo lo que está por encima es nuestro trabajo, cada máquina por debajo sigue siendo suya.
Por qué los workers son bare metal
Un pod en una VM en la nube corre sobre un kernel invitado encima de un kernel anfitrión. En un nodo dedicado hay un solo kernel, sobre el propio hardware, de modo que los núcleos y la memoria que alquilas van a tus pods y no a un segundo sistema operativo por debajo de ellos.
Ninguna carga de trabajo ajena comparte la máquina, sus discos ni su ancho de banda de memoria. Un benchmark que ejecutas el lunes no se ve arruinado por el trabajo por lotes de otra persona el viernes.
Los servidores worker se facturan a una tarifa plana mensual, sin cargo por gigabyte que salga del clúster. Servir tráfico no se convierte en una segunda factura.
Kubernetes es un proyecto de código abierto de la CNCF bajo la licencia Apache 2.0, y RKE2 lo ejecuta en su versión upstream. Los manifiestos que funcionan aquí funcionan en cualquier clúster conforme, de modo que irte te cuesta una migración, no una reescritura.
La pila
| Capa | Qué es |
|---|---|
| Distribución | RKE2, Kubernetes upstream conforme a CNCF |
| Plano de control | Operado por nosotros: 1 nodo para desarrollo, 3 nodos para alta disponibilidad |
| Estado del clúster | etcd integrado, con instantáneas cada 6 horas |
| Nodos worker | Servidores dedicados en tu cuenta, elegidos uno a uno del stock de Nueva York y tomados tal como están, ya con Ubuntu 24.04 o 26.04 (sin reinstalación, sin cargo de configuración); de 1 a 10 por pedido, se pueden añadir más después hasta 10 |
| Planificación | Un solo pool, cada nodo etiquetado pool=general; etiquetas y taints adicionales los defines tú con kubectl (cluster-admin) |
| Red de pods | Cilium, con NetworkPolicy de Kubernetes aplicada; sin cifrado entre nodos, así que usa TLS o mTLS en tus aplicaciones, o una service mesh, donde el tráfico deba ir cifrado |
| Balanceadores de carga | MetalLB: un Service de tipo LoadBalancer toma una de las direcciones IPv4 adicionales de tus servidores worker |
| Red de nodos | Las direcciones públicas de los nodos, con un firewall que solo admite los propios nodos del clúster; sin VLAN privada |
| Acceso | Descarga de kubeconfig; SSH root, consola y modo rescate en cada worker |
| Actualizaciones | Las inicias tú; primero el plano de control, luego los nodos uno a uno |
| Ubicación | Nueva York |
Así se ensambla cada clúster que construimos en Nueva York. Si una capa cambia, esta tabla cambia con ella.
Nodos de trabajo
Un pedido incluye de 1 a 10 servidores de trabajo, cada uno elegido entre las máquinas de Nueva York listas ahora mismo, y el panel añade más después hasta un total de 10. Cada nodo de trabajo se une a un pool y lleva la etiqueta pool=general. Usted tiene cluster-admin, así que separar las máquinas GPU del nivel web está a un kubectl label y un kubectl taint de distancia.
pool=general son suyos para definir; nosotros no añadimos reglas de programación propias$ kubectl label node k8s-250123-w3 gpu=true
$ kubectl taint node k8s-250123-w3 gpu=true:NoSchedule
apiVersion: v1
kind: Pod
metadata: name: inference
spec: nodeSelector: gpu: "true" tolerations: - key: gpu operator: Exists effect: NoSchedule containers: - name: model image: ghcr.io/example/model:1.0Preguntas
Gestionado. Nosotros operamos el plano de control, incluido etcd y sus snapshots, y dirigimos las actualizaciones cuando tú las inicias. Tus servidores dedicados se unen al clúster como nodos worker y nunca tienes que operar el plano de control por tu cuenta.
RKE2, una distribución conforme a CNCF que incluye Kubernetes upstream. Tus manifiestos, charts de Helm y operadores funcionan igual que en cualquier otro clúster conforme.
Sí. Cada worker es un servidor dedicado en tu cuenta, con SSH root, consola y modo de rescate, exactamente igual que cuando no forma parte de un clúster. Esa es la principal diferencia con la mayoría de Kubernetes gestionados, donde los nodos suelen estar cerrados para ti.
MetalLB les asigna las direcciones IPv4 adicionales de tus servidores worker, de modo que la dirección delante de tu Service es una que ya posees en lugar de una que prestamos de un pool compartido.
No, no hay una VLAN privada por clúster. Los nodos se comunican entre sí a través de sus direcciones públicas en nuestra red, y un firewall en cada nodo solo admite a los propios nodos del clúster. El tráfico entre nodos no está cifrado por el clúster: las políticas de red de Cilium controlan qué pods pueden comunicarse, y para tráfico cifrado entre servicios usa TLS o mTLS en tus aplicaciones, o una service mesh.
Sí. Tú eliges cada servidor worker entre las máquinas de Nueva York disponibles ahora mismo, así que los servidores GPU y CPU pueden unirse al mismo clúster. Todos comienzan en un pool etiquetado pool=general; con cluster-admin tú mismo etiquetas y aplicas taints a los nodos GPU, y las cargas de trabajo eligen entre ellos con node selectors y tolerations.
Tú decides cuándo. Primero actualizamos el plano de control y después los nodos worker uno a uno, de modo que una carga de trabajo con más de una réplica sigue sirviendo mientras el clúster pasa a la nueva versión.
Sí, en Nueva York. En la página de pedido eliges un plano de control Dev o HA y de uno a diez servidores worker entre las máquinas de Nueva York disponibles ahora mismo; el clúster se crea una vez pagadas las primeras facturas y su kubeconfig te espera en el panel.
Elige un plano de control, ponle nombre al clúster y selecciona de uno a diez servidores worker. Los workers se entregan tal como están en stock, ya con Ubuntu 24.04 o 26.04, así que no hay cuota de instalación y se unen justo después de la entrega, una vez pagadas sus primeras facturas; el kubeconfig aparece en tu panel en cuanto el clúster notifica que está listo.
¿Prefieres gestionar Kubernetes tú mismo? Consulta bare metal para contenedores. ¿Necesitas una sola máquina pequeña en lugar de un clúster? Un Cloud VPS es una máquina virtual KVM; la página de servidores dedicados enumera las máquinas que puede ser un worker.