Per ogni risorsa Kubernetes, puoi configurare due tipi di requisiti: Richieste e Limiti. Il primo descrive i requisiti minimi per la disponibilità delle risorse libere del nodo necessarie per eseguire un container o un pod, il secondo limita rigorosamente le risorse disponibili per il container.
Quando Kubernetes pianifica i pod, è molto importante che i contenitori dispongano di risorse sufficienti per funzionare correttamente. Se hai intenzione di distribuire un'applicazione di grandi dimensioni su un nodo con risorse limitate, è possibile che non venga eseguita perché la memoria del nodo sta esaurendo o sta esaurendo la potenza della CPU. In questo articolo esamineremo come risolvere le carenze di potenza di calcolo utilizzando richieste e limiti di risorse.
Richieste e limiti sono meccanismi utilizzati da Kubernetes per gestire risorse come CPU e memoria. Le richieste sono ciò che garantisce che il contenitore riceva la risorsa richiesta. Se un contenitore richiede una risorsa, Kubernetes la pianificherà solo su un nodo che può fornirla. I limiti controllano che le risorse richieste dal contenitore non supereranno mai un determinato valore.
Un contenitore può aumentare la propria potenza di calcolo solo fino a un certo limite, dopodiché sarà limitata. Vediamo come funziona. Quindi, esistono due tipi di risorse: processore e memoria. Lo scheduler Kubernetes utilizza i dati su queste risorse per capire dove eseguire i tuoi pod. Una tipica specifica di risorsa per un pod è simile alla seguente.
Ogni contenitore in un pod può impostare le proprie query e limiti, è tutto additivo. Le risorse del processore sono definite in millicore. Se il tuo contenitore necessita di due core completi per essere eseguito, imposta il valore su 2000 m. Se il contenitore necessita solo della potenza di 1/4 del nucleo, il valore sarà di 250 m. Tieni presente che se assegni un valore di risorsa CPU maggiore del numero di core del nodo più grande, l'avvio del tuo pod non verrà affatto pianificato. Una situazione simile si verificherà se disponi di un pod che necessita di quattro core e il cluster Kubernetes è composto solo da due macchine virtuali principali.
A meno che l'applicazione non sia progettata specificamente per sfruttare più core (vengono in mente programmi come calcoli scientifici complessi e operazioni di database), la procedura migliore è impostare le richieste CPU su 1 o un valore inferiore e quindi eseguire più repliche per la scalabilità. Questa soluzione conferirà al sistema maggiore flessibilità e affidabilità.
Quando si tratta di limitazioni della CPU, le cose si fanno più interessanti poiché è considerata una risorsa comprimibile. Se la tua applicazione inizia ad avvicinarsi al limite di potenza del processore, Kubernetes inizierà a rallentare il contenitore utilizzando la limitazione della CPU, riducendo la frequenza del processore. Ciò significa che la CPU verrà limitata artificialmente, dando all'applicazione prestazioni potenzialmente peggiori, ma il processo non verrà terminato o interrotto.
Le risorse di memoria sono definite in byte. Solitamente il valore nelle impostazioni viene misurato in mebibyte Mib, ma è possibile impostare qualsiasi valore, dai byte ai petabyte. In questo caso si applica la stessa situazione che con la CPU: se effettui una richiesta per una quantità di memoria maggiore della quantità di memoria sui tuoi nodi, l'esecuzione di quel pod non verrà pianificata. Ma a differenza delle risorse della CPU, la memoria non viene compressa perché non c'è modo di limitarne l'utilizzo. Pertanto, l'esecuzione del contenitore verrà interrotta non appena supererà la memoria ad esso assegnata.
È importante ricordare che non è possibile configurare richieste che superano le risorse che i tuoi nodi possono fornire. Le specifiche delle risorse condivise per le macchine virtuali GKE sono disponibili nei collegamenti sotto questo video.
In un mondo ideale, le impostazioni predefinite del contenitore sarebbero sufficienti per garantire il corretto funzionamento dei flussi di lavoro. Ma il mondo reale non è così, le persone possono facilmente dimenticare di configurare l’uso delle risorse, oppure gli hacker imporranno richieste e restrizioni che superano le reali capacità dell’infrastruttura. Per evitare che si verifichino tali scenari, è possibile configurare le quote delle risorse ResourceQuota e LimitRange.
Una volta creato uno spazio dei nomi, è possibile bloccarlo utilizzando le quote. Ad esempio, se disponi degli spazi dei nomi prod e dev, lo schema è che non ci sono quote di produzione e quote di sviluppo molto rigide. Ciò consente a prod, in caso di forte aumento del traffico, di impossessarsi dell'intera risorsa disponibile, bloccando completamente dev.
La quota delle risorse potrebbe assomigliare a questa. In questo esempio ci sono 4 sezioni: queste sono le 4 righe finali del codice.
Diamo un'occhiata a ciascuno di essi. Requests.cpu è il numero massimo di richieste CPU combinate che possono provenire da tutti i contenitori nello spazio dei nomi. In questo esempio, potresti avere 50 container con 10 milioni di richieste, cinque container con 100 milioni di richieste o solo un container con 500 milioni di richieste. Finché il numero totale di request.cpu di un dato spazio dei nomi è inferiore a 500 m, tutto andrà bene.
Richieste di memoria richieste. memoria è la quantità massima di richieste di memoria combinate che possono avere tutti i contenitori nello spazio dei nomi. Come nel caso precedente, si possono avere 50 contenitori da 2 mib, cinque contenitori da 20 mib, oppure un singolo contenitore da 100 mib purché la quantità totale di memoria richiesta nel namespace sia inferiore a 100 mebibyte.
Limits.cpu è la quantità massima combinata di potenza della CPU che tutti i contenitori nello spazio dei nomi possono utilizzare. Possiamo considerare questo come il limite delle richieste di potenza del processore.
Infine, Limits.Memory è la quantità massima di memoria condivisa che possono utilizzare tutti i contenitori nello spazio dei nomi. Questo è un limite alle richieste di memoria totali.
Pertanto, per impostazione predefinita, i contenitori in un cluster Kubernetes vengono eseguiti con risorse di elaborazione illimitate. Con le quote delle risorse, gli amministratori del cluster possono limitare il consumo e la creazione di risorse in base allo spazio dei nomi. In uno spazio dei nomi, un pod o un contenitore può consumare la stessa potenza della CPU e memoria determinata dalla quota delle risorse dello spazio dei nomi. Tuttavia, esiste il timore che un pod o un contenitore possano monopolizzare tutte le risorse disponibili. Per evitare questa situazione, viene utilizzato un intervallo limite: una policy per limitare l'allocazione delle risorse (per pod o contenitori) nello spazio dei nomi.
L'intervallo limite fornisce restrizioni che possono:
- Garantire l'utilizzo minimo e massimo delle risorse di elaborazione per ciascun modulo o contenitore nello spazio dei nomi;
- applicare richieste di archiviazione minime e massime di Starage Request per ogni PersistentVolumeClaim nello spazio dei nomi;
- imporre una relazione tra una richiesta e un limite per una risorsa in uno spazio dei nomi;
- impostare richieste/limiti predefiniti per le risorse di calcolo nello spazio dei nomi e inserirli automaticamente nei contenitori in fase di runtime.
In questo modo puoi creare un intervallo limite nel tuo spazio dei nomi. A differenza di una quota, che si applica all'intero spazio dei nomi, Limit Range viene utilizzato per i singoli contenitori. Ciò può impedire agli utenti di creare contenitori molto piccoli o, al contrario, giganteschi all'interno dello spazio dei nomi. L'intervallo limite potrebbe assomigliare a questo.
Come nel caso precedente, anche qui si possono distinguere 4 sezioni. Diamo un'occhiata a ciascuno di essi.
La sezione predefinita imposta i limiti predefiniti per il contenitore nel pod. Se imposti questi valori sull'intervallo estremo, tutti i contenitori per i quali questi valori non sono stati impostati esplicitamente seguiranno i valori predefiniti.
La sezione di richiesta predefinita defaultRequest configura le richieste predefinite per il contenitore nel pod. Ancora una volta, se imposti questi valori sull'intervallo estremo, tutti i contenitori che non impostano esplicitamente queste opzioni verranno impostati automaticamente su questi valori.
La sezione max specifica i limiti massimi che possono essere impostati per un contenitore nel pod. I valori nella sezione predefinita e i limiti del contenitore non possono essere impostati al di sopra di questo limite. È importante notare che se il valore è impostato su max e non è presente alcuna sezione predefinita, il valore massimo diventa il valore predefinito.
La sezione min specifica le richieste minime che possono essere impostate per un contenitore in un pod. Tuttavia, i valori nella sezione predefinita e nelle query per il contenitore non possono essere impostati al di sotto di questo limite.
Ancora una volta, è importante notare che se questo valore è impostato, il valore predefinito non lo è, quindi il valore minimo diventa il prompt predefinito.
Queste richieste di risorse vengono infine utilizzate dallo scheduler Kubernetes per eseguire i carichi di lavoro. Per poter configurare correttamente i tuoi contenitori, è molto importante capire come funziona. Supponiamo che tu voglia eseguire più pod nel tuo cluster. Supponendo che le specifiche del pod siano valide, la pianificazione Kubernetes utilizzerà il bilanciamento round robin per selezionare un nodo per eseguire il carico di lavoro.
Kubernetes controllerà se il nodo 1 dispone di risorse sufficienti per soddisfare le richieste dai contenitori pod e, in caso contrario, passerà al nodo successivo. Se nessuno dei nodi nel sistema è in grado di soddisfare le richieste, i pod passeranno allo stato In sospeso. Utilizzando le funzionalità del motore Google Kubernetes come la scalabilità automatica dei nodi, GKE può rilevare automaticamente lo stato di attesa e creare molti altri nodi aggiuntivi.
Se successivamente esaurisci la capacità dei nodi, la scalabilità automatica ridurrà il numero di nodi per farti risparmiare denaro. Questo è il motivo per cui Kubernetes pianifica i pod in base alle richieste. Tuttavia, il limite potrebbe essere superiore alle richieste e in alcuni casi il nodo potrebbe effettivamente esaurire le risorse. Chiamiamo questo stato stato di overcommit.
Come ho detto, quando si tratta di CPU, Kubernetes inizierà a limitare i pod. Ogni pod riceverà quanto richiesto, ma se non raggiunge il limite, inizierà ad essere applicata la limitazione.
Quando si tratta di risorse di memoria, Kubernetes è costretto a prendere decisioni su quali pod eliminare e quali conservare finché non si liberano risorse di sistema o l'intero sistema non si blocca.
Immaginiamo uno scenario in cui una macchina sta esaurendo la memoria: come lo gestirebbe Kubernetes?
Kubernetes cercherà i pod che utilizzano più risorse di quelle richieste. Quindi, se i tuoi contenitori non hanno alcuna Richiesta, significa che per impostazione predefinita stanno utilizzando più di quanto hanno chiesto, semplicemente perché non hanno chiesto nulla! Tali contenitori diventano i primi candidati per la chiusura. I successivi candidati sono contenitori che hanno soddisfatto tutte le loro richieste ma sono ancora al di sotto del limite massimo.
Pertanto, se Kubernetes trova diversi pod che hanno superato i parametri di richiesta, li ordinerà per priorità e quindi rimuoverà i pod con la priorità più bassa. Se tutti i pod hanno la stessa priorità, Kubernetes terminerà i pod che superano le loro richieste più degli altri pod.
In casi molto rari, Kubernetes potrebbe interrompere i pod che rientrano ancora nell'ambito delle sue richieste. Ciò può accadere quando componenti critici del sistema come l'agente Kubelet o Docker iniziano a consumare più risorse di quelle a loro riservate.
Pertanto, nelle fasi iniziali delle piccole aziende, un cluster Kubernetes può funzionare bene senza impostare richieste e restrizioni sulle risorse, ma man mano che i tuoi team e progetti iniziano a crescere di dimensioni, corri il rischio di incorrere in problemi in quest'area. L'aggiunta di query e vincoli ai moduli e agli spazi dei nomi richiede uno sforzo aggiuntivo minimo e può far risparmiare molti problemi.
Alcuni annunci 🙂
Grazie per stare con noi. Ti piacciono i nostri articoli? Vuoi vedere contenuti più interessanti? Sostienici effettuando un ordine o raccomandando agli amici, , un analogo unico dei server entry-level, che è stato inventato da noi per te: (disponibile con RAID1 e RAID10, fino a 24 core e fino a 40 GB DDR4).
Dell R730xd 2 volte più economico nel data center Equinix Tier IV ad Amsterdam? Solo qui In Olanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - da $99! Leggi
Fonte: habr.com