Decidere quanti cluster creare

I tuoi utenti hanno meno probabilità di riscontrare tempi di inattività quando distribuisci le tue applicazioni tra più nodi di lavoro, zone e cluster. Le funzionalità integrate, come il bilanciamento del carico e l'isolamento, aumentano la resilienza nei confronti di potenziali errori con host, reti o applicazioni.

Il numero di cluster da creare dipende dal carico di lavoro, dalle politiche e dalle normative aziendali, dai requisiti di business, dagli accordi sul livello di servizio stipulati con i clienti, dalle risorse che si vogliono spendere e da ciò che si vuole fare con le risorse di calcolo.

• Cluster multipli: i cluster multipli sono generalmente più complessi da gestire, ma possono aiutarti a raggiungere obiettivi importanti come quelli riportati di seguito.

  • Conformarsi alle politiche di sicurezza che ti richiedono l'isolamento dei carichi di lavoro.
  • Verificare in che modo viene eseguita la tua applicazione in una versione diversa di Kubernetes o di altri software cluster quale Calico.
  • Ottenere prestazioni più elevate per gli utenti di aree geografiche diverse.
  • Semplificate l'accesso degli utenti per controllare l'accesso all'interno di un cluster configurando l'accesso a livello di istanza del cluster invece di personalizzare e gestire più criteri RBAC a livello di namespace.
  • Ridurre il numero di nodi lavoratori. La larghezza di banda della rete sulle macchine virtuali in scala è di circa 1000 Mbps. Se hai bisogno di centinaia di nodi di lavoro in un cluster, puoi suddividere la configurazione in più cluster con un numero inferiore di nodi oppure ordinare nodi bare metal.
  • Consentire un numero maggiore di integrazioni di servizi, ad esempio più di 5.000 servizi.
  • Fornire una maggiore disponibilità a un'applicazione. Analogamente all'utilizzo di 3 zone nei cluster multizona, è possibile garantire una maggiore disponibilità dell'applicazione configurando tre cluster distribuiti su zone diverse.
  • Riducete i costi acquistando macchinari più piccoli in grado di gestire il vostro carico di lavoro.

• Un cluster con più nodi worker: Un numero inferiore di cluster può aiutare a ridurre l'impegno operativo e i costi per cluster per le risorse fisse. Invece di creare più cluster, è possibile aggiungere pool di lavoratori a un cluster per ottenere diversi tipi di risorse di calcolo disponibili per i componenti di app e servizi. Quando sviluppi l'applicazione, le risorse che quest'ultima utilizza si trovano nella stessa zona, o strettamente connesse in una multizona, cosicché tu possa formulare ipotesi sulla latenza, sulla larghezza di banda o sugli errori correlati. Tuttavia, quando si dispone di un solo cluster, diventa ancora più importante organizzare il cluster utilizzando spazi dei nomi, quote di risorse ed etichette.

Determinare il numero di sedi necessarie

Un cluster può distribuire le repliche tra i nodi worker in un'unica posizione o tra più posizioni. Questa scelta può influenzare i tipi di cluster disponibili nella sezione successiva.

La distribuzione del carico di lavoro in tre zone garantisce un'elevata disponibilità dell'applicazione nel caso in cui una zona non sia disponibile. È necessario che i tuoi nodi di lavoro siano distribuiti uniformemente su tutte e tre le zone di disponibilità per soddisfare lo SLA (service level agreement) IBM Cloud per la configurazione HA.

Un malfunzionamento della zona riguarda tutti gli host di calcolo fisici e l'archiviazione NFS. I malfunzionamenti includono interruzioni di alimentazione, raffreddamento, collegamento in rete o di archiviazione e disastri naturali, come inondazioni, terremoti e uragani. Per proteggersi da un guasto di zona, è necessario disporre di cluster in due zone diverse, il cui carico è bilanciato da un bilanciatore di carico esterno, creare un cluster in una posizione multizona, che distribuisce il master tra le zone, oppure considerare la possibilità di creare un secondo cluster in un'altra zona.

