Perché disabilitare lo scambio su kubernetes


35

Da Kubernetes 1.8, sembra che debba disabilitare lo scambio sui miei nodi (o impostato --fail-swap-onsu false).

Non riesco a trovare il motivo tecnico per cui Kubernetes insista sul fatto che lo swap sia disabilitato. È per motivi di prestazioni? Ragioni di sicurezza? Perché la ragione di ciò non è documentata?

Risposte:


28

L'idea di kubernetes è quella di comprimere le istanze il più vicino possibile al 100%. Tutte le distribuzioni devono essere bloccate con limiti CPU / memoria. Quindi, se lo scheduler invia un pod a un computer, non dovrebbe mai usare lo swap. Non vuoi scambiarti perché rallenterà le cose.

È principalmente per le prestazioni.


2
l'idea è se un nodo ha solo 3gig gratis da usare .. e il tuo nuovo pod vuole 4 .. andrà su un altro nodo.
Mike,

Questo non ha molto senso per me, sicuramente potresti comprimere un po 'di più i tuoi nodi lasciando che l'OS metta in scambio alcune pagine di memoria usate di rado senza danneggiare le prestazioni in modo evidente?
Frederik Baetens,

13

La ragione di ciò, a quanto ho capito, è che il kubelet non è progettato per gestire le situazioni di scambio e il team di Kubernetes non sta pianificando di implementarlo poiché l'obiettivo è che i pod dovrebbero adattarsi alla memoria dell'host.

da questo problema

Il supporto per lo scambio non è banale. I pod garantiti non dovrebbero mai richiedere lo scambio. I baccelli vulnerabili dovrebbero soddisfare le loro richieste senza richiedere lo scambio. I pod BestEffort non hanno garanzia. Al momento il kubelet non ha le capacità intelligenti per fornire la giusta quantità di comportamento prevedibile in tutti i pod.


10

TL; DR che non utilizza correttamente lo swap è solo un trucco pigro che dimostra una scarsa comprensione dei sottosistemi di memoria e una mancanza di abilità di amministrazione dei sistemi fondamentali. Progettare servizi di infrastruttura e non comprendere questi sistemi è destinato a finire in un fallimento.

Quindi, ho alcuni commenti su questo, mi sembra più una pigrizia piuttosto che una caratteristica o un requisito. È assolutamente possibile gestire correttamente lo scambio, analizzare la memoria e determinare come utilizzare correttamente il sottosistema di memoria senza colpire lo scambio. Ci sono una miriade di strumenti costruiti attorno a questo e puoi garantire che un processo non utilizzerà lo swap abbastanza facilmente, quindi il punto di prestazione non è corretto. È semplicemente codifica pigra non inserire questa strumentazione e, nel complesso, la completa rimozione dello swap andrà a scapito delle prestazioni del sistema. La chiave qui lo sta usando correttamente. Concordo sul fatto che lo scambio di pod su dischi influirà sulle prestazioni, tuttavia ci sono una serie di cose che dovrebbero essere scambiate su disco.

Inoltre, il kernel di Linux è progettato per utilizzare lo swap, e disabilitarlo completamente avrà conseguenze negative. Un modo migliore per gestirlo sarebbe quello di bloccare i pod nella memoria principale e non consentire loro di scambiare su disco, ridurre la pressione della cache vfs in modo che non si cambi a meno che non sia assolutamente necessario e anche in questo caso si potrebbero causare processi bloccati fallire MALLOC nel caso in cui la memoria principale sia esaurita.

A seconda dei processi nei contenitori che hanno un guasto grave del contenitore o che lo hanno ucciso dal killer OOM, si potrebbero ottenere risultati piuttosto disastrosi. Capisco tuttavia che i processi eseguiti in questi contenitori dovrebbero idealmente essere apolidi ed effimeri, ma in 20 anni di sistemi in esecuzione, non ho visto una volta tutti seguire il progetto previsto alla lettera il 100% delle volte.

Inoltre, ciò non tiene conto delle tecnologie future come la memoria non volatile e dei più recenti sistemi di memoria come Intel xpoint che possono essere utilizzati per estendere la memoria principale in modo significativo utilizzando sistemi di memoria / disco ibridi. Con questo tipo di sistemi possono usarli direttamente come memoria principale supplementare o utilizzare i file di scambio per estendere la memoria principale con un impatto trascurabile sulle prestazioni.


2
Dubito fortemente che i manutentori del progetto kubernetes siano pigri. Nessuno degli argomenti proposti sembra essere nel contesto di un ecosistema containerizzato in esecuzione in kubernetes.
spuder

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.