Jetzt bestellbar · New York
Upstream-Kubernetes, aufgebaut mit RKE2, bei dem API-Server, Scheduler und etcd von uns betrieben werden und jeder Worker-Node ein dedizierter Server ist, den Sie bei uns mieten. Kein Hypervisor unter Ihren Pods, kein Nachbar auf Ihren Kernen, und Sie behalten Root-SSH, Konsole und Rescue-Modus auf jedem Node.
Fragen vor der Bestellung? . Unsere KI antwortet in Sekunden und kann Ihr Konto und Ihre Server prüfen; ein Techniker übernimmt, wann immer Sie es wünschen. Kein Chat? Schreiben Sie uns über die Kontaktseite.
Die Arbeitsteilung
Viele Managed-Kubernetes-Dienste halten die Nodes außerhalb Ihrer Reichweite. Hier verläuft die Grenze an der Control Plane: Alles darüber ist unsere Aufgabe, jede Maschine darunter bleibt Ihre.
Warum die Worker Bare-Metal sind
Ein Pod auf einer Cloud-VM läuft auf einem Gast-Kernel über einem Host-Kernel. Auf einem dedizierten Node gibt es einen Kernel, direkt auf der Hardware, sodass die Kerne und der Speicher, die Sie mieten, Ihren Pods zugutekommen statt einem zweiten Betriebssystem darunter.
Keine fremde Arbeitslast teilt sich die Maschine, ihre Festplatten oder ihre Speicherbandbreite. Ein Benchmark, den Sie am Montag ausführen, wird nicht durch den Batch-Job eines anderen am Freitag zunichte gemacht.
Worker-Server werden pauschal pro Monat abgerechnet, ohne Gebühr pro Gigabyte, das den Cluster verlässt. Die Bereitstellung von Traffic wird nicht zu einer zweiten Rechnung.
Kubernetes ist ein Open-Source-CNCF-Projekt unter der Apache-2.0-Lizenz, und RKE2 betreibt es upstream. Manifeste, die hier laufen, laufen auf jedem konformen Cluster – ein Wechsel kostet Sie also eine Migration, keine Neuentwicklung.
Der Stack
| Schicht | Was sie ist |
|---|---|
| Distribution | RKE2, upstream CNCF-konformes Kubernetes |
| Control Plane | Von uns betrieben: 1 Node für Entwicklung, 3 Nodes für Hochverfügbarkeit |
| Cluster-Zustand | Eingebettetes etcd, alle 6 Stunden gesnapshottet |
| Worker-Nodes | Dedizierte Server auf Ihrem Konto, einzeln aus dem New Yorker Bestand gewählt und so übernommen, wie sie sind, bereits mit Ubuntu 24.04 oder 26.04 (keine Neuinstallation, keine Einrichtungsgebühr); 1 bis 10 pro Bestellung, später bis zu 10 weitere |
| Scheduling | Ein Pool, jeder Node mit dem Label pool=general; weitere Labels und Taints setzen Sie selbst mit kubectl (cluster-admin) |
| Pod-Netzwerk | Cilium, mit durchgesetzter Kubernetes NetworkPolicy; keine Verschlüsselung zwischen den Nodes, verwenden Sie daher TLS oder mTLS in Ihren Anwendungen oder ein Service Mesh, wo der Traffic verschlüsselt werden muss |
| Load Balancer | MetalLB: Ein Service vom Typ LoadBalancer übernimmt eine der zusätzlichen IPv4-Adressen auf Ihren Worker-Servern |
| Node-Netzwerk | Die öffentlichen Adressen der Nodes, mit einer Firewall, die nur die eigenen Nodes des Clusters zulässt; kein privates VLAN |
| Zugriff | Kubeconfig-Download; Root-SSH, Konsole und Rescue-Modus auf jedem Worker |
| Upgrades | Von Ihnen gestartet; zuerst die Control Plane, dann die Nodes einzeln nacheinander |
| Standort | New York |
So ist jeder Cluster aufgebaut, den wir in New York erstellen. Ändert sich eine Schicht, ändert sich auch diese Tabelle.
Worker-Nodes
Eine Bestellung umfasst 1 bis 10 Worker-Server, jeweils aus den sofort verfügbaren New-York-Maschinen ausgewählt, und das Dashboard fügt später weitere hinzu, bis zu insgesamt 10. Jeder Worker gehört zu einem Pool und trägt das Label pool=general. Sie besitzen cluster-admin, daher trennen Sie die GPU-Maschinen von der Web-Ebene mit einem kubectl label und einem kubectl taint.
pool=general hinaus können Sie selbst setzen; wir fügen keine eigenen Scheduling-Regeln hinzu$ 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.0Fragen
Managed. Wir betreiben die Control Plane, einschließlich etcd und dessen Snapshots, und wir führen die Upgrades durch, wenn Sie eines starten. Ihre dedizierten Server treten dem Cluster als Worker-Nodes bei, und Sie müssen die Control Plane nie selbst betreiben.
RKE2, eine CNCF-konforme Distribution, die Upstream-Kubernetes ausliefert. Ihre Manifeste, Helm-Charts und Operatoren funktionieren wie auf jedem anderen konformen Cluster.
Ja. Jeder Worker ist ein dedizierter Server in Ihrem Account, mit Root-SSH, Konsole und Rescue-Modus, genau wie wenn er nicht Teil eines Clusters wäre. Das ist der Hauptunterschied zu den meisten Managed-Kubernetes-Angeboten, bei denen die Nodes für Sie oft verschlossen sind.
MetalLB weist ihnen die zusätzlichen IPv4-Adressen auf Ihren Worker-Servern zu, sodass die Adresse vor Ihrem Service eine ist, die Sie bereits besitzen, statt einer, die wir aus einem gemeinsamen Pool verleihen.
Nein, es gibt kein privates VLAN pro Cluster. Die Nodes erreichen sich gegenseitig über ihre öffentlichen Adressen in unserem Netzwerk, und eine Firewall auf jedem Node lässt nur die eigenen Nodes des Clusters zu. Der Verkehr zwischen den Nodes wird vom Cluster nicht verschlüsselt: Cilium-Netzwerkrichtlinien steuern, welche Pods miteinander kommunizieren dürfen, und für verschlüsselten Verkehr zwischen Diensten nutzen Sie TLS oder mTLS in Ihren Anwendungen oder ein Service Mesh.
Ja. Sie wählen jeden Worker-Server aus den sofort verfügbaren New-York-Maschinen, sodass GPU- und CPU-Server demselben Cluster beitreten können. Sie starten alle in einem Pool mit dem Label pool=general; mit cluster-admin labeln und tainten Sie die GPU-Nodes selbst, und Workloads wählen mit Node-Selectors und Tolerations zwischen ihnen.
Sie bestimmen den Zeitpunkt. Wir aktualisieren zuerst die Control Plane, dann die Worker-Nodes einzeln nacheinander, sodass ein Workload mit mehr als einer Replica weiterhin erreichbar bleibt, während der Cluster auf die neue Version wechselt.
Ja, in New York. Auf der Bestellseite wählen Sie eine Dev- oder HA-Control-Plane und ein bis zehn Worker-Server aus den sofort verfügbaren New-York-Maschinen; der Cluster wird erstellt, sobald die ersten Rechnungen bezahlt sind, und seine Kubeconfig wartet in Ihrem Dashboard.
Wählen Sie eine Control Plane, benennen Sie den Cluster und wählen Sie ein bis zehn Worker-Server. Die Worker kommen genau so, wie sie auf Lager stehen, bereits mit Ubuntu 24.04 oder 26.04, daher entfällt die Einrichtungsgebühr und sie werden direkt nach der Lieferung eingebunden, sobald ihre ersten Rechnungen bezahlt sind; die Kubeconfig finden Sie in Ihrem Dashboard, sobald der Cluster als bereit gemeldet wird.
Möchten Sie Kubernetes lieber selbst betreiben? Siehe Bare Metal für Container. Brauchen Sie eine kleine Maschine statt eines Clusters? Eine Cloud-VPS ist eine KVM-VM; die Seite Dedicated Server listet die Maschinen auf, die ein Worker sein kann.