Selezionare un tipo di cluster

I livelli di isolamento e i profili del nodo di lavoro a tua disposizione dipendono dalla piattaforma del contenitore, dal tipo di cluster, dal provider dell'infrastruttura che vuoi utilizzare e dall'ubicazione IBM Cloud Kubernetes Service in cui vuoi creare il tuo cluster. È possibile scegliere tra cluster classici, VPC o Satellite. Il tipo di cluster di cui hai bisogno dipende dalle decisioni che hai preso riguardo al numero di cluster e alle loro ubicazioni.

{: caption="standardOpzioni hardware per i nodi worker in un " caption-side="bottom"} standard

Cluster VPC

I nodi di lavoro vengono configurati come istanze di server virtuali sull'infrastruttura VPC. Il VPC è il tipo di infrastruttura consigliato per i nuovi cluster. Garantisce l'isolamento di rete per impostazione predefinita e supporta le più recenti funzionalità di IBM Cloud Kubernetes Service, tra cui gli host dedicati e la sicurezza predefinita.

Satellite cluster

I nodi di lavoro vengono configurati sulla propria infrastruttura, compreso l'hardware in loco o le macchine virtuali presso altri fornitori di servizi cloud quali AWS, Azure e GCP. Utilizza Satellite quando devi eseguire cluster gestiti d IBM Cloud e al di fuori dei data center di IBM Cloud.

Cluster classici

I nodi di lavoro vengono configurati su macchine virtuali o bare metal all’interno dell’infrastruttur IBM Cloud e classica. Utilizza Classic se hai bisogno di nodi di lavoro bare metal, opzioni di storage definito dal software (SDS) o connessioni a risorse dell'infrastruttura classica esistente.

Selezionare un sistema operativo per il cluster

I sistemi operativi disponibili dipendono dal tipo di cluster scelto.

Ubuntu 24

Per ulteriori informazioni, consultare le note di rilascio Ubuntu 24.04. Si noti che con Ubuntu 24, l'NTP utilizza timesyncd e i relativi comandi potrebbero essere aggiornati.

Stai passando a un nuovo sistema operativo? Vedere Migrazione a una nuova versione di Ubuntu.

Definire una strategia di denominazione dei cluster

Considera la possibilità di assegnare ai cluster nomi univoci tra i gruppi di risorse e le regioni nel tuo account per evitare conflitti di denominazione. Non è possibile rinominare un cluster dopo la sua creazione.

Decidere il numero di nodi worker per ogni cluster

Il livello di disponibilità configurato per il cluster influisce sulla copertura prevista dai termini del contratto di servizio(SLA)relativo al servizio HA(IBM Cloud). Ad esempio, per beneficiare della copertura HA completa prevista dai termini dello SLA, è necessario configurare un cluster multizona con un totale di almeno 6 nodi di lavoro, due nodi di lavoro per zona, distribuiti in modo uniforme su tre zone.

Il numero totale di nodi di lavoro in un cluster determina la capacità di calcolo disponibile alle tue applicazioni nel cluster. È possibile proteggere la propria configurazione in caso di guasto di un nodo di lavoro configurando più nodi di lavoro nel proprio cluster. I guasti dei nodi di lavoro possono includere interruzioni a livello hardware, quali problemi di alimentazione, raffreddamento o rete, nonché problemi relativi all’ VM o stesso.

• Cluster multizona Classic VPC: Prevedere almeno due nodi di lavoro per zona, per un totale di sei nodi distribuiti su tre zone. Inoltre, pianifica una capacità totale del cluster pari ad almeno il 150% della capacità richiesta da tuo carico di lavoro totale in modo che, se una zona diventa inattiva, disponi delle risorse necessarie per mantenere il carico di lavoro.

