Ordinabile ora · New York
Kubernetes upstream, costruito con RKE2, dove il server API, lo scheduler ed etcd li gestiamo noi e ogni nodo worker è un server dedicato che noleggi da noi. Nessun hypervisor sotto i tuoi pod, nessun vicino sui tuoi core, e mantieni SSH root, la console e la modalità rescue su ogni nodo.
Domande prima di ordinare? . La nostra IA risponde in pochi secondi e può controllare il tuo account e i tuoi server; un tecnico subentra ogni volta che lo chiedi. Niente chat? Scrivici dalla pagina contatti.
La divisione del lavoro
Molti servizi Kubernetes gestiti tengono i nodi fuori dalla tua portata. Qui il confine è tracciato al piano di controllo: tutto ciò che sta sopra è compito nostro, ogni macchina al di sotto resta tua.
Perché i worker sono bare metal
Un pod su una VM cloud gira su un kernel guest sopra un kernel host. Su un nodo dedicato c'è un solo kernel, direttamente sull'hardware, quindi i core e la memoria che noleggi vanno ai tuoi pod invece che a un secondo sistema operativo sotto di loro.
Nessun carico di lavoro altrui condivide la macchina, i suoi dischi o la sua larghezza di banda di memoria. Un benchmark eseguito lunedì non viene vanificato dal job batch di qualcun altro venerdì.
I server worker vengono fatturati a canone mensile fisso, senza alcun costo per gigabyte in uscita dal cluster. Servire traffico non si trasforma in una seconda fattura.
Kubernetes è un progetto open-source della CNCF sotto licenza Apache 2.0, e RKE2 lo esegue upstream. I manifest che girano qui girano su qualsiasi cluster conforme, quindi andarsene ti costa una migrazione, non una riscrittura.
Lo stack
| Livello | Che cos'è |
|---|---|
| Distribuzione | RKE2, Kubernetes upstream conforme a CNCF |
| Piano di controllo | Gestito da noi: 1 nodo per lo sviluppo, 3 nodi per l'alta disponibilità |
| Stato del cluster | etcd integrato, con snapshot ogni 6 ore |
| Nodi worker | Server dedicati sul tuo account, scelti uno a uno dallo stock di New York e presi così come sono, già su Ubuntu 24.04 o 26.04 (nessuna reinstallazione, nessun costo di configurazione); da 1 a 10 per ordine, altri aggiunti in seguito fino a 10 |
| Pianificazione | Un unico pool, ogni nodo etichettato pool=general; ulteriori etichette e taint impostati da te con kubectl (cluster-admin) |
| Rete dei pod | Cilium, con NetworkPolicy di Kubernetes applicate; nessuna crittografia tra i nodi, quindi usa TLS o mTLS nelle tue applicazioni, oppure un service mesh, dove il traffico deve essere crittografato |
| Bilanciatori di carico | MetalLB: un Service di tipo LoadBalancer prende uno degli indirizzi IPv4 aggiuntivi sui tuoi server worker |
| Rete dei nodi | Gli indirizzi pubblici dei nodi, con un firewall che ammette solo i nodi del cluster stesso; nessuna VLAN privata |
| Accesso | Download del kubeconfig; SSH root, console e modalità rescue su ogni worker |
| Aggiornamenti | Avviati da te; prima il piano di controllo, poi i nodi uno alla volta |
| Posizione | New York |
È così che viene assemblato ogni cluster che costruiamo a New York. Se un livello cambia, questa tabella cambia con esso.
Nodi worker
Un ordine richiede da 1 a 10 server worker, ciascuno scelto tra le macchine di New York già pronte, e la dashboard ne aggiunge altri in seguito fino a 10 in totale. Ogni worker entra in un pool e porta l'etichetta pool=general. Hai il ruolo cluster-admin, quindi separare le macchine GPU dal livello web è questione di un kubectl label e un kubectl taint.
pool=general li decidi tu; non aggiungiamo regole di scheduling nostre$ 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.0Domande
Gestito. Gestiamo noi il piano di controllo, incluso etcd e i suoi snapshot, e guidiamo gli aggiornamenti quando ne avvii uno. I tuoi server dedicati si uniscono al cluster come nodi worker e non devi mai occuparti tu del piano di controllo.
RKE2, una distribuzione conforme alla CNCF che fornisce Kubernetes upstream. I tuoi manifest, le chart Helm e gli operator funzionano come su qualsiasi altro cluster conforme.
Sì. Ogni worker è un server dedicato sul tuo account, con SSH root, console e modalità rescue, esattamente come quando non fa parte di un cluster. Questa è la differenza principale rispetto alla maggior parte dei Kubernetes gestiti, dove spesso i nodi non ti sono accessibili.
MetalLB assegna loro gli indirizzi IPv4 aggiuntivi sui tuoi server worker, quindi l'indirizzo davanti al tuo Service è uno che già possiedi, non uno che prestiamo noi da un pool condiviso.
No, non c'è una VLAN privata per cluster. I nodi si raggiungono tra loro tramite i loro indirizzi pubblici sulla nostra rete e un firewall su ogni nodo ammette solo i nodi del cluster stesso. Il traffico tra i nodi non è cifrato dal cluster: le network policy di Cilium controllano quali pod possono comunicare e, per il traffico cifrato tra i servizi, usa TLS o mTLS nelle tue applicazioni oppure un service mesh.
Sì. Scegli ogni server worker tra le macchine di New York pronte subito, quindi server GPU e CPU possono unirsi allo stesso cluster. Partono tutti in un pool etichettato pool=general; con cluster-admin etichetti e applichi i taint ai nodi GPU da solo, e i carichi di lavoro scelgono tra loro con node selector e tolerations.
Decidi tu quando. Aggiorniamo prima il piano di controllo, poi i nodi worker uno alla volta, così un carico di lavoro con più di una replica continua a servire mentre il cluster passa alla nuova versione.
Sì, a New York. Nella pagina d'ordine scegli un piano di controllo Dev o HA e da uno a dieci server worker tra le macchine di New York pronte subito; il cluster viene creato una volta pagate le prime fatture e il suo kubeconfig ti aspetta nella dashboard.
Scegli un piano di controllo, assegna un nome al cluster e seleziona da uno a dieci server worker. I worker arrivano esattamente come sono a magazzino, già su Ubuntu 24.04 o 26.04, quindi non ci sono costi di attivazione e si uniscono subito dopo la consegna, una volta pagate le prime fatture; il kubeconfig è nella tua dashboard non appena il cluster risulta pronto.
Preferisci gestire Kubernetes da solo? Vedi bare metal per container. Ti serve una singola macchina piccola invece di un cluster? Un Cloud VPS è una macchina virtuale KVM; la pagina dei server dedicati elenca le macchine che un worker può essere.