Per ogni risorsa di Kubernetes è possibile configurare due tipi di requisiti: Requests e Limits. Il primo descrive i requisiti minimi riguardanti la disponibilità di risorse libere nel nodo, necessarie per avviare un container o un pod; il secondo limita rigidamente le risorse disponibili per il container.
Quando Kubernetes pianifica un pod, è molto importante che i container dispongano di risorse sufficienti per funzionare correttamente. Se prevedi di distribuire una grande applicazione su un nodo con risorse limitate, è molto probabile che non funzionerà a causa della mancanza di memoria o di potenza di elaborazione del processore. In questo articolo esamineremo come affrontare i problemi di carenza di risorse computazionali tramite richieste di risorse e limitazioni.
Le richieste Requests e le limitazioni Limits sono meccanismi che Kubernetes utilizza per gestire risorse come CPU e memoria. Le Requests garantiscono che il container riceva la risorsa richiesta. Se un container richiede una risorsa, Kubernetes lo pianificherà solo su un nodo capace di fornirla. Le limitazioni Limits controllano che le risorse richieste dal container non superino mai un certo valore.
Un container può aumentare le proprie capacità computazionali solo fino a un certo limite, oltre il quale sarà limitato. Vediamo come funziona. Esistono due tipi di risorse: CPU e memoria. Il pianificatore di Kubernetes utilizza i dati su queste risorse per determinare dove avviare i tuoi pod. Una specifica tipica delle risorse per un pod appare così.
Ogni contenitore in un pod può impostare le proprie richieste e limiti, e tutto questo è additivo. Le risorse della CPU sono definite in millicrore. Se il tuo contenitore richiede due core completi per funzionare, imposti il valore a 2000m. Se invece il contenitore ha bisogno solo di 1/4 di core, il valore sarà 250m. Tieni presente che se assegni un valore di risorse della CPU maggiore del numero totale di core del nodo più grande, l'avvio del tuo pod non sarà pianificato affatto. Una situazione simile si verificherà se hai un pod che richiede quattro core e il cluster Kubernetes è composto da sole due macchine virtuali principali.
A meno che la tua applicazione non sia stata progettata specificamente per sfruttare i vantaggi di più core (tra cui programmi come calcoli scientifici complessi e operazioni con database), la prassi migliore è impostare le richieste della CPU a 1 o meno, seguita dall'esecuzione di un numero maggiore di repliche per la scalabilità. Questa soluzione darà al sistema maggiore flessibilità e affidabilità.
Quando si tratta di limiti della CPU, tutto diventa più interessante poiché è considerato una risorsa comprimibile. Se la tua applicazione inizia ad avvicinarsi al limite della potenza di calcolo, Kubernetes inizierà a limitare il tuo contenitore attraverso il CPU Throttling — riducendo la frequenza della CPU. Ciò significa che la CPU sarà artificialmente limitata, fornendo all'applicazione potenzialmente prestazioni inferiori, tuttavia il processo non verrà interrotto o terminato.
Le risorse di memoria sono definite in byte. Di solito, il valore nelle impostazioni è misurato in mibibyte Mib, ma puoi impostare qualsiasi valore, da byte a petabyte. Qui si verifica la stessa situazione della CPU: se invii una richiesta per una quantità di memoria superiore alla quantità disponibile sui tuoi nodi, l'esecuzione di questo pod non sarà pianificata. Ma a differenza delle risorse CPU, la memoria non è comprimibile, in quanto non esiste un modo per limitare il suo utilizzo. Pertanto, l'esecuzione del contenitore verrà interrotta non appena supererà la memoria a esso assegnata.
È importante ricordare che non è possibile impostare le richieste che superano le dimensioni delle risorse che i tuoi nodi possono fornire. Le caratteristiche delle risorse comuni per le macchine virtuali GKE possono essere trovate nei link posti sotto questo video.
In un mondo ideale, le impostazioni predefinite del contenitore sarebbero più che sufficienti per garantire flussi di lavoro senza intoppi. Ma il mondo reale non è così: le persone possono facilmente dimenticare di configurare l'uso delle risorse o i hacker possono impostare richieste e limiti che superano le reali capacità dell'infrastruttura. Per evitare lo sviluppo di scenari simili, è possibile configurare le quote risorse ResourceQuota e le gamme di limitazione LimitRange.
Dopo la creazione degli spazi dei nomi, è possibile bloccarli utilizzando le quote. Ad esempio, se hai spazi dei nomi prod e dev, si utilizza un modello in cui le quote per la produzione sono completamente assenti e le quote per lo sviluppo sono molto severe. Questo consente a prod, in caso di un'improvvisa impennata del traffico, di appropriarsi di tutte le risorse disponibili, bloccando completamente dev.
La quota delle risorse può apparire in questo modo. In questo esempio ci sono 4 sezioni: queste sono le 4 righe di codice in basso.
Esaminiamo ciascuna di esse. Requests.cpu rappresenta il numero massimo di richieste combinate di potenza di elaborazione che possono provenire da tutti i contenitori dello spazio dei nomi. In questo esempio puoi avere 50 contenitori con richieste di 10m, cinque contenitori con richieste di 100m, o semplicemente un contenitore con una richiesta di 500m. Finché il numero totale di requests.cpu di questo spazio dei nomi è inferiore a 500m, tutto andrà bene.
La memoria richiesta requests.memory è la quantità massima di richieste combinate di memoria che possono avere tutti i contenitori nello spazio dei nomi. Come nel caso precedente, puoi avere 50 contenitori da 2 mib, cinque contenitori da 20 Mib o un unico contenitore da 100 Mib, purché l'ammontare totale della memoria richiesta nello spazio dei nomi sia inferiore a 100 mebibyte.
Limits.cpu è il valore massimo combinato di potenza di elaborazione che possono utilizzare tutti i contenitori nello spazio dei nomi. Può essere considerato come il limite delle richieste di potenza di elaborazione.
Infine, limits.memory è la quantità massima di memoria condivisa che può essere utilizzata da tutti i container nello spazio dei nomi. Questa è una limitazione delle richieste di memoria complessive.
Quindi, per impostazione predefinita, i container nel cluster Kubernetes operano con risorse di calcolo illimitate. Utilizzando le quote delle risorse, gli amministratori del cluster possono limitare il consumo e la creazione delle risorse sulla base dello spazio dei nomi. All'interno dello spazio dei nomi, un modulo pod o container può utilizzare tanta potenza CPU e memoria quanto definito dalla quota delle risorse dello spazio dei nomi. Tuttavia, c'è preoccupazione che un singolo pod o container possa monopolizzare tutte le risorse disponibili. Per prevenire una tale situazione, viene utilizzato il range limite Limit Range: una politica di restrizione della distribuzione delle risorse (per pod o container) nello spazio dei nomi.
Il range limite fornisce restrizioni che possono:
- garantire l'utilizzo minimo e massimo delle risorse di calcolo per ciascun modulo o container nello spazio dei nomi;
- imporre requisiti minimi e massimi di storage Storage Request per ciascun PersistentVolumeClaim nello spazio dei nomi;
- imporre un rapporto tra la richiesta Request e il limite Limit per una risorsa nello spazio dei nomi;
- stabilire richieste/limiti predefiniti per le risorse di calcolo nello spazio dei nomi e applicarli automaticamente ai container durante l'esecuzione.
Pertanto, puoi creare un range limite nel tuo spazio dei nomi. A differenza della quota, che si applica a tutto lo spazio dei nomi, il Limit Range è utilizzato per singoli container. Questo può prevenire la creazione da parte degli utenti di container molto piccoli o, al contrario, enormi all'interno dello spazio dei nomi. Il range limite Limit Range può apparire così.
Come nel caso precedente, qui possiamo identificare 4 sezioni. Esaminiamo ciascuna di esse.
Nella sezione default vengono impostati i limiti predefiniti per il container nel pod. Se imposti questi valori nel range limite, tutti i container per i quali questi valori non sono stati esplicitamente definiti seguiranno i valori predefiniti.
Nella sezione di richiesta predefinita defaultRequest sono configurate le richieste di default per il container nel pod. Ancora una volta, se imposti questi valori nel intervallo limite, tutti i container per i quali questi parametri non sono stati specificati esplicitamente utilizzeranno questi valori per default.
Nella sezione max sono indicate le limitazioni massime che possono essere impostate per il container nel pod. I valori nella sezione default e le limitazioni per il container non possono essere superiori a questo limite. È importante sottolineare che se è stato impostato un valore max e la sezione default è assente, allora il valore massimo diventa il valore predefinito.
Nella sezione min sono indicate le richieste minime che possono essere impostate per il container nel pod. I valori nella sezione default e le richieste per il container non possono essere inferiori a questo limite.
Ancora una volta, è importante notare che se questo valore è impostato, mentre il valore default non è, allora il valore minimo diventa la richiesta di default.
In definitiva, queste richieste di risorse vengono utilizzate dal pianificatore Kubernetes per l'esecuzione dei tuoi carichi di lavoro. Per poter configurare correttamente i tuoi container, è molto importante capire come funziona. Supponiamo che tu voglia avviare diversi moduli nel tuo cluster. Supponendo che le specifiche del pod siano valide, il bilanciamento del carico in Kubernetes verrà utilizzato per scegliere il nodo per eseguire il carico di lavoro.
Kubernetes verificherà se il nodo Node 1 ha risorse sufficienti per soddisfare le richieste dei container del pod, e se non è così, passerà al nodo successivo. Se nessuno dei nodi nel sistema è in grado di soddisfare le richieste, i pod passeranno allo stato di attesa Pending state. Con funzionalità come il dimensionamento automatico dei nodi in Google Kubernetes Engine, GKE può automaticamente rilevare lo stato di attesa e creare ulteriori nodi.
Se successivamente si verificherà una capacità eccessiva dei nodi, la funzione di dimensionamento automatico ne ridurrà il numero per farti risparmiare soldi. Ecco perché Kubernetes pianifica i pod in base alle richieste. Tuttavia, il limite può essere superiore alle richieste e in alcuni casi il nodo potrebbe esaurire effettivamente le risorse. Chiamano questa situazione stato di overcommitment.
Come ho già detto, quando si tratta di processori, Kubernetes inizierà a limitare i pod. Ogni pod riceverà quanto richiesto, ma se non raggiunge il limite, inizierà ad applicarsi il throttling.
Per quanto riguarda le risorse di memoria, qui Kubernetes deve prendere decisioni su quali pod cancellare e quali mantenere finché non libererai risorse di sistema, altrimenti l'intero sistema collasserà.
Immaginiamo uno scenario in cui hai una macchina che ha esaurito il limite di memoria: come si comporterà Kubernetes?
Kubernetes cercherà i pod che utilizzano più risorse di quelle richieste. Quindi, se i tuoi container non hanno richieste di risorse, significa che di default utilizzano più di quanto richiesto, semplicemente perché non hanno fatto alcuna richiesta! Questi container diventano i principali candidati per essere disattivati. I candidati successivi sono i container che hanno soddisfatto tutte le loro richieste, ma sono ancora al di sotto del limite massimo.
Se Kubernetes trova diversi pod che hanno superato i parametri delle loro richieste, li ordinerà per priorità e quindi rimuoverà i moduli con la priorità più bassa. Se tutti i moduli hanno la stessa priorità, Kubernetes fermerà i pod che hanno superato le loro richieste più di altri pod.
In rari casi, Kubernetes può interrompere i pod che sono ancora all'interno dei loro limiti di richiesta. Questo può accadere quando componenti critici di sistema, come l'agente Kubelet o Docker, iniziano a consumare più risorse di quelle riservate per loro.
Quindi, nelle fasi iniziali delle piccole aziende, un cluster Kubernetes può funzionare perfettamente senza impostare richieste e limiti di risorse, ma man mano che i tuoi team e progetti iniziano a crescere, rischi di incontrare problemi in quest'area. Aggiungere richieste e limiti ai tuoi moduli e spazi dei nomi richiede pochissimi sforzi aggiuntivi e può evitare molti problemi.
Un po' di pubblicità 🙂
Grazie per rimanere con noi. Ti piacciono i nostri articoli? Vuoi vedere più contenuti interessanti? Supportaci effettuando un ordine o raccomandandoci a qualcuno. , unica alternativa ai server entry-level, concepita da noi per te: (sono disponibili opzioni con RAID1 e RAID10, fino a 24 core e fino a 40GB DDR4).
Dell R730xd a metà prezzo nel data center Equinix Tier IV ad Amsterdam? Solo da noi nei Paesi Bassi! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — a partire da $99! Leggi di
Fonte: habr.com