• Cluster a zona singola: prevedere almeno tre nodi di lavoro nel cluster. Inoltre, ti conviene disporre, all'interno del cluster, di una capacità di memoria e CPU equivalente a un nodo supplementare. Se le tue app richiedono meno risorse rispetto a quelle disponibili sul nodo di lavoro, potresti riuscire a limitare il numero di pod distribuiti su un singolo nodo di lavoro.

Tenete presente:

• È possibile provare l'autoscaler del cluster per essere sicuri di avere sempre abbastanza nodi worker per coprire il carico di lavoro.
• Kubernetes limita il numero massimo di nodi di lavoro che puoi avere in un cluster. Per ulteriori informazioni, consulta le quote relative ai nodi di lavoro e ai pod.

Selezionare i gusti dei nodi worker

Un nodo di lavoro è un’ VM e che gira su hardware fisico. Un profilo del nodo di lavoro descrive le risorse di calcolo, ad esempio CPU, memoria e capacità disco che ottieni quando esegui il provisioning del tuo nodo di lavoro. I nodi di lavoro dello stesso profilo sono raggruppati in pool di lavoro.

Durante la scelta del tipo di cluster, si è già pensato a come la posizione del nodo worker e il tipo di macchina influiscano sulla decisione. Nella scelta dei nodi worker, considerare quanto segue.

• Tenancy: A seconda del livello di isolamento hardware di cui avete bisogno, i nodi worker virtuali possono essere impostati come condivisi da più IBM clienti (multi tenancy) o dedicati solo a voi (single tenancy). Le macchine bare metal sono sempre configurate come dedicate. Quando devi scegliere tra nodi condivisi e dedicati, ti consigliamo di rivolgerti all'ufficio legale per valutare il livello di isolamento dell'infrastruttura e di conformità richiesto dall'ambiente della tua applicazione.

  • Condivise: le risorse fisiche, quali la CPU e la memoria, sono condivise tra tutte le macchine virtuali distribuite sullo stesso hardware fisico. Per assicurare che ogni macchina virtuale possa essere eseguita indipendentemente, un monitoraggio della macchina virtuale, conosciuto anche come hypervisor, divide le risorse fisiche in entità isolate e le alloca come risorse dedicate a una macchina virtuale (isolamento hypervisor). I nodi condivisi sono generalmente più economici dei nodi dedicati perché i costi dell'hardware sottostante sono condivisi tra più clienti.
  • Dedicato: Tutte le risorse fisiche sono dedicate solo a voi. Puoi distribuire più nodi di lavoro come macchine virtuali allo stesso host fisico. In modo analogo alla configurazione a più tenant, l'hypervisor assicura che ogni nodo di lavoro ottenga la propria quota di risorse fisiche disponibili.

