{"id":31173,"date":"2025-10-06T20:31:48","date_gmt":"2025-10-06T17:31:48","guid":{"rendered":"https:\/\/fatihsoysal.com\/blog\/oomkilled-podlar-kuberneteste-sorun-giderme-rehberi\/"},"modified":"2025-10-06T20:31:48","modified_gmt":"2025-10-06T17:31:48","slug":"oomkilled-podlar-kuberneteste-sorun-giderme-rehberi","status":"publish","type":"post","link":"https:\/\/fatihsoysal.com\/blog\/oomkilled-podlar-kuberneteste-sorun-giderme-rehberi\/","title":{"rendered":"OOMKilled Pod’lar: Kubernetes’te Sorun Giderme Rehberi"},"content":{"rendered":"

<\/p>\n

Kubernetes ortamlar\u0131nda kar\u015f\u0131la\u015f\u0131lan en sinir bozucu durumlardan biri olan OOMKilled<\/code> pod’lar, uygulamalar\u0131n\u0131z\u0131n beklenmedik bir \u015fekilde kapanmas\u0131na neden olabilir. Bu kapsaml\u0131 rehber, bellek y\u00f6netimi, kaynak k\u0131s\u0131tlamalar\u0131 ve ad\u0131m ad\u0131m sorun giderme tekniklerini i\u00e7ererek bu yayg\u0131n Kubernetes sorununu anlaman\u0131za ve \u00e7\u00f6zmenize yard\u0131mc\u0131 olacakt\u0131r.<\/p>\n

Modern bulut altyap\u0131lar\u0131n\u0131n kalbi say\u0131lan Kubernetes, uygulamalar\u0131n da\u011f\u0131t\u0131m\u0131n\u0131, \u00f6l\u00e7eklendirilmesini ve y\u00f6netimini basitle\u015ftirir. Ancak bu karma\u015f\u0131k orkestrasyon sistemi i\u00e7erisinde zaman zaman \u00e7\u00f6z\u00fclmesi gereken zorluklar ortaya \u00e7\u0131kar. \u0130\u015fte bu zorluklardan biri de \u201cOut Of Memory Killed\u201d veya k\u0131saca OOMKilled<\/code> olarak bilinen durumdur. Bir pod’un OOMKilled<\/code> olmas\u0131, \u00e7al\u0131\u015ft\u0131\u011f\u0131 d\u00fc\u011f\u00fcmdeki i\u015fletim sisteminin (Linux kernel) belle\u011fi t\u00fckenen bir uygulamay\u0131 zorla sonland\u0131rmas\u0131 anlam\u0131na gelir. Bu durum, uygulaman\u0131z\u0131n aniden kapanmas\u0131na, hizmet kesintilerine ve kullan\u0131c\u0131 deneyiminin olumsuz etkilenmesine yol a\u00e7abilir.<\/p>\n

Peki, uygulaman\u0131z neden bu duruma d\u00fc\u015f\u00fcyor ve Kubernetes’te \u00e7al\u0131\u015fan pod’lar\u0131n\u0131z neden aniden bellek yetersizli\u011finden kapan\u0131yor? Bu sorular\u0131n yan\u0131tlar\u0131, hem uygulaman\u0131z\u0131n bellek kullan\u0131m al\u0131\u015fkanl\u0131klar\u0131nda hem de Kubernetes k\u00fcmenizin kaynak y\u00f6netim politikalar\u0131nda gizli olabilir. Genellikle, bir pod’un bellek yetersizli\u011finden \u00f6lmesi, kaynak limitlerinin yanl\u0131\u015f belirlenmesi, uygulaman\u0131n beklenenden daha fazla bellek t\u00fcketmesi (bellek s\u0131z\u0131nt\u0131s\u0131 gibi) veya d\u00fc\u011f\u00fcmdeki genel bellek bask\u0131s\u0131 gibi \u00e7e\u015fitli fakt\u00f6rlerden kaynaklanabilir. Bu t\u00fcr olaylar, yaln\u0131zca hizmet kesintisi yaratmakla kalmaz, ayn\u0131 zamanda sorun giderme s\u00fcre\u00e7lerini uzatarak geli\u015ftirme ve operasyon ekipleri i\u00e7in gereksiz yere zaman ve enerji kayb\u0131na neden olur.<\/p>\n

Bu rehberde, OOMKilled<\/code> pod’lar\u0131n temel nedenlerini, Kubernetes’in bellek y\u00f6netimi prensiplerini ve bu t\u00fcr sorunlar\u0131 etkili bir \u015fekilde nas\u0131l te\u015fhis edip \u00e7\u00f6zebilece\u011finizi ad\u0131m ad\u0131m inceleyece\u011fiz. Amac\u0131m\u0131z, hem yeni ba\u015flayanlar hem de deneyimli Kubernetes kullan\u0131c\u0131lar\u0131 i\u00e7in pratik bilgiler sunarak, sistemlerinizi daha kararl\u0131 ve verimli hale getirmenize yard\u0131mc\u0131 olmakt\u0131r. Gelin, bu karma\u015f\u0131k g\u00f6r\u00fcnen sorunun perde arkas\u0131n\u0131 aralayal\u0131m ve uygulamalar\u0131n\u0131z\u0131n kesintisiz \u00e7al\u0131\u015fmas\u0131n\u0131 sa\u011flayacak \u00e7\u00f6z\u00fcmleri birlikte ke\u015ffedelim.<\/p>\n

Temel Kavramlar: Kubernetes’te Bellek Y\u00f6netimi ve OOM Killer Nas\u0131l \u0130\u015fler?<\/h2>\n

OOMKilled<\/code> sorunlar\u0131n\u0131 anlamak i\u00e7in \u00f6ncelikle Kubernetes’in ve alt\u0131nda yatan Linux i\u015fletim sisteminin bellek y\u00f6netimini nas\u0131l ele ald\u0131\u011f\u0131n\u0131 kavramak esast\u0131r. Bu temel bilgiler, sorun giderme s\u00fcrecinde do\u011fru y\u00f6n\u00fc bulman\u0131z i\u00e7in kritik bir temel olu\u015fturacakt\u0131r.<\/p>\n

Kubernetes Bellek Kaynaklar\u0131: requests<\/code> ve limits<\/code><\/h3>\n

Kubernetes, pod’lar\u0131n kaynak t\u00fcketimini kontrol etmek i\u00e7in g\u00fc\u00e7l\u00fc mekanizmalar sunar. Bu mekanizmalar\u0131n ba\u015f\u0131nda requests<\/code> ve limits<\/code> kavramlar\u0131 gelir. Bu kavramlar, bir pod’un ne kadar bellek (ve CPU) talep etti\u011fini (requests<\/code>) ve maksimum ne kadar kullanabilece\u011fini (limits<\/code>) belirtmenize olanak tan\u0131r.<\/p>\n

    \n
  • requests.memory<\/code>:<\/strong> Bir pod’un bir d\u00fc\u011f\u00fcm \u00fczerinde \u00e7al\u0131\u015fabilmesi i\u00e7in garantilenen minimum bellek miktar\u0131d\u0131r. Kubernetes scheduler’\u0131, pod’u yerle\u015ftirirken bu de\u011feri dikkate al\u0131r. Yani, bir d\u00fc\u011f\u00fcmde pod’unuzun talep etti\u011fi bellek miktar\u0131 kadar bo\u015f yer yoksa, pod o d\u00fc\u011f\u00fcme yerle\u015ftirilemez.<\/li>\n
  • limits.memory<\/code>:<\/strong> Bir pod’un kullanabilece\u011fi maksimum bellek miktar\u0131d\u0131r. E\u011fer bir pod, kendisine atanan bu limiti a\u015fmaya \u00e7al\u0131\u015f\u0131rsa, Linux kernel’\u0131n\u0131n OOM Killer’\u0131 devreye girer ve o pod’u sonland\u0131r\u0131r. Bu, di\u011fer pod’lar\u0131n ve d\u00fc\u011f\u00fcm\u00fcn genel stabilitesinin korunmas\u0131 i\u00e7in hayati bir mekanizmad\u0131r.<\/li>\n<\/ul>\n

    Bu de\u011ferleri YAML dosyan\u0131zda a\u015fa\u011f\u0131daki gibi belirtirsiniz:<\/p>\n

    \napiVersion: v1\nkind: Pod\nmetadata:\n  name: my-app-pod\nspec:\n  containers:\n  - name: my-app\n    image: my-app-image:latest\n    resources:\n      requests:\n        memory: \"128Mi\"\n        cpu: \"250m\"\n      limits:\n        memory: \"256Mi\"\n        cpu: \"500m\"\n    <\/pre>\n
    <\/code><\/p>\n
    Burada 128Mi<\/code> (mebibyte) bellek talep edildi\u011fini, 256Mi<\/code> ise limit olarak belirlendi\u011fini g\u00f6r\u00fcyoruz. CPU i\u00e7in de benzer bir yap\u0131 mevcuttur; 250m<\/code> (250 milicore) CPU talep edilirken, 500m<\/code> (500 milicore) limit olarak atanm\u0131\u015ft\u0131r.<\/p>\n
    QoS S\u0131n\u0131flar\u0131 ve \u00d6nemi<\/h3>\n
    Kubernetes, pod'lar\u0131 bellek ve CPU kaynaklar\u0131na olan taleplerine ve limitlerine g\u00f6re \u00fc\u00e7 farkl\u0131 Kalite Hizmet (QoS) s\u0131n\u0131f\u0131na ay\u0131r\u0131r:<\/p>\n
      \n
    1. Guaranteed (Garantili):<\/strong> Bu s\u0131n\u0131ftaki pod'lar, hem requests<\/code> hem de limits<\/code> de\u011ferlerinin CPU ve bellek i\u00e7in e\u015fit olarak ayarlanm\u0131\u015f olmas\u0131 durumunda atan\u0131r. Bu pod'lar, kaynaklar konusunda en y\u00fcksek garantiyi al\u0131r ve OOM Killer taraf\u0131ndan en son sonland\u0131r\u0131l\u0131rlar. Bir d\u00fc\u011f\u00fcmde bellek bask\u0131s\u0131 oldu\u011funda, bu pod'lar genellikle en g\u00fcvenli durumdad\u0131r.<\/li>\n
    2. Burstable (Patlamal\u0131):<\/strong> requests<\/code> de\u011ferleri belirtilmi\u015f ancak limits<\/code> de\u011ferleri requests<\/code>'ten daha y\u00fcksek veya hi\u00e7 belirtilmemi\u015fse bu s\u0131n\u0131fa girerler. Bu pod'lar, talep ettikleri kaynaklar\u0131n \u00fczerinde bellek kullanabilirler (limitlerine kadar). Ancak, d\u00fc\u011f\u00fcmde bellek s\u0131k\u0131nt\u0131s\u0131 ya\u015fand\u0131\u011f\u0131nda, Guaranteed pod'lardan sonra OOM Killer'\u0131n hedefi olma olas\u0131l\u0131klar\u0131 daha y\u00fcksektir.<\/li>\n
    3. BestEffort (En \u0130yi \u00c7aba):<\/strong> CPU ve bellek i\u00e7in hi\u00e7bir requests<\/code> veya limits<\/code> belirtilmemi\u015fse bu s\u0131n\u0131fa girerler. Bu pod'lar en d\u00fc\u015f\u00fck \u00f6nceli\u011fe sahiptir ve d\u00fc\u011f\u00fcmde bellek s\u0131k\u0131nt\u0131s\u0131 oldu\u011funda OOM Killer taraf\u0131ndan ilk sonland\u0131r\u0131lacak olanlard\u0131r. Genellikle d\u00fc\u015f\u00fck \u00f6ncelikli veya geli\u015ftirme ortam\u0131 uygulamalar\u0131 i\u00e7in kullan\u0131l\u0131r.<\/li>\n<\/ol>\n
      QoS s\u0131n\u0131f\u0131, bir d\u00fc\u011f\u00fcmde bellek yetersizli\u011fi ya\u015fand\u0131\u011f\u0131nda pod'unuzun hayatta kalma \u015fans\u0131n\u0131 do\u011frudan etkiler. Bu nedenle, kritik uygulamalar\u0131n\u0131z i\u00e7in genellikle Guaranteed<\/code> veya iyi ayarlanm\u0131\u015f Burstable<\/code> s\u0131n\u0131flar\u0131 hedeflenmelidir.<\/p>\n
      OOMKilled Pod'lar\u0131n Kayna\u011f\u0131n\u0131 Nas\u0131l Tespit Edersiniz? Kapsaml\u0131 Te\u015fhis Y\u00f6ntemleri<\/h2>\n
      OOMKilled<\/code> bir pod ile kar\u015f\u0131la\u015ft\u0131\u011f\u0131n\u0131zda, sorunun k\u00f6k nedenini do\u011fru bir \u015fekilde belirlemek, etkili bir \u00e7\u00f6z\u00fcm bulman\u0131n ilk ad\u0131m\u0131d\u0131r. Bu b\u00f6l\u00fcmde, yayg\u0131n nedenleri ve bu sorunlar\u0131 te\u015fhis etmek i\u00e7in kullanabilece\u011finiz Kubernetes ara\u00e7lar\u0131n\u0131 ve metrikleri ele alaca\u011f\u0131z.<\/p>\n
      Yayg\u0131n Nedenler ve \u0130lk Kontrol Noktalar\u0131<\/h3>\n
      OOMKilled<\/code> olaylar\u0131n\u0131n birka\u00e7 temel nedeni olabilir:<\/p>\n
        \n
      1. Uygulama Bellek S\u0131z\u0131nt\u0131s\u0131:<\/strong> Belki de en yayg\u0131n nedendir. Uygulaman\u0131zdaki bir hata nedeniyle bellek do\u011fru \u015fekilde serbest b\u0131rak\u0131lm\u0131yor ve zamanla bellek t\u00fcketimi artarak limitleri a\u015f\u0131yor.<\/li>\n
      2. Yanl\u0131\u015f Ayarlanm\u0131\u015f Kaynak Limitleri:<\/strong> Geli\u015ftiriciler veya operasyon ekipleri, uygulaman\u0131n ger\u00e7ek bellek ihtiyac\u0131n\u0131 do\u011fru tahmin edemeyebilir ve gere\u011finden d\u00fc\u015f\u00fck bir limits.memory<\/code> de\u011feri belirlemi\u015f olabilirler.<\/li>\n
      3. Anl\u0131k Bellek Y\u00fcksekli\u011fi (Spike):<\/strong> Uygulaman\u0131z normalde d\u00fc\u015f\u00fck bellek t\u00fcketse de, yo\u011fun y\u00fck alt\u0131nda veya belirli i\u015flemler s\u0131ras\u0131nda anl\u0131k olarak bellek t\u00fcketimi artabilir ve limitleri a\u015fabilir.<\/li>\n
      4. D\u00fc\u011f\u00fcmdeki Genel Bellek Bask\u0131s\u0131:<\/strong> \u00c7ok say\u0131da pod'un \u00e7al\u0131\u015ft\u0131\u011f\u0131 bir d\u00fc\u011f\u00fcmde, genel bellek kullan\u0131m\u0131 \u00e7ok y\u00fcksekse, OOM Killer'\u0131n devreye girme olas\u0131l\u0131\u011f\u0131 artar, \u00f6zellikle BestEffort veya Burstable pod'lar i\u00e7in.<\/li>\n
      5. Yanl\u0131\u015f Image Kullan\u0131m\u0131 veya Ba\u011f\u0131ml\u0131l\u0131klar:<\/strong> Bazen, kullan\u0131lan Docker imaj\u0131n\u0131n kendisi veya i\u00e7erdi\u011fi ba\u011f\u0131ml\u0131l\u0131klar beklenenden daha fazla bellek t\u00fcketebilir.<\/li>\n<\/ol>\n
        \u0130lk olarak, pod'unuzun durumunu kontrol edin:<\/p>\n
        \nkubectl get pods -n \n    <\/pre>\n
        <\/code><\/p>\n
        E\u011fer bir pod OOMKilled<\/code> olduysa, status s\u00fctununda CrashLoopBackOff<\/code> veya OOMKilled<\/code> gibi bir ifade g\u00f6rebilirsiniz. Ard\u0131ndan, detayl\u0131 bilgi i\u00e7in kubectl describe<\/code> komutunu kullan\u0131n:<\/p>\n
        \nkubectl describe pod  -n \n    <\/pre>\n
        <\/code><\/p>\n
        Bu komutun \u00e7\u0131kt\u0131s\u0131nda, Events<\/code> b\u00f6l\u00fcm\u00fcne dikkat edin. Burada Reason: OOMKilled<\/code> ve Message: Container  was OOMKilled<\/code> gibi mesajlar g\u00f6rmelisiniz. Ayr\u0131ca, pod'unuzun kaynak limitlerini ve taleplerini (resources<\/code> b\u00f6l\u00fcm\u00fc alt\u0131nda) kontrol etti\u011finizden emin olun.<\/p>\n
        Kubernetes Ara\u00e7lar\u0131yla Bellek Kullan\u0131m\u0131n\u0131 \u0130zleme<\/h3>\n
        Sadece OOMKilled<\/code> oldu\u011funu bilmek yetmez, ne zaman ve ne kadar bellek kulland\u0131\u011f\u0131n\u0131 da anlamam\u0131z gerekir. \u0130\u015fte bu noktada loglar ve metrikler devreye girer.<\/p>\n
          \n
        • Pod Loglar\u0131n\u0131 \u0130nceleme:<\/strong> Pod'unuzun loglar\u0131, uygulaman\u0131n bellek yetersizli\u011fi ya\u015famadan \u00f6nceki davran\u0131\u015flar\u0131 hakk\u0131nda de\u011ferli ipu\u00e7lar\u0131 verebilir.<\/li>\n
          \nkubectl logs  -n  --previous\n            <\/pre>\n
          <\/code><\/p>\n
          --previous<\/code> bayra\u011f\u0131, pod yeniden ba\u015flat\u0131lm\u0131\u015f olsa bile \u00f6nceki konteyner\u0131n loglar\u0131n\u0131 g\u00f6rmenizi sa\u011flar. Uygulaman\u0131z\u0131n bellek kullan\u0131m\u0131na dair hata mesajlar\u0131 veya anormal davran\u0131\u015flar olup olmad\u0131\u011f\u0131n\u0131 kontrol edin.<\/p>\n
        • Metrik Toplama ve \u0130zleme Sistemleri:<\/strong> Prometheus, Grafana gibi sistemler, Kubernetes k\u00fcmelerindeki t\u00fcm pod'lar\u0131n ve d\u00fc\u011f\u00fcmlerin kaynak t\u00fcketimini anl\u0131k olarak izlemek i\u00e7in vazge\u00e7ilmezdir. \u00d6zellikle, container_memory_usage_bytes<\/code> ve container_memory_working_set_bytes<\/code> gibi metrikler, bir pod'un bellek t\u00fcketimini ve limitlerine ne kadar yakla\u015ft\u0131\u011f\u0131n\u0131 g\u00f6rselle\u015ftirmenize yard\u0131mc\u0131 olur.\n
          \n              Uzman \u0130pucu: Bellek metriklerini izlerken sadece anl\u0131k t\u00fcketimi de\u011fil, ayn\u0131 zamanda zaman i\u00e7indeki e\u011filimleri de de\u011ferlendirin. S\u00fcrekli artan bir bellek t\u00fcketimi, bir bellek s\u0131z\u0131nt\u0131s\u0131n\u0131n habercisi olabilir.\n            <\/div>\n<\/li>\n
        • kubectl top<\/code> Komutu:<\/strong> Basit bir h\u0131zl\u0131 kontrol i\u00e7in kubectl top<\/code> komutunu kullanabilirsiniz.\n
          \nkubectl top pod  --containers -n \nkubectl top node\n            <\/pre>\n
          <\/code><\/p>\n
          Bu komutlar, pod'lar\u0131n ve d\u00fc\u011f\u00fcmlerin anl\u0131k CPU ve bellek kullan\u0131mlar\u0131n\u0131 g\u00f6sterir. Ancak, bu anl\u0131k bir g\u00f6r\u00fcnt\u00fcd\u00fcr ve ge\u00e7mi\u015f verileri sa\u011flamaz.<\/p>\n<\/ul>\n
          Vaka Analizi 1: Yanl\u0131\u015f Konfig\u00fcre Edilmi\u015f Kaynak Limitlerinin Dramas\u0131<\/h3>\n
          Bir e-ticaret uygulamas\u0131n\u0131n arama motoru bile\u015feni (Solr tabanl\u0131) genellikle stabil \u00e7al\u0131\u015f\u0131yordu. Ancak, \u00f6zellikle Black Friday gibi yo\u011fun al\u0131\u015fveri\u015f d\u00f6nemlerinde, pod'lar s\u00fcrekli olarak OOMKilled<\/code> olmaya ba\u015flad\u0131. Geli\u015ftiriciler ilk ba\u015fta uygulaman\u0131n bellek s\u0131z\u0131nt\u0131s\u0131 oldu\u011funu d\u00fc\u015f\u00fcnd\u00fcler ve loglar\u0131 kontrol ettiler, ancak belirgin bir s\u0131z\u0131nt\u0131 i\u015faretine rastlamad\u0131lar. Sonunda, kubectl describe pod<\/code> komutuyla pod'un tan\u0131mlamas\u0131n\u0131 incelediklerinde, a\u015fa\u011f\u0131daki kaynak limitlerini g\u00f6rd\u00fcler:<\/p>\n
          \nresources:\n  requests:\n    memory: \"512Mi\"\n  limits:\n    memory: \"768Mi\"\n    <\/pre>\n
          <\/code><\/p>\n
          Ard\u0131ndan, Prometheus ve Grafana \u00fczerinden Solr pod'unun bellek kullan\u0131m metriklerini incelediler. Normal zamanda ortalama 400-500 MiB bellek kullanan Solr, yo\u011fun y\u00fck alt\u0131nda anl\u0131k olarak 800-950 MiB'ye kadar \u00e7\u0131kabiliyordu. limits.memory<\/code> de\u011feri 768Mi<\/code> oldu\u011fu i\u00e7in, bu anl\u0131k y\u00fckselmeler do\u011frudan OOM Killer'\u0131 tetikliyordu. \u00c7\u00f6z\u00fcm, limits.memory<\/code> de\u011ferini 1Gi<\/code> (1024Mi) olarak art\u0131rmak oldu. Bu de\u011fi\u015fiklikten sonra, yo\u011fun y\u00fck alt\u0131nda dahi Solr pod'lar\u0131 stabil bir \u015fekilde \u00e7al\u0131\u015fmaya devam etti. Bu vaka, uygulama davran\u0131\u015f\u0131n\u0131 do\u011fru anlamadan rastgele limitler belirlemenin ne kadar riskli olabilece\u011fini a\u00e7\u0131k\u00e7a g\u00f6stermektedir. Metrikler olmadan bu sorunu te\u015fhis etmek \u00e7ok daha zor olurdu.<\/p>\n
          Ad\u0131m Ad\u0131m \u00c7\u00f6z\u00fcmler: OOMKilled Olaylar\u0131n\u0131 Kal\u0131c\u0131 Olarak Engelleme Stratejileri<\/h2>\n
          OOMKilled sorunlar\u0131n\u0131n nedenini tespit ettikten sonra, s\u0131ra kal\u0131c\u0131 \u00e7\u00f6z\u00fcmler uygulamaya gelir. Bu \u00e7\u00f6z\u00fcmler, kaynak y\u00f6netiminden uygulama optimizasyonuna kadar geni\u015f bir yelpazeyi kapsar ve genellikle iteratif bir yakla\u015f\u0131mla en iyi sonu\u00e7lar\u0131 verir.<\/p>\n
          Kaynak Limitlerinizi Do\u011fru \u015eekilde Nas\u0131l Ayarlars\u0131n\u0131z?<\/h3>\n
          Kaynak limitlerini ayarlamak, OOMKilled<\/code> olaylar\u0131n\u0131 \u00f6nlemenin en do\u011frudan yollar\u0131ndan biridir. Ancak bu, geli\u015fig\u00fczel bir art\u0131rma meselesi de\u011fildir; dikkatli bir analiz gerektirir.<\/p>\n
            \n
          1. Ger\u00e7ek T\u00fcketimi Anlay\u0131n:<\/strong> \u0130lk ad\u0131m, uygulaman\u0131z\u0131n ger\u00e7ek bellek kullan\u0131m\u0131n\u0131 anlamakt\u0131r. Prometheus, Grafana veya di\u011fer izleme ara\u00e7lar\u0131 arac\u0131l\u0131\u011f\u0131yla pod'unuzun belirli bir s\u00fcre boyunca (birka\u00e7 g\u00fcn veya bir hafta) bellek kullan\u0131m grafi\u011fini inceleyin. En y\u00fcksek bellek t\u00fcketimi (peak usage) ne kadar oluyor? Ortalama t\u00fcketim ne kadar?<\/li>\n
          2. requests<\/code> ve limits<\/code> Fark\u0131:<\/strong>\n
              \n
            • requests.memory<\/code>:<\/strong> Pod'unuzun ortalama bellek t\u00fcketiminin biraz \u00fczerinde bir de\u011fer belirleyin. Bu, pod'unuzun d\u00fc\u011f\u00fcm \u00fczerinde garantili bir alana sahip olmas\u0131n\u0131 sa\u011flar.<\/li>\n
            • limits.memory<\/code>:<\/strong> Uygulaman\u0131z\u0131n g\u00f6zlemlenen en y\u00fcksek bellek t\u00fcketiminin (peak usage) \u00fczerinde, ancak \u00e7ok da abart\u0131l\u0131 olmayan bir de\u011fer belirleyin. \u00d6rne\u011fin, peak kullan\u0131m 700 MiB ise, 900 MiB veya 1 GiB olarak belirleyebilirsiniz. Bu, uygulaman\u0131z\u0131n anl\u0131k y\u00fcksek bellek kullan\u0131m\u0131n\u0131 kar\u015f\u0131lamas\u0131na izin verirken, kontrols\u00fcz bellek s\u0131z\u0131nt\u0131lar\u0131n\u0131 da yakalamaya yard\u0131mc\u0131 olur. A\u015f\u0131r\u0131 y\u00fcksek limitler belirlemek, d\u00fc\u011f\u00fcmdeki di\u011fer pod'lar\u0131n kaynak eksikli\u011fi ya\u015famas\u0131na veya d\u00fc\u011f\u00fcm\u00fcn genel olarak karars\u0131z hale gelmesine neden olabilir.<\/li>\n<\/ul>\n<\/li>\n
            • \u0130teratif Yakla\u015f\u0131m:<\/strong> Kaynak limitlerini bir kez ayarlay\u0131p b\u0131rakmay\u0131n. De\u011fi\u015fiklikleri uygulad\u0131ktan sonra sistemi izlemeye devam edin. E\u011fer hala OOMKilled<\/code> olaylar\u0131 ya\u015fan\u0131yorsa, limitleri tekrar de\u011ferlendirin veya sorunun ba\u015fka bir yerde (uygulama s\u0131z\u0131nt\u0131s\u0131 gibi) olup olmad\u0131\u011f\u0131n\u0131 ara\u015ft\u0131r\u0131n.<\/li>\n<\/ol>\n
              \n# \u00d6rnek: Optimize edilmi\u015f kaynak limitleri\nresources:\n  requests:\n    memory: \"750Mi\" # Ortalama kullan\u0131m\u0131n \u00fczerinde\n  limits:\n    memory: \"1Gi\"  # Peak kullan\u0131m\u0131n \u00fczerinde, g\u00fcvenli bir marj ile\n    <\/pre>\n
              <\/code><\/p>\n
              Uygulama D\u00fczeyinde Bellek Optimizasyonlar\u0131<\/h3>\n
              Bazen sorun Kubernetes konfig\u00fcrasyonunda de\u011fil, uygulaman\u0131n kendisindedir. Uygulama kodunda yap\u0131lacak optimizasyonlar, bellek kullan\u0131m\u0131n\u0131 \u00f6nemli \u00f6l\u00e7\u00fcde azaltabilir.<\/p>\n
                \n
              • Bellek S\u0131z\u0131nt\u0131lar\u0131n\u0131 Tespit Etme:<\/strong> Geli\u015ftiriciler, uygulaman\u0131n bellek s\u0131z\u0131nt\u0131lar\u0131n\u0131 tespit etmek i\u00e7in profil olu\u015fturma ara\u00e7lar\u0131n\u0131 (profilers) kullanmal\u0131d\u0131r. Java i\u00e7in VisualVM, Python i\u00e7in memory_profiler, Node.js i\u00e7in Chrome DevTools gibi ara\u00e7lar yard\u0131mc\u0131 olabilir.<\/li>\n
              • Garbage Collection Ayarlar\u0131:<\/strong> \u00d6zellikle Java gibi dillerde, Garbage Collector (GC) ayarlar\u0131 bellek kullan\u0131m\u0131n\u0131 ve performans\u0131 b\u00fcy\u00fck \u00f6l\u00e7\u00fcde etkileyebilir. Do\u011fru GC algoritmas\u0131n\u0131 ve parametrelerini se\u00e7mek, bellek s\u0131z\u0131nt\u0131lar\u0131n\u0131 ve ani bellek kullan\u0131mlar\u0131n\u0131 kontrol alt\u0131na alabilir.<\/li>\n
              • Veri Yap\u0131lar\u0131n\u0131 Optimize Etme:<\/strong> Uygulaman\u0131z\u0131n kulland\u0131\u011f\u0131 veri yap\u0131lar\u0131n\u0131 ve algoritmalar\u0131 g\u00f6zden ge\u00e7irin. Daha az bellek t\u00fcketen alternatifler olup olmad\u0131\u011f\u0131n\u0131 ara\u015ft\u0131r\u0131n. \u00d6rne\u011fin, b\u00fcy\u00fck listeler yerine ak\u0131\u015f (stream) tabanl\u0131 yakla\u015f\u0131mlar kullanmak.<\/li>\n
              • Ba\u011f\u0131ml\u0131l\u0131klar\u0131 G\u00f6zden Ge\u00e7irme:<\/strong> Uygulaman\u0131z\u0131n kulland\u0131\u011f\u0131 k\u00fct\u00fcphanelerin ve ba\u011f\u0131ml\u0131l\u0131klar\u0131n bellek ayak izini (memory footprint) de\u011ferlendirin. Gereksiz veya a\u015f\u0131r\u0131 bellek t\u00fcketen ba\u011f\u0131ml\u0131l\u0131klar\u0131 ortadan kald\u0131r\u0131n veya daha hafif alternatiflerini kullan\u0131n.<\/li>\n<\/ul>\n
                Otomatik \u00d6l\u00e7eklendirme (HPA\/VPA) ile Dinamik Kaynak Y\u00f6netimi<\/h3>\n
                Manuel kaynak ayarlamalar\u0131 her zaman yeterli olmayabilir. Kubernetes'in otomatik \u00f6l\u00e7eklendirme \u00f6zellikleri, dinamik y\u00fck de\u011fi\u015fimlerine uyum sa\u011flayarak OOMKilled<\/code> olaylar\u0131n\u0131 azaltmaya yard\u0131mc\u0131 olabilir.<\/p>\n
                  \n
                • Horizontal Pod Autoscaler (HPA):<\/strong> HPA, CPU veya bellek gibi metrikleri izleyerek pod say\u0131s\u0131n\u0131 otomatik olarak art\u0131r\u0131r veya azalt\u0131r. E\u011fer uygulaman\u0131z\u0131n bellek talebi y\u00fck alt\u0131nda do\u011frusal olarak art\u0131yorsa, HPA ile daha fazla pod ba\u015flatarak y\u00fck\u00fc da\u011f\u0131tabilir ve her bir pod'un bellek limitlerine tak\u0131lmas\u0131n\u0131 \u00f6nleyebilirsiniz. Ancak HPA do\u011frudan bellek limitlerini y\u00f6netmez, sadece pod say\u0131s\u0131n\u0131 art\u0131r\u0131r.\n
                  \napiVersion: autoscaling\/v2beta2\nkind: HorizontalPodAutoscaler\nmetadata:\n  name: my-app-hpa\nspec:\n  scaleTargetRef:\n    apiVersion: apps\/v1\n    kind: Deployment\n    name: my-app-deployment\n  minReplicas: 2\n  maxReplicas: 10\n  metrics:\n  - type: Resource\n    resource:\n      name: memory\n      target:\n        type: Utilization\n        averageUtilization: 80 # Ortalama %80 bellek kullan\u0131m\u0131na ula\u015ft\u0131\u011f\u0131nda \u00f6l\u00e7eklendir\n            <\/pre>\n
                  <\/code>\n        <\/li>\n
                • Vertical Pod Autoscaler (VPA):<\/strong> VPA, pod'lar\u0131n CPU ve bellek requests<\/code> ve limits<\/code> de\u011ferlerini otomatik olarak ayarlar. VPA'n\u0131n \"OOMKilled\" olaylar\u0131n\u0131 do\u011frudan azaltma yetene\u011fi \u00e7ok g\u00fc\u00e7l\u00fcd\u00fcr. Pod'un ge\u00e7mi\u015f kullan\u0131m verilerini analiz ederek, uygulaman\u0131n ihtiyac\u0131na g\u00f6re kaynak limitlerini dinamik olarak g\u00fcnceller. Bu, manuel tahmin hatalar\u0131n\u0131 ortadan kald\u0131r\u0131r ve kaynak kullan\u0131m\u0131n\u0131 optimize eder. Ancak VPA, pod'lar\u0131 yeniden ba\u015flatabilir, bu nedenle dikkatli kullan\u0131lmal\u0131d\u0131r.<\/li>\n<\/ul>\n
                  \n      Uzman \u0130pucu: VPA'y\u0131 kullan\u0131rken updateMode: \"Off\"<\/code> ile ba\u015flayarak \u00f6nerilen limitleri g\u00f6zlemleyebilir, ard\u0131ndan g\u00fcvenli bir \u015fekilde \"Auto\"<\/code> moduna ge\u00e7i\u015f yapabilirsiniz.\n    <\/div>\n
                  Vaka Analizi 2: Bellek S\u0131z\u0131nt\u0131s\u0131 Olan Bir Uygulaman\u0131n Kurtar\u0131lmas\u0131<\/h3>\n
                  Bir veri i\u015fleme mikroservisi, g\u00fcn\u00fcn belirli saatlerinde OOMKilled<\/code> oluyordu. G\u00f6zlemler, pod'un bellek kullan\u0131m\u0131n\u0131n s\u00fcrekli artt\u0131\u011f\u0131n\u0131, ancak gece d\u00fc\u015f\u00fck y\u00fckte bile s\u0131f\u0131rlanmad\u0131\u011f\u0131n\u0131 g\u00f6sterdi. Bu durum, belirgin bir bellek s\u0131z\u0131nt\u0131s\u0131na i\u015faret ediyordu. Geli\u015ftirici ekibi, Go dilinde yaz\u0131lm\u0131\u015f olan uygulamay\u0131 profil olu\u015fturma ara\u00e7lar\u0131 (go tool pprof<\/code>) ile analiz etti. Analiz sonucunda, b\u00fcy\u00fck bir \u00f6nbellek yap\u0131s\u0131n\u0131n (map<\/code>) d\u00fczg\u00fcn bir \u015fekilde temizlenmedi\u011fi ve eski verilerin bellekten at\u0131lmad\u0131\u011f\u0131 anla\u015f\u0131ld\u0131. \u00d6nbelle\u011fin TTL (Time To Live) mekanizmas\u0131 yanl\u0131\u015f yap\u0131land\u0131r\u0131lm\u0131\u015ft\u0131.<\/p>\n
                  \u00c7\u00f6z\u00fcm olarak:<\/p>\n
                    \n
                  1. \u00d6nbellek temizleme mekanizmas\u0131 d\u00fczeltildi ve TTL s\u00fcresi optimize edildi.<\/li>\n
                  2. Ge\u00e7ici bir \u00f6nlem olarak, limits.memory<\/code> de\u011feri biraz art\u0131r\u0131ld\u0131 ve HPA, bellek kullan\u0131m\u0131na g\u00f6re pod say\u0131s\u0131n\u0131 art\u0131racak \u015fekilde yap\u0131land\u0131r\u0131ld\u0131. Bu, uygulama d\u00fczeltilene kadar hizmetin kesintisiz devam etmesini sa\u011flad\u0131.<\/li>\n
                  3. Uygulama kodu d\u00fczeltildikten sonra, bellek t\u00fcketimi stabilize oldu ve HPA daha az replika ile hizmeti s\u00fcrd\u00fcrebildi.<\/li>\n<\/ol>\n
                    Bu vaka analizi, hem uygulama i\u00e7i optimizasyonun \u00f6nemini hem de ge\u00e7ici olarak Kubernetes ara\u00e7lar\u0131yla sorunu hafifletmenin m\u00fcmk\u00fcn oldu\u011funu vurgulamaktad\u0131r.<\/p>\n
                    \u0130leri D\u00fczey Optimizasyonlar ve En \u0130yi Uygulamalar: Proaktif Yakla\u015f\u0131mlar<\/h2>\n
                    OOMKilled<\/code> olaylar\u0131n\u0131 \u00f6nlemek ve k\u00fcmenizin genel stabilitesini art\u0131rmak i\u00e7in daha ileri seviye baz\u0131 optimizasyonlar ve proaktif yakla\u015f\u0131mlar mevcuttur. Bu teknikler, genellikle b\u00fcy\u00fck ve karma\u015f\u0131k Kubernetes ortamlar\u0131nda daha da \u00f6nem kazan\u0131r.<\/p>\n
                    Node D\u00fczeyinde Bellek Y\u00f6netimi ve Kernel Ayarlar\u0131<\/h3>\n
                    OOMKilled<\/code> sorunlar\u0131 her zaman belirli bir pod'dan kaynaklanmayabilir; bazen d\u00fc\u011f\u00fcm\u00fcn genel bellek y\u00f6netimi veya kernel ayarlar\u0131 da etkili olabilir. Linux kernel'\u0131, vm.overcommit_memory<\/code> gibi parametrelerle bellek tahsis davran\u0131\u015f\u0131n\u0131 y\u00f6netir.<\/p>\n
                      \n
                    • vm.overcommit_memory<\/code>:<\/strong> Bu kernel parametresi, sistemin belle\u011fi \"overcommit\" etme (yani, talep edilen belle\u011fin fiziksel olarak var olandan daha fazla olmas\u0131na izin verme) davran\u0131\u015f\u0131n\u0131 kontrol eder.\n
                        \n
                      • 0<\/code> (varsay\u0131lan): Sezgisel overcommit. Kernel, belle\u011fi overcommit etme karar\u0131n\u0131 kendi sezgilerine g\u00f6re verir.<\/li>\n
                      • 1<\/code>: Her zaman overcommit. Kernel, talep edilen belle\u011fi her zaman tahsis etmeye \u00e7al\u0131\u015f\u0131r. Bu, potansiyel olarak \u00e7ok say\u0131da OOMKilled<\/code>'a yol a\u00e7abilir.<\/li>\n
                      • 2<\/code>: Asla overcommit. Kernel, fiziksel RAM ve takas alan\u0131n\u0131n toplam\u0131ndan daha fazla bellek tahsis etmeye asla izin vermez. Bu, bellek limitlerine ula\u015fan uygulamalar\u0131n h\u0131zl\u0131ca bellek tahsisi hatas\u0131 almas\u0131na neden olur ve genellikle daha stabil bir ortam sa\u011flar, ancak kaynak planlamas\u0131 \u00e7ok daha kat\u0131 olmal\u0131d\u0131r.<\/li>\n<\/ul>\n<\/li>\n
                      • Takas Alan\u0131 (Swap Space):<\/strong> Geleneksel olarak, Kubernetes d\u00fc\u011f\u00fcmlerinde takas alan\u0131 (swap space) kapal\u0131 tutulur. Takas alan\u0131 etkinle\u015ftirildi\u011finde performans sorunlar\u0131 ve tahmin edilemez davran\u0131\u015flar ortaya \u00e7\u0131kabilir. En iyi uygulama, d\u00fc\u011f\u00fcmlerde takas alan\u0131n\u0131 devre d\u0131\u015f\u0131 b\u0131rakmakt\u0131r. Ancak baz\u0131 \u00f6zel durumlarda (\u00f6rne\u011fin, \u00e7ok b\u00fcy\u00fck bellek gerektiren ama anl\u0131k olarak kullanmayan uygulamalar), takas alan\u0131n\u0131n s\u0131n\u0131rl\u0131 kullan\u0131m\u0131 d\u00fc\u015f\u00fcn\u00fclebilir, fakat bu genellikle \u00f6nerilmez.<\/li>\n<\/ul>\n
                        Bu kernel parametreleri, genellikle kubelet<\/code> konfig\u00fcrasyonu arac\u0131l\u0131\u011f\u0131yla veya d\u00fc\u011f\u00fcm ba\u015flatma betiklerinde ayarlan\u0131r. De\u011fi\u015fiklikler dikkatlice test edilmelidir.<\/p>\n
                        Pod Priority, Preemption ve Kaynak Payla\u015f\u0131m\u0131<\/h3>\n
                        Kubernetes, Pod Priority ve Preemption mekanizmalar\u0131 ile d\u00fc\u011f\u00fcm \u00fczerindeki kaynaklar\u0131n kritik pod'lara \u00f6ncelik verilmesini sa\u011flar. Bu, \u00f6zellikle bellek bask\u0131s\u0131 alt\u0131ndaki d\u00fc\u011f\u00fcmlerde baz\u0131 pod'lar\u0131n feda edilmesi gerekti\u011finde \u00f6nemlidir.<\/p>\n
                          \n
                        • Pod Priority:<\/strong> Her pod'a bir \u00f6ncelik de\u011feri (integer) atayabilirsiniz. Y\u00fcksek \u00f6ncelikli pod'lar, d\u00fc\u015f\u00fck \u00f6ncelikli pod'lar\u0131n kaynaklar\u0131n\u0131 kullanmak i\u00e7in onlar\u0131 tahliye edebilir (preempt edebilir).<\/li>\n
                        • Preemption:<\/strong> Bir d\u00fc\u011f\u00fcmde y\u00fcksek \u00f6ncelikli bir pod'un yerle\u015fimi i\u00e7in yeterli kaynak yoksa, Kubernetes scheduler'\u0131, o d\u00fc\u011f\u00fcmdeki daha d\u00fc\u015f\u00fck \u00f6ncelikli pod'lar\u0131 sonland\u0131rarak yer a\u00e7maya \u00e7al\u0131\u015fabilir. Bu, kritik servislerinizin OOMKilled<\/code> olma riskini azalt\u0131rken, daha az \u00f6nemli uygulamalar\u0131n bu duruma d\u00fc\u015fmesine neden olabilir.\n
                          \n# \u00d6rnek: Y\u00fcksek \u00f6ncelikli bir Pod Priority Class\napiVersion: scheduling.k8s.io\/v1\nkind: PriorityClass\nmetadata:\n  name: high-priority\nvalue: 1000000\nglobalDefault: false\ndescription: \"Bu, kritik servisler i\u00e7in kullan\u0131lan y\u00fcksek \u00f6ncelikli bir s\u0131n\u0131f.\"\n---\napiVersion: v1\nkind: Pod\nmetadata:\n  name: critical-app\nspec:\n  priorityClassName: high-priority # Pod'u y\u00fcksek \u00f6ncelikli s\u0131n\u0131fa atama\n  containers:\n  - name: my-app\n    image: my-app-image:latest\n    resources:\n      requests:\n        memory: \"512Mi\"\n      limits:\n        memory: \"1Gi\"\n            <\/pre>\n
                          <\/code>\n        <\/li>\n<\/ul>\n
                          Gelece\u011fe Y\u00f6nelik: Cgroup v2 ve Bellek \u0130zlemedeki Yenilikler<\/h3>\n
                          Linux kernel'\u0131ndaki cgroup (control group) mekanizmas\u0131, s\u00fcre\u00e7lerin kaynak t\u00fcketimini y\u00f6netmek i\u00e7in kullan\u0131l\u0131r. Kubernetes, pod'lar\u0131n kaynak limitlerini cgroup'lar arac\u0131l\u0131\u011f\u0131yla uygular. Cgroup v2, v1'e g\u00f6re daha birle\u015fik ve g\u00fc\u00e7l\u00fc bir kaynak y\u00f6netimi aray\u00fcz\u00fc sunar. Cgroup v2'nin yayg\u0131nla\u015fmas\u0131yla, bellek limitleri ve izlemesi daha hassas ve tutarl\u0131 hale gelecektir. Bu da OOMKilled<\/code> olaylar\u0131n\u0131 daha do\u011fru bir \u015fekilde y\u00f6netmemize yard\u0131mc\u0131 olacakt\u0131r. Mevcut durumda \u00e7o\u011fu Kubernetes k\u00fcmesi cgroup v1 kullan\u0131rken, gelecekte v2'ye ge\u00e7i\u015f, bellek y\u00f6netimi optimizasyonlar\u0131 i\u00e7in yeni kap\u0131lar a\u00e7acakt\u0131r.<\/p>\n
                          Sonu\u00e7 ve S\u0131k\u00e7a Sorulan Sorular: OOMKilled Problemlerine Veda Edin<\/h2>\n
                          OOMKilled<\/code> pod'lar, Kubernetes ortamlar\u0131nda yayg\u0131n bir sorun olsa da, do\u011fru bilgi, etkili ara\u00e7lar ve sistematik bir yakla\u015f\u0131mla \u00fcstesinden gelinebilir. Bu rehberde, bellek y\u00f6netiminin temel prensiplerinden, sorun giderme ad\u0131mlar\u0131na ve ileri d\u00fczey optimizasyonlara kadar bir\u00e7ok konuyu ele ald\u0131k. Unutmay\u0131n ki, proaktif izleme ve s\u00fcrekli optimizasyon, stabil ve verimli bir Kubernetes k\u00fcmesinin anahtar\u0131d\u0131r. Uygulamalar\u0131n\u0131z\u0131n bellek kullan\u0131m al\u0131\u015fkanl\u0131klar\u0131n\u0131 anlamak, do\u011fru kaynak limitleri belirlemek ve otomatik \u00f6l\u00e7eklendirme gibi ara\u00e7lar\u0131 etkin bir \u015fekilde kullanmak, OOMKilled<\/code> kabusunu ge\u00e7mi\u015fte b\u0131rakman\u0131za yard\u0131mc\u0131 olacakt\u0131r. Bu s\u00fcre\u00e7, bir kerede biten bir i\u015flem de\u011fil, s\u00fcrekli bir \u00f6\u011frenme ve adaptasyon yolculu\u011fudur.<\/p>\n
                          Umar\u0131z bu rehber, OOMKilled<\/code> pod'larla kar\u015f\u0131la\u015ft\u0131\u011f\u0131n\u0131zda size yol g\u00f6sterir ve uygulamalar\u0131n\u0131z\u0131n Kubernetes \u00fczerinde daha kararl\u0131 bir \u015fekilde \u00e7al\u0131\u015fmas\u0131na katk\u0131da bulunur.<\/p>\n
                          S\u0131k\u00e7a Sorulan Sorular (SSS)<\/h3>\n
                            \n
                          • \n            S: Bir pod neden OOMKilled<\/code> olur?<\/strong>
                            \n            C:<\/strong> Bir pod, kendisine Kubernetes taraf\u0131ndan atanan bellek limitini (limits.memory<\/code>) a\u015ft\u0131\u011f\u0131nda, Linux kernel'\u0131n\u0131n OOM Killer'\u0131 taraf\u0131ndan sonland\u0131r\u0131l\u0131r. Bu durum genellikle bellek s\u0131z\u0131nt\u0131lar\u0131, yanl\u0131\u015f belirlenmi\u015f kaynak limitleri veya uygulaman\u0131n anl\u0131k y\u00fcksek bellek t\u00fcketimi nedeniyle meydana gelir.\n        <\/li>\n
                          • \n            S: requests.memory<\/code> ve limits.memory<\/code> aras\u0131ndaki fark nedir?<\/strong>
                            \n            C:<\/strong> requests.memory<\/code>, pod'un \u00e7al\u0131\u015fmas\u0131 i\u00e7in talep etti\u011fi ve Kubernetes'in garantiledi\u011fi minimum bellek miktar\u0131d\u0131r. limits.memory<\/code> ise pod'un kullanabilece\u011fi maksimum bellek miktar\u0131d\u0131r; bu limiti a\u015fan bir pod OOMKilled edilir.\n        <\/li>\n
                          • \n            S: OOMKilled<\/code> olaylar\u0131n\u0131 nas\u0131l te\u015fhis edebilirim?<\/strong>
                            \n            C:<\/strong> kubectl describe pod <\/code> komutuyla pod'un olaylar\u0131n\u0131 kontrol edin. Ayr\u0131ca, kubectl logs --previous<\/code> ile \u00f6nceki konteyner loglar\u0131na bak\u0131n ve Prometheus\/Grafana gibi metrik izleme ara\u00e7lar\u0131yla pod'un bellek kullan\u0131m grafiklerini analiz edin.\n        <\/li>\n
                          • \n            S: Kaynak limitlerini nas\u0131l do\u011fru ayarlamal\u0131y\u0131m?<\/strong>
                            \n            C:<\/strong> Uygulaman\u0131z\u0131n ger\u00e7ek bellek kullan\u0131m\u0131n\u0131 (ortalama ve en y\u00fcksek) izleme ara\u00e7lar\u0131 arac\u0131l\u0131\u011f\u0131yla tespit edin. requests.memory<\/code>'yi ortalama kullan\u0131m\u0131n biraz \u00fczerine, limits.memory<\/code>'yi ise en y\u00fcksek kullan\u0131m\u0131n g\u00fcvenli bir marj \u00fczerinde olacak \u015fekilde ayarlay\u0131n. \u0130teratif bir yakla\u015f\u0131mla s\u00fcrekli izleyip ayarlamalar yap\u0131n.\n        <\/li>\n
                          • \n            S: HPA ve VPA, OOMKilled<\/code> sorunlar\u0131na nas\u0131l yard\u0131mc\u0131 olur?<\/strong>
                            \n            C:<\/strong> HPA (Horizontal Pod Autoscaler), bellek kullan\u0131m\u0131na g\u00f6re pod say\u0131s\u0131n\u0131 art\u0131rarak y\u00fck\u00fc da\u011f\u0131t\u0131r ve her bir pod'un limitlere tak\u0131lmas\u0131n\u0131 \u00f6nler. VPA (Vertical Pod Autoscaler) ise pod'lar\u0131n requests<\/code> ve limits<\/code> de\u011ferlerini otomatik olarak optimize ederek bellek yetersizli\u011fi riskini do\u011frudan azalt\u0131r.\n        <\/li>\n<\/ul>\n
                            <\/body><\/p>\n","protected":false},"excerpt":{"rendered":"Kubernetes ortamlar\u0131nda kar\u015f\u0131la\u015f\u0131lan en sinir bozucu durumlardan biri olan OOMKilled pod’lar, uygulamalar\u0131n\u0131z\u0131n beklenmedik bir \u015fekilde kapanmas\u0131na neden olabilir.…","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"csco_page_header_type":"","csco_page_load_nextpost":"","csco_page_subscribe_form":"","csco_page_contact_form":"","footnotes":""},"categories":[1491],"tags":[],"class_list":{"0":"post-31173","1":"post","2":"type-post","3":"status-publish","4":"format-standard","6":"category-kubernetes","7":"cs-entry","8":"cs-video-wrap"},"yoast_head":"\nOOMKilled Pod'lar: Kubernetes'te Sorun Giderme Rehberi<\/title>\n<meta name=\"description\" content=\"Kubernetes ortamlar\u0131nda kar\u015f\u0131la\u015f\u0131lan en sinir bozucu durumlardan biri olan OOMKilled pod'lar, uygulamalar\u0131n\u0131z\u0131n beklenmedik bir \u015fekilde kapanmas\u0131na neden olabilir. Bu kapsaml\u0131 rehber, bellek y\u00f6netimi, kaynak k\u0131s\u0131tlamalar\u0131 ve ad\u0131m ad\u0131m sorun giderme tekniklerini i\u00e7ererek bu yayg\u0131n Kubernetes sorununu anlaman\u0131za ve \u00e7\u00f6zmenize yard\u0131mc\u0131 olacakt\u0131r.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/fatihsoysal.com\/blog\/oomkilled-podlar-kuberneteste-sorun-giderme-rehberi\/\" \/>\n<meta property=\"og:locale\" content=\"tr_TR\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"OOMKilled Pod'lar: Kubernetes'te Sorun Giderme Rehberi\" \/>\n<meta property=\"og:description\" content=\"Kubernetes ortamlar\u0131nda kar\u015f\u0131la\u015f\u0131lan en sinir bozucu durumlardan biri olan OOMKilled pod'lar, uygulamalar\u0131n\u0131z\u0131n beklenmedik bir \u015fekilde kapanmas\u0131na neden olabilir. Bu kapsaml\u0131 rehber, bellek y\u00f6netimi, kaynak k\u0131s\u0131tlamalar\u0131 ve ad\u0131m ad\u0131m sorun giderme tekniklerini i\u00e7ererek bu yayg\u0131n Kubernetes sorununu anlaman\u0131za ve \u00e7\u00f6zmenize yard\u0131mc\u0131 olacakt\u0131r.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/fatihsoysal.com\/blog\/oomkilled-podlar-kuberneteste-sorun-giderme-rehberi\/\" \/>\n<meta property=\"og:site_name\" content=\"Kodlar\u0131n Gizemli D\u00fcnyas\u0131\" \/>\n<meta property=\"article:published_time\" content=\"2025-10-06T17:31:48+00:00\" \/>\n<meta name=\"author\" content=\"Fatih Soysal\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Yazan:\" \/>\n\t<meta name=\"twitter:data1\" content=\"Fatih Soysal\" \/>\n\t<meta name=\"twitter:label2\" content=\"Tahmini okuma s\u00fcresi\" \/>\n\t<meta name=\"twitter:data2\" content=\"20 dakika\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\/\/fatihsoysal.com\/blog\/oomkilled-podlar-kuberneteste-sorun-giderme-rehberi\/#article\",\"isPartOf\":{\"@id\":\"https:\/\/fatihsoysal.com\/blog\/oomkilled-podlar-kuberneteste-sorun-giderme-rehberi\/\"},\"author\":{\"name\":\"Fatih Soysal\",\"@id\":\"https:\/\/fatihsoysal.com\/blog\/#\/schema\/person\/002a254750921dcfd568a99e48240dd1\"},\"headline\":\"OOMKilled Pod’lar: Kubernetes’te Sorun Giderme Rehberi\",\"datePublished\":\"2025-10-06T17:31:48+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/fatihsoysal.com\/blog\/oomkilled-podlar-kuberneteste-sorun-giderme-rehberi\/\"},\"wordCount\":3594,\"commentCount\":0,\"publisher\":{\"@id\":\"https:\/\/fatihsoysal.com\/blog\/#\/schema\/person\/002a254750921dcfd568a99e48240dd1\"},\"articleSection\":[\"Kubernetes\"],\"inLanguage\":\"tr\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\/\/fatihsoysal.com\/blog\/oomkilled-podlar-kuberneteste-sorun-giderme-rehberi\/#respond\"]}],\"copyrightYear\":\"2025\",\"copyrightHolder\":{\"@id\":\"https:\/\/fatihsoysal.com\/blog\/#organization\"}},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/fatihsoysal.com\/blog\/oomkilled-podlar-kuberneteste-sorun-giderme-rehberi\/\",\"url\":\"https:\/\/fatihsoysal.com\/blog\/oomkilled-podlar-kuberneteste-sorun-giderme-rehberi\/\",\"name\":\"OOMKilled Pod'lar: Kubernetes'te Sorun Giderme Rehberi\",\"isPartOf\":{\"@id\":\"https:\/\/fatihsoysal.com\/blog\/#website\"},\"datePublished\":\"2025-10-06T17:31:48+00:00\",\"description\":\"Kubernetes ortamlar\u0131nda kar\u015f\u0131la\u015f\u0131lan en sinir bozucu durumlardan biri olan OOMKilled pod'lar, uygulamalar\u0131n\u0131z\u0131n beklenmedik bir \u015fekilde kapanmas\u0131na neden olabilir. Bu kapsaml\u0131 rehber, bellek y\u00f6netimi, kaynak k\u0131s\u0131tlamalar\u0131 ve ad\u0131m ad\u0131m sorun giderme tekniklerini i\u00e7ererek bu yayg\u0131n Kubernetes sorununu anlaman\u0131za ve \u00e7\u00f6zmenize yard\u0131mc\u0131 olacakt\u0131r.\",\"breadcrumb\":{\"@id\":\"https:\/\/fatihsoysal.com\/blog\/oomkilled-podlar-kuberneteste-sorun-giderme-rehberi\/#breadcrumb\"},\"inLanguage\":\"tr\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/fatihsoysal.com\/blog\/oomkilled-podlar-kuberneteste-sorun-giderme-rehberi\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/fatihsoysal.com\/blog\/oomkilled-podlar-kuberneteste-sorun-giderme-rehberi\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Anasayfa\",\"item\":\"https:\/\/fatihsoysal.com\/blog\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"OOMKilled Pod’lar: Kubernetes’te Sorun Giderme Rehberi\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/fatihsoysal.com\/blog\/#website\",\"url\":\"https:\/\/fatihsoysal.com\/blog\/\",\"name\":\"Fatihsoysal.com\",\"description\":\"Blog - Yaz\u0131l\u0131m D\u00fcnyas\u0131 Tecr\u00fcbelerim\",\"publisher\":{\"@id\":\"https:\/\/fatihsoysal.com\/blog\/#\/schema\/person\/002a254750921dcfd568a99e48240dd1\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/fatihsoysal.com\/blog\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"tr\"},{\"@type\":[\"Person\",\"Organization\"],\"@id\":\"https:\/\/fatihsoysal.com\/blog\/#\/schema\/person\/002a254750921dcfd568a99e48240dd1\",\"name\":\"Fatih Soysal\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"tr\",\"@id\":\"https:\/\/fatihsoysal.com\/blog\/#\/schema\/person\/image\/\",\"url\":\"https:\/\/fatihsoysal.com\/blog\/wp-content\/uploads\/2024\/04\/cropped-replicate-prediction-3kgg1hgjn5rgp0cf0p5tr0jw7w-1.png\",\"contentUrl\":\"https:\/\/fatihsoysal.com\/blog\/wp-content\/uploads\/2024\/04\/cropped-replicate-prediction-3kgg1hgjn5rgp0cf0p5tr0jw7w-1.png\",\"width\":512,\"height\":512,\"caption\":\"Fatih Soysal\"},\"logo\":{\"@id\":\"https:\/\/fatihsoysal.com\/blog\/#\/schema\/person\/image\/\"},\"description\":\"Kullan\u0131m ve kodlama m\u00fckemmeliyetini odak alan uygulamalar olu\u015fturma deneyimine sahip, profesyonel olarak 15+ y\u0131l \u00fczeri deneyime sahip bir yaz\u0131l\u0131m m\u00fchendisi.\",\"url\":\"https:\/\/fatihsoysal.com\/blog\/author\/fatihsoysal\/\"}]}<\/script>\n<!-- \/ Yoast SEO Premium plugin. -->","yoast_head_json":{"title":"OOMKilled Pod'lar: Kubernetes'te Sorun Giderme Rehberi","description":"Kubernetes ortamlar\u0131nda kar\u015f\u0131la\u015f\u0131lan en sinir bozucu durumlardan biri olan OOMKilled pod'lar, uygulamalar\u0131n\u0131z\u0131n beklenmedik bir \u015fekilde kapanmas\u0131na neden olabilir. Bu kapsaml\u0131 rehber, bellek y\u00f6netimi, kaynak k\u0131s\u0131tlamalar\u0131 ve ad\u0131m ad\u0131m sorun giderme tekniklerini i\u00e7ererek bu yayg\u0131n Kubernetes sorununu anlaman\u0131za ve \u00e7\u00f6zmenize yard\u0131mc\u0131 olacakt\u0131r.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/fatihsoysal.com\/blog\/oomkilled-podlar-kuberneteste-sorun-giderme-rehberi\/","og_locale":"tr_TR","og_type":"article","og_title":"OOMKilled Pod'lar: Kubernetes'te Sorun Giderme Rehberi","og_description":"Kubernetes ortamlar\u0131nda kar\u015f\u0131la\u015f\u0131lan en sinir bozucu durumlardan biri olan OOMKilled pod'lar, uygulamalar\u0131n\u0131z\u0131n beklenmedik bir \u015fekilde kapanmas\u0131na neden olabilir. Bu kapsaml\u0131 rehber, bellek y\u00f6netimi, kaynak k\u0131s\u0131tlamalar\u0131 ve ad\u0131m ad\u0131m sorun giderme tekniklerini i\u00e7ererek bu yayg\u0131n Kubernetes sorununu anlaman\u0131za ve \u00e7\u00f6zmenize yard\u0131mc\u0131 olacakt\u0131r.","og_url":"https:\/\/fatihsoysal.com\/blog\/oomkilled-podlar-kuberneteste-sorun-giderme-rehberi\/","og_site_name":"Kodlar\u0131n Gizemli D\u00fcnyas\u0131","article_published_time":"2025-10-06T17:31:48+00:00","author":"Fatih Soysal","twitter_card":"summary_large_image","twitter_misc":{"Yazan:":"Fatih Soysal","Tahmini okuma s\u00fcresi":"20 dakika"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/fatihsoysal.com\/blog\/oomkilled-podlar-kuberneteste-sorun-giderme-rehberi\/#article","isPartOf":{"@id":"https:\/\/fatihsoysal.com\/blog\/oomkilled-podlar-kuberneteste-sorun-giderme-rehberi\/"},"author":{"name":"Fatih Soysal","@id":"https:\/\/fatihsoysal.com\/blog\/#\/schema\/person\/002a254750921dcfd568a99e48240dd1"},"headline":"OOMKilled Pod’lar: Kubernetes’te Sorun Giderme Rehberi","datePublished":"2025-10-06T17:31:48+00:00","mainEntityOfPage":{"@id":"https:\/\/fatihsoysal.com\/blog\/oomkilled-podlar-kuberneteste-sorun-giderme-rehberi\/"},"wordCount":3594,"commentCount":0,"publisher":{"@id":"https:\/\/fatihsoysal.com\/blog\/#\/schema\/person\/002a254750921dcfd568a99e48240dd1"},"articleSection":["Kubernetes"],"inLanguage":"tr","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/fatihsoysal.com\/blog\/oomkilled-podlar-kuberneteste-sorun-giderme-rehberi\/#respond"]}],"copyrightYear":"2025","copyrightHolder":{"@id":"https:\/\/fatihsoysal.com\/blog\/#organization"}},{"@type":"WebPage","@id":"https:\/\/fatihsoysal.com\/blog\/oomkilled-podlar-kuberneteste-sorun-giderme-rehberi\/","url":"https:\/\/fatihsoysal.com\/blog\/oomkilled-podlar-kuberneteste-sorun-giderme-rehberi\/","name":"OOMKilled Pod'lar: Kubernetes'te Sorun Giderme Rehberi","isPartOf":{"@id":"https:\/\/fatihsoysal.com\/blog\/#website"},"datePublished":"2025-10-06T17:31:48+00:00","description":"Kubernetes ortamlar\u0131nda kar\u015f\u0131la\u015f\u0131lan en sinir bozucu durumlardan biri olan OOMKilled pod'lar, uygulamalar\u0131n\u0131z\u0131n beklenmedik bir \u015fekilde kapanmas\u0131na neden olabilir. Bu kapsaml\u0131 rehber, bellek y\u00f6netimi, kaynak k\u0131s\u0131tlamalar\u0131 ve ad\u0131m ad\u0131m sorun giderme tekniklerini i\u00e7ererek bu yayg\u0131n Kubernetes sorununu anlaman\u0131za ve \u00e7\u00f6zmenize yard\u0131mc\u0131 olacakt\u0131r.","breadcrumb":{"@id":"https:\/\/fatihsoysal.com\/blog\/oomkilled-podlar-kuberneteste-sorun-giderme-rehberi\/#breadcrumb"},"inLanguage":"tr","potentialAction":[{"@type":"ReadAction","target":["https:\/\/fatihsoysal.com\/blog\/oomkilled-podlar-kuberneteste-sorun-giderme-rehberi\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/fatihsoysal.com\/blog\/oomkilled-podlar-kuberneteste-sorun-giderme-rehberi\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Anasayfa","item":"https:\/\/fatihsoysal.com\/blog\/"},{"@type":"ListItem","position":2,"name":"OOMKilled Pod’lar: Kubernetes’te Sorun Giderme Rehberi"}]},{"@type":"WebSite","@id":"https:\/\/fatihsoysal.com\/blog\/#website","url":"https:\/\/fatihsoysal.com\/blog\/","name":"Fatihsoysal.com","description":"Blog - Yaz\u0131l\u0131m D\u00fcnyas\u0131 Tecr\u00fcbelerim","publisher":{"@id":"https:\/\/fatihsoysal.com\/blog\/#\/schema\/person\/002a254750921dcfd568a99e48240dd1"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/fatihsoysal.com\/blog\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"tr"},{"@type":["Person","Organization"],"@id":"https:\/\/fatihsoysal.com\/blog\/#\/schema\/person\/002a254750921dcfd568a99e48240dd1","name":"Fatih Soysal","image":{"@type":"ImageObject","inLanguage":"tr","@id":"https:\/\/fatihsoysal.com\/blog\/#\/schema\/person\/image\/","url":"https:\/\/fatihsoysal.com\/blog\/wp-content\/uploads\/2024\/04\/cropped-replicate-prediction-3kgg1hgjn5rgp0cf0p5tr0jw7w-1.png","contentUrl":"https:\/\/fatihsoysal.com\/blog\/wp-content\/uploads\/2024\/04\/cropped-replicate-prediction-3kgg1hgjn5rgp0cf0p5tr0jw7w-1.png","width":512,"height":512,"caption":"Fatih Soysal"},"logo":{"@id":"https:\/\/fatihsoysal.com\/blog\/#\/schema\/person\/image\/"},"description":"Kullan\u0131m ve kodlama m\u00fckemmeliyetini odak alan uygulamalar olu\u015fturma deneyimine sahip, profesyonel olarak 15+ y\u0131l \u00fczeri deneyime sahip bir yaz\u0131l\u0131m m\u00fchendisi.","url":"https:\/\/fatihsoysal.com\/blog\/author\/fatihsoysal\/"}]}},"yoast_meta":{"yoast_wpseo_title":"","yoast_wpseo_metadesc":"","yoast_wpseo_canonical":""},"amp_enabled":true,"_links":{"self":[{"href":"https:\/\/fatihsoysal.com\/blog\/wp-json\/wp\/v2\/posts\/31173","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/fatihsoysal.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/fatihsoysal.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/fatihsoysal.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/fatihsoysal.com\/blog\/wp-json\/wp\/v2\/comments?post=31173"}],"version-history":[{"count":0,"href":"https:\/\/fatihsoysal.com\/blog\/wp-json\/wp\/v2\/posts\/31173\/revisions"}],"wp:attachment":[{"href":"https:\/\/fatihsoysal.com\/blog\/wp-json\/wp\/v2\/media?parent=31173"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/fatihsoysal.com\/blog\/wp-json\/wp\/v2\/categories?post=31173"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/fatihsoysal.com\/blog\/wp-json\/wp\/v2\/tags?post=31173"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}