{"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":"Le migliori pratiche di 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 contenitori<\/a><\/noindex>
\nLe migliori pratiche di Kubernetes. Organizzazione di Kubernetes con gli spazi dei nomi<\/a><\/noindex>
\nLe migliori pratiche di Kubernetes. Verifica della vitalit\u00e0 di Kubernetes tramite test di Readiness e Liveness<\/a><\/noindex><\/p>\n

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

Quando Kubernetes pianifica un pod, \u00e8 molto importante che i contenitori abbiano risorse sufficienti per funzionare normalmente. Se prevedi di distribuire una grande applicazione su un nodo con risorse limitate, \u00e8 possibile che non funzioni a causa della mancanza di memoria o di potenza della CPU. In questo articolo vedremo come risolvere i problemi di carenza di potenza informatica utilizzando le richieste di risorse e i limiti.<\/p>\n

Le richieste e i limiti sono meccanismi utilizzati da Kubernetes per gestire risorse come CPU e memoria. Le richieste garantiscono che un contenitore ottenga le risorse richieste. Se un contenitore richiede una risorsa, Kubernetes lo pianificher\u00e0 solo su quel nodo in grado di fornirla. I limiti controllano che le risorse richieste dal contenitore non superino mai un certo valore.<\/p>\n

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

Un contenitore pu\u00f2 aumentare le sue capacit\u00e0 computazionali solo fino a un certo limite, oltre il quale sar\u00e0 limitato. Vediamo come funziona. Ci sono due tipi di risorse: CPU e memoria. Il pianificatore Kubernetes utilizza informazioni su queste risorse per capire dove eseguire i tuoi pod. Una specifica tipica delle risorse per un pod appare cos\u00ec.<\/p>\n

\"Le
\n
\nOgni contenitore in un pod pu\u00f2 impostare le proprie richieste e limitazioni, e tutto ci\u00f2 \u00e8 additivo. Le risorse della CPU sono definite in milli-core. Se il tuo contenitore ha bisogno di due core completi per funzionare, imposti un valore di 2000m. Se invece il contenitore richiede solo un quarto di core, il valore sar\u00e0 250m. Tieni presente che, se imposti un valore delle risorse della CPU superiore al numero di core del nodo pi\u00f9 grande, il tuo pod non sar\u00e0 programmato per l'esecuzione. Una situazione simile avverr\u00e0 se hai un pod che richiede quattro core, mentre 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 (pensando a programmi come calcoli scientifici complessi e operazioni su database), la prassi migliore \u00e8 impostare le richieste CPU su 1 o inferiore, aumentando poi il numero di repliche per la scalabilit\u00e0. Questa soluzione conferir\u00e0 maggiore flessibilit\u00e0 e affidabilit\u00e0 al sistema.<\/p>\n

Quando si tratta di limitazioni della CPU, la situazione si fa pi\u00f9 interessante, poich\u00e9 \u00e8 considerata una risorsa comprimibile. Se la tua applicazione si avvicina al limite della potenza di elaborazione della CPU, Kubernetes inizier\u00e0 a rallentare il tuo container tramite il CPU Throttling \u2014 riduzione della frequenza della CPU. Ci\u00f2 significa che la CPU sar\u00e0 artificialmente limitata, fornendo potenzialmente prestazioni inferiori all'applicazione, ma il processo non verr\u00e0 fermato o terminato. <\/p>\n

Le risorse di memoria sono definite in byte. Di solito, il valore nelle impostazioni \u00e8 misurato in mebibyte (Mib), ma puoi impostare qualsiasi valore, dai byte ai petabyte. Qui si verifica la stessa situazione della CPU: se fai una richiesta per una quantit\u00e0 di memoria che supera la quantit\u00e0 disponibile sui tuoi nodi, l'esecuzione di quel pod non verr\u00e0 programmata. Ma a differenza delle risorse della CPU, la memoria non \u00e8 comprimibile, poich\u00e9 non esiste un modo per limitare il suo utilizzo. Pertanto, l'esecuzione del container verr\u00e0 interrotta non appena supera la memoria a lui allocata.<\/p>\n

\"Le
\n
\n\u00c8 importante ricordare che non puoi configurare richieste che superano la quantit\u00e0 di risorse che i tuoi nodi possono fornire. Le caratteristiche delle risorse condivise per le macchine virtuali GKE possono essere trovate nei link forniti sotto questo video.<\/p>\n

In un mondo ideale, le impostazioni predefinite del container sarebbero pi\u00f9 che sufficienti per permettere un flusso di lavoro fluido. Ma il mondo reale non \u00e8 cos\u00ec: le persone possono dimenticare facilmente di configurare l'uso delle risorse, o i hacker possono impostare richieste e limiti che superano le reali capacit\u00e0 dell'infrastruttura. Per prevenire lo sviluppo di tali scenari, \u00e8 possibile configurare le quote delle risorse ResourceQuota e i limiti range LimitRange.<\/p>\n

Dopo aver creato gli spazi dei nomi, \u00e8 possibile bloccarli utilizzando le quote. Ad esempio, se hai spazi dei nomi prod e dev, si usa un modello in cui non ci sono quote per la produzione, mentre le quote per lo sviluppo sono molto rigorose. Questo consente a prod, in caso di un'improvvisa impennata del traffico, di attingere a 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 \u2013 queste sono 4 righe di codice in basso.<\/p>\n

\"Le
\n
\nEsaminiamo ciascuna di esse. requests.cpu rappresenta il numero massimo di richieste di potenza di elaborazione che possono arrivare da tutti i contenitori nello spazio dei nomi. In questo esempio, puoi avere 50 contenitori con richieste di 10m, cinque contenitori con richieste di 100m oppure semplicemente un contenitore con una richiesta di 500m. Finch\u00e9 il numero totale di requests.cpu per questo spazio dei nomi rimarr\u00e0 sotto i 500m, tutto andr\u00e0 bene.<\/p>\n

La memoria richiesta requests.memory \u00e8 la massima quantit\u00e0 combinata di richieste 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 con 100 MiB, finch\u00e9 la quantit\u00e0 totale di memoria richiesta nello spazio dei nomi sar\u00e0 inferiore ai 100 mebibyte.<\/p>\n

limits.cpu \u00e8 il valore massimo combinato della potenza di elaborazione che pu\u00f2 essere utilizzato da tutti i container nello spazio dei nomi. Pu\u00f2 essere considerato come il limite delle richieste di potenza di elaborazione.<\/p>\n

Infine, limits.memory rappresenta la quantit\u00e0 massima di memoria totale che possono utilizzare tutti i container nello spazio dei nomi. Questa \u00e8 una limitazione delle richieste aggregate di memoria.
\nQuindi, per impostazione predefinita, i container nel cluster Kubernetes funzionano con risorse computazionali illimitate. Utilizzando le quote di risorse, gli amministratori del cluster possono limitare il consumo e la creazione di risorse sulla base dello spazio dei nomi. In uno spazio dei nomi, il modulo pod o container pu\u00f2 consumare tanta potenza di CPU e memoria quanto definito dalla quota di risorse dello spazio dei nomi. Tuttavia, c'\u00e8 preoccupazione che un singolo pod o container possa monopolizzare tutte le risorse disponibili. Per evitare tale situazione, si utilizza il limite Range, una politica di limitazione dell'allocazione delle risorse (per pod o container) nello spazio dei nomi.<\/p>\n

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