Kubernetes pop\u00fclerli\u011fi artt\u0131k\u00e7a, maliyetler de kontrols\u00fczce b\u00fcy\u00fcyebilir. Bu makalede, Kubernetes maliyetlerini nas\u0131l y\u00f6netece\u011finizi ve FinOps prensiplerini nas\u0131l uygulayaca\u011f\u0131n\u0131z\u0131 ad\u0131m ad\u0131m \u00f6\u011freneceksiniz.<\/p>\n
Kubernetes (K8s), konteynerize uygulamalar\u0131 da\u011f\u0131tmak, \u00f6l\u00e7eklendirmek ve y\u00f6netmek i\u00e7in g\u00fc\u00e7l\u00fc bir platformdur. Ancak, bu g\u00fcc\u00fcn kontrols\u00fcz kullan\u0131m\u0131, “maliyet sprawl’\u0131” ad\u0131 verilen bir duruma yol a\u00e7abilir. Bu durum, tahmin edilemeyen ve y\u00f6netilemeyen artan bulut maliyetleri anlam\u0131na gelir. \u015eirketler, Kubernetes’in sundu\u011fu esneklik ve otomasyon sayesinde h\u0131zla b\u00fcy\u00fcyebilirken, altyap\u0131 maliyetleri de ayn\u0131 h\u0131zla artabilir. Bu, \u00f6zellikle b\u00fct\u00e7e planlamas\u0131 ve finansal \u00f6ng\u00f6r\u00fclebilirlik a\u00e7\u0131s\u0131ndan b\u00fcy\u00fck bir zorluk te\u015fkil eder. FinOps (Cloud Financial Operations), bulut harcamalar\u0131n\u0131 anlamak, optimize etmek ve kontrol etmek i\u00e7in finans, teknoloji ve i\u015f ekiplerini bir araya getiren bir disiplindir. Kubernetes maliyetlerini etkin bir \u015fekilde y\u00f6netmek, yaln\u0131zca b\u00fct\u00e7eyi korumakla kalmaz, ayn\u0131 zamanda kaynaklar\u0131n daha verimli kullan\u0131lmas\u0131n\u0131 sa\u011flayarak rekabet avantaj\u0131 da sunar. Bu makalede, Kubernetes ortam\u0131n\u0131zdaki maliyetleri nas\u0131l kontrol alt\u0131na alabilece\u011finizi ve FinOps prensiplerini nas\u0131l uygulayabilece\u011finizi detayl\u0131 bir \u015fekilde inceleyece\u011fiz.<\/p>\n
Peki, bu maliyet sprawl’\u0131 tam olarak nas\u0131l olu\u015fuyor? Genellikle, h\u0131zl\u0131 geli\u015fim s\u00fcre\u00e7lerinde ekipler, maliyetleri ikinci planda tutarak i\u015flevselli\u011fe odaklanabilirler. Bu durum, kullan\u0131lmayan kaynaklar\u0131n (idle resources), yanl\u0131\u015f yap\u0131land\u0131r\u0131lm\u0131\u015f \u00f6l\u00e7eklendirme politikalar\u0131n\u0131n, gereksiz yere b\u00fcy\u00fck sanal makinelerin (VMs) veya yetersiz depolama y\u00f6netiminin birikmesine yol a\u00e7ar. \u00d6rne\u011fin, bir geli\u015ftirme ekibi bir uygulamay\u0131 h\u0131zl\u0131ca devreye almak i\u00e7in varsay\u0131lan ayarlar\u0131 kullanabilir ve bu ayarlar, \u00fcretim ortam\u0131 i\u00e7in a\u015f\u0131r\u0131 kaynak t\u00fcketimine neden olabilir. Benzer \u015fekilde, otomatik \u00f6l\u00e7eklendirme (autoscaling) politikalar\u0131 do\u011fru ayarlanmad\u0131\u011f\u0131nda, trafik az olsa bile y\u00fcksek kapasite sa\u011flanabilir, bu da gereksiz maliyetlere yol a\u00e7ar. Bu t\u00fcr durumlar, zamanla k\u00fc\u00e7\u00fck birikimlerle ba\u015flay\u0131p b\u00fcy\u00fck finansal sorunlara d\u00f6n\u00fc\u015febilir. Bu nedenle, Kubernetes maliyet y\u00f6netimi, yaln\u0131zca bir “teknik optimizasyon” meselesi de\u011fil, ayn\u0131 zamanda stratejik bir i\u015f karar\u0131d\u0131r.<\/p>\n
Kubernetes’in sundu\u011fu dinamik yap\u0131, maliyet takibini de karma\u015f\u0131kla\u015ft\u0131r\u0131r. Konteynerler s\u00fcrekli olarak ba\u015flat\u0131l\u0131r, durdurulur ve \u00f6l\u00e7eklenir. Bu de\u011fi\u015fkenlik, geleneksel altyap\u0131 maliyetlendirme y\u00f6ntemleriyle ba\u015fa \u00e7\u0131kmay\u0131 zorla\u015ft\u0131r\u0131r. \u0130\u015fte tam bu noktada FinOps devreye girer. FinOps, bulut maliyetlerini \u015feffaf hale getirmeyi, sorumluluklar\u0131 belirlemeyi ve s\u00fcrekli iyile\u015ftirme d\u00f6ng\u00fcleri olu\u015fturmay\u0131 hedefler. Kubernetes ortam\u0131nda FinOps uygulamak, geli\u015ftiricilerden operasyon ekiplerine ve finans departman\u0131na kadar t\u00fcm payda\u015flar\u0131n maliyet bilincini art\u0131rmas\u0131n\u0131 gerektirir. Bu, sadece maliyetleri d\u00fc\u015f\u00fcrmekle kalmaz, ayn\u0131 zamanda ekiplerin daha bilin\u00e7li kararlar almas\u0131n\u0131 sa\u011flayarak inovasyonu da destekler.<\/p>\n
Bu makalenin amac\u0131, y\u00f6neticilere ve teknik liderlere, Kubernetes maliyetlerini anlamalar\u0131, kontrol alt\u0131na almalar\u0131 ve s\u00fcrd\u00fcr\u00fclebilir bir bulut finansal y\u00f6netimi modeli olu\u015fturmalar\u0131 i\u00e7in pratik bir rehber sunmakt\u0131r. Ad\u0131m ad\u0131m ilerleyerek, temel kavramlardan ba\u015flay\u0131p, uygulamal\u0131 \u00f6rneklere ve ileri d\u00fczey stratejilere kadar her \u015feyi ele alaca\u011f\u0131z. Amac\u0131m\u0131z, Kubernetes’in g\u00fcc\u00fcn\u00fc maliyet y\u00fck\u00fc olmadan kullanman\u0131z\u0131 sa\u011flamakt\u0131r.<\/p>\n
Kubernetes maliyetlerini y\u00f6netmeye ba\u015flamadan \u00f6nce, temel kavramlar\u0131 netle\u015ftirmek \u00f6nemlidir. Kubernetes’in maliyetleri genellikle birka\u00e7 ana bile\u015fene ayr\u0131l\u0131r: i\u015flem (compute), depolama (storage), a\u011f (networking) ve y\u00f6netilen servisler (managed services). \u0130\u015flem maliyetleri, Pod’lar\u0131n\u0131z\u0131n \u00e7al\u0131\u015ft\u0131\u011f\u0131 sanal makinelerin (node’lar) CPU ve bellek kullan\u0131m\u0131ndan kaynaklan\u0131r. Depolama maliyetleri, kal\u0131c\u0131 depolama birimleri (Persistent Volumes) ve log dosyalar\u0131 gibi veri depolama alanlar\u0131ndan olu\u015fur. A\u011f maliyetleri, Pod’lar aras\u0131ndaki trafik, d\u0131\u015far\u0131ya \u00e7\u0131kan veri transferi ve y\u00fck dengeleyiciler (load balancers) ile ilgilidir. Y\u00f6netilen servisler ise, Kubernetes’i bar\u0131nd\u0131ran bulut sa\u011flay\u0131c\u0131s\u0131n\u0131n (AWS EKS, Google GKE, Azure AKS gibi) sundu\u011fu ek hizmetlerdir ve kendi maliyet modelleri vard\u0131r.<\/p>\n
Bu maliyet bile\u015fenlerini anlamak, optimizasyon \u00e7abalar\u0131n\u0131z\u0131 nereye odaklaman\u0131z gerekti\u011fini belirlemenize yard\u0131mc\u0131 olur. \u00d6rne\u011fin, e\u011fer i\u015flem maliyetleriniz y\u00fcksekse, Pod’lar\u0131n\u0131z\u0131n kaynak isteklerini (resource requests) ve limitlerini (resource limits) optimize etmeniz gerekebilir. Bu istekler ve limitler, Kubernetes’in Pod’lara ne kadar CPU ve bellek ay\u0131raca\u011f\u0131n\u0131 belirler. Yanl\u0131\u015f yap\u0131land\u0131r\u0131lm\u0131\u015f istekler, Pod’lar\u0131n gere\u011finden fazla veya az kaynak talep etmesine neden olabilir. Kaynak isteklerini do\u011fru ayarlamak, node’lar\u0131n daha verimli kullan\u0131lmas\u0131n\u0131 sa\u011flar ve gereksiz yere fazla node kiralamay\u0131 \u00f6nler. Bu, maliyetleri do\u011frudan d\u00fc\u015f\u00fcren en temel optimizasyon ad\u0131mlar\u0131ndan biridir.<\/p>\n
Depolama maliyetleri de g\u00f6z ard\u0131 edilmemelidir. Kullan\u0131lmayan veya gere\u011finden b\u00fcy\u00fck Persistent Volumes, \u00f6nemli maliyet kalemleri olu\u015fturabilir. D\u00fczenli olarak depolama kullan\u0131m\u0131n\u0131 g\u00f6zden ge\u00e7irmek ve art\u0131k ihtiya\u00e7 duyulmayan birimleri silmek, bu maliyetleri azaltmada etkilidir. Ayr\u0131ca, farkl\u0131 depolama s\u0131n\u0131flar\u0131 (storage classes) aras\u0131ndaki performans ve maliyet farklar\u0131n\u0131 anlamak, uygulaman\u0131z\u0131n ihtiya\u00e7lar\u0131na en uygun depolama \u00e7\u00f6z\u00fcm\u00fcn\u00fc se\u00e7menize yard\u0131mc\u0131 olur. \u00d6rne\u011fin, y\u00fcksek performans gerektirmeyen uygulamalar i\u00e7in daha uygun fiyatl\u0131 depolama se\u00e7enekleri tercih edilebilir.<\/p>\n
A\u011f maliyetleri, \u00f6zellikle b\u00fcy\u00fck \u00f6l\u00e7ekli uygulamalarda ve yo\u011fun veri transferi olan senaryolarda \u00f6nemli bir yer tutabilir. Pod’lar aras\u0131ndaki ileti\u015fim, d\u0131\u015far\u0131ya veri ak\u0131\u015f\u0131 ve y\u00fck dengeleyicilerin kullan\u0131m\u0131, a\u011f faturalar\u0131n\u0131 do\u011frudan etkiler. Veri transferini optimize etmek, gereksiz a\u011f trafi\u011fini azaltmak ve y\u00fck dengeleyicilerin do\u011fru yap\u0131land\u0131r\u0131lmas\u0131n\u0131 sa\u011flamak, bu maliyetleri kontrol alt\u0131na almak i\u00e7in kritik \u00f6neme sahiptir. Baz\u0131 durumlarda, \u00f6zel a\u011f \u00e7\u00f6z\u00fcmleri veya daha verimli ileti\u015fim protokolleri kullanarak a\u011f maliyetlerini d\u00fc\u015f\u00fcrmek m\u00fcmk\u00fcnd\u00fcr.<\/p>\n
Son olarak, y\u00f6netilen Kubernetes servislerinin (managed Kubernetes services) maliyetlerini anlamak \u00f6nemlidir. Bulut sa\u011flay\u0131c\u0131lar\u0131, Kubernetes kontrol d\u00fczlemini (control plane) y\u00f6netme, otomatik y\u00fckseltmeler ve di\u011fer operasyonel y\u00fckleri \u00fcstlenerek kolayl\u0131k sa\u011flarlar. Ancak, bu hizmetlerin de kendi \u00fccretlendirme modelleri vard\u0131r. Kulland\u0131\u011f\u0131n\u0131z bulut sa\u011flay\u0131c\u0131s\u0131n\u0131n fiyatland\u0131rma belgelerini dikkatlice incelemek ve hangi \u00f6zelliklerin ek maliyet getirdi\u011fini anlamak, b\u00fct\u00e7enizi daha iyi planlaman\u0131za yard\u0131mc\u0131 olur. \u00d6rne\u011fin, baz\u0131 sa\u011flay\u0131c\u0131lar, y\u00fcksek oranda kullan\u0131labilirlik (high availability) veya ek \u00f6zellikler i\u00e7in daha y\u00fcksek \u00fccret talep edebilirler. Bu nedenle, ihtiya\u00e7lar\u0131n\u0131za en uygun hizmet seviyesini se\u00e7mek maliyet optimizasyonu a\u00e7\u0131s\u0131ndan \u00f6nemlidir.<\/p>\n
Etkin bir maliyet y\u00f6netimi i\u00e7in ilk ad\u0131m, mevcut durumu anlamakt\u0131r. Kubernetes maliyetlerini izleme ve analiz etme, hangi alanlar\u0131n optimizasyona ihtiya\u00e7 duydu\u011funu belirlemenizi sa\u011flar. Bunun i\u00e7in \u00e7e\u015fitli ara\u00e7lar ve yakla\u015f\u0131mlar mevcuttur. \u00d6ncelikle, bulut sa\u011flay\u0131c\u0131n\u0131z\u0131n sundu\u011fu maliyet y\u00f6netim ara\u00e7lar\u0131 (AWS Cost Explorer, Google Cloud Billing, Azure Cost Management gibi) temel bir ba\u015flang\u0131\u00e7 noktas\u0131d\u0131r. Bu ara\u00e7lar, genel bulut harcamalar\u0131n\u0131z\u0131 kategorilere ay\u0131rman\u0131za ve Kubernetes ile ilgili maliyetleri belirlemenize yard\u0131mc\u0131 olur.<\/p>\n
Ancak, sadece bulut sa\u011flay\u0131c\u0131s\u0131n\u0131n ara\u00e7lar\u0131 genellikle yeterli olmaz. Kubernetes’in dinamik yap\u0131s\u0131 nedeniyle, maliyetleri Pod, Deployment, Namespace veya etiket (label) baz\u0131nda daha ayr\u0131nt\u0131l\u0131 analiz etmek gerekir. \u0130\u015fte bu noktada, \u00f6zel Kubernetes maliyet izleme ara\u00e7lar\u0131 devreye girer. OpenCost, Kubecost, ve Harness gibi a\u00e7\u0131k kaynakl\u0131 veya ticari \u00e7\u00f6z\u00fcmler, Kubernetes k\u00fcmelerinizdeki maliyetleri detayl\u0131 bir \u015fekilde analiz etmenizi sa\u011flar. Bu ara\u00e7lar, hangi uygulamalar\u0131n veya ekiplerin en \u00e7ok maliyete neden oldu\u011funu, hangi kaynaklar\u0131n israf edildi\u011fini ve potansiyel optimizasyon f\u0131rsatlar\u0131n\u0131 belirlemenize yard\u0131mc\u0131 olur.<\/p>\n
\u00d6rne\u011fin, OpenCost, k\u00fcmelerinizdeki kaynak kullan\u0131m\u0131n\u0131 ve maliyetlerini ger\u00e7ek zamanl\u0131 olarak izlemenizi sa\u011flar. Hangi Pod’lar\u0131n en \u00e7ok CPU veya bellek t\u00fcketti\u011fini, hangi Persistent Volumes’lar\u0131n bo\u015fta oldu\u011funu ve hangi node’lar\u0131n a\u015f\u0131r\u0131 kullan\u0131ld\u0131\u011f\u0131n\u0131 g\u00f6rselle\u015ftirebilirsiniz. Bu bilgiler, geli\u015ftirme ekiplerinin ve operasyon personelinin maliyet bilincini art\u0131rmak i\u00e7in kritik \u00f6neme sahiptir. Ekipler, kendi geli\u015ftirdikleri uygulamalar\u0131n maliyet etkisini do\u011frudan g\u00f6rebildiklerinde, daha bilin\u00e7li kararlar alabilirler.<\/p>\n
Etiketleme (labeling) stratejisi, maliyet analizi i\u00e7in hayati bir \u00f6neme sahiptir. Kubernetes kaynaklar\u0131na anlaml\u0131 etiketler atayarak, maliyetleri belirli projelere, ekiplere, uygulamalara veya ortamlara (geli\u015ftirme, test, \u00fcretim) g\u00f6re ay\u0131rabilirsiniz. \u00d6rne\u011fin, bir Deployment’a Maliyet analizinin bir di\u011fer \u00f6nemli y\u00f6n\u00fc, “kullan\u0131m d\u0131\u015f\u0131” (idle) veya “a\u015f\u0131r\u0131 tahsis edilmi\u015f” (over-provisioned) kaynaklar\u0131 tespit etmektir. Bir\u00e7ok Kubernetes k\u00fcmesinde, Pod’lar i\u00e7in tan\u0131mlanan kaynak istekleri ve limitleri, ger\u00e7ek kullan\u0131m\u0131n \u00e7ok \u00fczerindedir. Bu, node’lar\u0131n tam kapasiteyle kullan\u0131lmas\u0131n\u0131 engeller ve maliyetleri art\u0131r\u0131r. Maliyet izleme ara\u00e7lar\u0131, bu t\u00fcr durumlar\u0131 tespit etmek i\u00e7in ge\u00e7mi\u015f kullan\u0131m verilerini analiz edebilir ve daha do\u011fru kaynak istekleri ve limitleri \u00f6nerebilir. \u00d6rne\u011fin, bir Pod’un CPU kullan\u0131m\u0131 s\u00fcrekli olarak Son olarak, maliyet trendlerini takip etmek ve d\u00fczenli raporlar olu\u015fturmak, uzun vadeli maliyet y\u00f6netimi i\u00e7in \u00f6nemlidir. Hangi alanlarda maliyetlerin artt\u0131\u011f\u0131n\u0131 veya azald\u0131\u011f\u0131n\u0131 anlamak, uygulanan optimizasyon stratejilerinin etkinli\u011fini de\u011ferlendirmenizi sa\u011flar. Bu raporlar, y\u00f6neticilere ve finans departman\u0131na, bulut harcamalar\u0131 hakk\u0131nda \u015feffaf bir g\u00f6r\u00fcn\u00fcm sunar ve gelecekteki b\u00fct\u00e7e planlamas\u0131 i\u00e7in temel olu\u015fturur.<\/p>\n Kubernetes maliyetlerini d\u00fc\u015f\u00fcrmenin en etkili yollar\u0131ndan biri, kaynaklar\u0131 ak\u0131ll\u0131ca y\u00f6netmek ve \u00f6l\u00e7eklendirme politikalar\u0131n\u0131 optimize etmektir. Bu, hem Pod seviyesinde hem de k\u00fcme seviyesinde ger\u00e7ekle\u015ftirilebilir.<\/p>\n Daha \u00f6nce de bahsedildi\u011fi gibi, Pod’lar\u0131n\u0131z i\u00e7in do\u011fru kaynak istekleri (resource requests) ve limitleri (resource limits) belirlemek kritiktir. Kaynak istekleri, Kubernetes’in bir Pod’u \u00e7al\u0131\u015ft\u0131rmak i\u00e7in ne kadar CPU ve bellek garanti etmesi gerekti\u011fini belirtir. Kaynak limitleri ise, bir Pod’un kullanabilece\u011fi maksimum CPU ve bellek miktar\u0131n\u0131 belirler. Bu ikisinin do\u011fru ayarlanmas\u0131, node’lar\u0131n verimli kullan\u0131lmas\u0131n\u0131 sa\u011flar ve “noisy neighbor” sorununu (bir Pod’un di\u011ferlerinin performans\u0131n\u0131 etkilemesi) \u00f6nler.<\/p>\n \u00d6rnek Senaryo:<\/strong> Bir geli\u015ftirme ekibi, bir web uygulamas\u0131n\u0131n Pod’lar\u0131 i\u00e7in Bu optimizasyonu yapmak i\u00e7in, Pod’lar\u0131n\u0131z\u0131n ger\u00e7ek kullan\u0131m\u0131n\u0131 izlemek amac\u0131yla Prometheus, Grafana veya Kubecost gibi ara\u00e7lar\u0131 kullanabilirsiniz. Elde etti\u011finiz verilere dayanarak, \u0130\u015fte \u00f6rnek bir manifest g\u00fcncellemesi:<\/p>\n Kubernetes’in en g\u00fc\u00e7l\u00fc \u00f6zelliklerinden biri olan otomatik \u00f6l\u00e7eklendirme, talebe g\u00f6re kaynaklar\u0131 dinamik olarak ayarlaman\u0131z\u0131 sa\u011flar. \u0130ki ana otomatik \u00f6l\u00e7eklendirme t\u00fcr\u00fc vard\u0131r:<\/p>\n HPA Optimizasyonu:<\/strong> HPA’y\u0131 do\u011fru yap\u0131land\u0131rmak, maliyetleri \u00f6nemli \u00f6l\u00e7\u00fcde d\u00fc\u015f\u00fcrebilir. \u00d6rne\u011fin, HPA’n\u0131n tetiklenme e\u015fiklerini \u00e7ok d\u00fc\u015f\u00fck ayarlamak, gereksiz yere fazla Pod ba\u015flat\u0131lmas\u0131na neden olabilir. Tersine, \u00e7ok y\u00fcksek ayarlamak ise, talebi kar\u015f\u0131lamada gecikmelere yol a\u00e7abilir. Ger\u00e7ek kullan\u0131m verilerine dayanarak HPA metriklerini ve e\u015fiklerini ayarlamak \u00f6nemlidir.<\/p>\n Cluster Autoscaler Optimizasyonu:<\/strong> Cluster Autoscaler, Pod’lar\u0131n \u00e7al\u0131\u015fmas\u0131 i\u00e7in yeterli kaynak olmad\u0131\u011f\u0131nda yeni node’lar ekler. Bu, maliyetleri art\u0131rabilir. Cluster Autoscaler’\u0131n do\u011fru \u015fekilde yap\u0131land\u0131r\u0131lmas\u0131, yaln\u0131zca ger\u00e7ekten ihtiya\u00e7 duyuldu\u011funda node eklenmesini sa\u011flar. \u00d6rne\u011fin, \u00d6rnek Senaryo:<\/strong> Bir e-ticaret sitesi, \u00f6zel g\u00fcnlerde (Kara Cuma, Anneler G\u00fcn\u00fc) yo\u011fun trafik al\u0131r. HPA, bu yo\u011funlukta Pod say\u0131s\u0131n\u0131 otomatik olarak art\u0131rarak talebi kar\u015f\u0131lar. Ancak, bu art\u0131\u015fa paralel olarak k\u00fcme \u00fczerindeki node say\u0131s\u0131 da yetersiz kalabilir. Cluster Autoscaler, bu durumda otomatik olarak yeni node’lar ekleyerek Pod’lar\u0131n \u00e7al\u0131\u015fmas\u0131n\u0131 sa\u011flar. Yo\u011funluk azald\u0131\u011f\u0131nda ise, hem Pod say\u0131s\u0131 hem de node say\u0131s\u0131 otomatik olarak d\u00fc\u015f\u00fcr\u00fcl\u00fcr. Bu dinamik \u00f6l\u00e7eklendirme, sadece yo\u011fun zamanlarda gerekli olan kapasiteyi sa\u011flar, b\u00f6ylece maliyetler optimize edilir.<\/p>\n HPA i\u00e7in \u00f6rnek bir yap\u0131land\u0131rma:<\/p>\n Bulut sa\u011flay\u0131c\u0131lar\u0131, kullan\u0131lmayan kapasitelerini daha d\u00fc\u015f\u00fck fiyatlarla sunan “spot instance”lar (AWS) veya “preemptible VMs” (Google Cloud) gibi se\u00e7enekler sunar. Bu instance’lar, bulut sa\u011flay\u0131c\u0131s\u0131 taraf\u0131ndan herhangi bir zamanda geri al\u0131nabilir, bu nedenle kritik olmayan veya kesintiye u\u011frayabilir i\u015f y\u00fckleri i\u00e7in idealdir.<\/p>\n Kubernetes k\u00fcmelerinizde spot instance’lar\u0131 kullanarak \u00f6nemli maliyet tasarrufu sa\u011flayabilirsiniz. \u00d6rne\u011fin, Batch i\u015fleri, CI\/CD pipeline’lar\u0131 veya veri i\u015fleme g\u00f6revleri gibi kesintiye u\u011frayabilir i\u015fler i\u00e7in spot instance’lar\u0131 kullanmak, maliyetleri %70-90 oran\u0131nda d\u00fc\u015f\u00fcrebilir. Cluster Autoscaler, spot instance’lar\u0131 da destekleyebilir, b\u00f6ylece k\u00fcme kapasiteniz talebe g\u00f6re dinamik olarak ayarlan\u0131r.<\/p>\n Dikkat Edilmesi Gerekenler:<\/strong> Spot instance’lar\u0131 kullan\u0131rken, i\u015f y\u00fcklerinizin kesintiye u\u011frayabilece\u011fini g\u00f6z \u00f6n\u00fcnde bulundurmal\u0131s\u0131n\u0131z. Bu nedenle, i\u015flerinizi yeniden ba\u015flat\u0131labilir veya durumunu kaydedebilir \u015fekilde tasarlamak \u00f6nemlidir. Ayr\u0131ca, spot instance’lar her zaman mevcut olmayabilir, bu nedenle yedek olarak on-demand instance’lar\u0131n da bulunmas\u0131 \u00f6nerilir.<\/p>\n Kubernetes maliyetlerinin \u00f6nemli bir k\u0131sm\u0131n\u0131 depolama ve a\u011f bile\u015fenleri olu\u015fturabilir. Bu alanlarda yap\u0131lacak optimizasyonlar, genel maliyetleri \u00f6nemli \u00f6l\u00e7\u00fcde d\u00fc\u015f\u00fcrebilir.<\/p>\n Persistent Volumes (PV) ve Persistent Volume Claims (PVC) kullan\u0131m\u0131, Kubernetes’te veri kal\u0131c\u0131l\u0131\u011f\u0131n\u0131 sa\u011flar. Ancak, kullan\u0131lmayan veya gere\u011finden b\u00fcy\u00fck PV’ler \u00f6nemli bir maliyet kalemi olabilir. D\u00fczenli olarak depolama kullan\u0131m\u0131n\u0131 g\u00f6zden ge\u00e7irmek ve a\u015fa\u011f\u0131daki ad\u0131mlar\u0131 uygulamak \u00f6nemlidir:<\/p>\n \u00d6rnek Senaryo:<\/strong> Bir veritaban\u0131 uygulamas\u0131 i\u00e7in olu\u015fturulan bir Persistent Volume, ba\u015flang\u0131\u00e7ta 1TB olarak yap\u0131land\u0131r\u0131lm\u0131\u015f. Ancak, uygulama b\u00fcy\u00fcd\u00fck\u00e7e ve veri temizli\u011fi yap\u0131ld\u0131k\u00e7a, ger\u00e7ek depolama kullan\u0131m\u0131 sadece 100GB’a d\u00fc\u015fm\u00fc\u015f. Bu durumda, PV’nin boyutunu 100GB’a d\u00fc\u015f\u00fcrmek, ayl\u0131k depolama maliyetlerinde \u00f6nemli bir tasarruf sa\u011flayacakt\u0131r. Bu t\u00fcr optimizasyonlar i\u00e7in d\u00fczenli denetimler ve otomatik ara\u00e7lar kullan\u0131labilir.<\/p>\n Kubernetes’te a\u011f maliyetleri genellikle veri transferi (data transfer), y\u00fck dengeleyiciler (load balancers) ve harici IP adresleri gibi kalemlerden olu\u015fur. Bu maliyetleri d\u00fc\u015f\u00fcrmek i\u00e7in a\u015fa\u011f\u0131daki stratejiler uygulanabilir:<\/p>\n \u00d6rnek Senaryo:<\/strong> Bir mikroservis mimarisinde, farkl\u0131 servisler aras\u0131ndaki ileti\u015fim i\u00e7in s\u00fcrekli olarak b\u00fcy\u00fck miktarda veri transferi ger\u00e7ekle\u015fiyor. E\u011fer bu servisler farkl\u0131 availability zone’larda bulunuyorsa, veri transfer maliyetleri y\u00fcksek olabilir. Bu durumu optimize etmek i\u00e7in, ilgili servisleri ayn\u0131 availability zone’a ta\u015f\u0131mak veya servisler aras\u0131ndaki ileti\u015fimi daha verimli hale getirecek \u00e7\u00f6z\u00fcmler (\u00f6rne\u011fin, gRPC yerine daha hafif protokoller kullanmak) uygulamak maliyetleri d\u00fc\u015f\u00fcrebilir.<\/p>\n Kubernetes maliyetlerini s\u00fcrd\u00fcr\u00fclebilir bir \u015fekilde y\u00f6netmek, yaln\u0131zca teknik optimizasyonlarla de\u011fil, ayn\u0131 zamanda g\u00fc\u00e7l\u00fc bir FinOps k\u00fclt\u00fcr\u00fc olu\u015fturmakla m\u00fcmk\u00fcnd\u00fcr. FinOps, bulut harcamalar\u0131n\u0131 \u015feffaf hale getirmeyi, sorumluluklar\u0131 belirlemeyi ve s\u00fcrekli iyile\u015ftirme d\u00f6ng\u00fcleri olu\u015fturmay\u0131 hedefler. Bu, finans, teknoloji ve i\u015f ekiplerinin birlikte \u00e7al\u0131\u015fmas\u0131n\u0131 gerektirir.<\/p>\n FinOps’un temelinde ekip i\u00e7i i\u015fbirli\u011fi yatar. Geli\u015ftirme ekipleri, altyap\u0131 ekipleri ve finans departman\u0131, bulut maliyetleri konusunda ortak bir anlay\u0131\u015fa sahip olmal\u0131d\u0131r. Geli\u015ftiriciler, yazd\u0131klar\u0131 kodun ve da\u011f\u0131tt\u0131klar\u0131 uygulamalar\u0131n maliyet etkisini anlamal\u0131d\u0131r. Altyap\u0131 ekipleri, maliyet optimizasyonu i\u00e7in teknik \u00e7\u00f6z\u00fcmler \u00fcretmeli ve finans departman\u0131 ise, b\u00fct\u00e7e planlamas\u0131 ve maliyet takibi konular\u0131nda rehberlik etmelidir.<\/p>\n \u00d6rnek Senaryo:<\/strong> Bir \u015firkette, geli\u015ftirme ekibi yeni bir \u00f6zellik geli\u015ftirmek i\u00e7in h\u0131zl\u0131 bir \u015fekilde bir Kubernetes k\u00fcmesi olu\u015fturur. Ancak, bu k\u00fcme i\u00e7in ayr\u0131lan kaynaklar ve kullan\u0131lan servisler, maliyetleri h\u0131zla art\u0131r\u0131r. Finans departman\u0131, bu art\u0131\u015f\u0131 fark etti\u011finde, geli\u015ftirme ekibiyle ileti\u015fime ge\u00e7er. Birlikte, maliyetleri d\u00fc\u015f\u00fcrmek i\u00e7in daha uygun fiyatl\u0131 servisler kullanma, kaynaklar\u0131 optimize etme ve gereksiz yere \u00e7al\u0131\u015fan servisleri kapatma gibi \u00e7\u00f6z\u00fcmler \u00fczerinde \u00e7al\u0131\u015f\u0131rlar. Bu i\u015fbirli\u011fi, hem maliyetleri d\u00fc\u015f\u00fcr\u00fcr hem de gelecekte benzer sorunlar\u0131n ya\u015fanmas\u0131n\u0131 engeller.<\/p>\n Her ekibin veya projenin, kulland\u0131\u011f\u0131 kaynaklar\u0131n maliyetinden sorumlu tutulmas\u0131, maliyet bilincini art\u0131r\u0131r. Bu, “finansal \u015feffafl\u0131k” ilkesiyle uyumludur. Maliyet izleme ara\u00e7lar\u0131 ve etkili etiketleme stratejileri, hangi ekibin veya projenin ne kadar harcama yapt\u0131\u011f\u0131n\u0131 net bir \u015fekilde belirlemeye yard\u0131mc\u0131 olur. Bu veriler, d\u00fczenli toplant\u0131larda veya raporlarda payla\u015f\u0131labilir.<\/p>\n \u00d6rnek Senaryo:<\/strong> Bir \u015firkette, her geli\u015ftirme ekibine, kendi projeleri i\u00e7in ayr\u0131lan bir b\u00fct\u00e7e verilir. Ekipler, bu b\u00fct\u00e7e dahilinde kalmak i\u00e7in kaynak kullan\u0131mlar\u0131n\u0131 optimize etmeye te\u015fvik edilir. Maliyet izleme ara\u00e7lar\u0131, her ekibin harcamalar\u0131n\u0131 ger\u00e7ek zamanl\u0131 olarak takip eder ve belirli bir b\u00fct\u00e7e s\u0131n\u0131r\u0131na yakla\u015f\u0131ld\u0131\u011f\u0131nda uyar\u0131lar g\u00f6nderir. Bu yakla\u015f\u0131m, ekipleri maliyet konusunda daha dikkatli olmaya te\u015fvik eder.<\/p>\n FinOps, tek seferlik bir \u00e7aba de\u011fil, s\u00fcrekli bir iyile\u015ftirme s\u00fcrecidir. Kubernetes ortam\u0131n\u0131zdaki maliyetleri d\u00fczenli olarak izlemeli, analiz etmeli ve optimizasyon f\u0131rsatlar\u0131n\u0131 belirlemelisiniz. Bu, d\u00fczenli maliyet g\u00f6zden ge\u00e7irme toplant\u0131lar\u0131, otomasyon ara\u00e7lar\u0131n\u0131n kullan\u0131m\u0131 ve yeni maliyet optimizasyon tekniklerinin ara\u015ft\u0131r\u0131lmas\u0131 yoluyla ger\u00e7ekle\u015ftirilir.<\/p>\n \u00d6rnek Senaryo:<\/strong> Bir \u015firket, her ay\u0131n ba\u015f\u0131nda bir “Maliyet Optimizasyon Haftas\u0131” d\u00fczenler. Bu hafta boyunca, m\u00fchendislik ve finans ekipleri bir araya gelerek, ge\u00e7en ay\u0131n maliyet raporlar\u0131n\u0131 inceler, potansiyel israf alanlar\u0131n\u0131 belirler ve bu alanlarda optimizasyon \u00e7al\u0131\u015fmalar\u0131 yaparlar. Bu s\u00fcrekli iyile\u015ftirme d\u00f6ng\u00fcs\u00fc, maliyetlerin zaman i\u00e7inde kontrol alt\u0131nda tutulmas\u0131n\u0131 sa\u011flar.<\/p>\n Temel optimizasyon tekniklerinin \u00f6tesine ge\u00e7erek, Kubernetes maliyetlerini daha da ileri d\u00fczeyde y\u00f6netmek i\u00e7in geli\u015fmi\u015f stratejiler ve ara\u00e7lar mevcuttur. Bu stratejiler, daha karma\u015f\u0131k senaryolarda daha fazla tasarruf ve kontrol sa\u011flamay\u0131 hedefler.<\/p>\n Geli\u015fmi\u015f otomasyon ara\u00e7lar\u0131 ve scriptler kullanarak, maliyet optimizasyonunu programatik hale getirebilirsiniz. Bu, tekrarlayan g\u00f6revleri otomatikle\u015ftirmenizi ve insan hatas\u0131n\u0131 azaltman\u0131z\u0131 sa\u011flar.<\/p>\n \u00d6rnek Kod Par\u00e7ac\u0131\u011f\u0131 (Konsept):<\/strong> A\u015fa\u011f\u0131daki \u00f6rnek, belirli bir label’a sahip olmayan Pod’lar\u0131 tespit edip kapatmak i\u00e7in basit bir Python scriptinin konseptini g\u00f6stermektedir. Ger\u00e7ek uygulamada, Kubernetes API’si ile entegrasyon ve daha geli\u015fmi\u015f mant\u0131k gereklidir.<\/p>\n Uygulamalar\u0131n\u0131z\u0131 tasarlarken maliyetleri g\u00f6z \u00f6n\u00fcnde bulundurmak, uzun vadede en b\u00fcy\u00fck tasarrufu sa\u011flar. Bu, “shift-left” yakla\u015f\u0131m\u0131n\u0131n bir par\u00e7as\u0131d\u0131r, yani maliyet optimizasyonunu geli\u015ftirme s\u00fcrecinin erken a\u015famalar\u0131na ta\u015f\u0131mak.<\/p>\n Bulut sa\u011flay\u0131c\u0131lar\u0131n\u0131n sundu\u011fu farkl\u0131 fiyatland\u0131rma modellerini (Reserved Instances, Savings Plans, Spot Instances) anlamak ve stratejik olarak kullanmak, maliyetleri optimize etmenin \u00f6nemli bir par\u00e7as\u0131d\u0131r. Uzun vadeli taahh\u00fctler genellikle daha d\u00fc\u015f\u00fck fiyatlar sunar, ancak bu taahh\u00fctlerin i\u015f y\u00fcklerinizin \u00f6ng\u00f6r\u00fclebilirli\u011fi ile uyumlu olmas\u0131 gerekir.<\/p>\n Senaryo:<\/strong> B\u00fcy\u00fck bir e-ticaret \u015firketi, artan trafik ve yeni \u00f6zellikler nedeniyle Kubernetes altyap\u0131s\u0131n\u0131 kullanmaya ba\u015flad\u0131. Ba\u015flang\u0131\u00e7ta h\u0131z ve esnekli\u011fe odaklan\u0131ld\u0131\u011f\u0131ndan, maliyetler ikinci planda kald\u0131. Birka\u00e7 ay sonra, ayl\u0131k bulut faturalar\u0131 beklenenin \u00e7ok \u00fczerine \u00e7\u0131kt\u0131. \u00d6zellikle, geli\u015ftirme ortamlar\u0131ndaki kaynaklar\u0131n israf\u0131, \u00fcretim ortam\u0131ndaki gereksiz yere b\u00fcy\u00fck VM’ler ve optimize edilmemi\u015f a\u011f trafi\u011fi \u00f6nemli maliyet kalemleri olu\u015fturuyordu.<\/p>\n Uygulanan Ad\u0131mlar:<\/strong><\/p>\n Sonu\u00e7:<\/strong> Bu ad\u0131mlar sonucunda \u015firket, alt\u0131 ay i\u00e7inde Kubernetes maliyetlerinde yakla\u015f\u0131k %35’lik bir tasarruf sa\u011flad\u0131. Maliyetler daha \u00f6ng\u00f6r\u00fclebilir hale geldi ve ekiplerin maliyet bilinci \u00f6nemli \u00f6l\u00e7\u00fcde artt\u0131. Geli\u015fmi\u015f izleme ve otomasyon ara\u00e7lar\u0131n\u0131n kullan\u0131m\u0131yla, maliyet y\u00f6netimi s\u00fcrekli bir iyile\u015ftirme s\u00fcreci haline geldi.<\/p>\n Kubernetes’in sundu\u011fu esneklik ve \u00f6l\u00e7eklenebilirlik, modern uygulamalar i\u00e7in vazge\u00e7ilmezdir. Ancak, bu g\u00fcc\u00fcn kontrols\u00fcz kullan\u0131m\u0131, maliyetlerin h\u0131zla artmas\u0131na neden olabilir. FinOps prensiplerini benimseyerek ve etkili maliyet y\u00f6netimi stratejileri uygulayarak, Kubernetes maliyetlerinizi kontrol alt\u0131na alabilir, kaynaklar\u0131n\u0131z\u0131 daha verimli kullanabilir ve bulut harcamalar\u0131n\u0131z\u0131 \u00f6ng\u00f6r\u00fclebilir hale getirebilirsiniz. Bu makalede ele ald\u0131\u011f\u0131m\u0131z izleme, analiz, optimizasyon ve k\u00fclt\u00fcr olu\u015fturma ad\u0131mlar\u0131, bu yolculukta size rehberlik edecektir. Unutmay\u0131n ki maliyet y\u00f6netimi, s\u00fcrekli bir s\u00fcre\u00e7tir ve d\u00fczenli dikkat ve iyile\u015ftirme gerektirir.<\/p>\n \u00d6ncelikle mevcut maliyetlerinizi izlemek ve analiz etmekle ba\u015flay\u0131n. Bulut sa\u011flay\u0131c\u0131n\u0131z\u0131n ara\u00e7lar\u0131n\u0131 ve OpenCost, Kubecost gibi Kubernetes \u00f6zelindeki izleme \u00e7\u00f6z\u00fcmlerini kullan\u0131n. Hangi alanlar\u0131n en \u00e7ok maliyete neden oldu\u011funu belirleyin ve ard\u0131ndan optimizasyon ad\u0131mlar\u0131na ge\u00e7in.<\/p>\n<\/li>\n Kubecost, OpenCost, Dynatrace, Datadog gibi ara\u00e7lar, Kubernetes k\u00fcmelerindeki maliyetleri detayl\u0131 olarak izlemek ve analiz etmek i\u00e7in pop\u00fcler se\u00e7eneklerdir. Bulut sa\u011flay\u0131c\u0131n\u0131z\u0131n (AWS Cost Explorer, Google Cloud Billing, Azure Cost Management) sundu\u011fu ara\u00e7lar da genel maliyet analizi i\u00e7in faydal\u0131d\u0131r.<\/p>\n<\/li>\n Do\u011fru yap\u0131land\u0131r\u0131ld\u0131\u011f\u0131nda, otomatik \u00f6l\u00e7eklendirme (HPA ve Cluster Autoscaler) maliyetleri d\u00fc\u015f\u00fcrebilir. Talebe g\u00f6re kaynaklar\u0131 dinamik olarak ayarlayarak, yaln\u0131zca ihtiya\u00e7 duyulan kapasiteyi sa\u011flar ve gereksiz yere ayr\u0131lan kaynaklar\u0131 azalt\u0131r. Ancak, yanl\u0131\u015f yap\u0131land\u0131r\u0131lm\u0131\u015f \u00f6l\u00e7eklendirme politikalar\u0131 maliyetleri art\u0131rabilir.<\/p>\n<\/li>\n FinOps k\u00fclt\u00fcr\u00fc, t\u00fcm ekiplerin bulut maliyetleri konusunda ortak bir anlay\u0131\u015fa sahip olmas\u0131n\u0131 ve maliyet bilincini art\u0131rmas\u0131n\u0131 sa\u011flar. Bu, kaynaklar\u0131n daha verimli kullan\u0131lmas\u0131n\u0131, israf\u0131n azalt\u0131lmas\u0131n\u0131 ve daha bilin\u00e7li kararlar al\u0131nmas\u0131n\u0131 te\u015fvik eder. Sorumlulukland\u0131rma, bu k\u00fclt\u00fcr\u00fcn temel ta\u015flar\u0131ndan biridir.<\/p>\n<\/li>\n Spot instance’lar, bulut sa\u011flay\u0131c\u0131s\u0131 taraf\u0131ndan herhangi bir zamanda geri al\u0131nabilir. Bu nedenle, kritik olmayan veya kesintiye u\u011frayabilir i\u015f y\u00fckleri i\u00e7in uygundurlar. Kesintiye u\u011frayabilecek i\u015f y\u00fcklerini yeniden ba\u015flat\u0131labilir veya durumunu kaydedebilir \u015fekilde tasarlamak \u00f6nemlidir. Her zaman yedek olarak on-demand instance’lar\u0131n da bulunmas\u0131 \u00f6nerilir.<\/p>\n<\/li>\n<\/ul>\n #Kubernetes #FinOps #MaliyetOptimizasyonu #BulutBili\u015fim #DevOps<\/p>\napp: my-app<\/code>, team: backend-dev<\/code>, environment: production<\/code> gibi etiketler ekleyebilirsiniz. Bu etiketler, maliyet izleme ara\u00e7lar\u0131 taraf\u0131ndan okunarak, maliyetleri ilgili kategorilere atar. Etkili bir etiketleme stratejisi, maliyetleri kimin veya neyin t\u00fcketti\u011fini net bir \u015fekilde anlaman\u0131z\u0131 sa\u011flar ve maliyet sorumlulu\u011funu (cost accountability) olu\u015fturur.<\/p>\nrequest<\/code> de\u011ferinin %10’u civar\u0131ndaysa, bu request<\/code> de\u011ferinin d\u00fc\u015f\u00fcr\u00fclmesi gerekti\u011fini g\u00f6sterir.<\/p>\nUygulamal\u0131 Optimizasyon Teknikleri: Kaynak Y\u00f6netimi ve \u00d6l\u00e7eklendirme<\/h2>\n
Pod Kaynak \u0130stekleri ve Limitleri<\/h3>\n
requests: {cpu: "500m", memory: "1Gi"}<\/code> ve limits: {cpu: "1000m", memory: "2Gi"}<\/code> \u015feklinde ayarlar kullan\u0131yor. Ancak, yap\u0131lan izleme sonucunda bu Pod’lar\u0131n ortalama CPU kullan\u0131m\u0131n\u0131n sadece 50m<\/code> ve bellek kullan\u0131m\u0131n\u0131n 200Mi<\/code> oldu\u011fu g\u00f6r\u00fcl\u00fcyor. Bu durumda, kaynak istekleri ve limitleri gere\u011finden y\u00fcksek ayarlanm\u0131\u015ft\u0131r. Bu Pod’lar, asl\u0131nda daha az kaynakla sorunsuz \u00e7al\u0131\u015fabilir. Kaynak isteklerini requests: {cpu: "100m", memory: "300Mi"}<\/code> ve limitlerini limits: {cpu: "500m", memory: "1Gi"}<\/code> gibi daha ger\u00e7ek\u00e7i de\u011ferlere d\u00fc\u015f\u00fcrmek, ayn\u0131 node \u00fczerinde daha fazla Pod \u00e7al\u0131\u015ft\u0131r\u0131lmas\u0131na olanak tan\u0131r ve toplam node maliyetini azalt\u0131r.<\/p>\nDeployment<\/code>, StatefulSet<\/code> veya Pod<\/code> manifestlerinizdeki resources<\/code> b\u00f6l\u00fcm\u00fcn\u00fc g\u00fcncelleyebilirsiniz.<\/p>\n\napiVersion: apps\/v1\nkind: Deployment\nmetadata:\n name: my-web-app\nspec:\n replicas: 3\n selector:\n matchLabels:\n app: my-web-app\n template:\n metadata:\n labels:\n app: my-web-app\n spec:\n containers:\n - name: web-container\n image: nginx:latest\n resources:\n requests:\n cpu: \"100m\" # Ger\u00e7ek kullan\u0131m verilerine g\u00f6re ayarlanm\u0131\u015f\n memory: \"300Mi\" # Ger\u00e7ek kullan\u0131m verilerine g\u00f6re ayarlanm\u0131\u015f\n limits:\n cpu: \"500m\" # A\u015f\u0131r\u0131 kullan\u0131mdan ka\u00e7\u0131nmak i\u00e7in \u00fcst s\u0131n\u0131r\n memory: \"1Gi\" # Bellek s\u0131z\u0131nt\u0131s\u0131 durumunda koruma\n <\/code><\/pre>\nOtomatik \u00d6l\u00e7eklendirme (Autoscaling)<\/h3>\n
\n
min-nodes<\/code> ve max-nodes<\/code> gibi parametreleri dikkatli ayarlamak, k\u00fcmenin minimum ve maksimum boyutunu kontrol alt\u0131nda tutar. Ayr\u0131ca, Pod’lar\u0131n PodDisruptionBudget<\/code> (PDB) gibi ayarlar\u0131, Cluster Autoscaler’\u0131n node’lar\u0131 kald\u0131r\u0131rken uygulamalar\u0131n kesintiye u\u011framas\u0131n\u0131 engellemesini sa\u011flar.<\/p>\n\napiVersion: autoscaling\/v2\nkind: HorizontalPodAutoscaler\nmetadata:\n name: my-web-app-hpa\nspec:\n scaleTargetRef:\n apiVersion: apps\/v1\n kind: Deployment\n name: my-web-app\n minReplicas: 3\n maxReplicas: 10\n metrics:\n - type: Resource\n resource:\n name: cpu\n target:\n type: Utilization\n averageUtilization: 70 # %70 CPU kullan\u0131m\u0131na ula\u015f\u0131ld\u0131\u011f\u0131nda \u00f6l\u00e7eklenir\n <\/code><\/pre>\nSpot Instance Kullan\u0131m\u0131<\/h3>\n
Depolama ve A\u011f Maliyetlerini Optimize Etme<\/h2>\n
Depolama Optimizasyonu<\/h3>\n
\n
A\u011f Maliyetlerini Optimize Etme<\/h3>\n
\n
FinOps K\u00fclt\u00fcr\u00fc Olu\u015fturma ve Sorumlulukland\u0131rma<\/h2>\n
Ekipler Aras\u0131 \u0130\u015fbirli\u011fi<\/h3>\n
Maliyet Sorumlulu\u011fu (Cost Accountability)<\/h3>\n
S\u00fcrekli \u0130yile\u015ftirme D\u00f6ng\u00fcleri<\/h3>\n
Geli\u015fmi\u015f FinOps Stratejileri ve Ara\u00e7lar\u0131<\/h2>\n
Programatik Maliyet Optimizasyonu<\/h3>\n
\n
\nimport kubernetes.client\nimport kubernetes.config\n\ndef find_and_terminate_idle_pods():\n kubernetes.config.load_kube_config()\n v1 = kubernetes.client.CoreV1Api()\n\n pods = v1.list_pod_for_all_namespaces(watch=False).items\n\n for pod in pods:\n # Belirli bir etiket yoksa veya Pod belirli bir durumda ise\n if 'app' not in pod.metadata.labels and pod.status.phase == 'Running':\n print(f\"Terminating idle pod: {pod.metadata.name} in namespace {pod.metadata.namespace}\")\n try:\n v1.delete_namespaced_pod(name=pod.metadata.name, namespace=pod.metadata.namespace)\n except kubernetes.client.ApiException as e:\n print(f\"Error terminating pod: {e}\")\n\n# Bu fonksiyonun d\u00fczenli olarak \u00e7al\u0131\u015ft\u0131r\u0131lmas\u0131 gerekir.\n# find_and_terminate_idle_pods()\n <\/code><\/pre>\nMaliyet Odakl\u0131 Tasar\u0131m (Cost-Aware Design)<\/h3>\n
\n
Bulut Sa\u011flay\u0131c\u0131s\u0131 Fiyatland\u0131rma Modellerini Anlama<\/h3>\n
Vaka Analizi: Bir E-Ticaret \u015eirketinde Kubernetes Maliyet Kontrol\u00fc<\/h2>\n
\n
Sonu\u00e7 ve S\u0131k\u00e7a Sorulan Sorular<\/h2>\n
S\u0131k\u00e7a Sorulan Sorular (SSS)<\/h3>\n
\n