• Tipo di macchina: è possibile scegliere tra diversi tipi di macchina.

  • Macchine virtuali: Per una maggiore flessibilità, tempi di provisioning più rapidi, funzioni di scalabilità automatica e un prezzo più conveniente, utilizzate le macchine virtuali. Puoi utilizzare le VM per casi di utilizzo più generali, quali gli ambienti di sviluppo e test, di preparazione e di produzione, i microservizi e le applicazioni di business. Tuttavia, ciò comporta un compromesso in termini di prestazioni.

  • Macchine bare metal (fisiche): se hai bisogno di elaborazione ad alte prestazioni per carichi di lavoro che richiedono un uso intensivo di dati o di RAM, valuta la possibilità di creare cluster con nodi di lavoro bare metal. Poiché hai il pieno controllo dell'isolamento e del consumo di risorse per i tuoi carichi di lavoro, puoi utilizzare le macchine bare metal per ottenere la conformità HIPAA e PCI per il tuo ambiente. Bare metal ti dà accesso diretto alle risorse fisiche sulla macchina, come la memoria o la CPU. Questa configurazione elimina l'hypervisor della macchina virtuale che assegna risorse fisiche alle macchine virtuali eseguite sull'host. Al contrario, tutte le risorse di una macchina bare metal sono dedicate esclusivamente al worker, quindi non devi preoccuparti che dei “vicini rumorosi” condividano le risorse o rallentino le prestazioni. I profili fisici hanno più archiviazione locale rispetto a quelli virtuali e alcuni dispongono di RAID per aumentare la disponibilità dei dati. Lo spazio di archiviazione locale sul nodo di lavoro è destinato esclusivamente all'elaborazione a breve termine; i dischi primario e ausiliario vengono cancellati quando si aggiorna o si ricarica il nodo di lavoro. Sono disponibili operatori bare metal sia per i cluster classici che per le configurazioni bare metal VPC.

    La fatturazione dei nodi di lavoro bare metal varia a seconda del tipo di infrastruttura. I server bare metal classici vengono fatturati mensilmente. Se si disattiva un server bare metal classico prima della fine del mese, il costo verrà addebitato fino alla fine di quel mese. Dopo aver effettuato l'ordine o annullato un server bare metal classico, la procedura viene completata manualmente nel tuo account dell'infrastruttura IBM Cloud; pertanto, il completamento dell'operazione potrebbe richiedere più di un giorno lavorativo. I server bare metal VPC vengono fatturati su base oraria senza alcun periodo minimo di impegno.

  • Macchine SDS: I gusti di storage definito dal software (SDS) hanno dischi grezzi aggiuntivi per l'archiviazione fisica locale. A differenza del disco locale primario e di quello ausiliario, questi dischi grezzi non vengono cancellati durante l'aggiornamento o il ricaricamento di un nodo di lavoro. Poiché i dati hanno la stessa ubicazione del nodo di calcolo, le macchine SDS sono adatte per i carichi di lavoro ad alte prestazioni. Le varianti di storage definito dal software sono disponibili solo per i cluster classici e non sono supportate nei cluster VPC.

    Poiché hai il pieno controllo dell'isolamento e del consumo di risorse per i tuoi carichi di lavoro, puoi utilizzare le macchine SDS per ottenere la conformità HIPAA e PCI per il tuo ambiente.

    Di norma utilizzi le macchine SDS nei seguenti casi: * Se si utilizza un componente aggiuntivo SDS come Portworx, utilizzare una macchina SDS. * Se la tua app è un'applicazione StatefulSet che richiede spazio di archiviazione locale, puoi utilizzare macchine SDS e configurare volumi persistenti locali c Kubernetes. * Se hai applicazioni personalizzate che richiedono ulteriore archiviazione locale non elaborata.

• Costo: in generale, i carichi di lavoro intensivi sono più adatti all'esecuzione su macchine fisiche bare metal, mentre per attività di test e sviluppo a costi contenuti è possibile optare per macchine virtuali su hardware condiviso o dedicato.

• Localizzazione: Decidere in quali località si vuole avere un cluster. Il luogo in cui lo si desidera potrebbe anche indicare il numero di cluster o il tipo di cluster di cui si ha bisogno. Ad esempio, se si sa che la sede deve essere a Montreal, questo aiuta a restringere la scelta. Verificate le sedi disponibili.

• Dimensioni: i nodi più grandi possono risultare più convenienti rispetto a quelli più piccoli, in particolare per i carichi di lavoro progettati per ottenere una maggiore efficienza quando vengono elaborati su una macchina ad alte prestazioni. Tuttavia, se un nodo di lavoro di grandi dimensioni smette di funzionare, è necessario assicurarsi che il cluster disponga di capacità sufficiente per riprogrammare in modo sicuro tutti i pod del carico di lavoro su altri nodi di lavoro del cluster. I nodi lavoratori più piccoli possono aiutarvi a scalare in modo sicuro. Scopri di più sulla capacità.

• GPU: è possibile utilizzare una macchina GPU per accelerare il tempo di elaborazione richiesto dai carichi di lavoro ad alta intensità di calcolo, come l'intelligenza artificiale, l'apprendimento automatico, l'inferenza e altro ancora.

