Kubernetes Oomkilled
Prerequisito
Per utilizzare i servizi Kubernetes, avrai bisogno di un cluster minikube. Dovrai impostare un cluster di minikube sul tuo sistema per far funzionare questa tecnica. Per impostare un cluster minikube, utilizzare il terminale della riga di comando. Può essere usato in due modi. Cerca "Terminal" nella sezione di ricerca del programma del sistema. Ctrl+Alt+T è una scorciatoia da tastiera che può essere utilizzata per questo:
Almeno 300 MIB di memoria devono essere disponibili su ciascun nodo nel cluster. Dovrai far funzionare il servizio Metrics-Server nel tuo cluster per alcune attività in questa pagina. Puoi saltare quei passaggi se il server metrica è già funzionante. Ora, digita il seguente comando aggiunto.
Ora usa il comando allegato.
Le metriche guidano la risposta.K8S.IO se l'API delle metriche delle risorse è accessibile, come mostrato nello screenshot sopra.
Passaggi per creare uno spazio dei nomi
Crea uno spazio dei nomi per le risorse che creerai qui per separarle dal resto del tuo cluster.
Si forma un nuovo pod, come puoi visualizzare di seguito.
Fornire le risorse: campo richieste nel manifest della risorsa del contenitore al fine di definire una richiesta di memoria. Includi risorse: limiti per impostare un limite di RAM. Progetterai un pod con un contenitore. Il contenitore ha una richiesta di memoria da 100 MIB e un limite di memoria di 200 MIB. Il file di configurazione del pod è il seguente:
All'avvio del contenitore, la sezione Args del file di configurazione fornisce i suoi parametri. Le opzioni "-vm-bytes" e "150m" indicano al contenitore di assegnare 150 MIB di RAM.
Di seguito puoi vedere che abbiamo creato il pod:
Questo comando controllerà se il contenitore POD è attivo e funzionante:
Secondo il risultato, il singolo contenitore del pod ha una richiesta di memoria di 100 MIB e un limite di memoria di 200 MIB.
Per ottenere le metriche del pod, eseguire il comando top kubectl.
Come può essere superato il limite di memoria di un contenitore?
Se il nodo sembra avere una memoria sufficiente, un contenitore può superare la sua richiesta di memoria. D'altra parte, un contenitore non può usare più memoria di quanto non abbia. Se un contenitore prende più memoria di quanto assegnato, verrà terminato. Il contenitore verrà rimosso se continua a utilizzare la memoria rispetto al limite. Il kubelet riavvia un contenitore terminato se può essere ripreso, molto simile a qualsiasi altra forma di fallimento del runtime.
Qui creeremo un pod. Questo pod proverà ad allocare più memoria di quanto non abbia già.
Il file di configurazione per un pod con un contenitore e una richiesta di memoria di 50 MIB e un limite di memoria di 100 MIB è il seguente:
Secondo la sezione Args del file di configurazione, il contenitore tenterà di allocare 250 MIB di RAM, significativamente al di sopra del limite di 100 MIB.
Ancora una volta, abbiamo creato il pod qui.
Qui puoi visualizzare le informazioni complete del pod. Il contenitore sia in esecuzione o no a questo punto. Ripetizione del comando precedente fino a quando non è richiesto il contenitore:
Ottieni uno sguardo più approfondito allo stato del contenitore. Secondo l'output, il contenitore è stato distrutto perché ha esaurito la memoria.
In questo esempio, il kubelet riavvia il contenitore perché può essere riavviato. Ripeti questo comando numerose volte per assicurarti che il contenitore venga ucciso e riavviato regolarmente. Secondo l'output, il contenitore viene ucciso, restaurato, ucciso di nuovo, ricominciato, ecc.
Il seguente comando consente di visualizzare informazioni complete relative alla cronologia del pod.
Il risultato rivela che il contenitore inizia costantemente e si ferma:
Qui puoi visualizzare le informazioni dettagliate sui nodi del tuo cluster:
Nell'output è incluso un record del contenitore a causa di un problema fuori memoria:
Questo comando elimina il baccello, come puoi vedere di seguito.
Cosa dovresti fare se hai una richiesta di memoria troppo grande per i tuoi nodi?
Le richieste di memoria e le limitazioni sono generalmente collegate ai contenitori, ma è anche utile pensare ai pod come avere richieste e restrizioni di memoria. La richiesta di memoria è definita come il totale di tutte le esigenze di memoria per tutti i contenitori nel pod.
I pod sono programmati e mantenuti tramite richieste.
Qui costruiremo un pod con una richiesta di memoria più grande di qualsiasi nodo nella capacità del cluster.
Ecco il file di configurazione per un pod, incluso un contenitore e una necessità di memoria di 1000 gib, che è probabilmente più di qualsiasi nodo nel cluster può gestire.
Il comando di applicazione seguente crea il baccello, come puoi vedere.
Ora utilizza il comando "get pod". Lo stato del pod è in sospeso (vedere l'output). Il pod non è impostato per eseguire su nessun nodo e rimarrà in corso indefinitamente.
Questo comando ti aiuterà a visualizzare maggiori dettagli sul pod, inclusi i prossimi eventi:
L'output dimostra che il contenitore non può essere programmato perché i nodi non hanno abbastanza memoria:
Cosa succede se non si specifica un limite di memoria?
Uno dei seguenti scenari si verifica se non si definisce un limite di memoria per un contenitore:
- Il contenitore non ha limiti a quanta ariete può utilizzare. Il killer OOM potrebbe essere attivato se il contenitore consuma tutta la memoria disponibile sul nodo in cui è in esecuzione. Inoltre, i vincoli di Acontainer senza risorse avranno un rischio più elevato di essere ucciso in caso di uccisione OOM.
- Il contenitore viene eseguito in uno spazio dei nomi con un limite di memoria predefinito e il limite predefinito viene applicato automaticamente al contenitore. Gli amministratori del cluster possono utilizzare un limite per impostare un numero predefinito per il limite di memoria.
Conclusione:
Abbiamo dato un'occhiata più da vicino all'errore Oomkilled di Kubernetes in questo articolo. Aiuta Kubernetes a gestire la memoria mentre pianifica i baccelli e decide quali pod distruggere quando le risorse diventano scarse.