Bare metal per i container
Kubernetes su bare metal significa che ogni nodo del tuo cluster è un intero server dedicato, senza hypervisor tra i tuoi pod e l'hardware. Primcast noleggia questi server a canone mensile con accesso root e porta senza limiti di traffico, così puoi installare Docker, k3s, RKE2 o kubeadm e gestire il cluster a modo tuo.
Un server già installato in rack viene consegnato circa 30 minuti dopo l'approvazione dell'ordine. Nessun contratto: paghi un mese alla volta.
01Perché il bare metal
I container condividono già un kernel, quindi una macchina virtuale sotto aggiunge un secondo livello che non ti serve a nulla. Su un server dedicato i tuoi carichi di lavoro ottengono direttamente processore, memoria, dischi e scheda di rete.
ANessun livello virtuale
Nessun hypervisor prende una quota del processore o si frappone nel percorso di disco e rete. Ciò che misuri sul nodo è ciò che ottengono i tuoi container, il che rende più facile impostare richieste e limiti.
BUn solo tenant
Nessun altro esegue nulla sul tuo server. Un estraneo indaffarato non può consumare la coda del disco o la larghezza di banda della memoria su cui contava il pod del tuo database, quindi la latenza resta dove l'avevi lasciata.
CFattura fissa
Ogni server include una porta senza limiti di traffico non condivisa, da 1 Gbps o 500 Mbps a seconda della linea. Il pull delle immagini, la replica tra nodi e il traffico verso i tuoi utenti non compaiono mai come addebito per gigabyte.
DControllo totale
Ottieni root su ogni server e puoi reinstallare il sistema dal pannello di controllo senza costi. I server rack e blade dispongono anche di una console browser con controllo dell'alimentazione, per il giorno in cui una modifica di rete ti lascia fuori.
02Scegli il tuo percorso
Parti dal lavoro da fare. Una manciata di servizi su una macchina richiede Docker e nient'altro. Più macchine che devono autoripararsi richiedono Kubernetes, e a quel punto la domanda è chi si occupa del control plane.
| Percorso | Ideale per | Control plane | Dove andare |
|---|---|---|---|
| Docker su un server dedicato | Poche app con Docker Compose, un runner di build, una copia di staging della produzione | Non necessario | Qualsiasi server qui sotto |
| Il tuo cluster Kubernetes | Team che vogliono scegliere la distribuzione, il plugin di rete e le date di aggiornamento | Lo gestisci tu, sui tuoi server | Questa pagina |
| Kubernetes gestito | Team che vogliono kubectl e i propri worker, senza occuparsi di etcd | Lo gestiamo noi; i tuoi server sono i worker | Kubernetes gestito |
Ti serve solo una piccola macchina? Anche un Cloud VPS esegue Docker. Vuoi macchine virtuali e container fianco a fianco sul tuo hardware? Guarda i server Proxmox.
03Dimensionamento
La documentazione di kubeadm fissa il minimo: 2 GB di memoria su ogni macchina e almeno 2 core del processore su un nodo del piano di controllo. Qualsiasi server dedicato supera facilmente questi requisiti, quindi dimensiona in base ai tuoi carichi di lavoro e pianifica tre nodi del piano di controllo se il cluster deve sopravvivere alla perdita di uno di essi.
| Ruolo | Minimo | Porte da aprire tra i nodi |
|---|---|---|
| Piano di controllo | 2 core, 2 GB di memoria | 6443, 2379-2380, 10250, 10257, 10259 |
| Worker | 2 GB di memoria | 10250, 10256, 30000-32767 |
| Ogni nodo | Un hostname, un indirizzo MAC e un UUID del prodotto univoci | Piena raggiungibilità di rete verso gli altri nodi |
Un nodo del piano di controllo e due worker bastano per imparare e per gestire lo staging. Metti etcd su server con unità a stato solido: è sensibile alla latenza di scrittura del disco e un disco lento rallenta ogni modifica nel cluster.
Tre nodi del piano di controllo mantengono etcd in quorum quando uno di essi si guasta. Aggiungi worker per la capacità e inserisci server GPU nello stesso cluster per carichi di inferenza o codifica, tenuti separati dagli altri pod con label e taint.
04Configurazione
Ecco il consueto ordine di lavoro con kubeadm. k3s e RKE2 uniscono i passaggi 2 e 3 in un unico script di installazione, mentre il resto rimane invariato.
Scegli i server dall'elenco qui sotto e seleziona un'immagine Ubuntu o Debian aggiornata al momento del checkout. I server rack arrivano circa 30 minuti dopo l'approvazione; un server costruito secondo le tue specifiche richiede da 4 a 24 ore quando i componenti sono disponibili.
Installa un runtime per container come containerd, mantieni gli orologi sincronizzati e disattiva lo swap a meno che tu non abbia configurato il kubelet per gestirlo. Quindi installa kubeadm, kubelet e kubectl dal repository dei pacchetti di Kubernetes.
Esegui kubeadm init sul primo server del piano di controllo, poi la riga kubeadm join che stampa su ogni worker. Il tuo kubeconfig si trova su quel primo server.
I pod non possono comunicare finché non è installato un plugin di rete. Cilium, Calico e Flannel sono le scelte più comuni; Cilium e Calico applicano anche le NetworkPolicy.
Consenti le porte della tabella qui sopra solo dagli indirizzi dei tuoi nodi e mantieni la porta API aperta solo per chi gestisce il cluster.
Il bare metal non ha un bilanciatore di carico cloud, quindi uno strumento come MetalLB assegna ai servizi di tipo LoadBalancer indirizzi IPv4 aggiuntivi ordinati con i tuoi server. Un controller ingress serve poi i tuoi siti sulle porte 80 e 443.
Ti serve solo Docker? Installa Docker Engine dal repository ufficiale di Docker per la tua distribuzione, verificalo con docker run hello-world ed esegui il tuo stack con Docker Compose. Questa è l'intera configurazione.
05Server
Ogni server qui sotto può essere un host Docker o un nodo in un cluster Kubernetes autogestito. Prezzi e specifiche provengono direttamente dal catalogo; aprine uno per vedere le opzioni e ordinarlo.
06Prima di ordinare
Su questo percorso ci occupiamo noi dell'hardware e della rete, mentre tu gestisci tutto dal sistema operativo in su. Ecco dove passa il confine.
07Domande
Di solito sì, perché nulla si frappone tra i tuoi pod e l'hardware. Una macchina virtuale aggiunge un hypervisor nel percorso di processore, disco e rete e spesso condivide l'host con altri clienti. Su un server dedicato i tuoi container hanno l'intera macchina e le loro prestazioni non cambiano quando qualcun altro è sotto carico.
Sì. Hai i privilegi di root, quindi installi Docker Engine dal repository Docker per la tua distribuzione ed esegui subito i tuoi container o uno stack Docker Compose. Molti iniziano così e aggiungono Kubernetes quando hanno più di un server.
Non sui server di questa pagina: scegli tu la distribuzione e gestisci il cluster da solo. Se preferisci non occuparti del piano di controllo, il nostro Kubernetes gestito lo esegue per te a New York mentre i tuoi server dedicati restano i worker, con root mantenuta su ciascuno.
Un solo server può eseguire un cluster a nodo singolo con k3s o kubeadm, il che va bene per lo sviluppo. Per un cluster che continua a funzionare quando una macchina si guasta, usa tre nodi del piano di controllo affinché etcd mantenga il quorum, più tanti worker quanti ne richiedono i tuoi carichi di lavoro.
Non c'è un bilanciatore di carico cloud da chiamare, quindi ne installi uno nel cluster. MetalLB è la scelta comune: assegna a ogni Service di tipo LoadBalancer uno degli indirizzi IPv4 aggiuntivi che hai ordinato con i tuoi server e lo annuncia sulla rete.
No. Nulla conta il traffico su un server dedicato. Ognuno ha la propria porta, 1 Gbps o 500 Mbps a seconda della linea, e i pull delle immagini, la replica e il traffico degli utenti passano tutti da lì allo stesso prezzo mensile.
Un server già montato in rack è pronto circa 30 minuti dopo l'approvazione dell'ordine, con il sistema operativo che hai scelto. Un server costruito secondo le tue specifiche richiede da 4 a 24 ore quando abbiamo i componenti. L'approvazione stessa, pagamento e controlli antifrode, viene prima ed è la parte che varia.
La nostra chat AI risponde in pochi secondi e può controllare account e server per te, e una persona subentra ogni volta che lo chiedi. Risolviamo i problemi di hardware e rete; le questioni interne al cluster spettano a te, anche se siamo lieti di indicarti la direzione giusta.
Noleggia i server mese per mese, mantieni i privilegi di root su ognuno ed esegui Docker o Kubernetes come preferisci. Nessun contratto, nessun traffico conteggiato.