• Archiviazione: ogni VM è dotato di un disco integrato per l'archiviazione delle informazioni necessarie al funzionamento dell' VM, quali il file system del sistema operativo, il runtime del container e l' kubelet. L'archiviazione locale sul nodo di lavoro è solo per l'elaborazione a breve termine e i dischi di archiviazione vengono cancellati quando elimini, ricarichi, sostituisci o aggiorni il nodo di lavoro. Inoltre, l'infrastruttura classica e VPC sono diverse nella configurazione del disco.

  • VM classiche: le VM classiche hanno due dischi collegati. Il disco di archiviazione principale dispone di 25 GB per il file system del sistema operativo, mentre il disco di archiviazione ausiliario dispone di 100 GB per i dati quali il runtime dei container e l' kubelet. Per garantire l'affidabilità, i volumi di archiviazione primari e ausiliari sono dischi locali anziché una rete di archiviazione (SAN). I vantaggi dell'affidabilità includono una velocità di elaborazione più elevata durante la serializzazione dei byte sul disco locale e una riduzione del danneggiamento del file system dovuto a errori di rete. Il disco ausiliario è crittografato per impostazione predefinita.
  • VM di calcolo VPC: le VM VPC hanno un disco primario che è un volume di archiviazione blocchi collegato tramite la rete. Il livello di archiviazione non è separato dagli altri livelli di rete e sia il traffico di rete che di archiviazione vengono instradati sulla stessa rete. Il disco di archiviazione primario viene utilizzato per archiviare i dati come il file system SO, il runtime del contenitore e kubelet e viene crittografato per impostazione predefinita. Per i cluster VPC, è anche possibile eseguire il provisioning di un disco secondario sui nodi worker. Questo disco opzionale è stato configurato nel tuo account ed è visibile nella console VPC. Gli addebiti per questi dischi sono separati dal costo di ciascun lavoratore e figurano come una voce diversa sulla fattura. Anche questi volumi secondari vengono conteggiati ai fini del raggiungimento della quota del tuo account. Per evitare le evacuazioni predefinite dei pod, il 10% del disco dati di Kubernetes (disco ausiliario nel classico, disco di avvio primario nel VPC) è riservato ai componenti del sistema.

  In un'applicazione con stato, i dati svolgono un ruolo importante per mantenere operativa la tua applicazione. Assicurati che i tuoi dati siano altamente disponibili in modo da poterli recuperare in caso di malfunzionamento. In IBM Cloud Kubernetes Service, puoi scegliere tra diverse opzioni per conservare i tuoi dati. Ad esempio, puoi eseguire il provisioning dell'archiviazione NFS utilizzando i volumi persistenti nativi di Kubernetes o memorizzare i tuoi dati utilizzando un servizio di database IBM Cloud. Per ulteriori informazioni, consultare la sezione " Pianificazione dei dati ad alta disponibilità ".

  Scegli un modello o un tipo di macchina con la configurazione di archiviazione adeguata al tuo carico di lavoro. Alcuni profili hanno una combinazione delle seguenti configurazioni di dischi e archiviazione. Ad esempio, alcuni profili possono avere un disco primario SATA con un disco secondario SSD raw.

Per un elenco dei gusti disponibili, consultare i gusti VPC o i gusti classici.

Determinare la capacità dei nodi worker per le risorse

Per ottenere il massimo dalle prestazioni del nodo worker, è necessario considerare quanto segue durante l'impostazione delle risorse:

• Considerate le attività dell'applicazione: iniziate ad allineare le dimensioni dell'applicazione con la capacità di uno dei nodi worker disponibili. Considera anche aspetti quali il fatto che la tua app scarichi immagini di grandi dimensioni o in numero elevato, poiché queste possono occupare spazio di archiviazione locale sul nodo di lavoro.

• Mantieni la potenza del tuo core: ogni macchina dispone di un certo numero di core. A seconda del carico di lavoro della tua applicazione, configura un limite per il numero di pod per core, ad esempio 10.

