Orderable now · New York
Upstream Kubernetes, built with RKE2, where the API server, the scheduler and etcd are ours to operate and every worker node is a dedicated server you rent from us. No hypervisor under your pods, no neighbour on your cores, and you keep root SSH, the console and rescue mode on each node.
Questions before you order? . Our AI answers in seconds and can check your account and servers; an engineer takes over whenever you ask. No chat? Write to us from the contact page.
The division of labour
Many managed Kubernetes services keep the nodes out of your reach. Here the line is drawn at the control plane: everything above it is our job, every machine below it stays yours.
Why the workers are bare metal
A pod on a cloud VM runs on a guest kernel on top of a host kernel. On a dedicated node there is one kernel, on the hardware itself, so the cores and memory you rent go to your pods rather than to a second operating system underneath them.
Nobody else's workload shares the machine, its disks or its memory bandwidth. A benchmark you run on Monday is not undone by somebody else's batch job on Friday.
Worker servers are billed flat by the month, with no charge per gigabyte leaving the cluster. Serving traffic does not turn into a second invoice.
Kubernetes is an open-source CNCF project under the Apache 2.0 licence, and RKE2 runs it upstream. Manifests that run here run on any conformant cluster, so leaving costs you a migration, not a rewrite.
The stack
| Layer | What it is |
|---|---|
| Distribution | RKE2, upstream CNCF-conformant Kubernetes |
| Control plane | Operated by us: 1 node for development, 3 nodes for high availability |
| Cluster state | Embedded etcd, snapshotted every 6 hours |
| Worker nodes | Dedicated servers on your account, picked one by one from New York stock and taken as they stand, already on Ubuntu 24.04 or 26.04 (no reinstall, no setup fee); 1 to 10 per order, more added later up to 10 |
| Scheduling | One pool, every node labelled pool=general; further labels and taints set by you with kubectl (cluster-admin) |
| Pod network | Cilium, with Kubernetes NetworkPolicy enforced; no encryption between nodes, so use TLS or mTLS in your apps, or a service mesh, where traffic must be encrypted |
| Load balancers | MetalLB: a Service of type LoadBalancer takes one of the extra IPv4 addresses on your worker servers |
| Node network | The nodes' public addresses, with a firewall that admits only the cluster's own nodes; no private VLAN |
| Access | Kubeconfig download; root SSH, console and rescue mode on each worker |
| Upgrades | Started by you; control plane first, then nodes one at a time |
| Location | New York |
This is how every cluster we build in New York is put together. If a layer changes, this table changes with it.
Worker nodes
An order takes 1 to 10 worker servers, each one picked from the New York machines ready now, and the dashboard adds more later up to 10 in all. Every worker joins one pool and carries the label pool=general. You hold cluster-admin, so separating the GPU machines from the web tier is a kubectl label and a kubectl taint away.
pool=general are yours to set; we add no scheduling rules of our own$ 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.0Questions
Managed. We run the control plane, including etcd and its snapshots, and we drive the upgrades when you start one. Your dedicated servers join the cluster as worker nodes, and you never have to operate the control plane yourself.
RKE2, a CNCF-conformant distribution that ships upstream Kubernetes. Your manifests, Helm charts and operators work as they would on any other conformant cluster.
Yes. Each worker is a dedicated server on your account, with root SSH, the console and rescue mode, exactly as when it is not part of a cluster. That is the main difference from most managed Kubernetes, where the nodes are often closed to you.
MetalLB assigns them the extra IPv4 addresses on your worker servers, so the address in front of your Service is one you already hold rather than one we lend from a shared pool.
No, there is no private VLAN per cluster. The nodes reach each other over their public addresses on our network, and a firewall on every node admits only the cluster's own nodes. Traffic between nodes is not encrypted by the cluster: Cilium network policies control which pods may talk, and for encrypted traffic between services use TLS or mTLS in your applications, or a service mesh.
Yes. You pick each worker server from the New York machines ready now, so GPU and CPU servers can join the same cluster. They all start in one pool labelled pool=general; with cluster-admin you label and taint the GPU nodes yourself, and workloads choose between them with node selectors and tolerations.
You choose when. We upgrade the control plane first, then the worker nodes one at a time, so a workload running more than one replica keeps serving while the cluster moves to the new version.
Yes, in New York. On the order page you choose a Dev or HA control plane and one to ten worker servers from the New York machines ready now; the cluster is built once the first invoices are paid, and its kubeconfig waits in your dashboard.
Pick a control plane, name the cluster and choose one to ten worker servers. The workers come exactly as they stand in stock, already on Ubuntu 24.04 or 26.04, so there is no setup fee and they join right after delivery, once their first invoices are paid; the kubeconfig is in your dashboard as soon as the cluster reports ready.
Would rather run Kubernetes yourself? See bare metal for containers. Need one small machine rather than a cluster? A Cloud VPS is a KVM virtual machine; the dedicated servers page lists the machines a worker can be.