{"id":36246,"date":"2019-10-31T22:10:28","date_gmt":"2019-10-31T19:10:28","guid":{"rendered":"https:\/\/prohoster.info\/blog\/avtomasshtabirovanie-i-upravlenie-resursami-v-kubernetes-obzor-i-video-doklada\/"},"modified":"2019-10-31T22:10:28","modified_gmt":"2019-10-31T19:10:28","slug":"avtomasshtabirovanie-i-upravlenie-resursami-v-kubernetes-obzor-i-video-doklada","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/avtomasshtabirovanie-i-upravlenie-resursami-v-kubernetes-obzor-i-video-doklada","title":{"rendered":"Autoscaling e gestione delle risorse in Kubernetes (panoramica e video della presentazione)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

27 aprile alla conferenza Sciopero-2019<\/a><\/noindex>, nel corso della sezione \u00abDevOps\u00bb, \u00e8 stata presentata la relazione \u00abAutoscaling e gestione delle risorse in Kubernetes\u00bb. Qui si discute di come garantire alta disponibilit\u00e0 delle applicazioni e massimizzarne le prestazioni con K8s.<\/p>\n

\"Autoscaling
\n
\nSeguendo la tradizione, siamo lieti di presentare il video della presentazione<\/b><\/a><\/noindex> (44 minuti, molto pi\u00f9 informativo di un articolo) e il riassunto principale in formato testuale. Andiamo!<\/a><\/noindex><\/p>\n

Analizziamo il tema della relazione parola per parola e iniziamo dalla fine.<\/p>\n

Kubernetes<\/h2>\n

\nImmaginiamo di avere contenitori Docker sul nostro host. Perch\u00e9? Per garantire ripetibilit\u00e0 e isolamento, che a loro volta permettono una distribuzione, CI\/CD semplice e ben organizzata. Abbiamo molte di queste macchine con contenitori.<\/p>\n

Qual \u00e8 il vantaggio di Kubernetes in questo caso?<\/p>\n

    \n
  1. Smettiamo di pensare a queste macchine e cominciamo a lavorare con il \u00abcloud\u00bb, un cluster di contenitori<\/b> o pod della containerizzazione.<\/li>\n
  2. Inoltre, non consideriamo nemmeno i singoli pod, ma gestiamo anche bun<\/i>sono primitivi di alto livello primitivi di alto livello<\/b> ci consentono di dire che esiste un modello per avviare un certo carico di lavoro, e il numero necessario di istanze per farlo. Se in seguito modifichiamo il modello, cambieranno anche tutte le istanze.<\/li>\n
  3. Con API dichiarativa<\/b> invece di eseguire una sequenza di comandi specifici, descriviamo \"la struttura del mondo\" (in YAML), che viene creata da Kubernetes. E ancora: al cambiare della descrizione, cambier\u00e0 anche la sua rappresentazione reale.<\/li>\n<\/ol>\n

    <\/p>\n

    Gestione delle risorse<\/h2>\n

    <\/p>\n

    CPU<\/h3>\n

    \nSupponiamo di avviare nginx, php-fpm e mysql su un server. Questi servizi avranno in realt\u00e0 anche pi\u00f9 processi attivi, ognuno dei quali richiede risorse computazionali:<\/p>\n

    \"Autoscaling
    \n(i numeri sulla diapositiva sono \u00abpappagalli\u00bb, l'astratta necessit\u00e0 di ciascun processo in termini di potenza di calcolo)<\/i><\/p>\n

    Per gestirlo in modo conveniente, \u00e8 logico raggruppare i processi (ad esempio, tutti i processi nginx in un gruppo \u00abnginx\u00bb). Un modo semplice e ovvio per farlo \u00e8 mettere ogni gruppo in un contenitore:<\/p>\n

    \"Autoscaling
    \n
    \nPer proseguire, \u00e8 necessario ricordare cosa sia un contenitore (in Linux). La loro nascita \u00e8 stata possibile grazie a tre funzionalit\u00e0 chiave nel kernel, implementate gi\u00e0 da tempo:     capacit\u00e0<\/a><\/noindex>, namespaces<\/a><\/noindex> e cgroups<\/a><\/noindex>. E lo sviluppo successivo \u00e8 stato facilitato da altre tecnologie (inclusi i comodi \"wrapper\" come Docker):<\/p>\n

    \"Autoscaling
    \n
    \nNel contesto della relazione ci interessa solo cgroups<\/b>, perch\u00e9 i gruppi di controllo sono proprio quella parte delle funzionalit\u00e0 dei container (di Docker e simili) che gestisce la risorsa. I processi raggruppati come desideravamo, sono appunto i gruppi di controllo.<\/p>\n

    Torniamo alle esigenze di CPU di questi processi, e ora \u2014 di gruppi di processi:<\/p>\n

    \"Autoscaling
    \n(ripeto, che tutti i numeri sono espressioni astratte delle necessit\u00e0 di risorse)<\/i><\/p>\n

    A questo punto, la CPU ha una certa risorsa finita (nell'esempio sono 1000)<\/i>, che potrebbe non bastare a tutti (la somma delle necessit\u00e0 di tutti i gruppi \u00e8 150+850+460=1460). Cosa succede in questo caso?<\/p>\n

    Il kernel inizia a distribuire le risorse e lo fa in modo \"equo\", assegnando la stessa quantit\u00e0 di risorse a ciascun gruppo. Ma nel primo caso ce ne sono pi\u00f9 del necessario (333>150), quindi l'eccedenza (333-150=183) rimane in riserva, che viene poi distribuita equamente tra gli altri due contenitori:<\/p>\n

    \"Autoscaling
    \n
    \nDi conseguenza: il primo contenitore ha avuto risorse sufficienti, al secondo sono mancate considerevolmente, mentre al terzo ne sono mancate lievemente. Questo \u00e8 il risultato delle azioni. del pianificatore \"equo\" in Linux<\/b> \u2014     CFS<\/a><\/noindex>. Il suo funzionamento pu\u00f2 essere regolato tramite l'assegnazione di pesi<\/b> a ciascuno dei contenitori. Ad esempio, in questo modo:<\/p>\n

    \"Autoscaling
    \n
    \nEsaminiamo il caso di carenza di risorse nel secondo container (php-fpm). Tutte le risorse del container vengono distribuite equamente tra i processi. Di conseguenza, il processo master funziona bene, mentre tutti i worker rallentano, ricevendo meno della met\u00e0 di ci\u00f2 che \u00e8 necessario:<\/p>\n

    \"Autoscaling
    \n
    \nQuesto \u00e8 il funzionamento del pianificatore CFS. I pesi che assegniamo ai contenitori verranno successivamente chiamati richieste<\/b>. Il motivo di questa denominazione \u2014 si veda pi\u00f9 avanti.<\/p>\n

    Guardiamo tutta la situazione da un'altra prospettiva. Come si suol dire, tutte le strade portano a Roma, e nel caso di un computer \u2014 alla CPU. La CPU \u00e8 una, ci sono molte attivit\u00e0 \u2014 \u00e8 necessario un semaforo. Il modo pi\u00f9 semplice per gestire le risorse \u00e8 il metodo \"semaforo\": assegniamo a un processo un tempo fisso di accesso alla CPU, poi al successivo e cos\u00ec via.<\/p>\n

    \"Autoscaling
    \n
    \nQuesto approccio \u00e8 chiamato quotazione rigida (hard limiting)<\/i>. Ricordiamolo come limiti<\/b>. Tuttavia, se si distribuiscono i limiti a tutti i container, si presenta un problema: MySQL ha percorso la strada e a un certo punto la sua richiesta di CPU \u00e8 terminata, ma tutti gli altri processi devono attendere finch\u00e9 la CPU \u00e8 inattiva<\/b>.<\/p>\n

    \"Autoscaling
    \n
    \nTorniamo al kernel Linux e al suo rapporto con la CPU: la situazione generale \u00e8 la seguente:<\/p>\n

    \"Autoscaling
    \n
    \nCgroup ha due impostazioni: fondamentalmente sono due semplici \"manopole\" che consentono di definire:<\/p>\n

      \n
    1. peso per il container (richieste) \u2014 \u00e8 shares<\/b>;<\/li>\n
    2. la percentuale del tempo totale della CPU per lavorare sui compiti del container (limits) \u2014 si tratta di quota<\/b>.<\/li>\n<\/ol>\n

      <\/p>\n

      Come misurare la CPU?<\/h3>\n

      \nCi sono diversi modi:<\/p>\n

        \n
      1. Che cos'\u00e8 pappagalli<\/i>, nessuno lo sa: bisogna sempre accordarsi.<\/li>\n
      2. Percentuali<\/i> sono pi\u00f9 chiare, ma relative: il 50% di un server con 4 core e di uno con 20 core sono cose completamente diverse.<\/li>\n
      3. Si possono utilizzare gi\u00e0 menzionati di pesi<\/i>, che Linux conosce, ma anche questi sono relativi.<\/li>\n
      4. L'opzione pi\u00f9 adeguata \u00e8 misurare le risorse computazionali in secondi<\/i>. Cio\u00e8, in secondi di tempo di CPU rispetto ai secondi di tempo reale: se si fornisce 1 secondo di tempo di CPU in 1 secondo reale\u2014 questo \u00e8 un core CPU interamente.<\/li>\n<\/ol>\n

        \nPer semplificare ulteriormente, si misura direttamente in core<\/i>, intendendo con questo il tempo della CPU reale. Poich\u00e9 Linux comprende i pesi e non il tempo della CPU\/core, \u00e8 stato necessario un meccanismo di conversione da uno all'altro.<\/p>\n

        Consideriamo un semplice esempio con un server a 3 core CPU, dove a tre pod verranno assegnati pesi (500, 1000 e 1500), facilmente convertibili nelle rispettive porzioni di core assegnati (0,5, 1 e 1,5).<\/p>\n

        \"Autoscaling
        \n
        \nSe prendiamo un secondo server, dove i core saranno doppi (6), e ci mettiamo gli stessi pod, la distribuzione dei core pu\u00f2 essere facilmente calcolata semplicemente moltiplicando per 2 (1, 2 e 3 rispettivamente). Ma un punto importante si verifica quando su questo server appare un quarto pod, il cui peso, per comodit\u00e0, poniamo sia 3000. Essi si prendono una parte delle risorse CPU (met\u00e0 dei core), e gli altri pod vengono ricalibrati (dimezzati):<\/p>\n

        \"Autoscaling
        \n<\/p>\n

        Kubernetes e risorse CPU<\/h3>\n

        \nIn Kubernetes, le risorse CPU sono misurate in milliardi<\/b>, cio\u00e8 come peso di base si usa 0,001 core. (Lo stesso nella terminologia di Linux\/cgroups \u00e8 chiamato CPU share, anche se, per essere pi\u00f9 precisi, 1000 miliardi = 1024 CPU shares.)<\/i> K8s si assicura di non posizionare sul server pi\u00f9 pod di quanti siano le risorse CPU disponibili per la somma dei pesi di tutti i pod.<\/p>\n

        Come funziona? Quando si aggiunge un server al cluster Kubernetes, viene comunicato quanti core CPU sono disponibili. E quando viene creato un nuovo pod, lo scheduler di Kubernetes sa quanti core saranno necessari a quel pod. In questo modo, il pod sar\u00e0 allocato su un server dove ci sono sufficienti core.<\/p>\n

        Cosa succede se non<\/b> \u00e8 specificato un request (cio\u00e8, il pod non ha definito il numero di core di cui necessita)? Vediamo come Kubernetes calcola effettivamente le risorse.<\/p>\n

        Al pod si possono specificare sia i request (scheduler CFS) che i limiti (ricordate il semaforo?):<\/p>\n