{"id":31548,"date":"2025-10-11T05:01:28","date_gmt":"2025-10-11T02:01:28","guid":{"rendered":"https:\/\/fatihsoysal.com\/blog\/kubernetes-istek-ve-limit-ayarlari-oomkilleri-ve-kaybi-onleme\/"},"modified":"2025-10-11T05:01:28","modified_gmt":"2025-10-11T02:01:28","slug":"kubernetes-istek-ve-limit-ayarlari-oomkilleri-ve-kaybi-onleme","status":"publish","type":"post","link":"https:\/\/fatihsoysal.com\/blog\/kubernetes-istek-ve-limit-ayarlari-oomkilleri-ve-kaybi-onleme\/","title":{"rendered":"Kubernetes \u0130stek ve Limit Ayarlar\u0131: OOMKilleri ve Kayb\u0131 \u00d6nleme"},"content":{"rendered":"<style>\n  body {\n    font-family: Arial, sans-serif;\n    line-height: 1.6;\n    color: #333;\n    max-width: 1000px;\n    margin: 0 auto;\n    padding: 20px;\n  }\n  h2, h3 {\n    color: #2c3e50;\n    margin-top: 30px;\n    margin-bottom: 15px;\n  }\n  h2 {\n    border-bottom: 2px solid #3498db;\n    padding-bottom: 10px;\n  }\n  h3 {\n    color: #34495e;\n  }\n  p {\n    margin-bottom: 15px;\n  }\n  ul, ol {\n    margin-bottom: 15px;\n    padding-left: 20px;\n  }\n  li {\n    margin-bottom: 5px;\n  }\n  table {\n    width: 100%;\n    border-collapse: collapse;\n    margin-bottom: 20px;\n  }\n  th, td {\n    border: 1px solid #ddd;\n    padding: 8px;\n    text-align: left;\n  }\n  th {\n    background-color: #f2f2f2;\n  }\n  pre {\n    background-color: #ecf0f1;\n    padding: 15px;\n    border-radius: 5px;\n    overflow-x: auto;\n    margin-bottom: 20px;\n  }\n  code {\n    font-family: \"Courier New\", Courier, monospace;\n    background-color: #e0e0e0;\n    padding: 2px 4px;\n    border-radius: 3px;\n  }\n  pre code {\n    background-color: transparent;\n    padding: 0;\n  }\n  .uzman-ipucu {\n    background-color: #e7f3ff;\n    border-left: 5px solid #2196f3;\n    padding: 15px;\n    margin: 20px 0;\n    border-radius: 4px;\n  }\n  .s\u0131kca-sorulan-soru {\n    background-color: #f9f9f9;\n    border: 1px solid #eee;\n    padding: 15px;\n    margin-bottom: 10px;\n    border-radius: 5px;\n  }<\/p>\n<p>  \/* Mobil Uyumlu Tasar\u0131m *\/\n  @media (max-width: 768px) {\n    body {\n      padding: 10px;\n    }\n    table, thead, tbody, th, td, tr {\n      display: block;\n    }\n    thead tr {\n      position: absolute;\n      top: -9999px;\n      left: -9999px;\n    }\n    tr {\n      border: 1px solid #ccc;\n      margin-bottom: 10px;\n    }\n    td {\n      border: none;\n      border-bottom: 1px solid #eee;\n      position: relative;\n      padding-left: 50%;\n      text-align: right;\n    }\n    td:before {\n      position: absolute;\n      top: 6px;\n      left: 6px;\n      width: 45%;\n      padding-right: 10px;\n      white-space: nowrap;\n      content: attr(data-label); \/* Tablo ba\u015fl\u0131\u011f\u0131n\u0131 mobil g\u00f6r\u00fcn\u00fcmde h\u00fccreye ekle *\/\n      font-weight: bold;\n      text-align: left;\n    }\n  }\n<\/style>\n<p><body><\/p>\n<p>Kubernetes ortamlar\u0131nda kar\u015f\u0131la\u015f\u0131lan en b\u00fcy\u00fck zorluklardan biri, uygulamalar i\u00e7in do\u011fru kaynak miktar\u0131n\u0131 belirlemektir. Peki, uygulamalar\u0131n\u0131z i\u00e7in ne kadar CPU ve haf\u0131za ay\u0131rmal\u0131s\u0131n\u0131z? Yetersiz ayarlamalar OOMKill&#8217;lere ve performans sorunlar\u0131na yol a\u00e7arken, a\u015f\u0131r\u0131 kaynak ay\u0131rmalar\u0131 ciddi maliyet israf\u0131na neden olabilir. Bu makalede, Kubernetes isteklerini (requests) ve limitlerini (limits) optimize ederek hem sistem kararl\u0131l\u0131\u011f\u0131n\u0131 sa\u011flamay\u0131 hem de gereksiz harcamalardan ka\u00e7\u0131nmay\u0131 ad\u0131m ad\u0131m inceleyece\u011fiz.<\/p>\n<p>Modern bulut tabanl\u0131 uygulamalar\u0131n kalbi genellikle Kubernetes&#8217;te atar. Bu karma\u015f\u0131k sistemde, uygulamalar\u0131n\u0131z\u0131n sorunsuz ve verimli bir \u015fekilde \u00e7al\u0131\u015fmas\u0131n\u0131 sa\u011flamak, sadece geli\u015ftiricilerin de\u011fil, operasyon ekiplerinin de \u00f6ncelikli hedeflerinden biridir. Ancak, bir\u00e7ok ekip, uygulamalar\u0131n\u0131n ger\u00e7ek kaynak ihtiya\u00e7lar\u0131n\u0131 do\u011fru bir \u015fekilde analiz edemedi\u011fi i\u00e7in \u00e7e\u015fitli sorunlarla kar\u015f\u0131la\u015f\u0131r. Bu sorunlar\u0131n ba\u015f\u0131nda, uygulaman\u0131n aniden kapanmas\u0131na yol a\u00e7an &#8220;Out Of Memory Kills&#8221; (OOMKills) ve gereksiz yere y\u00fcksek bulut faturalar\u0131 gelir.<\/p>\n<p>Uygulamalar\u0131n\u0131za ayr\u0131lan CPU (i\u015flemci) ve Memory (haf\u0131za) miktarlar\u0131, Kubernetes k\u00fcmenizin genel sa\u011fl\u0131\u011f\u0131 ve maliyet etkinli\u011fi \u00fczerinde do\u011frudan bir etkiye sahiptir. Yetersiz kaynak ayarlar\u0131, uygulaman\u0131n kritik anlarda yava\u015flamas\u0131na, hatta tamamen durmas\u0131na neden olabilir. \u00d6rne\u011fin, bir e-ticaret sitesi kampanya d\u00f6neminde yo\u011fun talep g\u00f6rd\u00fc\u011f\u00fcnde, kaynaklar\u0131 yetersiz olan bir servis OOMKill ya\u015fayabilir ve bu da b\u00fcy\u00fck bir gelir kayb\u0131na yol a\u00e7abilir. Di\u011fer yandan, uygulamalar\u0131n\u0131za gere\u011finden fazla kaynak ay\u0131rmak, kullan\u0131lmayan kapasite i\u00e7in bo\u015f yere para \u00f6demek demektir. Bu durum, \u00f6zellikle b\u00fcy\u00fck \u00f6l\u00e7ekli ve \u00e7ok say\u0131da servisi olan altyap\u0131larda zamanla on binlerce dolarl\u0131k gereksiz maliyet yaratabilir. Bu nedenle, Kubernetes&#8217;te kaynak isteklerini ve limitlerini do\u011fru bir \u015fekilde yap\u0131land\u0131rmak, hem uygulaman\u0131z\u0131n performans\u0131n\u0131 ve kararl\u0131l\u0131\u011f\u0131n\u0131 sa\u011flamak hem de operasyonel maliyetleri optimize etmek i\u00e7in hayati bir ad\u0131md\u0131r. Kaynak y\u00f6netiminin inceliklerini anlamak, Kubernetes&#8217;i daha verimli ve s\u00fcrd\u00fcr\u00fclebilir bir \u015fekilde kullanman\u0131n anahtar\u0131d\u0131r.<\/p>\n<div class=\"uzman-ipucu\">\n    Uzman \u0130pucu: Kaynak y\u00f6netimini bir kez yap\u0131p b\u0131rakmak yerine, s\u00fcrekli izleme ve periyodik optimizasyon d\u00f6ng\u00fcs\u00fc olu\u015fturmak, uzun vadede en iyi sonu\u00e7lar\u0131 verecektir. Uygulama davran\u0131\u015flar\u0131 zamanla de\u011fi\u015febilir, bu nedenle kaynak ayarlar\u0131n\u0131n da bu de\u011fi\u015fimlere ayak uydurmas\u0131 gerekir.\n  <\/div>\n<p>Bu ba\u011flamda, Kubernetes&#8217;in sundu\u011fu kaynak istekleri (requests) ve limitleri (limits) mekanizmas\u0131 devreye girer. Bu mekanizmalar sayesinde, her bir uygulaman\u0131n (daha do\u011frusu her bir Pod&#8217;un i\u00e7erisindeki konteynerin) ne kadar CPU ve Memory&#8217;e ihtiya\u00e7 duydu\u011funu ve maksimum ne kadar\u0131n\u0131 kullanabilece\u011fini Kubernetes&#8217;e bildirebiliriz. Bu bilgiler, Kubernetes&#8217;in scheduler&#8217;\u0131n\u0131n Pod&#8217;lar\u0131 en uygun d\u00fc\u011f\u00fcmlere (node&#8217;lara) yerle\u015ftirmesi ve kaynak \u00e7at\u0131\u015fmalar\u0131n\u0131 \u00f6nlemesi a\u00e7\u0131s\u0131ndan kritik \u00f6neme sahiptir. Dolay\u0131s\u0131yla, Kubernetes&#8217;te ba\u015far\u0131ya ula\u015fmak i\u00e7in bu temel kavramlar\u0131 derinlemesine anlamak ve do\u011fru bir \u015fekilde uygulamak \u015fartt\u0131r.<\/p>\n<h2>Temel Kavramlar: Kubernetes Kaynak \u0130stekleri (Requests) ve Limitleri (Limits) Nelerdir?<\/h2>\n<p>Kubernetes&#8217;te kaynak y\u00f6netimi denildi\u011finde akla gelen ilk iki kavram &#8220;requests&#8221; (istekler) ve &#8220;limits&#8221; (limitler) olmal\u0131d\u0131r. Bu iki mekanizma, Pod&#8217;lar\u0131n\u0131z\u0131n ihtiya\u00e7 duydu\u011fu ve kullanabilece\u011fi kaynak miktar\u0131n\u0131 tan\u0131mlaman\u0131z\u0131 sa\u011flar. Bu tan\u0131mlamalar, Kubernetes k\u00fcmenizin verimli \u00e7al\u0131\u015fmas\u0131, Pod&#8217;lar\u0131n\u0131z\u0131n istikrarl\u0131 bir \u015fekilde da\u011f\u0131t\u0131lmas\u0131 ve kaynak \u00e7at\u0131\u015fmalar\u0131n\u0131n \u00f6nlenmesi i\u00e7in olmazsa olmazd\u0131r. Gelin, bu temel kavramlar\u0131 daha yak\u0131ndan inceleyelim.<\/p>\n<h3>\u0130stekler (Requests) Ne Anlama Geliyor ve Neden \u00d6nemlidir?<\/h3>\n<p>Kaynak istekleri, bir Pod&#8217;un i\u00e7erisindeki bir konteynerin \u00e7al\u0131\u015fmak i\u00e7in garanti alt\u0131na al\u0131nm\u0131\u015f minimum CPU ve Memory miktar\u0131n\u0131 Kubernetes&#8217;e bildiren ayard\u0131r. Yani, bir konteyner i\u00e7in belirli bir CPU ve Memory iste\u011fi tan\u0131mlad\u0131\u011f\u0131n\u0131zda, Kubernetes scheduler&#8217;\u0131 bu iste\u011fi kar\u015f\u0131layabilecek yeterli kayna\u011fa sahip bir d\u00fc\u011f\u00fcm bulmadan o Pod&#8217;u \u00e7al\u0131\u015ft\u0131rmaz. Bu, uygulaman\u0131z\u0131n temel \u00e7al\u0131\u015fma gereksinimlerinin kar\u015f\u0131lanmas\u0131n\u0131 garanti alt\u0131na al\u0131r.<\/p>\n<ul>\n<li><strong>CPU \u0130stekleri:<\/strong> CPU istekleri genellikle millicpu (m) cinsinden belirtilir. \u00d6rne\u011fin, <code>250m<\/code>, 0.25 CPU \u00e7ekirde\u011fine e\u015fde\u011ferdir. Bu, Pod&#8217;un belirli bir s\u00fcre boyunca bu kadar CPU s\u00fcresi alaca\u011f\u0131 anlam\u0131na gelir. CPU, payla\u015f\u0131ml\u0131 bir kaynak oldu\u011fu i\u00e7in, istekler uygulaman\u0131z\u0131n CPU kullan\u0131m\u0131n\u0131n bir oran\u0131n\u0131 garanti eder.<\/li>\n<li><strong>Memory \u0130stekleri:<\/strong> Memory istekleri genellikle Mi (megabytes) veya Gi (gigabytes) cinsinden belirtilir. \u00d6rne\u011fin, <code>256Mi<\/code>, 256 megabayt belle\u011fe e\u015fittir. Bellek, payla\u015f\u0131ml\u0131 olmayan bir kaynak oldu\u011fu i\u00e7in, bir Pod&#8217;a atanan bellek, ba\u015fka bir Pod taraf\u0131ndan kullan\u0131lamaz. Kubernetes, d\u00fc\u011f\u00fcmler \u00fczerinde yeterli bellek alan\u0131 oldu\u011fundan emin olmak i\u00e7in bu iste\u011fi kullan\u0131r.<\/li>\n<\/ul>\n<p>Kaynak istekleri, \u00f6zellikle Kubernetes scheduler&#8217;\u0131n\u0131n do\u011fru kararlar vermesi i\u00e7in hayati \u00f6neme sahiptir. Scheduler, yeni bir Pod&#8217;u konu\u015fland\u0131rmadan \u00f6nce, k\u00fcmedeki t\u00fcm d\u00fc\u011f\u00fcmleri analiz eder ve Pod&#8217;un isteklerini kar\u015f\u0131layabilecek bo\u015f kayna\u011fa sahip bir d\u00fc\u011f\u00fcm bulmaya \u00e7al\u0131\u015f\u0131r. E\u011fer bir d\u00fc\u011f\u00fcmde Pod&#8217;un isteklerini kar\u015f\u0131layacak kadar kaynak yoksa, Pod o d\u00fc\u011f\u00fcmde \u00e7al\u0131\u015ft\u0131r\u0131lmaz. Bu da, Pod&#8217;lar\u0131n\u0131z\u0131n daha kararl\u0131 bir ortamda \u00e7al\u0131\u015fmas\u0131n\u0131 sa\u011flar.<\/p>\n<h3>Limitler (Limits) Nas\u0131l \u00c7al\u0131\u015f\u0131r ve OOMKills ile \u0130li\u015fkisi Nedir?<\/h3>\n<p>Kaynak limitleri, bir Pod&#8217;un i\u00e7erisindeki bir konteynerin maksimum ne kadar CPU ve Memory kullanabilece\u011fini belirler. \u0130steklerin aksine, limitler uygulaman\u0131z\u0131n bu de\u011ferlerin \u00fczerine \u00e7\u0131kmas\u0131n\u0131 engeller. Yani, bir konteyner bu limitlerin \u00fczerine \u00e7\u0131kmaya \u00e7al\u0131\u015ft\u0131\u011f\u0131nda, Kubernetes bu durumu farkl\u0131 \u015fekillerde y\u00f6netir.<\/p>\n<ul>\n<li><strong>CPU Limitleri:<\/strong> CPU limitleri de millicpu (m) cinsinden belirtilir. Bir konteyner CPU limitinin \u00fczerine \u00e7\u0131kmaya \u00e7al\u0131\u015ft\u0131\u011f\u0131nda, Kubernetes bu konteynerin CPU kullan\u0131m\u0131n\u0131 k\u0131s\u0131tlar (throttling). Bu, uygulaman\u0131n yava\u015flamas\u0131na neden olabilir, ancak uygulaman\u0131n \u00e7\u00f6kmesini engeller. \u00d6rne\u011fin, bir konteynere <code>500m<\/code> CPU limiti verdiyseniz ve uygulama <code>700m<\/code> CPU kullanmaya \u00e7al\u0131\u015f\u0131yorsa, Kubernetes uygulaman\u0131n CPU kullan\u0131m\u0131n\u0131 <code>500m<\/code>&#8216;de tutacakt\u0131r.<\/li>\n<li><strong>Memory Limitleri:<\/strong> Memory limitleri de Mi veya Gi cinsinden belirtilir. Memory limitleri CPU limitlerinden daha kritik bir role sahiptir. Bir konteyner memory limitini a\u015ft\u0131\u011f\u0131nda, Kubernetes o konteyneri an\u0131nda sonland\u0131r\u0131r. Bu duruma &#8220;Out Of Memory Kill&#8221; (OOMKill) denir. OOMKill&#8217;ler, uygulaman\u0131z\u0131n beklenmedik bir \u015fekilde \u00e7\u00f6kmesine ve hizmet kesintilerine yol a\u00e7an ciddi performans sorunlar\u0131d\u0131r. Bellek t\u00fcketen bir uygulama, d\u00fc\u011f\u00fcmdeki di\u011fer Pod&#8217;lar\u0131 etkilemesini \u00f6nlemek i\u00e7in sonland\u0131r\u0131l\u0131r.<\/li>\n<\/ul>\n<p>Limitler, d\u00fc\u011f\u00fcmlerinizdeki kaynaklar\u0131n a\u015f\u0131r\u0131 t\u00fcketilmesini ve di\u011fer Pod&#8217;lar\u0131n etkilenmesini \u00f6nlemek i\u00e7in bir g\u00fcvenlik mekanizmas\u0131 g\u00f6revi g\u00f6r\u00fcr. \u00d6zellikle bellek limitleri, uygulaman\u0131z\u0131n kararl\u0131l\u0131\u011f\u0131 ve k\u00fcmenizin genel performans\u0131 i\u00e7in hayati \u00f6neme sahiptir. Uygulaman\u0131z\u0131n ne kadar bellek kulland\u0131\u011f\u0131n\u0131 do\u011fru bir \u015fekilde tahmin etmek ve buna uygun bir limit belirlemek, OOMKill&#8217;lerin \u00f6n\u00fcne ge\u00e7menin en etkili yoludur.<\/p>\n<h3>Quality of Service (QoS) S\u0131n\u0131flar\u0131 Nelerdir ve Neden \u00d6nemlidir?<\/h3>\n<p>Kubernetes, Pod&#8217;lar\u0131n\u0131za atad\u0131\u011f\u0131n\u0131z kaynak istekleri ve limitlerine g\u00f6re \u00fc\u00e7 farkl\u0131 Quality of Service (QoS) s\u0131n\u0131f\u0131 atar. Bu QoS s\u0131n\u0131flar\u0131, Pod&#8217;lar\u0131n kaynak k\u0131tl\u0131\u011f\u0131 durumunda nas\u0131l \u00f6nceliklendirilece\u011fini belirler ve k\u00fcmenizin genel kararl\u0131l\u0131\u011f\u0131n\u0131 etkiler. \u015eunlard\u0131r:<\/p>\n<ol>\n<li><strong>Guaranteed (Garantili):<\/strong> Bu s\u0131n\u0131ftaki Pod&#8217;lar en y\u00fcksek \u00f6nceli\u011fe sahiptir. Bir Pod&#8217;un Guaranteed s\u0131n\u0131f\u0131nda olmas\u0131 i\u00e7in, <strong>t\u00fcm konteynerleri i\u00e7in CPU ve Memory isteklerinin (requests) ve limitlerinin (limits) e\u015fit ve tan\u0131mlanm\u0131\u015f olmas\u0131<\/strong> gerekir. \u00d6rne\u011fin, <code>cpu: 200m<\/code> request ve <code>cpu: 200m<\/code> limit ile <code>memory: 256Mi<\/code> request ve <code>memory: 256Mi<\/code> limit. Bu Pod&#8217;lar\u0131n kaynaklar\u0131 her zaman garanti alt\u0131na al\u0131nm\u0131\u015ft\u0131r ve bir d\u00fc\u011f\u00fcmde kaynak k\u0131tl\u0131\u011f\u0131 ya\u015fand\u0131\u011f\u0131nda en son sonland\u0131r\u0131lacak Pod&#8217;lar onlard\u0131r.<\/li>\n<li><strong>Burstable (Patlayabilir):<\/strong> Bu s\u0131n\u0131ftaki Pod&#8217;lar orta \u00f6nceli\u011fe sahiptir. Bir Pod&#8217;un Burstable s\u0131n\u0131f\u0131nda olmas\u0131 i\u00e7in, <strong>en az bir konteyner i\u00e7in CPU veya Memory iste\u011fi (request) tan\u0131mlanm\u0131\u015f olmal\u0131 ve bu istekler limitlerden daha d\u00fc\u015f\u00fck olmal\u0131d\u0131r<\/strong> (veya istekler tan\u0131mlanm\u0131\u015fken limitler tan\u0131mlanmam\u0131\u015f olabilir). \u00d6rne\u011fin, <code>cpu: 100m<\/code> request ve <code>cpu: 500m<\/code> limit. Bu Pod&#8217;lar, d\u00fc\u011f\u00fcmde bo\u015fta kaynak varsa isteklerinin \u00fczerinde kullanabilirler, ancak Guaranteed Pod&#8217;lardan sonra, BestEffort Pod&#8217;lardan \u00f6nce sonland\u0131r\u0131labilirler.<\/li>\n<li><strong>BestEffort (En \u0130yi \u00c7aba):<\/strong> Bu s\u0131n\u0131ftaki Pod&#8217;lar en d\u00fc\u015f\u00fck \u00f6nceli\u011fe sahiptir. Bir Pod&#8217;un BestEffort s\u0131n\u0131f\u0131nda olmas\u0131 i\u00e7in, <strong>hi\u00e7bir konteyner i\u00e7in CPU veya Memory iste\u011fi veya limiti tan\u0131mlanmam\u0131\u015f olmal\u0131d\u0131r<\/strong>. Bu Pod&#8217;lar, kalan t\u00fcm kaynaklar\u0131 kullanabilirler ancak d\u00fc\u011f\u00fcmde kaynak k\u0131tl\u0131\u011f\u0131 ya\u015fand\u0131\u011f\u0131nda ilk sonland\u0131r\u0131lacak Pod&#8217;lar onlard\u0131r. Genellikle kritik olmayan, ge\u00e7ici veya deneme ama\u00e7l\u0131 i\u015f y\u00fckleri i\u00e7in uygundur.<\/li>\n<\/ol>\n<p>QoS s\u0131n\u0131flar\u0131n\u0131 anlamak, hangi uygulamalar\u0131n\u0131z\u0131n daha y\u00fcksek \u00f6nceli\u011fe sahip olmas\u0131 gerekti\u011fini belirlemenize yard\u0131mc\u0131 olur. Kritik \u00fcretim i\u015f y\u00fckleriniz i\u00e7in Guaranteed s\u0131n\u0131f\u0131n\u0131 hedeflemek, onlar\u0131n kararl\u0131l\u0131\u011f\u0131n\u0131 sa\u011flaman\u0131n \u00f6nemli bir yoludur. Di\u011fer yandan, geli\u015ftirme veya test ortamlar\u0131ndaki baz\u0131 uygulamalar i\u00e7in BestEffort veya Burstable s\u0131n\u0131flar\u0131 daha uygun olabilir, bu da kaynak kullan\u0131m\u0131nda esneklik sa\u011flar.<\/p>\n<p>\u00d6zetle, istekler (requests) uygulaman\u0131z\u0131n \u00e7al\u0131\u015fmas\u0131 i\u00e7in minimum garantiyi sa\u011flarken, limitler (limits) uygulaman\u0131z\u0131n kaynak t\u00fcketimini s\u0131n\u0131rlar ve k\u00fcmenizin kararl\u0131l\u0131\u011f\u0131n\u0131 korur. Bu iki ayar\u0131n do\u011fru kombinasyonu, uygulaman\u0131z\u0131n performans\u0131, kararl\u0131l\u0131\u011f\u0131 ve maliyet etkinli\u011fi \u00fczerinde do\u011frudan bir etkiye sahiptir. Bu y\u00fczden, do\u011fru boyutland\u0131rma, yani &#8220;right-sizing&#8221;, Kubernetes&#8217;in temel ta\u015flar\u0131ndan biridir.<\/p>\n<h2>Do\u011fru Boyutland\u0131rma (Right-Sizing) Neden Gereklidir ve Nas\u0131l Ba\u015flan\u0131r?<\/h2>\n<p>Kaynaklar\u0131 do\u011fru boyutland\u0131rmak (right-sizing), Kubernetes&#8217;te verimlili\u011fin ve maliyet tasarrufunun alt\u0131n kural\u0131d\u0131r. Uygulamalar\u0131n\u0131z\u0131n ger\u00e7ekten ne kadar CPU ve Memory&#8217;e ihtiyac\u0131 oldu\u011funu bilmek ve bu bilgiyi Kubernetes&#8217;e do\u011fru bir \u015fekilde iletmek, hem teknik hem de finansal a\u00e7\u0131dan b\u00fcy\u00fck faydalar sa\u011flar. Yanl\u0131\u015f boyutland\u0131rma, ya performans sorunlar\u0131na ve OOMKill&#8217;lere ya da gereksiz harcamalara yol a\u00e7ar. Peki, bu dengeyi nas\u0131l kurar\u0131z ve do\u011fru boyutland\u0131rmaya nas\u0131l ba\u015flar\u0131z?<\/p>\n<h3>Kaynak \u0130sraf\u0131n\u0131 Nas\u0131l \u00d6nleriz?<\/h3>\n<p>\u00c7o\u011fu zaman geli\u015ftiriciler, uygulamalar\u0131n\u0131n asla yetersiz kaynakla kar\u015f\u0131la\u015fmamas\u0131 i\u00e7in &#8220;garanti olsun&#8221; diye y\u00fcksek limitler belirleme e\u011filimindedir. Ancak, bu durum genellikle a\u015f\u0131r\u0131 kaynak tahsisine ve dolay\u0131s\u0131yla kaynak israf\u0131na neden olur. \u00d6rne\u011fin, bir konteynere 2 CPU \u00e7ekirde\u011fi ve 4GB bellek atad\u0131n\u0131z, ancak uygulama nadiren 0.5 CPU ve 1GB bellekten fazlas\u0131n\u0131 kullan\u0131yor. Bu durumda, d\u00fc\u011f\u00fcmdeki 1.5 CPU ve 3GB bellek, o Pod&#8217;a ayr\u0131ld\u0131\u011f\u0131 i\u00e7in ba\u015fka Pod&#8217;lar taraf\u0131ndan kullan\u0131lamaz hale gelir. Bu, \u00f6zellikle bulut ortamlar\u0131nda, kullan\u0131lmayan kaynaklar i\u00e7in \u00f6deme yapt\u0131\u011f\u0131n\u0131z anlam\u0131na gelir ve zamanla ciddi maliyetlere d\u00f6n\u00fc\u015f\u00fcr.<\/p>\n<p>Kaynak israf\u0131n\u0131 \u00f6nlemek i\u00e7in \u00f6ncelikle uygulamalar\u0131n\u0131z\u0131n ger\u00e7ek kaynak kullan\u0131m\u0131n\u0131 anlaman\u0131z gerekir. Bo\u015fta duran veya \u00e7ok az kullan\u0131lan kaynaklar\u0131 tespit etmek, k\u00fcmenizin genel doluluk oran\u0131n\u0131 art\u0131rarak mevcut donan\u0131mdan daha fazla verim alman\u0131z\u0131 sa\u011flar. Bu da, yeni d\u00fc\u011f\u00fcm ekleme ihtiyac\u0131n\u0131 azalt\u0131r ve bulut sa\u011flay\u0131c\u0131n\u0131zdan daha k\u00fc\u00e7\u00fck\/daha az sanal makine kiralaman\u0131za olanak tan\u0131r. Dolay\u0131s\u0131yla, kaynaklar\u0131 do\u011fru boyutland\u0131rmak, do\u011frudan maliyet optimizasyonuna katk\u0131da bulunur.<\/p>\n<h3>OOMKills ve Performans Sorunlar\u0131n\u0131 Nas\u0131l Engelleriz?<\/h3>\n<p>Di\u011fer u\u00e7ta ise yetersiz kaynak atamas\u0131 yer al\u0131r. Uygulama kaynak ihtiya\u00e7lar\u0131n\u0131n alt\u0131nda kalan istek ve limit ayarlar\u0131, \u00e7e\u015fitli performans sorunlar\u0131na ve sistem karars\u0131zl\u0131\u011f\u0131na yol a\u00e7ar. \u00d6zellikle bellek (Memory) taraf\u0131nda yetersiz limitler, &#8220;Out Of Memory Kill&#8221; (OOMKill) senaryolar\u0131n\u0131 tetikler. Bir uygulama, atanm\u0131\u015f bellek limitini a\u015ft\u0131\u011f\u0131nda, Kubernetes o konteyneri an\u0131nda sonland\u0131r\u0131r. Bu durum, hizmet kesintilerine, kullan\u0131c\u0131 memnuniyetsizli\u011fine ve gelir kay\u0131plar\u0131na yol a\u00e7abilir.<\/p>\n<p>CPU taraf\u0131nda ise, d\u00fc\u015f\u00fck limitler &#8220;CPU throttling&#8221; (k\u0131s\u0131tlama) ile sonu\u00e7lan\u0131r. Uygulama, ihtiya\u00e7 duydu\u011fu CPU kaynaklar\u0131na eri\u015femedi\u011fi i\u00e7in yava\u015flar, yan\u0131t s\u00fcreleri uzar ve genel performans d\u00fc\u015fer. Bu da kullan\u0131c\u0131 deneyimini olumsuz etkiler ve uygulama SLA&#8217;lar\u0131n\u0131 (Hizmet Seviyesi Anla\u015fmalar\u0131) ihlal etme riskini art\u0131r\u0131r. Bu sorunlar\u0131 engellemenin yolu, uygulamalar\u0131n\u0131z\u0131n tepe y\u00fck durumlar\u0131nda bile sorunsuz \u00e7al\u0131\u015fmas\u0131n\u0131 sa\u011flayacak yeterli, ancak gereksiz olmayan, kaynaklar\u0131 belirlemekten ge\u00e7er.<\/p>\n<h3>Ba\u015flang\u0131\u00e7 Noktas\u0131: Uygulama \u0130htiya\u00e7lar\u0131n\u0131 Nas\u0131l Belirleriz?<\/h3>\n<p>Do\u011fru boyutland\u0131rman\u0131n ilk ve en \u00f6nemli ad\u0131m\u0131, uygulamalar\u0131n\u0131z\u0131n kaynak kullan\u0131m profilini derinlemesine anlamakt\u0131r. Bu, tahminler veya &#8220;k\u00f6t\u00fc senaryo&#8221; varsay\u0131mlar\u0131 yerine, verilere dayal\u0131 kararlar vermenizi sa\u011flar. \u0130\u015fte bu s\u00fcrece nas\u0131l ba\u015flayabilece\u011finize dair baz\u0131 ipu\u00e7lar\u0131:<\/p>\n<ul>\n<li><strong>\u0130zleme ve Metrikler:<\/strong> Prometheus, Grafana, Datadog, New Relic gibi izleme ara\u00e7lar\u0131, uygulamalar\u0131n\u0131z\u0131n CPU ve Memory kullan\u0131m\u0131n\u0131 zaman i\u00e7inde takip etmek i\u00e7in vazge\u00e7ilmezdir. Bu ara\u00e7lar sayesinde, uygulaman\u0131z\u0131n normal y\u00fck alt\u0131nda, tepe y\u00fck anlar\u0131nda ve farkl\u0131 senaryolarda ne kadar kaynak t\u00fcketti\u011fini g\u00f6rselle\u015ftirebilirsiniz. \u00d6zellikle %90 veya %95 y\u00fczdelik dilimdeki (percentile) kullan\u0131m de\u011ferlerine odaklanmak, anl\u0131k s\u0131\u00e7ramalar\u0131 g\u00f6z ard\u0131 etmeden ger\u00e7ek\u00e7i bir resim elde etmenizi sa\u011flar.<\/li>\n<li><strong>Y\u00fck Testleri:<\/strong> Uygulamalar\u0131n\u0131z\u0131 \u00fcretim ortam\u0131na da\u011f\u0131tmadan \u00f6nce y\u00fck testlerine tabi tutmak, beklenen trafik alt\u0131nda nas\u0131l davrand\u0131klar\u0131n\u0131 anlaman\u0131n en iyi yoludur. Bu testler s\u0131ras\u0131nda kaydedilen kaynak kullan\u0131m verileri, requests ve limits belirlemeniz i\u00e7in sa\u011flam bir temel olu\u015fturur. \u00d6zellikle uygulaman\u0131n haf\u0131za s\u0131z\u0131nt\u0131s\u0131 olup olmad\u0131\u011f\u0131n\u0131 veya ani CPU s\u0131\u00e7ramalar\u0131 ya\u015fay\u0131p ya\u015famad\u0131\u011f\u0131n\u0131 bu testlerle anlayabilirsiniz.<\/li>\n<li><strong>Profilleme Ara\u00e7lar\u0131:<\/strong> Baz\u0131 durumlarda, bir uygulaman\u0131n neden bu kadar kaynak t\u00fcketti\u011fini anlamak i\u00e7in daha derinlemesine analizlere ihtiya\u00e7 duyulur. Java&#8217;daki JConsole\/JVisualVM, Python&#8217;daki cProfile gibi profilleme ara\u00e7lar\u0131, uygulaman\u0131z\u0131n hangi k\u0131s\u0131mlar\u0131n\u0131n daha fazla CPU veya Memory kulland\u0131\u011f\u0131n\u0131 tespit etmenize yard\u0131mc\u0131 olabilir. Bu sayede, kod seviyesinde optimizasyonlar yaparak kaynak ihtiyac\u0131n\u0131 azaltabilirsiniz.<\/li>\n<li><strong>Geli\u015ftirme ve Test Ortamlar\u0131:<\/strong> \u00dcretim ortam\u0131na ge\u00e7meden \u00f6nce, geli\u015ftirme ve test ortamlar\u0131nda farkl\u0131 kaynak ayarlar\u0131yla deneyler yapmak \u00f6nemlidir. Bu ortamlar, olas\u0131 sorunlar\u0131 erken a\u015famada tespit etmenize ve do\u011fru ayarlar\u0131 bulman\u0131za yard\u0131mc\u0131 olur. Ancak unutulmamal\u0131d\u0131r ki geli\u015ftirme ve test ortamlar\u0131n\u0131n y\u00fck profili, \u00fcretim ortam\u0131ndan farkl\u0131 olabilir, bu nedenle bu ortamlardaki ayarlar bir ba\u015flang\u0131\u00e7 noktas\u0131 olarak g\u00f6r\u00fclmelidir.<\/li>\n<\/ul>\n<p>Bu ad\u0131mlar\u0131 takip ederek, uygulamalar\u0131n\u0131z\u0131n ger\u00e7ek kaynak ihtiya\u00e7lar\u0131n\u0131 daha net bir \u015fekilde anlayacak ve Kubernetes&#8217;te do\u011fru boyutland\u0131rma i\u00e7in sa\u011flam bir temel olu\u015fturacaks\u0131n\u0131z. Bu sayede hem performans sorunlar\u0131ndan ka\u00e7\u0131nacak hem de bulut maliyetlerinizi optimize edeceksiniz. Unutmay\u0131n, do\u011fru bilgiye sahip olmak, do\u011fru kararlar\u0131 vermenin anahtar\u0131d\u0131r.<\/p>\n<h2>Uygulamal\u0131 Ad\u0131mlar: \u0130stek ve Limitleri Nas\u0131l Ayarlar\u0131z?<\/h2>\n<p>Teorik bilgileri anlad\u0131ktan sonra, s\u0131ra geldi bunlar\u0131 prati\u011fe d\u00f6kmeye. Kubernetes&#8217;te kaynak isteklerini ve limitlerini YAML dosyalar\u0131n\u0131zda nas\u0131l tan\u0131mlayaca\u011f\u0131n\u0131z\u0131 ve bu s\u00fcreci nas\u0131l y\u00f6netece\u011finizi ad\u0131m ad\u0131m inceleyelim. Uygulamalar\u0131n\u0131za kaynak atarken dikkat etmeniz gereken incelikleri ve yayg\u0131n hatalar\u0131 da ele alaca\u011f\u0131z.<\/p>\n<h3>Basit Bir Pod \u0130\u00e7in Kaynak Tan\u0131mlamas\u0131<\/h3>\n<p>Kubernetes&#8217;te, kaynak istekleri ve limitleri Pod tan\u0131m\u0131n\u0131n i\u00e7erisindeki konteyner spesifikasyonunda belirtilir. A\u015fa\u011f\u0131daki YAML \u00f6rne\u011fi, tek bir konteyneri olan basit bir Pod i\u00e7in CPU ve Memory isteklerini ve limitlerini nas\u0131l ayarlayaca\u011f\u0131n\u0131z\u0131 g\u00f6stermektedir. Bu \u00f6rnek, bir Nginx web sunucusunun temel kaynak gereksinimlerini tan\u0131ml\u0131yor.<\/p>\n<pre><code>\napiVersion: v1\nkind: Pod\nmetadata:\n  name: my-app-pod\nspec:\n  containers:\n  - name: my-app-container\n    image: nginx:latest\n    resources:\n      requests:\n        memory: \"64Mi\"\n        cpu: \"250m\"\n      limits:\n        memory: \"128Mi\"\n        cpu: \"500m\"\n  <\/pre>\n<p><\/code><\/p>\n<p>Bu \u00f6rnekte:<\/p>\n<ul>\n<li><code>requests.memory: \"64Mi\"<\/code>: Bu konteynerin en az 64 megabayt bellek ile \u00e7al\u0131\u015fmas\u0131 gerekti\u011fini Kubernetes'e bildirir. Scheduler, bu miktar\u0131 kar\u015f\u0131layabilecek bir d\u00fc\u011f\u00fcm bulana kadar Pod'u planlamaz.<\/li>\n<li><code>requests.cpu: \"250m\"<\/code>: Bu konteynerin en az 250 millicpu (\u00e7eyrek bir CPU \u00e7ekirde\u011fi) ile \u00e7al\u0131\u015fmas\u0131 gerekti\u011fini belirtir.<\/li>\n<li><code>limits.memory: \"128Mi\"<\/code>: Bu konteynerin kullanabilece\u011fi maksimum bellek miktar\u0131n\u0131 128 megabayt ile s\u0131n\u0131rlar. E\u011fer konteyner bu limiti a\u015farsa, Kubernetes taraf\u0131ndan OOMKill (Out Of Memory Kill) ile sonland\u0131r\u0131l\u0131r.<\/li>\n<li><code>limits.cpu: \"500m\"<\/code>: Bu konteynerin kullanabilece\u011fi maksimum CPU miktar\u0131n\u0131 500 millicpu (yar\u0131m bir CPU \u00e7ekirde\u011fi) ile s\u0131n\u0131rlar. E\u011fer konteyner bu limiti a\u015fmaya \u00e7al\u0131\u015f\u0131rsa, CPU kullan\u0131m\u0131 k\u0131s\u0131tlan\u0131r (throttling).<\/li>\n<\/ul>\n<p>Bu ayarlar sayesinde, Pod'unuzun Guaranteed QoS s\u0131n\u0131f\u0131nda yer ald\u0131\u011f\u0131n\u0131 d\u00fc\u015f\u00fcnebiliriz, \u00e7\u00fcnk\u00fc hem istekler hem de limitler her iki kaynak t\u00fcr\u00fc i\u00e7in de tan\u0131mlanm\u0131\u015f ve e\u015fit olmasalar bile mevcut. Kubernetes'in kaynak y\u00f6netiminde bu yap\u0131land\u0131rma, hem performans\u0131 garanti alt\u0131na almaya yard\u0131mc\u0131 olur hem de kaynaklar\u0131n a\u015f\u0131r\u0131 t\u00fcketilmesini \u00f6nler.<\/p>\n<h3>Uygulama Geli\u015ftirme Ya\u015fam D\u00f6ng\u00fcs\u00fcnde Kaynak Ayarlar\u0131<\/h3>\n<p>Kaynak ayarlar\u0131, uygulaman\u0131n ya\u015fam d\u00f6ng\u00fcs\u00fcn\u00fcn farkl\u0131 a\u015famalar\u0131nda de\u011fi\u015fiklik g\u00f6sterebilir ve g\u00f6stermelidir. Geli\u015ftirme, test ve \u00fcretim ortamlar\u0131n\u0131n her birinin farkl\u0131 gereksinimleri vard\u0131r.<\/p>\n<ul>\n<li><strong>Geli\u015ftirme Ortam\u0131:<\/strong> Genellikle kaynak k\u0131s\u0131tl\u0131d\u0131r ve geli\u015ftiricilerin h\u0131zl\u0131 iterasyon yapmas\u0131 esast\u0131r. Bu a\u015famada, ba\u015flang\u0131\u00e7ta daha gev\u015fek limitler belirlenebilir veya hatta hi\u00e7 limit belirtilmeyebilir (BestEffort QoS). Ancak, uygulaman\u0131n temel kaynak t\u00fcketimini g\u00f6zlemlemek ve ilerideki a\u015famalar i\u00e7in bir \u00f6n tahmin elde etmek faydal\u0131d\u0131r.<\/li>\n<li><strong>Test Ortam\u0131:<\/strong> Y\u00fck testleri, stres testleri ve entegrasyon testleri bu a\u015famada yap\u0131l\u0131r. Burada, \u00fcretim benzeri y\u00fckler alt\u0131nda uygulaman\u0131n kaynak davran\u0131\u015f\u0131n\u0131 g\u00f6zlemlemek kritik \u00f6neme sahiptir. Elde edilen veriler, \u00fcretim ortam\u0131 i\u00e7in istek ve limitlerin daha kesin bir \u015fekilde belirlenmesini sa\u011flar. Buradaki limitler, \u00fcretimdeki ilk tahminlere yak\u0131n olmal\u0131d\u0131r.<\/li>\n<li><strong>\u00dcretim Ortam\u0131:<\/strong> En kat\u0131 ve optimize edilmi\u015f ayarlar\u0131n kullan\u0131ld\u0131\u011f\u0131 yerdir. Burada ama\u00e7, uygulaman\u0131n y\u00fcksek performans, kararl\u0131l\u0131k ve maliyet etkinli\u011fi ile \u00e7al\u0131\u015fmas\u0131n\u0131 sa\u011flamakt\u0131r. \u0130zleme ara\u00e7lar\u0131ndan toplanan ger\u00e7ek veriler \u0131\u015f\u0131\u011f\u0131nda, istekler ve limitler s\u00fcrekli olarak ayarlanmal\u0131 ve optimize edilmelidir. Bir uygulamay\u0131 \u00fcretim ortam\u0131na da\u011f\u0131t\u0131rken mutlaka istek ve limit tan\u0131mlar\u0131 olmal\u0131d\u0131r.<\/li>\n<\/ul>\n<p>Her ortam i\u00e7in ayr\u0131 YAML dosyalar\u0131 veya Helm \u015fablonlar\u0131 kullanarak bu farkl\u0131l\u0131klar\u0131 y\u00f6netmek yayg\u0131n bir yakla\u015f\u0131md\u0131r. Bu, esneklik sa\u011flar ve her ortama \u00f6zg\u00fc ihtiya\u00e7lar\u0131 kar\u015f\u0131lamaya yard\u0131mc\u0131 olur.<\/p>\n<h3>Yayg\u0131n Hatalardan Nas\u0131l Ka\u00e7\u0131n\u0131l\u0131r?<\/h3>\n<p>Kaynak ayarlar\u0131nda yap\u0131lan baz\u0131 yayg\u0131n hatalar, Kubernetes ortam\u0131nda istenmeyen sonu\u00e7lara yol a\u00e7abilir:<\/p>\n<ol>\n<li><strong>A\u015f\u0131r\u0131 Y\u00fcksek Limitler:<\/strong> Uygulaman\u0131n gere\u011finden \u00e7ok daha fazla kaynak limiti belirlemek, d\u00fc\u011f\u00fcmlerde \"kaynak israf\u0131na\" neden olur. Bu, di\u011fer Pod'lar\u0131n planlanamamas\u0131na veya d\u00fc\u011f\u00fcm\u00fcn gereksiz yere b\u00fcy\u00fcmesine yol a\u00e7ar. \u00d6rne\u011fin, bir Pod'a 4GB haf\u0131za limiti verip sadece 500MB kullan\u0131yorsa, 3.5GB haf\u0131za bo\u015fta durur ve maliyet yarat\u0131r.<\/li>\n<li><strong>\u00c7ok D\u00fc\u015f\u00fck \u0130stekler:<\/strong> E\u011fer bir Pod i\u00e7in \u00e7ok d\u00fc\u015f\u00fck istekler belirlenirse, Kubernetes onu kapasitesi olmayan bir d\u00fc\u011f\u00fcme dahi planlayabilir. Bu durum, Pod'un yeterli kaynak bulamad\u0131\u011f\u0131 i\u00e7in yava\u015f \u00e7al\u0131\u015fmas\u0131na veya performans sorunlar\u0131 ya\u015famas\u0131na neden olur. Scheduler'\u0131n do\u011fru kararlar vermesini engeller.<\/li>\n<li><strong>Sadece Limit Belirleyip \u0130stek Belirlememek:<\/strong> Yaln\u0131zca limit belirlemek, Pod'unuzun Burstable QoS s\u0131n\u0131f\u0131na girmesine neden olur. Bu, iyi bir ba\u015flang\u0131\u00e7 olabilir, ancak uygulaman\u0131z\u0131n temel garantilerini sa\u011flamaz. Kaynak k\u0131tl\u0131\u011f\u0131 durumunda, istekleri olmayan Pod'lar (BestEffort) ile birlikte sonland\u0131r\u0131lma riski ta\u015f\u0131r.<\/li>\n<li><strong>Hi\u00e7 Kaynak Ayar\u0131 Yapmamak:<\/strong> Hi\u00e7bir istek veya limit belirlememek (BestEffort QoS), uygulaman\u0131z\u0131n d\u00fc\u011f\u00fcmdeki di\u011fer t\u00fcm Pod'lar\u0131n kaynaklar\u0131n\u0131 kullanma potansiyeli oldu\u011fu anlam\u0131na gelir. Ancak bu Pod'lar, d\u00fc\u011f\u00fcmde kaynak k\u0131tl\u0131\u011f\u0131 ya\u015fand\u0131\u011f\u0131nda ilk olarak sonland\u0131r\u0131l\u0131r. Kritik uygulamalar i\u00e7in bu durum asla kabul edilemez.<\/li>\n<li><strong>Monit\u00f6ring Olmadan Tahminlere Dayanmak:<\/strong> En b\u00fcy\u00fck hatalardan biri, uygulama davran\u0131\u015flar\u0131n\u0131 g\u00f6zlemlemeden ve metriklere dayanmadan kaynak ayarlar\u0131n\u0131 \"tahmin\" etmektir. Veriye dayal\u0131 kararlar vermek yerine yap\u0131lan bu t\u00fcr tahminler genellikle ya kaynak israf\u0131na ya da performans sorunlar\u0131na yol a\u00e7ar.<\/li>\n<\/ol>\n<div class=\"uzman-ipucu\">\n    Uzman \u0130pucu: CPU limitlerini belirlerken dikkatli olun. A\u015f\u0131r\u0131 s\u0131k\u0131 CPU limitleri, uygulaman\u0131z\u0131n ani spike'lar\u0131 (y\u00fck art\u0131\u015flar\u0131) y\u00f6netmesini engelleyebilir ve \"throttling\" ile gereksiz performans d\u00fc\u015f\u00fc\u015flerine yol a\u00e7abilir. Genellikle, CPU isteklerini daha ger\u00e7ek\u00e7i tutup, limitleri isteklerden biraz daha y\u00fcksek veya hi\u00e7 belirlememek (e\u011fer uygulaman\u0131z di\u011fer kritik i\u015f y\u00fcklerini etkilemeyecekse) daha esnek bir yakla\u015f\u0131m sunar. Ancak, bellek limitleri OOMKill'leri \u00f6nlemek i\u00e7in her zaman kritik \u00f6neme sahiptir.\n  <\/div>\n<p>Bu yayg\u0131n hatalardan ka\u00e7\u0131nmak ve uygulamal\u0131 olarak do\u011fru ad\u0131mlar\u0131 atmak, Kubernetes k\u00fcmenizin sa\u011fl\u0131kl\u0131 ve verimli \u00e7al\u0131\u015fmas\u0131n\u0131n temelini olu\u015fturur. \u0130zleme, test ve s\u00fcrekli optimizasyon d\u00f6ng\u00fcs\u00fc, bu s\u00fcre\u00e7te en b\u00fcy\u00fck m\u00fcttefikleriniz olacakt\u0131r.<\/p>\n<h2>\u0130leri D\u00fczey Kaynak Y\u00f6netimi ve Otomasyon<\/h2>\n<p>Uygulamalar\u0131n\u0131z\u0131n kaynak isteklerini ve limitlerini manuel olarak ayarlamak iyi bir ba\u015flang\u0131\u00e7 olsa da, dinamik ve de\u011fi\u015fen i\u015f y\u00fckleri i\u00e7in bu y\u00f6ntem zamanla yetersiz kalabilir. \u00d6zellikle b\u00fcy\u00fck \u00f6l\u00e7ekli ve mikroservis tabanl\u0131 ortamlarda, her bir uygulaman\u0131n kaynak ihtiya\u00e7lar\u0131n\u0131 s\u00fcrekli manuel olarak takip etmek imkans\u0131z hale gelir. \u0130\u015fte bu noktada, Kubernetes'in sundu\u011fu ileri d\u00fczey kaynak y\u00f6netimi ara\u00e7lar\u0131 ve otomasyon \u00e7\u00f6z\u00fcmleri devreye girer. Bu ara\u00e7lar, kaynak y\u00f6netimini daha verimli, \u00f6l\u00e7eklenebilir ve otomatik hale getirerek hem operasyonel y\u00fck\u00fc azalt\u0131r hem de maliyet optimizasyonuna \u00f6nemli katk\u0131lar sa\u011flar.<\/p>\n<h3>Otomatik \u00d6l\u00e7ekleme \u00c7\u00f6z\u00fcmleri: HPA ve VPA Nas\u0131l Yard\u0131mc\u0131 Olur?<\/h3>\n<p>Kubernetes, i\u015f y\u00fcklerinizin kaynak ihtiya\u00e7lar\u0131na g\u00f6re otomatik olarak \u00f6l\u00e7eklenmesini sa\u011flayan g\u00fc\u00e7l\u00fc ara\u00e7lar sunar:<\/p>\n<ul>\n<li><strong>Horizontal Pod Autoscaler (HPA):<\/strong> HPA, bir Deployment veya ReplicaSet'teki Pod say\u0131s\u0131n\u0131, g\u00f6zlemlenen CPU kullan\u0131m\u0131, bellek kullan\u0131m\u0131 veya \u00f6zel metrikler gibi metrik de\u011ferlerine g\u00f6re otomatik olarak art\u0131r\u0131r veya azalt\u0131r. \u00d6rne\u011fin, bir web uygulamas\u0131n\u0131n CPU kullan\u0131m\u0131 %70'in \u00fczerine \u00e7\u0131kt\u0131\u011f\u0131nda HPA, yeni Pod'lar olu\u015fturarak y\u00fck\u00fc da\u011f\u0131tabilir. Bu sayede, uygulaman\u0131z y\u00fcksek trafik anlar\u0131nda bile performanstan \u00f6d\u00fcn vermez ve trafik d\u00fc\u015ft\u00fc\u011f\u00fcnde gereksiz Pod'lar\u0131 sonland\u0131rarak kaynak tasarrufu sa\u011flar. HPA, \u00f6zellikle ani trafik dalgalanmalar\u0131 ya\u015fayan, durumsuz (stateless) uygulamalar i\u00e7in idealdir.<\/li>\n<li><strong>Vertical Pod Autoscaler (VPA):<\/strong> VPA, bir Pod'un i\u00e7erisindeki konteynerlerin CPU ve Memory istek ve limitlerini dinamik olarak ayarlar. Uygulaman\u0131n ge\u00e7mi\u015f kaynak kullan\u0131m verilerini analiz ederek, optimum istek ve limit de\u011ferlerini \u00f6nerir veya do\u011frudan Pod'lar\u0131 yeniden yap\u0131land\u0131r\u0131r. VPA, uygulaman\u0131z\u0131n kaynak ihtiya\u00e7lar\u0131n\u0131n zamanla de\u011fi\u015fti\u011fi veya ba\u015flang\u0131\u00e7ta do\u011fru tahmin edilemedi\u011fi durumlarda \u00e7ok faydal\u0131d\u0131r. HPA'n\u0131n aksine, VPA Pod say\u0131s\u0131n\u0131 de\u011fi\u015ftirmez, mevcut Pod'lar\u0131n kaynaklar\u0131n\u0131 optimize eder. Bu, \u00f6zellikle bellek s\u0131z\u0131nt\u0131s\u0131 olan uygulamalar veya de\u011fi\u015fken bellek ihtiya\u00e7lar\u0131 olan i\u015f y\u00fckleri i\u00e7in \u00f6nemlidir. VPA, hem kaynak israf\u0131n\u0131 azalt\u0131r hem de OOMKill riskini d\u00fc\u015f\u00fcr\u00fcr.<\/li>\n<\/ul>\n<p>HPA ve VPA, birlikte kullan\u0131ld\u0131\u011f\u0131nda \u00e7ok g\u00fc\u00e7l\u00fc bir kombinasyon olu\u015fturabilir. HPA yatayda \u00f6l\u00e7eklemeyi sa\u011flarken, VPA dikeyde Pod'lar\u0131n kaynaklar\u0131n\u0131 optimize eder. Bu, uygulamalar\u0131n\u0131z\u0131n her t\u00fcrl\u00fc y\u00fck alt\u0131nda en verimli \u015fekilde \u00e7al\u0131\u015fmas\u0131n\u0131 garantiler.<\/p>\n<h3>\u0130zleme ve G\u00f6zlemlenebilirlik: Hangi Ara\u00e7lar\u0131 Kullanmal\u0131y\u0131z?<\/h3>\n<p>Otomatik \u00f6l\u00e7ekleme ve do\u011fru boyutland\u0131rma kararlar\u0131n\u0131n temelinde, g\u00fc\u00e7l\u00fc bir izleme altyap\u0131s\u0131 yatar. Uygulamalar\u0131n\u0131z\u0131n ve k\u00fcmenizin kaynak kullan\u0131m\u0131n\u0131 s\u00fcrekli olarak g\u00f6zlemlemek, do\u011fru ayarlamalar\u0131 yapman\u0131n ve olas\u0131 sorunlar\u0131 erken te\u015fhis etmenin anahtar\u0131d\u0131r.<\/p>\n<ul>\n<li><strong>Prometheus:<\/strong> A\u00e7\u0131k kaynakl\u0131 bir izleme sistemi olan Prometheus, Kubernetes k\u00fcmenizden ve uygulamalar\u0131n\u0131zdan metrikleri toplamak i\u00e7in end\u00fcstri standard\u0131 haline gelmi\u015ftir. CPU kullan\u0131m\u0131, bellek t\u00fcketimi, a\u011f trafi\u011fi, disk I\/O gibi bir\u00e7ok farkl\u0131 metri\u011fi Pod, Node veya konteyner seviyesinde toplar. Bu metrikler, HPA'n\u0131n tetikleyicisi olarak veya VPA'n\u0131n \u00f6nerileri i\u00e7in girdi olarak kullan\u0131labilir.<\/li>\n<li><strong>Grafana:<\/strong> Prometheus ile entegre \u00e7al\u0131\u015fan Grafana, toplanan metrikleri g\u00f6rselle\u015ftirmek i\u00e7in kullan\u0131l\u0131r. \u00d6zelle\u015ftirilebilir panolar (dashboards) arac\u0131l\u0131\u011f\u0131yla, uygulamalar\u0131n\u0131z\u0131n ve k\u00fcmenizin sa\u011fl\u0131k durumunu, performans\u0131n\u0131 ve kaynak kullan\u0131m\u0131n\u0131 ger\u00e7ek zamanl\u0131 olarak takip edebilirsiniz. Grafana panolar\u0131nda CPU throttling olaylar\u0131, OOMKill'ler veya y\u00fcksek bellek kullan\u0131m\u0131 gibi anormallikleri kolayca tespit edebilirsiniz.<\/li>\n<li><strong>cAdvisor:<\/strong> Her Kubernetes d\u00fc\u011f\u00fcm\u00fcnde \u00e7al\u0131\u015fan cAdvisor (Container Advisor), konteynerlerin kaynak kullan\u0131m\u0131n\u0131 (CPU, bellek, a\u011f, disk) toplar ve g\u00f6r\u00fcnt\u00fcler. Kubernetes, cAdvisor verilerini API arac\u0131l\u0131\u011f\u0131yla sa\u011flar ve bu veriler Prometheus gibi ara\u00e7lar taraf\u0131ndan toplanabilir.<\/li>\n<li><strong>Kubernetes Dashboard ve Komut Sat\u0131r\u0131 Ara\u00e7lar\u0131:<\/strong> <code>kubectl top nodes<\/code> ve <code>kubectl top pods<\/code> gibi komutlar, anl\u0131k CPU ve bellek kullan\u0131m\u0131n\u0131 h\u0131zl\u0131ca g\u00f6r\u00fcnt\u00fclemek i\u00e7in kullan\u0131\u015fl\u0131d\u0131r. Kubernetes Dashboard da k\u00fcme kaynaklar\u0131n\u0131n genel bir g\u00f6r\u00fcn\u00fcm\u00fcn\u00fc sunar.<\/li>\n<\/ul>\n<p>Bu ara\u00e7lar\u0131 kullanarak, uygulaman\u0131z\u0131n kaynak kullan\u0131m profilini derinlemesine analiz edebilir, darbo\u011fazlar\u0131 tespit edebilir ve kaynak istekleri ile limitlerini \u00e7ok daha bilin\u00e7li bir \u015fekilde ayarlayabilirsiniz. \u0130zleme, sadece sorunlar\u0131 tespit etmekle kalmaz, ayn\u0131 zamanda kaynak optimizasyonu i\u00e7in de de\u011ferli bilgiler sunar.<\/p>\n<h3>Maliyet Optimizasyonu \u0130\u00e7in Kaynak Y\u00f6netimi<\/h3>\n<p>Kubernetes'te kaynak y\u00f6netimi, sadece performans ve kararl\u0131l\u0131kla ilgili de\u011fildir, ayn\u0131 zamanda do\u011frudan bulut maliyetlerinizle de ili\u015fkilidir. Do\u011fru boyutland\u0131rma ve otomasyon ara\u00e7lar\u0131n\u0131n kullan\u0131m\u0131, maliyet optimizasyonunda b\u00fcy\u00fck rol oynar.<\/p>\n<ul>\n<li><strong>Gereksiz Harcamalar\u0131n \u00d6nlenmesi:<\/strong> A\u015f\u0131r\u0131 kaynak tahsisi, bo\u015fta duran kaynaklar i\u00e7in para \u00f6demek anlam\u0131na gelir. VPA gibi ara\u00e7lar, bu gereksiz tahsisleri azaltarak bulut sa\u011flay\u0131c\u0131n\u0131zdan daha k\u00fc\u00e7\u00fck veya daha az sanal makine kiralaman\u0131za olanak tan\u0131r.<\/li>\n<li><strong>Node Verimlili\u011finin Art\u0131r\u0131lmas\u0131:<\/strong> Kaynaklar\u0131 do\u011fru boyutland\u0131rmak, her bir Kubernetes d\u00fc\u011f\u00fcm\u00fcn\u00fcn daha y\u00fcksek bir doluluk oran\u0131yla \u00e7al\u0131\u015fmas\u0131n\u0131 sa\u011flar. Bu, mevcut donan\u0131m\u0131n\u0131zdan maksimum verim alman\u0131z ve yeni d\u00fc\u011f\u00fcm ekleme ihtiyac\u0131n\u0131 ertelemeniz anlam\u0131na gelir.<\/li>\n<li><strong>Dinamik \u00d6l\u00e7ekleme ile Tasarruf:<\/strong> HPA, uygulaman\u0131z\u0131n yaln\u0131zca ihtiya\u00e7 duydu\u011fu anda \u00f6l\u00e7eklenmesini sa\u011flayarak, d\u00fc\u015f\u00fck trafik d\u00f6nemlerinde gereksiz Pod'lar\u0131n \u00e7al\u0131\u015fmas\u0131n\u0131 engeller. Bu dinamik \u00f6l\u00e7ekleme, \u00f6zellikle de\u011fi\u015fken i\u015f y\u00fcklerine sahip uygulamalar i\u00e7in \u00f6nemli maliyet tasarrufu sa\u011flar. \u00d6rne\u011fin, geceleri veya hafta sonlar\u0131 trafik d\u00fc\u015f\u00fc\u015f\u00fc ya\u015fayan bir uygulama, HPA sayesinde daha az Pod ile \u00e7al\u0131\u015farak kaynak t\u00fcketimini minimuma indirebilir.<\/li>\n<li><strong>Maliyet G\u00f6r\u00fcn\u00fcrl\u00fc\u011f\u00fc:<\/strong> FinOps (Financial Operations) prensiplerini Kubernetes ortam\u0131na uygulamak i\u00e7in, kaynak kullan\u0131m\u0131n\u0131 maliyetle ili\u015fkilendiren ara\u00e7lar (\u00f6rn. Kubecost) kullan\u0131labilir. Bu ara\u00e7lar, hangi ekibin veya uygulaman\u0131n ne kadar maliyet yaratt\u0131\u011f\u0131n\u0131 net bir \u015fekilde g\u00f6stererek, daha bilin\u00e7li optimizasyon kararlar\u0131 alman\u0131z\u0131 sa\u011flar.<\/li>\n<\/ul>\n<p>\u00d6zetle, ileri d\u00fczey kaynak y\u00f6netimi teknikleri ve otomasyon ara\u00e7lar\u0131, Kubernetes'te sadece operasyonel verimlili\u011fi art\u0131rmakla kalmaz, ayn\u0131 zamanda \u00f6nemli maliyet tasarruflar\u0131 sa\u011flayarak i\u015fletmelerin genel karl\u0131l\u0131\u011f\u0131na do\u011frudan katk\u0131da bulunur. Bu y\u00fczden, manuel ayarlar\u0131n \u00f6tesine ge\u00e7erek bu ara\u00e7lar\u0131 benimsemek, modern bir Kubernetes stratejisinin ayr\u0131lmaz bir par\u00e7as\u0131d\u0131r.<\/p>\n<h2>Sonu\u00e7 ve S\u0131k\u00e7a Sorulan Sorular<\/h2>\n<p>Kubernetes'te kaynak isteklerini ve limitlerini do\u011fru bir \u015fekilde y\u00f6netmek, bulut tabanl\u0131 uygulamalar\u0131n\u0131z\u0131n performans\u0131n\u0131, kararl\u0131l\u0131\u011f\u0131n\u0131 ve maliyet etkinli\u011fini do\u011frudan etkileyen kritik bir beceridir. Bu makalede, bu kavramlar\u0131n temelinden ba\u015flayarak, uygulamal\u0131 ad\u0131mlara ve ileri d\u00fczey otomasyon \u00e7\u00f6z\u00fcmlerine kadar geni\u015f bir yelpazeyi ele ald\u0131k. Unutmay\u0131n ki kaynak y\u00f6netimi, bir kez yap\u0131l\u0131p bitirilen bir i\u015flem de\u011fil, s\u00fcrekli izleme, analiz ve optimizasyon gerektiren dinamik bir s\u00fcre\u00e7tir.<\/p>\n<h3>Anahtar \u00c7\u0131kar\u0131mlar Nelerdir?<\/h3>\n<ul>\n<li><strong>\u0130stekler (Requests) ve Limitler (Limits) Temeldir:<\/strong> \u0130stekler, Kubernetes'in Pod'lar\u0131 planlarken kullanaca\u011f\u0131 minimum kaynak garantisini sa\u011flarken, limitler bir Pod'un maksimum kullanabilece\u011fi kaynak miktar\u0131n\u0131 belirler. \u0130kisi de uygulaman\u0131n kararl\u0131l\u0131\u011f\u0131 ve k\u00fcmenin verimlili\u011fi i\u00e7in hayati \u00f6neme sahiptir.<\/li>\n<li><strong>Do\u011fru Boyutland\u0131rma Kritik \u00d6neme Sahiptir:<\/strong> Ne eksik ne de fazla kaynak tahsisi yapmak gerekir. Yetersiz kaynaklar OOMKill'lere ve performans d\u00fc\u015f\u00fc\u015flerine yol a\u00e7arken, a\u015f\u0131r\u0131 kaynaklar gereksiz maliyet israf\u0131na neden olur.<\/li>\n<li><strong>Veriye Dayal\u0131 Kararlar Al\u0131n:<\/strong> Uygulaman\u0131z\u0131n ger\u00e7ek kaynak kullan\u0131m\u0131n\u0131 izleme ara\u00e7lar\u0131 (Prometheus, Grafana) ve y\u00fck testleri arac\u0131l\u0131\u011f\u0131yla anlamak, do\u011fru istek ve limit de\u011ferlerini belirlemenin anahtar\u0131d\u0131r. Tahminler yerine verilere g\u00fcvenin.<\/li>\n<li><strong>Otomasyon ile Verimlili\u011fi Art\u0131r\u0131n:<\/strong> Horizontal Pod Autoscaler (HPA) ve Vertical Pod Autoscaler (VPA) gibi ara\u00e7lar, dinamik i\u015f y\u00fckleri i\u00e7in kaynak y\u00f6netimini otomatikle\u015ftirerek hem operasyonel y\u00fck\u00fc azalt\u0131r hem de s\u00fcrekli optimizasyon sa\u011flar.<\/li>\n<li><strong>S\u00fcrekli G\u00f6zlemleyin ve Optimize Edin:<\/strong> Uygulama davran\u0131\u015flar\u0131 zamanla de\u011fi\u015febilir. Bu nedenle, kaynak ayarlar\u0131n\u0131 d\u00fczenli olarak g\u00f6zden ge\u00e7irmek, izlemek ve gerekti\u011finde ayarlamak, s\u00fcrd\u00fcr\u00fclebilir bir Kubernetes ortam\u0131 i\u00e7in olmazsa olmazd\u0131r.<\/li>\n<\/ul>\n<p>Kaynak y\u00f6netimini ustal\u0131kla uygulamak, Kubernetes maceran\u0131zda size b\u00fcy\u00fck avantajlar sa\u011flayacak ve uygulamalar\u0131n\u0131z\u0131n hem teknik hem de finansal hedeflerine ula\u015fmas\u0131na yard\u0131mc\u0131 olacakt\u0131r.<\/p>\n<h3>S\u0131k\u00e7a Sorulan Sorular<\/h3>\n<div class=\"s\u0131kca-sorulan-soru\">\n<h4>1. Requests ve Limits belirlemezsem ne olur?<\/h4>\n<p>Cevap: E\u011fer bir Pod i\u00e7in hi\u00e7bir kaynak iste\u011fi veya limiti belirtmezseniz, Pod'unuz \"BestEffort\" QoS s\u0131n\u0131f\u0131na girer. Bu, Pod'unuzun d\u00fc\u011f\u00fcmde kalan t\u00fcm bo\u015fta kaynaklar\u0131 kullanabilece\u011fi anlam\u0131na gelir. Ancak, kaynak k\u0131tl\u0131\u011f\u0131 ya\u015fand\u0131\u011f\u0131nda (yani d\u00fc\u011f\u00fcmdeki di\u011fer Pod'lar veya sistem s\u00fcre\u00e7leri daha fazla kayna\u011fa ihtiya\u00e7 duydu\u011funda), BestEffort Pod'lar ilk olarak sonland\u0131r\u0131lacak olanlard\u0131r. Kritik \u00fcretim i\u015f y\u00fckleri i\u00e7in bu durum kesinlikle \u00f6nerilmez.<\/p>\n<\/p><\/div>\n<div class=\"s\u0131kca-sorulan-soru\">\n<h4>2. OOMKill durumunda ne yapmal\u0131y\u0131m?<\/h4>\n<p>Cevap: Bir OOMKill (Out Of Memory Kill) ya\u015fad\u0131\u011f\u0131n\u0131zda, uygulaman\u0131z\u0131n bellek limitini a\u015ft\u0131\u011f\u0131 i\u00e7in Kubernetes taraf\u0131ndan sonland\u0131r\u0131ld\u0131\u011f\u0131 anlam\u0131na gelir. Bu durumda yapman\u0131z gerekenler:<\/p>\n<ol>\n<li>Uygulaman\u0131z\u0131n bellek kullan\u0131m profilini izleme ara\u00e7lar\u0131yla (Grafana, Prometheus) detayl\u0131 olarak inceleyin.<\/li>\n<li>Uygulaman\u0131zda bellek s\u0131z\u0131nt\u0131s\u0131 olup olmad\u0131\u011f\u0131n\u0131 veya tepe y\u00fck anlar\u0131nda ne kadar bellek t\u00fcketti\u011fini belirleyin.<\/li>\n<li>Mevcut bellek limitini, uygulaman\u0131z\u0131n en yo\u011fun anlar\u0131ndaki kullan\u0131m\u0131n\u0131n biraz \u00fczerine \u00e7\u0131kar\u0131n.<\/li>\n<li>Gerekirse, Vertical Pod Autoscaler (VPA) kullanmay\u0131 d\u00fc\u015f\u00fcn\u00fcn, bu Pod'unuzun bellek limitlerini otomatik olarak optimize edebilir.<\/li>\n<\/ol><\/div>\n<div class=\"s\u0131kca-sorulan-soru\">\n<h4>3. CPU Limitleri neden \"throttling\" yapar?<\/h4>\n<p>Cevap: CPU limitleri, bir konteynerin kullanabilece\u011fi maksimum CPU miktar\u0131n\u0131 belirler. E\u011fer bir konteyner bu limiti a\u015fmaya \u00e7al\u0131\u015f\u0131rsa, Kubernetes konteynerin CPU kullan\u0131m\u0131n\u0131 \"throttling\" (k\u0131s\u0131tlama) yaparak s\u0131n\u0131rlar. Bu, uygulaman\u0131n yava\u015flamas\u0131na, yan\u0131t s\u00fcrelerinin uzamas\u0131na ve genel performans\u0131n d\u00fc\u015fmesine neden olabilir. Throttling, uygulaman\u0131n \u00e7\u00f6kmesini engellerken, a\u015f\u0131r\u0131 CPU t\u00fcketiminin d\u00fc\u011f\u00fcmdeki di\u011fer Pod'lar\u0131 etkilemesini \u00f6nlemek i\u00e7in bir g\u00fcvenlik mekanizmas\u0131d\u0131r. Bu durumu izlemek i\u00e7in CPU throttling metriklerini takip etmelisiniz.<\/p>\n<\/p><\/div>\n<div class=\"s\u0131kca-sorulan-soru\">\n<h4>4. Geli\u015ftirme ortam\u0131nda da kaynak ayarlar\u0131 yapmal\u0131 m\u0131y\u0131m?<\/h4>\n<p>Cevap: Geli\u015ftirme ortamlar\u0131nda, \u00fcretim ortam\u0131 kadar s\u0131k\u0131 kaynak ayarlar\u0131 genellikle gerekli de\u011fildir. Ancak, uygulaman\u0131z\u0131n temel kaynak t\u00fcketimini anlamak ve olas\u0131 bellek s\u0131z\u0131nt\u0131lar\u0131n\u0131 veya y\u00fcksek CPU kullan\u0131m\u0131n\u0131 erken a\u015famada tespit etmek i\u00e7in en az\u0131ndan ba\u015flang\u0131\u00e7 istekleri (requests) belirlemek faydal\u0131d\u0131r. Bu, ileriki a\u015famalarda (test ve \u00fcretim) do\u011fru ayarlamalar\u0131 yaparken size bir ba\u015flang\u0131\u00e7 noktas\u0131 sunar. Tamamen limitsiz \u00e7al\u0131\u015ft\u0131rmak, geli\u015ftirme makinelerinde gereksiz yere kaynak t\u00fcketimine yol a\u00e7abilir.<\/p>\n<\/p><\/div>\n<div class=\"s\u0131kca-sorulan-soru\">\n<h4>5. HPA ve VPA'y\u0131 birlikte kullanabilir miyim?<\/h4>\n<p>Cevap: Evet, HPA (Horizontal Pod Autoscaler) ve VPA (Vertical Pod Autoscaler) prensipte birlikte kullan\u0131labilir, ancak do\u011frudan ayn\u0131 Pod'lar \u00fczerinde tek ba\u015flar\u0131na kullan\u0131lamazlar. Kubernetes'in tasar\u0131m\u0131nda, VPA bir Pod'un kaynak isteklerini ve limitlerini y\u00f6netirken, HPA Pod'lar\u0131n say\u0131s\u0131n\u0131 y\u00f6netir. E\u011fer ayn\u0131 Pod \u00fczerinde hem HPA hem de VPA CPU veya bellek metriklerine g\u00f6re \u00f6l\u00e7eklendirme yapmaya \u00e7al\u0131\u015f\u0131rsa, bir \u00e7at\u0131\u015fma ya\u015fanabilir. Bu sorunu \u00e7\u00f6zmek i\u00e7in genellikle \"VPA'n\u0131n \u00f6neri modu\" kullan\u0131l\u0131r: VPA kaynak \u00f6nerilerinde bulunur, ancak bunlar\u0131 otomatik olarak uygulamaz, HPA ise Pod say\u0131s\u0131n\u0131 y\u00f6netir. Geli\u015fmi\u015f senaryolarda, Kubernetes'in yeni s\u00fcr\u00fcmlerinde veya operat\u00f6rler arac\u0131l\u0131\u011f\u0131yla bu ara\u00e7lar\u0131n uyumlu \u00e7al\u0131\u015fmas\u0131 i\u00e7in \u00e7\u00f6z\u00fcmler geli\u015ftirilmektedir. Detayl\u0131 kullan\u0131m durumlar\u0131 i\u00e7in Kubernetes dok\u00fcmantasyonunu incelemek faydal\u0131 olacakt\u0131r.<\/p>\n<\/p><\/div>\n<p><\/body><\/p>\n","protected":false},"excerpt":{"rendered":"Kubernetes ortamlar\u0131nda kar\u015f\u0131la\u015f\u0131lan en b\u00fcy\u00fck zorluklardan biri, uygulamalar i\u00e7in do\u011fru kaynak miktar\u0131n\u0131 belirlemektir. Peki, uygulamalar\u0131n\u0131z i\u00e7in ne kadar&hellip;","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-31548","1":"post","2":"type-post","3":"status-publish","4":"format-standard","6":"category-kubernetes","7":"cs-entry","8":"cs-video-wrap"},"yoast_head":"<!-- This site is optimized with the Yoast SEO Premium plugin v20.5 (Yoast SEO v25.3.1) - https:\/\/yoast.com\/wordpress\/plugins\/seo\/ -->\n<title>Kubernetes \u0130stek ve Limit Ayarlar\u0131: OOMKilleri ve Kayb\u0131 \u00d6nleme<\/title>\n<meta name=\"description\" content=\"Kubernetes ortamlar\u0131nda kar\u015f\u0131la\u015f\u0131lan en b\u00fcy\u00fck zorluklardan biri, uygulamalar i\u00e7in do\u011fru kaynak miktar\u0131n\u0131 belirlemektir. Peki, uygulamalar\u0131n\u0131z i\u00e7in ne kadar CPU ve haf\u0131za ay\u0131rmal\u0131s\u0131n\u0131z? Yetersiz ayarlamalar OOMKill&#039;lere ve performans sorunlar\u0131na yol a\u00e7arken, a\u015f\u0131r\u0131 kaynak ay\u0131rmalar\u0131 ciddi maliyet israf\u0131na neden olabilir. Bu makalede, Kubernetes isteklerini (requests) ve limitlerini (limits) optimize ederek hem sistem kararl\u0131l\u0131\u011f\u0131n\u0131 sa\u011flamay\u0131 hem de gereksiz harcamalardan ka\u00e7\u0131nmay\u0131 ad\u0131m ad\u0131m inceleyece\u011fiz.\" \/>\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\/kubernetes-istek-ve-limit-ayarlari-oomkilleri-ve-kaybi-onleme\/\" \/>\n<meta property=\"og:locale\" content=\"tr_TR\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Kubernetes \u0130stek ve Limit Ayarlar\u0131: OOMKilleri ve Kayb\u0131 \u00d6nleme\" \/>\n<meta property=\"og:description\" content=\"Kubernetes ortamlar\u0131nda kar\u015f\u0131la\u015f\u0131lan en b\u00fcy\u00fck zorluklardan biri, uygulamalar i\u00e7in do\u011fru kaynak miktar\u0131n\u0131 belirlemektir. Peki, uygulamalar\u0131n\u0131z i\u00e7in ne kadar CPU ve haf\u0131za ay\u0131rmal\u0131s\u0131n\u0131z? Yetersiz ayarlamalar OOMKill&#039;lere ve performans sorunlar\u0131na yol a\u00e7arken, a\u015f\u0131r\u0131 kaynak ay\u0131rmalar\u0131 ciddi maliyet israf\u0131na neden olabilir. Bu makalede, Kubernetes isteklerini (requests) ve limitlerini (limits) optimize ederek hem sistem kararl\u0131l\u0131\u011f\u0131n\u0131 sa\u011flamay\u0131 hem de gereksiz harcamalardan ka\u00e7\u0131nmay\u0131 ad\u0131m ad\u0131m inceleyece\u011fiz.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/fatihsoysal.com\/blog\/kubernetes-istek-ve-limit-ayarlari-oomkilleri-ve-kaybi-onleme\/\" \/>\n<meta property=\"og:site_name\" content=\"Kodlar\u0131n Gizemli D\u00fcnyas\u0131\" \/>\n<meta property=\"article:published_time\" content=\"2025-10-11T02:01:28+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=\"28 dakika\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\/\/fatihsoysal.com\/blog\/kubernetes-istek-ve-limit-ayarlari-oomkilleri-ve-kaybi-onleme\/#article\",\"isPartOf\":{\"@id\":\"https:\/\/fatihsoysal.com\/blog\/kubernetes-istek-ve-limit-ayarlari-oomkilleri-ve-kaybi-onleme\/\"},\"author\":{\"name\":\"Fatih Soysal\",\"@id\":\"https:\/\/fatihsoysal.com\/blog\/#\/schema\/person\/002a254750921dcfd568a99e48240dd1\"},\"headline\":\"Kubernetes \u0130stek ve Limit Ayarlar\u0131: OOMKilleri ve Kayb\u0131 \u00d6nleme\",\"datePublished\":\"2025-10-11T02:01:28+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/fatihsoysal.com\/blog\/kubernetes-istek-ve-limit-ayarlari-oomkilleri-ve-kaybi-onleme\/\"},\"wordCount\":5547,\"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\/kubernetes-istek-ve-limit-ayarlari-oomkilleri-ve-kaybi-onleme\/#respond\"]}],\"copyrightYear\":\"2025\",\"copyrightHolder\":{\"@id\":\"https:\/\/fatihsoysal.com\/blog\/#organization\"}},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/fatihsoysal.com\/blog\/kubernetes-istek-ve-limit-ayarlari-oomkilleri-ve-kaybi-onleme\/\",\"url\":\"https:\/\/fatihsoysal.com\/blog\/kubernetes-istek-ve-limit-ayarlari-oomkilleri-ve-kaybi-onleme\/\",\"name\":\"Kubernetes \u0130stek ve Limit Ayarlar\u0131: OOMKilleri ve Kayb\u0131 \u00d6nleme\",\"isPartOf\":{\"@id\":\"https:\/\/fatihsoysal.com\/blog\/#website\"},\"datePublished\":\"2025-10-11T02:01:28+00:00\",\"description\":\"Kubernetes ortamlar\u0131nda kar\u015f\u0131la\u015f\u0131lan en b\u00fcy\u00fck zorluklardan biri, uygulamalar i\u00e7in do\u011fru kaynak miktar\u0131n\u0131 belirlemektir. Peki, uygulamalar\u0131n\u0131z i\u00e7in ne kadar CPU ve haf\u0131za ay\u0131rmal\u0131s\u0131n\u0131z? Yetersiz ayarlamalar OOMKill'lere ve performans sorunlar\u0131na yol a\u00e7arken, a\u015f\u0131r\u0131 kaynak ay\u0131rmalar\u0131 ciddi maliyet israf\u0131na neden olabilir. Bu makalede, Kubernetes isteklerini (requests) ve limitlerini (limits) optimize ederek hem sistem kararl\u0131l\u0131\u011f\u0131n\u0131 sa\u011flamay\u0131 hem de gereksiz harcamalardan ka\u00e7\u0131nmay\u0131 ad\u0131m ad\u0131m inceleyece\u011fiz.\",\"breadcrumb\":{\"@id\":\"https:\/\/fatihsoysal.com\/blog\/kubernetes-istek-ve-limit-ayarlari-oomkilleri-ve-kaybi-onleme\/#breadcrumb\"},\"inLanguage\":\"tr\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/fatihsoysal.com\/blog\/kubernetes-istek-ve-limit-ayarlari-oomkilleri-ve-kaybi-onleme\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/fatihsoysal.com\/blog\/kubernetes-istek-ve-limit-ayarlari-oomkilleri-ve-kaybi-onleme\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Anasayfa\",\"item\":\"https:\/\/fatihsoysal.com\/blog\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Kubernetes \u0130stek ve Limit Ayarlar\u0131: OOMKilleri ve Kayb\u0131 \u00d6nleme\"}]},{\"@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":"Kubernetes \u0130stek ve Limit Ayarlar\u0131: OOMKilleri ve Kayb\u0131 \u00d6nleme","description":"Kubernetes ortamlar\u0131nda kar\u015f\u0131la\u015f\u0131lan en b\u00fcy\u00fck zorluklardan biri, uygulamalar i\u00e7in do\u011fru kaynak miktar\u0131n\u0131 belirlemektir. Peki, uygulamalar\u0131n\u0131z i\u00e7in ne kadar CPU ve haf\u0131za ay\u0131rmal\u0131s\u0131n\u0131z? Yetersiz ayarlamalar OOMKill'lere ve performans sorunlar\u0131na yol a\u00e7arken, a\u015f\u0131r\u0131 kaynak ay\u0131rmalar\u0131 ciddi maliyet israf\u0131na neden olabilir. Bu makalede, Kubernetes isteklerini (requests) ve limitlerini (limits) optimize ederek hem sistem kararl\u0131l\u0131\u011f\u0131n\u0131 sa\u011flamay\u0131 hem de gereksiz harcamalardan ka\u00e7\u0131nmay\u0131 ad\u0131m ad\u0131m inceleyece\u011fiz.","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\/kubernetes-istek-ve-limit-ayarlari-oomkilleri-ve-kaybi-onleme\/","og_locale":"tr_TR","og_type":"article","og_title":"Kubernetes \u0130stek ve Limit Ayarlar\u0131: OOMKilleri ve Kayb\u0131 \u00d6nleme","og_description":"Kubernetes ortamlar\u0131nda kar\u015f\u0131la\u015f\u0131lan en b\u00fcy\u00fck zorluklardan biri, uygulamalar i\u00e7in do\u011fru kaynak miktar\u0131n\u0131 belirlemektir. Peki, uygulamalar\u0131n\u0131z i\u00e7in ne kadar CPU ve haf\u0131za ay\u0131rmal\u0131s\u0131n\u0131z? Yetersiz ayarlamalar OOMKill'lere ve performans sorunlar\u0131na yol a\u00e7arken, a\u015f\u0131r\u0131 kaynak ay\u0131rmalar\u0131 ciddi maliyet israf\u0131na neden olabilir. Bu makalede, Kubernetes isteklerini (requests) ve limitlerini (limits) optimize ederek hem sistem kararl\u0131l\u0131\u011f\u0131n\u0131 sa\u011flamay\u0131 hem de gereksiz harcamalardan ka\u00e7\u0131nmay\u0131 ad\u0131m ad\u0131m inceleyece\u011fiz.","og_url":"https:\/\/fatihsoysal.com\/blog\/kubernetes-istek-ve-limit-ayarlari-oomkilleri-ve-kaybi-onleme\/","og_site_name":"Kodlar\u0131n Gizemli D\u00fcnyas\u0131","article_published_time":"2025-10-11T02:01:28+00:00","author":"Fatih Soysal","twitter_card":"summary_large_image","twitter_misc":{"Yazan:":"Fatih Soysal","Tahmini okuma s\u00fcresi":"28 dakika"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/fatihsoysal.com\/blog\/kubernetes-istek-ve-limit-ayarlari-oomkilleri-ve-kaybi-onleme\/#article","isPartOf":{"@id":"https:\/\/fatihsoysal.com\/blog\/kubernetes-istek-ve-limit-ayarlari-oomkilleri-ve-kaybi-onleme\/"},"author":{"name":"Fatih Soysal","@id":"https:\/\/fatihsoysal.com\/blog\/#\/schema\/person\/002a254750921dcfd568a99e48240dd1"},"headline":"Kubernetes \u0130stek ve Limit Ayarlar\u0131: OOMKilleri ve Kayb\u0131 \u00d6nleme","datePublished":"2025-10-11T02:01:28+00:00","mainEntityOfPage":{"@id":"https:\/\/fatihsoysal.com\/blog\/kubernetes-istek-ve-limit-ayarlari-oomkilleri-ve-kaybi-onleme\/"},"wordCount":5547,"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\/kubernetes-istek-ve-limit-ayarlari-oomkilleri-ve-kaybi-onleme\/#respond"]}],"copyrightYear":"2025","copyrightHolder":{"@id":"https:\/\/fatihsoysal.com\/blog\/#organization"}},{"@type":"WebPage","@id":"https:\/\/fatihsoysal.com\/blog\/kubernetes-istek-ve-limit-ayarlari-oomkilleri-ve-kaybi-onleme\/","url":"https:\/\/fatihsoysal.com\/blog\/kubernetes-istek-ve-limit-ayarlari-oomkilleri-ve-kaybi-onleme\/","name":"Kubernetes \u0130stek ve Limit Ayarlar\u0131: OOMKilleri ve Kayb\u0131 \u00d6nleme","isPartOf":{"@id":"https:\/\/fatihsoysal.com\/blog\/#website"},"datePublished":"2025-10-11T02:01:28+00:00","description":"Kubernetes ortamlar\u0131nda kar\u015f\u0131la\u015f\u0131lan en b\u00fcy\u00fck zorluklardan biri, uygulamalar i\u00e7in do\u011fru kaynak miktar\u0131n\u0131 belirlemektir. Peki, uygulamalar\u0131n\u0131z i\u00e7in ne kadar CPU ve haf\u0131za ay\u0131rmal\u0131s\u0131n\u0131z? Yetersiz ayarlamalar OOMKill'lere ve performans sorunlar\u0131na yol a\u00e7arken, a\u015f\u0131r\u0131 kaynak ay\u0131rmalar\u0131 ciddi maliyet israf\u0131na neden olabilir. Bu makalede, Kubernetes isteklerini (requests) ve limitlerini (limits) optimize ederek hem sistem kararl\u0131l\u0131\u011f\u0131n\u0131 sa\u011flamay\u0131 hem de gereksiz harcamalardan ka\u00e7\u0131nmay\u0131 ad\u0131m ad\u0131m inceleyece\u011fiz.","breadcrumb":{"@id":"https:\/\/fatihsoysal.com\/blog\/kubernetes-istek-ve-limit-ayarlari-oomkilleri-ve-kaybi-onleme\/#breadcrumb"},"inLanguage":"tr","potentialAction":[{"@type":"ReadAction","target":["https:\/\/fatihsoysal.com\/blog\/kubernetes-istek-ve-limit-ayarlari-oomkilleri-ve-kaybi-onleme\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/fatihsoysal.com\/blog\/kubernetes-istek-ve-limit-ayarlari-oomkilleri-ve-kaybi-onleme\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Anasayfa","item":"https:\/\/fatihsoysal.com\/blog\/"},{"@type":"ListItem","position":2,"name":"Kubernetes \u0130stek ve Limit Ayarlar\u0131: OOMKilleri ve Kayb\u0131 \u00d6nleme"}]},{"@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\/31548","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=31548"}],"version-history":[{"count":0,"href":"https:\/\/fatihsoysal.com\/blog\/wp-json\/wp\/v2\/posts\/31548\/revisions"}],"wp:attachment":[{"href":"https:\/\/fatihsoysal.com\/blog\/wp-json\/wp\/v2\/media?parent=31548"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/fatihsoysal.com\/blog\/wp-json\/wp\/v2\/categories?post=31548"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/fatihsoysal.com\/blog\/wp-json\/wp\/v2\/tags?post=31548"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}