• Evita il sovraccarico dei nodi: mantieni il tuo nodo worker a circa il 75% della capacità, in modo da lasciare spazio ad altri pod che potrebbero dover essere pianificati. Se le tue applicazioni richiedono più risorse di quelle disponibili sul tuo nodo di lavoro, utilizza un profilo di nodo di lavoro differente in grado di soddisfare questi requisiti. A seconda del carico di lavoro della tua applicazione, imposta un limite per il numero di pod per nodo, ad esempio 40.

• Scegliere i servizi: Quante integrazioni di servizi avete deciso di includere quando avete pensato a quanti cluster creare? Questi servizi integrati e componenti aggiuntivi possono avviare pod che consumano risorse del cluster e incidono su di esse.

• Repliche della tua applicazione: per determinare il numero di nodi di lavoro desiderati, puoi anche valutare quante repliche della tua applicazione vuoi eseguire. Ad esempio, se sai che il tuo carico di lavoro richiede 32 core CPU e prevedi di eseguire 16 repliche della tua applicazione, ogni pod di replica necessita di 2 core CPU. Se desideri eseguire un solo pod dell'applicazione per ciascun nodo di lavoro, puoi ordinare un numero adeguato di nodi di lavoro affinché il tuo tipo di cluster possa supportare questa configurazione.

• Lasciare spazio ai requisiti di runtime: I nodi worker devono riservare determinate quantità di risorse di CPU e memoria per eseguire i componenti necessari, come il sistema operativo o il runtime del container.

  La capacità riservata e le istanze riservate non sono supportate.

Scegliere il numero di spazi dei nomi da creare all'interno del cluster

Configura più spazi dei nomi, se il cluster è condiviso da più team e progetti. Gli spazi dei nomi sono un modo per dividere le risorse del cluster utilizzando quote di risorse e limiti predefiniti. Quando crei nuovi spazi dei nomi, assicurati di configurare le Politiche RBAC appropriate per controllare l'accesso. Per ulteriori informazioni, consultare la sezione " Condivisione di un cluster con spazi dei nomi " nella documentazione di " Kubernetes ".

Se hai un piccolo cluster, un paio di dozzine di utenti e risorse simili (quali versioni diverse dello stesso software), probabilmente non hai bisogno di più spazi dei nomi. Puoi utilizzare invece le etichette.

Rivedere le informazioni sulla sicurezza relative a questa decisione in Isolamento e sicurezza dei contenitori.

Stabilire le richieste di risorse e i limiti per gli spazi dei nomi

Per garantire che ogni team disponga delle risorse necessarie per distribuire servizi ed eseguire applicazioni nel cluster, è necessario configurare le quote di risorse per ogni namespace. Le quote delle risorse determinano i vincoli di distribuzione, quali il numero di risorse Kubernetes che è possibile distribuire e la quantità di CPU e memoria che tali risorse possono consumare. Dopo che hai impostato una quota, gli utenti devono includere le richieste di risorse e i limiti nelle loro distribuzioni.

Quando crei una distribuzione, limitala in modo che il pod della tua app venga distribuito solo su macchine che presentano la combinazione ottimale di risorse. Ad esempio, potresti voler limitare un'applicazione database a una macchina bare metal con una quantità significativa di archiviazione disco locale, quale md1c.28x512.4x4tb.

Rendete le vostre applicazioni altamente disponibili

I contenitori e i pod sono, come progettati, di breve durata e possono avere un malfunzionamento imprevisto. Ad esempio, un contenitore o un pod potrebbe arrestarsi se si verifica un errore nella tua applicazione. Per garantire un'elevata disponibilità della tua app, devi assicurarti di disporre di un numero sufficiente di istanze per gestire il carico di lavoro, oltre a istanze aggiuntive da utilizzare in caso di guasto. È possibile assicurarsi che le istanze siano sufficienti impostando il ridimensionamento automatico.

Passi successivi

Per continuare il processo di pianificazione, scegliere tra rete cluster VPC e rete cluster classica. Se siete pronti per iniziare a creare un cluster, cominciate con Preparare il vostro account per creare cluster.