Kubernetes ve Linux’ta OOMKill (\u00c7\u0131k\u0131\u015f Kodu 137)<\/p>\n
Kubernetes k\u00fcmelerinde \u00e7al\u0131\u015fan uygulamalar\u0131n\u0131z aniden \u00e7\u00f6k\u00fcyor ve hata loglar\u0131nda gizemli bir “Exit Code 137” hatas\u0131yla kar\u015f\u0131la\u015f\u0131yor musunuz? Bu, korkutucu g\u00f6r\u00fcnen ancak \u00e7\u00f6z\u00fclebilir bir sorun olan Out Of Memory (OOM) \u2013 Bellek Yetersizli\u011fi \u2013 hatas\u0131n\u0131n bir belirtisidir. Bu makalede, Kubernetes ve Linux sistemlerinde OOMKill olaylar\u0131n\u0131 ayr\u0131nt\u0131l\u0131 olarak inceleyecek, nedenlerini anlayacak ve bu sorunu \u00e7\u00f6zmek i\u00e7in ad\u0131m ad\u0131m stratejiler sunaca\u011f\u0131z. OOMKill hatas\u0131n\u0131n alt\u0131nda yatan nedenleri kavramak ve etkili \u00e7\u00f6z\u00fcmler uygulamak i\u00e7in okumaya devam edin.<\/p>\n
\u00d6ncelikle, OOMKill’in neden ortaya \u00e7\u0131kt\u0131\u011f\u0131n\u0131 anlamak i\u00e7in Kubernetes ve alt\u0131ndaki Linux \u00e7ekirde\u011finin bellek y\u00f6netimi mekanizmalar\u0131n\u0131 kavramam\u0131z gerekiyor. Linux, sanal bellek ad\u0131 verilen bir mekanizma kullanarak, fiziksel bellek miktar\u0131ndan daha fazla bellek kullan\u0131lmas\u0131na olanak tan\u0131r. Ancak, fiziksel bellek tamamen doldu\u011funda, \u00e7ekirdek OOM killer’\u0131 devreye sokar. OOM killer, sistem kaynaklar\u0131n\u0131 en fazla t\u00fcketen i\u015flemi tespit eder ve bu i\u015flemi zorla sonland\u0131r\u0131r. Bu i\u015flem, “Exit Code 137” olarak hata loglar\u0131nda g\u00f6r\u00fcn\u00fcr. Kubernetes, bu i\u015flemi konteyner seviyesinde y\u00f6netir; bir konteyner OOM’a girerse, Kubernetes onu sonland\u0131r\u0131r ve potansiyel olarak yeniden ba\u015flatmaya \u00e7al\u0131\u015f\u0131r. Ancak, s\u0131k tekrarlanan OOM olaylar\u0131, uygulaman\u0131z\u0131n istikrar\u0131n\u0131 ciddi \u015fekilde etkiler.<\/p>\n
Kubernetes’te, Pod’lar belirli miktarda kaynak talep eder (requests) ve s\u0131n\u0131rlar (limits) tan\u0131mlar. Talepler, Pod’un \u00e7al\u0131\u015fmas\u0131 i\u00e7in gereken minimum kaynaklar\u0131 temsil ederken, s\u0131n\u0131rlar, Pod’un kullanabilece\u011fi maksimum kaynaklar\u0131 belirtir. Bu s\u0131n\u0131rlamalar, kaynak t\u00fcketimi \u00fczerinde kontrol sa\u011flamak ve kaynak a\u00e7l\u0131\u011f\u0131 sorunlar\u0131n\u0131 \u00f6nlemek i\u00e7in kritik \u00f6neme sahiptir. Do\u011fru kaynak tahsisi ve s\u0131n\u0131rlama, OOMKill olaylar\u0131n\u0131 \u00f6nemli \u00f6l\u00e7\u00fcde azaltabilir.<\/p>\n
OOMKill olaylar\u0131n\u0131 tespit etmek i\u00e7in \u00f6ncelikle Kubernetes ve Linux sistem loglar\u0131n\u0131 incelemelisiniz. Kubernetes olay loglar\u0131nda, “OOMKilled” veya benzer bir ibare arayabilirsiniz. Linux sisteminde ise, Ba\u015fka bir \u00f6nemli y\u00f6ntem ise, sistem genelindeki bellek kullan\u0131m\u0131n\u0131 izlemektir. OOMKill olaylar\u0131n\u0131 \u00f6nlemek i\u00e7in birka\u00e7 strateji izleyebilirsiniz. \u00d6ncelikle, Pod’lar\u0131n\u0131z i\u00e7in uygun kaynak s\u0131n\u0131rlar\u0131n\u0131 ve taleplerini belirlemeniz \u00f6nemlidir. Pod’lar\u0131n\u0131z\u0131n ihtiya\u00e7 duydu\u011fu minimum kaynaklar\u0131 “requests” olarak ve maksimum kaynak s\u0131n\u0131r\u0131n\u0131 “limits” olarak tan\u0131mlayarak, kaynak t\u00fcketimini kontrol alt\u0131nda tutabilirsiniz. Bu de\u011ferleri do\u011fru belirlemek, hem kaynaklar\u0131n verimli kullan\u0131lmas\u0131n\u0131 sa\u011flar hem de OOMKill olaylar\u0131n\u0131 \u00f6nler. Ba\u015flang\u0131\u00e7ta, ger\u00e7ek\u00e7i bir \u015fekilde ba\u015flay\u0131n ve daha sonra ihtiyac\u0131n\u0131za g\u00f6re ayarlay\u0131n. Yetersiz kaynak s\u0131n\u0131rlar\u0131 OOMKill riskini art\u0131r\u0131rken, gereksiz yere y\u00fcksek s\u0131n\u0131rlar kaynak israf\u0131na yol a\u00e7abilir. Deney yaparak optimal de\u011feri bulmal\u0131s\u0131n\u0131z.<\/p>\n \u0130kinci olarak, uygulaman\u0131z\u0131n bellek kullan\u0131m\u0131n\u0131 optimize etmelisiniz. Bellek s\u0131z\u0131nt\u0131lar\u0131n\u0131 tespit edip gidermek, gereksiz nesneleri temizlemek ve verimli veri yap\u0131lar\u0131 kullanmak, bellek kullan\u0131m\u0131n\u0131 azaltabilir. Bellek kullan\u0131m\u0131 profil arac\u0131lar\u0131 kullanarak uygulaman\u0131z\u0131n bellek kullan\u0131m\u0131n\u0131 analiz edebilir ve performans sorunlar\u0131n\u0131 tespit edebilirsiniz. Profil ara\u00e7lar\u0131 sayesinde, bellek t\u00fcketen b\u00f6l\u00fcmleri belirleyip optimize edebilirsiniz. Bu optimizasyonlar, uygulaman\u0131z\u0131n daha az bellek t\u00fcketmesini sa\u011flayarak OOMKill riskini azalt\u0131r.<\/p>\n \u00dc\u00e7\u00fcnc\u00fc bir yakla\u015f\u0131m ise, yatay \u00f6l\u00e7eklendirmeyi (Horizontal Pod Autoscaling – HPA) kullanmakt\u0131r. Y\u00fcksek y\u00fck alt\u0131nda, HPA otomatik olarak daha fazla Pod olu\u015fturarak y\u00fck\u00fc da\u011f\u0131t\u0131r ve b\u00f6ylece tek bir Pod’un a\u015f\u0131r\u0131 y\u00fcklenmesini \u00f6nler. Bu, OOMKill riskini azaltmada olduk\u00e7a etkili bir y\u00f6ntemdir. HPA’y\u0131 do\u011fru yap\u0131land\u0131rmak i\u00e7in, CPU kullan\u0131m\u0131n\u0131 veya bellek kullan\u0131m\u0131n\u0131 izleyen metrikleri tan\u0131mlaman\u0131z gerekecektir.<\/p>\n OOMKill’i \u00e7\u00f6zmek i\u00e7in daha derinlemesine y\u00f6ntemlere ihtiya\u00e7 duyabilirsiniz. \u00d6ncelikle, Linux \u00e7ekirde\u011finin OOM killer algoritmas\u0131n\u0131 anlamak<\/strong> kritik \u00f6neme sahiptir. \u00c7ekirdek, OOM olaylar\u0131nda hangi i\u015flemi \u00f6ld\u00fcrece\u011fine karar verirken farkl\u0131 algoritmalar kullan\u0131r. Bu algoritmalar\u0131 anlamak ve nas\u0131l de\u011fi\u015ftirilebilece\u011fini \u00f6\u011frenmek, baz\u0131 durumlarda sorunu \u00e7\u00f6zebilir. Bununla birlikte, \u00e7ekirdek parametrelerinde de\u011fi\u015fiklik yapmadan \u00f6nce, iyice ara\u015ft\u0131rma yapmal\u0131 ve sisteminizin kararl\u0131l\u0131\u011f\u0131n\u0131 riske atmamal\u0131s\u0131n\u0131z.<\/p>\n Bellek kullan\u0131m\u0131n\u0131 daha detayl\u0131 izlemek<\/strong> i\u00e7in \u00f6zel ara\u00e7lar kullanabilirsiniz. Konteyner \u00e7al\u0131\u015ft\u0131rma stratejilerinizi g\u00f6zden ge\u00e7irin<\/strong>. \u00d6zellikle durumsuz uygulamalarda, konteynerlerin restart politikalar\u0131 OOMKill durumlar\u0131nda kritik \u00f6neme sahiptir. Bir e-ticaret uygulamas\u0131 d\u00fc\u015f\u00fcnelim. Y\u00fcksek trafik d\u00f6nemlerinde, uygulaman\u0131n veritaban\u0131 ba\u011flant\u0131lar\u0131 ve oturum y\u00f6netimi kaynak t\u00fcketimini art\u0131r\u0131yor. Bu durum, Pod’lar\u0131n bellek s\u0131n\u0131rlar\u0131n\u0131 a\u015fmas\u0131na ve OOMKill hatas\u0131na yol a\u00e7\u0131yor. Bu sorunu \u00e7\u00f6zmek i\u00e7in, \u00f6ncelikle uygulaman\u0131n bellek kullan\u0131m\u0131n\u0131 analiz ettik. Profil ara\u00e7lar\u0131 sayesinde, veritaban\u0131 sorgular\u0131nda optimizasyon yap\u0131lmas\u0131 gerekti\u011fini ve oturum y\u00f6netimi i\u00e7in daha verimli bir y\u00f6ntem kullan\u0131lmas\u0131 gerekti\u011fini tespit ettik. Uygulama kodu optimize edildikten sonra, Pod’lara daha uygun bellek s\u0131n\u0131rlar\u0131 belirledik ve yatay \u00f6l\u00e7eklendirmeyi etkinle\u015ftirdik. Bu ad\u0131mlar\u0131n ard\u0131ndan OOMKill hatalar\u0131 ortadan kalkt\u0131 ve uygulama kararl\u0131 hale geldi. Bu \u00f6rnekte oldu\u011fu gibi, sorunu \u00e7\u00f6zmek i\u00e7in ad\u0131m ad\u0131m analiz ve do\u011fru strateji belirlemek olduk\u00e7a \u00f6nemlidir.<\/p>\n\/var\/log\/kern.log<\/code> veya \/var\/log\/messages<\/code> dosyalar\u0131n\u0131 inceleyerek OOM olaylar\u0131na ait mesajlar\u0131 bulabilirsiniz. Bu loglar, hangi Pod’un OOM’a maruz kald\u0131\u011f\u0131n\u0131 ve ne kadar bellek kulland\u0131\u011f\u0131n\u0131 g\u00f6sterir. Bunun yan\u0131 s\u0131ra, kubectl describe pod top<\/code> veya htop<\/code> gibi komutlar, ger\u00e7ek zamanl\u0131 bellek kullan\u0131m\u0131n\u0131 g\u00f6sterir. Bu komutlar ile, sisteminizde bellek t\u00fcketiminin y\u00fcksek olup olmad\u0131\u011f\u0131n\u0131 ve hangi s\u00fcre\u00e7lerin en fazla bellek kulland\u0131\u011f\u0131n\u0131 g\u00f6zlemleyebilirsiniz. Y\u00fcksek bellek kullan\u0131m\u0131, OOMKill olaylar\u0131n\u0131n olu\u015fma riskini art\u0131r\u0131r. Bu durumu anlamak i\u00e7in, sisteminizin toplam bellek kapasitesini ve mevcut kullan\u0131labilir belle\u011fi kar\u015f\u0131la\u015ft\u0131rman\u0131z gerekecektir.<\/p>\nOOMKill’i \u00d6nlemek \u0130\u00e7in Pratik Ad\u0131mlar<\/h2>\n
\u0130leri D\u00fczey OOMKill Sorun Giderme Teknikleri<\/h2>\n
smem<\/code> veya top<\/code> gibi komutlar, s\u00fcre\u00e7lerin bellek kullan\u0131m\u0131n\u0131 detayl\u0131 olarak g\u00f6sterir. Bu ara\u00e7lar sayesinde, hangi s\u00fcre\u00e7lerin a\u015f\u0131r\u0131 bellek t\u00fcketti\u011fini daha net bir \u015fekilde g\u00f6rebilir ve sorun giderme s\u00fcrecini h\u0131zland\u0131rabilirsiniz. Ayr\u0131ca, sistem performans\u0131n\u0131 izlemek i\u00e7in, Prometheus ve Grafana gibi izleme ara\u00e7lar\u0131n\u0131 kullanabilirsiniz. Bu ara\u00e7lar, kaynak t\u00fcketimini ger\u00e7ek zamanl\u0131 olarak g\u00f6rselle\u015ftirerek, sorunlar\u0131 daha h\u0131zl\u0131 tespit etmenize yard\u0131mc\u0131 olur.<\/p>\nAlways<\/code> restart politikas\u0131, konteynerin her OOM’dan sonra yeniden ba\u015flat\u0131lmas\u0131n\u0131 sa\u011flar. Ancak bu durumun a\u015f\u0131r\u0131 y\u00fcklenme riski ile sonu\u00e7lanabilece\u011fini unutmay\u0131n. Durumunuz i\u00e7in en uygun restart politikas\u0131n\u0131 se\u00e7mek \u00f6nemlidir. Bir di\u011fer geli\u015fmi\u015f teknik ise, resource quotas<\/strong> ve limit ranges<\/strong> kullanarak, belirli namespace’lerde veya kullan\u0131c\u0131lar i\u00e7in kaynak kullan\u0131m\u0131n\u0131 s\u0131n\u0131rlamakt\u0131r. Bu sayede, tek bir Pod’un t\u00fcm kaynaklar\u0131 t\u00fcketmesini engelleyebilirsiniz. Bu teknik, \u00f6zellikle \u00e7oklu tenant ortamlar\u0131nda \u00e7ok \u00f6nemlidir. Ayr\u0131ca, uygulaman\u0131z\u0131 optimize ederek ve kaynak kullan\u0131m\u0131n\u0131 azaltarak, OOMKill olas\u0131l\u0131\u011f\u0131n\u0131 minimuma indirebilirsiniz.<\/p>\nGer\u00e7ek D\u00fcnya Vaka Analizi: Bir E-ticaret Uygulamas\u0131<\/h2>\n
\u00d6\u011frenme Yol Haritas\u0131<\/h2>\n
Yeni Ba\u015flayanlar \u0130\u00e7in:<\/h3>\n