{"id":82920,"date":"2020-05-26T13:42:37","date_gmt":"2020-05-26T11:42:37","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/luchshie-praktiki-kubernetes-nastrojka-zaprosov-i-limitov-resursov"},"modified":"2020-05-26T13:42:37","modified_gmt":"2020-05-26T11:42:37","slug":"luchshie-praktiki-kubernetes-nastrojka-zaprosov-i-limitov-resursov","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/luchshie-praktiki-kubernetes-nastrojka-zaprosov-i-limitov-resursov","title":{"rendered":"Migliori pratiche Kubernetes. Configurazione delle richieste e dei limiti delle risorse","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Le migliori pratiche di Kubernetes. Creazione di piccoli container<\/a><\/noindex>
\nLe migliori pratiche di Kubernetes. Organizzazione di Kubernetes con spazi dei nomi<\/a><\/noindex>
\nLe migliori pratiche di Kubernetes. Controllo della vitalit\u00e0 di Kubernetes tramite test di Readiness e Liveness<\/a><\/noindex><\/p>\n

Per ogni risorsa di Kubernetes \u00e8 possibile configurare due tipi di requisiti: Requests e Limits. Il primo descrive i requisiti minimi riguardanti la disponibilit\u00e0 di risorse libere nel nodo, necessarie per avviare un container o un pod; il secondo limita rigidamente le risorse disponibili per il container. <\/p>\n

Quando Kubernetes pianifica un pod, \u00e8 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, \u00e8 molto probabile che non funzioner\u00e0 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.<\/p>\n

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\u00e0 solo su un nodo capace di fornirla. Le limitazioni Limits controllano che le risorse richieste dal container non superino mai un certo valore.<\/p>\n

\"Migliori<\/a><\/noindex><\/p>\n

Un container pu\u00f2 aumentare le proprie capacit\u00e0 computazionali solo fino a un certo limite, oltre il quale sar\u00e0 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\u00ec.<\/p>\n

\"Migliori
\n
\nOgni contenitore in un pod pu\u00f2 impostare le proprie richieste e limiti, e tutto questo \u00e8 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\u00e0 250m. Tieni presente che se assegni un valore di risorse della CPU maggiore del numero totale di core del nodo pi\u00f9 grande, l'avvio del tuo pod non sar\u00e0 pianificato affatto. Una situazione simile si verificher\u00e0 se hai un pod che richiede quattro core e il cluster Kubernetes \u00e8 composto da sole due macchine virtuali principali.<\/p>\n

A meno che la tua applicazione non sia stata progettata specificamente per sfruttare i vantaggi di pi\u00f9 core (tra cui programmi come calcoli scientifici complessi e operazioni con database), la prassi migliore \u00e8 impostare le richieste della CPU a 1 o meno, seguita dall'esecuzione di un numero maggiore di repliche per la scalabilit\u00e0. Questa soluzione dar\u00e0 al sistema maggiore flessibilit\u00e0 e affidabilit\u00e0.<\/p>\n

Quando si tratta di limiti della CPU, tutto diventa pi\u00f9 interessante poich\u00e9 \u00e8 considerato una risorsa comprimibile. Se la tua applicazione inizia ad avvicinarsi al limite della potenza di calcolo, Kubernetes inizier\u00e0 a limitare il tuo contenitore attraverso il CPU Throttling \u2014 riducendo la frequenza della CPU. Ci\u00f2 significa che la CPU sar\u00e0 artificialmente limitata, fornendo all'applicazione potenzialmente prestazioni inferiori, tuttavia il processo non verr\u00e0 interrotto o terminato. <\/p>\n

Le risorse di memoria sono definite in byte. Di solito, il valore nelle impostazioni \u00e8 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\u00e0 di memoria superiore alla quantit\u00e0 disponibile sui tuoi nodi, l'esecuzione di questo pod non sar\u00e0 pianificata. Ma a differenza delle risorse CPU, la memoria non \u00e8 comprimibile, in quanto non esiste un modo per limitare il suo utilizzo. Pertanto, l'esecuzione del contenitore verr\u00e0 interrotta non appena superer\u00e0 la memoria a esso assegnata.<\/p>\n

\"Migliori
\n
\n\u00c8 importante ricordare che non \u00e8 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.<\/p>\n

In un mondo ideale, le impostazioni predefinite del contenitore sarebbero pi\u00f9 che sufficienti per garantire flussi di lavoro senza intoppi. Ma il mondo reale non \u00e8 cos\u00ec: le persone possono facilmente dimenticare di configurare l'uso delle risorse o i hacker possono impostare richieste e limiti che superano le reali capacit\u00e0 dell'infrastruttura. Per evitare lo sviluppo di scenari simili, \u00e8 possibile configurare le quote risorse ResourceQuota e le gamme di limitazione LimitRange.<\/p>\n

Dopo la creazione degli spazi dei nomi, \u00e8 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.<\/p>\n

La quota delle risorse pu\u00f2 apparire in questo modo. In questo esempio ci sono 4 sezioni: queste sono le 4 righe di codice in basso.<\/p>\n

\"Migliori
\n
\nEsaminiamo 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\u00e9 il numero totale di requests.cpu di questo spazio dei nomi \u00e8 inferiore a 500m, tutto andr\u00e0 bene.<\/p>\n

La memoria richiesta requests.memory \u00e8 la quantit\u00e0 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\u00e9 l'ammontare totale della memoria richiesta nello spazio dei nomi sia inferiore a 100 mebibyte.<\/p>\n

Limits.cpu \u00e8 il valore massimo combinato di potenza di elaborazione che possono utilizzare tutti i contenitori nello spazio dei nomi. Pu\u00f2 essere considerato come il limite delle richieste di potenza di elaborazione.<\/p>\n

Infine, limits.memory \u00e8 la quantit\u00e0 massima di memoria condivisa che pu\u00f2 essere utilizzata da tutti i container nello spazio dei nomi. Questa \u00e8 una limitazione delle richieste di memoria complessive.
\nQuindi, 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\u00f2 utilizzare tanta potenza CPU e memoria quanto definito dalla quota delle risorse dello spazio dei nomi. Tuttavia, c'\u00e8 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.<\/p>\n

Il range limite fornisce restrizioni che possono:<\/p>\n