Kubernetes Maliyet Optimizasyonu: 8 Adım, 23 Araç ve Vaka Çalışmaları
Kubernetes kümeleri fatura artarken tamamen sağlıklı görünebilir. Otomatik ölçeklendirme yapılandırılmış, panolar yeşil ve harcamalar yine de yükseliyor. Bir ankette, %42 455 platform mühendisi maliyeti bir numaralı Kubernetes zorluğu olarak belirtirken, %88 toplam sahip olma maliyetinin yıldan yıla arttığını gördü.1
68 Kubernetes maliyet optimizasyonu vaka çalışması topladık ve belirtilen her kullanım senaryosunu, onu yayınlayan her satıcıyla eşleştirdik:
Daha koyu hücreler daha fazla bahsedilme anlamına gelir. Boş hücreler, o aracın o kullanım senaryosu için yayınlanmış vakası olmadığı anlamına gelir.
Küme harcamasını azaltmaya yönelik gerçek hayattan örnekler içeren 8 adımlı kılavuz ve Kubernetes maliyet optimizasyonu aracının karşılaştırması için okumaya devam edin.
1. Hiçbir şeyi değiştirmeden önce ölçün
Bu kılavuzun geri kalanındaki her sayı bir deltadır ve bir deltanın bir başlangıç noktasına ihtiyacı vardır. İlk değişiklikten önce yakalanan bir temel olmadan, adım 1'in işe yarayıp yaramadığını anlamanın ve adım 3'ün tasarruflarını kendisinden önceki uygun boyutlandırmaya değil konsolidasyona atfetmenin hiçbir yolu yoktur. Bu, çoğu mühendislik çalışmasından daha fazla önem taşır çünkü altı eylemin tümü aynı faturası azaltır ve tasarrufları toplanmaz. Adım 1'de kapasiteyi serbest bırakmak, adım 3 düğümleri kaldırana kadar faturada hiçbir şey üretmez.
Dört şeyi ölçün:
- İş yükü başına istenen ve kullanılan CPU ve bellek. Fark, boyuta göre sıralanmış adım 1 birikiminizdir.
- Namespace başına ve iş yükü başına maliyet. Bu, adım 2 kotalarını bir dayatmadan ziyade müzakere haline getirir.
- Düğüm başına tahsis edilebilir ile istenen arasındaki bin-packing verimliliği. Adım 3'ün hedefi.
- Üretim dışı ortamda günün saatine ve haftanın gününe göre boşta maliyet. Adım 5'i siz onu inşa etmeden boyutlandırır.
En az bir tam iş döngüsü boyunca ölçün. Yedi gün minimumdur, otuz daha iyidir. Pencere prosedürel bir ihtiyat değildir. Adım 1, bellek isteklerini gözlemlenen maksimuma ayarlar ve gözlemlenen bir maksimum ancak onu gözlemleyen pencere kadar iyidir. 48 saat üzerinden alınan bir maksimum, haftalık toplu işi kaçırır ve sonraki Pazar bir OOMKill üretir.
Araçlar
- Maliyet tahsisi: Tahsis modelinin arkasındaki CNCF projesi OpenCost, ücretsiz tabandır. Kubecost'un ücretsiz katmanı, aynı motoru 250 çekirdeğe kadar bir arayüzde sarmalar.
- Kullanım: kube-state-metrics ile Prometheus alt tabakadır. Robusta KRR, kümeye hiçbir şey yüklemeden doğrudan okur.
- Daha geniş harcama: Kubernetes'in, finansın da açıklamak zorunda olduğu bir faturanın bir parçası olduğu yerlerde CloudZero, Vantage ve Finout bu katmanı değiştirmek yerine onun üzerinde konumlanır.
Her iki maliyet aracı da etiketle (label) ile ilişkilendirme yapar, bu yüzden önce etiketleme gelir. Etiketsiz harcama, bir temelin üç hafta sonra işe yaramaz hale gelmesinin en yaygın nedenidir.
Aşağıdaki her eylem; öneriyi, yöntemi, yapılandırmayı ve o adımı atan bir şirketi belirtir. Her vaka çalışması ve her istatistik bir kaynak bağlantısı taşır.
2. Namespace kotalarını koruyucu korkuluk olarak ayarlayın
Ekipler hiçbir istek belirtmeden yeni iş yükleri dağıttıkça tasarruflar azalır. Bir LimitRange, bunları atlayan konteynerlere varsayılan istekler sağlar ve bir ResourceQuota, bir namespace'in toplamda ne kadar tüketebileceğini sınırlar.
LimitRange'i ResourceQuota'dan önce dağıtın. Bir kota bir kaynağı kısıtladığında, o kaynak için isteği olmayan herhangi bir pod kabul sırasında reddedilir, bu yüzden ters sıra dağıtımları bozar.2
Her yük dengeleyici bulut sağlayıcı tarafından ayrı ayrı faturalandırılır ve sahipsiz birimler, pod'ları gittikten sonra da faturalandırılmaya devam eder.
2. CPU ve bellek isteklerini doğru boyutlandırın
İstekler düğüm sayısını, düğüm sayısı da faturayı belirler. Çoğu küme, ödedikleri kapasitenin çok altında çalışır çünkü istekler bir kez tahmin edilmiş ve bir daha gözden geçirilmemiştir. AWS, Azure ve Google Cloud genelinde 23.000 üretim kümesi üzerinde yapılan bir analiz, ortalama CPU kullanımını %8, bellek kullanımını %20 ve GPU kullanımını %5 olarak buldu. 3
CPU isteklerini gözlemlenen kullanımın 95th yüzdelik dilimine yakın ayarlayın. Bellek isteklerini bir yüzdelik dilim yerine gözlemlenen maksimuma ayarlayın ve bellek limitini isteğe eşit yapın. Yüzdelik dilim, kalan trafik sırasında konteyneri yetersiz bırakır ve limit isteğe eşit olduğundan, bu eksiklik yavaşlama yerine bir OOMKill olarak ortaya çıkar.
CPU limitini atlayın. CPU throttling, pod'u öldürmeden gecikmeyi kötüleştirir ve istek, iş yükünün ihtiyaç duyduğunu zaten ayırmıştır.
Yalnızca öneri modundaki Vertical Pod Autoscaler, bu rakamları üretim riski olmadan üretir.
Önerileri kubectl describe vpa payments-api ile okuyun ve hedef değeri mevcut istekle karşılaştırın.
Gerçek hayattan vaka çalışması: Tryg Insurance
Tryg Insurance, İskandinav bölgesinin en büyük genel sigortacısıdır ve Oracle Cloud Infrastructure üzerinde Kubernetes çalıştırır. Mühendislik ekibi, hizmet seviyelerini korurken iş yüklerini dinamik olarak doğru boyutlandırmak için Horizontal Pod Autoscaler ile Vertical Pod Autoscaler'ı birleştirdi ve hiçbir ticari optimizasyon platformu kullanmadan yalnızca açık kaynak otomatik ölçeklendiricilerle Kubernetes bulut maliyetlerini %50 azalttı.4
4. Karpenter ile düğümleri konsolide edin ve boştaki iş yüklerini sıfıra ölçeklendirin
Doğru boyutlandırma kapasiteyi serbest bırakır, ancak bu kapasite, bir şey onları kaldırana kadar çalışmaya devam eden düğümlerin üzerinde kalır. Karpenter, tam zamanında örnek sağlar ve iş yüklerini daha az düğüme yeniden paketler. KEDA, kuyruk güdümlü iş yüklerini sıfır replikaya ölçeklendirir; standart bir Horizontal Pod Autoscaler bunu yapamaz.
Konsolidasyon politikasını WhenEmptyOrUnderutilized olarak ayarlayın. Alternatif olan WhenEmpty, kesintiyi hiç iş yükü pod'u tutmayan düğümlerle sınırlar ve bunlar müdahale olmadan nadiren oluşur. 5
Dar bir örnek listesi bunu bozar çünkü Karpenter ucuz aykırı değerleri bulamaz ve spot dayanıklılığınız düşer. Tüm örnek aileleri arasından seçim yapmasına izin vermelisiniz.
Gerçek hayattan vaka çalışması: Adidas
Adidas, AWS EKS üzerinde birden fazla Kubernetes kümesi çalıştırır. Platform mühendisliği ekibi, düğüm sağlama için Karpenter'ı benimsedi, olay güdümlü ölçeklendirme için KEDA ekledi, Kyverno politikaları aracılığıyla otomatik olarak oluşturulan Vertical Pod Autoscaler nesneleri ekledi ve boştaki ortamlar için kube-downscaler kullandı. AWS üzerinde Kubernetes kümelerini çalıştırma maliyetini tamamen açık kaynaklı bir yığın kullanarak %50 kadar azalttılar.6
5. İş yüklerini spot'a taşımadan önce düzgün hazırlanın
Spot örnekler mevcut en büyük indirimi ve en dar uygulanabilirliği sunar. PodDisruptionBudgets, örnek çeşitlendirmesi, topoloji yayılımı ve sonlandırma yönetimi tam olarak yerine getirilmeden hiçbir şey spot'a taşınmamalıdır.
Hiçbir boşluk bırakmayan bir PodDisruptionBudget, Karpenter konsolidasyonu dahil tüm gönüllü kesintileri engeller, bu yüzden değerlerin esnekliğe ihtiyacı vardır. 7
Gerçek hayattan vaka çalışması: Delivery Hero
Delivery Hero, 43 ülkede 390 uygulama işletir ve iş yüklerinin yaklaşık %90'ı AWS EKS üzerinde çalışır. Ekipleri, kapasite türlerini doğrudan değiştirmek yerine sonlandırma yönetimi ve bir descheduler'ı sürece dahil ederek yaklaşık altı ayda Spot Instances'a geçiş yaptı.
- Altyapı maliyetleri yaklaşık %70 düştü
- Spot indirimleri, talep üzerine fiyatlandırmaya kıyasla %90'a kadar ulaştı
- Platform, normal hacmin 4 ila 5 katı trafik ani yükselmelerini emer.8
6. Üretim dışı ortamları bir programa göre kapatın
Geliştirme ve hazırlama ortamları gece boyunca ve hafta sonları çok az yük taşır veya hiç taşımaz. Programlı kapatma teknik olarak basittir ve politik olarak tartışmasızdır; bu da onu sunulması en hızlı tasarruf ve daha zor değişikliklerin daha sonra desteğe ihtiyaç duyacağı yerlerde yararlı bir ilk eylem haline getirir.
Programı üretim dışı namespace'lerde varsayılan olarak uygulayın ve ekiplerin açıkça vazgeçmesini isteyin. Katılmak için eylem gerektiren bir politika, ayrılmak için eylem gerektiren bir politikadan daha az ekibe ulaşır.
Tasarruf ancak düğüm konsolidasyonu zaten çalışıyorsa faturaya yansır, çünkü küçültülmüş dağıtımlar geride boş düğümler bırakır.
Gerçek hayattan vaka çalışması: Bud Financial
Bud Financial, finansal hizmetler sektörü için finansal işlem verilerini zenginleştirir ve Google Kubernetes Engine üzerinde yaklaşık 25 küme çalıştırır. Ekipleri, günlük yeniden dengeleme ile birlikte gece ve hafta sonları küme düğümlerini daraltmak için programlı duraklatma ve devam ettirme kullandı.
- Yalnızca programlama değişikliğiyle maliyetler %47 düştü
- Program, haftada 80 saat küme çalışmasını ortadan kaldırdı
- Kaynak kullanımı %90'ın üzerine çıktı.9
7. Uyumlu iş yüklerini ARM'a taşıyın
ARM tabanlı örnekler, yukarıdaki eylemlerle aynı boş kapasite için rekabet etmek yerine birim fiyatı değiştirir; bu nedenle bu tasarruflar gerçekten geri kalanıyla birikir. Engelleyiciler, ARM64 yapıları olmayan bağımlılıklar olacaktır.
Kullanıcılar bunu tüm altyapı yerine iş yükü başına kapsamalı ve herhangi bir şey zamanlamadan önce çok mimarili imajlar oluşturmalıdır.
Gerçek hayattan vaka çalışması: Pinterest
Pinterest, web API iş yükünü ARM64 üzerinde çalışan AWS Graviton örneklerine taşıdı; bunu hem maliyet hem de karbon azaltımı motive etti.
- Maliyetler %47 düştü
- Hesaplama tüketimi %38 düştü
- Karbon emisyonları %62 düştü.10
8. Ayar yapma tükendiğinde mimariyi değiştirin
Yukarıdaki altı eylem, mevcut kümeler içindeki iş yüklerini ayarlar. Bunlar tükendiğinde, daha fazla kazanım daha fazla ayar yapmak yerine mimari değişiklik gerektirir.
Yayınlanmış iki sonuç pratik sınırı işaret ediyor. InCred Finance, ekibinin zaten optimize edilmiş olarak değerlendirdiği kümelerde harcamayı %30 düşürdü11, ve Yotpo, iş yüklerinin %80'ini zaten spot örneklerde çalıştırırken 30–%40 elde etti12. Bu aralığın ötesinde, kalan israf artık kümelerin içinde değil, küme sayısındadır. Her biri bir kontrol düzlemi ücreti taşır ve bin-packing'in geçemeyeceği bir zamanlama adası oluşturur.
Çok kiracılık her iki maliyeti de ortadan kaldırır. Her müşteri, ekip veya ortama bir küme ayırmak yerine sanal kümeler paylaşılan fiziksel altyapı üzerinde çalışır. Düğümler havuzlanırken her kiracı kendi API sunucusunu ve sanal kontrol düzlemini alır. Bu, küme başına kontrol düzlemi ücretini ortadan kaldırır ve yalıtılmış alanlar içinde değil, paylaşılan düğüm havuzu genelinde bin-packing yapılmasını sağlar.
yaml
bash
İki mekanizma mevcuttur. Namespace'ler her zaman daha ucuzdur, bu nedenle seçim maliyete göre değil, kiracıların gerektirdiği ayrıştırmaya göre yapılır.
- Namespace'ler tek bir kümeyi bölümlere ayırır ve kendi kontrol düzlemlerini eklemez. Kiracılar birbirine güvendiğinde ve tek bir API sunucusu ile tek bir CRD kümesini paylaşabildiğinde yeterlidir.
- Sanal kümeler, her kiracıya ana bilgisayar üzerinde bir iş yükü olarak çalışan kendi API sunucusunu verir. Bu maliyet iki durumda haklıdır: kendi küme kapsamlı kaynaklarına ihtiyaç duyan kiracılar ve paylaşılan bir API sunucusunun karşılayamayacağı izolasyon gereksinimleri.
Gerçek hayattan vaka çalışması: Atlan
Atlan, müşterilerinin yaklaşık %95'i için platformu barındıran bir veri kataloğu şirketidir; bunların çoğu, veri izolasyonunun sözleşmeye dayalı olduğu sağlık ve finans sektörlerindedir. Müşteri başına bir tam EKS kümesi çalıştırıyordu ve 100 kümeyi aştı; bu altyapının 7/24 çalıştırılması pahalı ve bakımı zordu. 2022'nin ilk çeyreğinden itibaren çok kiracılık seçeneklerini değerlendirdi ve her müşteriye fiziksel değil sanal bir küme veren vCluster üzerinde yeniden inşa etti.
- Fiziksel EKS kümeleri 100'den fazla iken 20'ye düştü ve hâlâ 100+ müşteriye hizmet veriyor
- Kubernetes harcaması 600.000 $ düştü.14
Tercih edilen kaynak olarak ekleUygulama sırası
Taahhütler en kolay eylem olmasına rağmen en sonda yer alır. Doğru boyutlandırmadan önce satın almak, doğru boyutlandırmanın gidermek üzere olduğu israfı bir ila üç yıl boyunca kilitler. Bu, mevcut en maliyetli sıralama hatasıdır ve satın alma gerektirdiği için mühendislik çalışmasından ziyade yaygındır.
Eylem 7 bir dal, bir adım değildir. Yalnızca ilk altısı tamamlandığında ve sonuç hâlâ yetersiz olduğunda onu uygulayın, çünkü her kümenin ne kadar verimli çalıştığını değil, kaç küme çalıştığını değiştirir.
Kubernetes maliyet optimizasyonu araçları
Veri kümesindeki 68 vaka çalışmasının 47'sini kapsayan, üç veya daha fazla yayınlanmış vaka çalışmasına sahip araçları grafiğe döktük:
- Yatay: her aracın sahip olduğu vaka çalışması sayısı; her biri bir kez sayılır.
- Dikey: bu vakaların on üzerinden kaç farklı kullanım senaryosu kategorisini kapsadığı. Bir araç, orada ne sıklıkla görünürse görünsün kategori başına bir kez sayılır; bu nedenle CAST AI’nın 12 ayrı doğru boyutlandırma bahsi, 10 puanına 1 katkıda bulunur.
- Balon boyutu: aracın sekiz strateji aşamasının kaçında göründüğü.
Açık kaynak framework'ler
Açık kaynak framework'ler 0'dan 6'ya kadar aşamalar için dağıtılabilir. Kullanıcılar yükseltmelerin, sürüm değişiminin, Prometheus saklama faturasının ve ticari bir önericinin onlar için yapacağı yargı kararlarının sahibi olur.
Bunların her biri farklı bir alana sahiptir; bu yüzden birkaçı aynı anda çalışır.
- Robusta KRR veya VPA
updateMode: "Off"içinde adım 1 birikimini üretir. Hiçbir şey yazmaz. - Karpenter düğümleri sahiplenir: sağlama, konsolidasyon, örnek seçimi, spot çeşitlendirme, mimari. Adımlar 3, 4 ve 6'yı yürütür.
- KEDA replika sayılarını sahiplenir, HPA'nın tek başına yapamadığı sıfıra ölçeklendirme dahil.
- py-kube-downscaler veya kube-green üretim dışı programı sahiplenir. Listedeki en ucuz tasarruf.
- OpenCost süreç boyunca ölçer ve hiçbir şeye katılmaz.
Ticari platformlar
Her ticari araç düğüm katmanında üç konumdan birini alır. Karar budur ve fiyat veya özellik sayısından daha önemlidir, çünkü adım 3'ün NodePool manifestosu ya varlığını sürdürür ya da sürdürmez.
- Dokunmayın: StormForge, PerfectScale, Sedai ve Kubex yalnızca iş yüklerini doğru boyutlandırır. Altlarında Karpenter veya Cluster Autoscaler'a ihtiyaç duyarlar ve ona asla dokunmazlar. Mevcut kuruluma en güvenli eklenti.
- Onunla çalışın: ScaleOps, Karpenter'ın üzerine bin packing ekler. nOps, kendi sağlayıcısını koymak yerine mevcut Cluster Autoscaler veya Karpenter'ı ayarlar. Daha fazla kapsam, provisioner hâlâ sizin.
- Değiştirin: CAST AI ve Spot Ocean kendi provisioner'larını kurar ve manifestoyu atar. En geniş kapsam, en az kontrol.
- Görünürlük araçları dışarıda durur: OpenCost, Kubecost, CloudZero, Vantage ve Finout yalnızca okur; bu nedenle hiçbir şeyle çakışmazlar ve özgürce üst üste binebilirler. Başka ne benimsenirse benimsensin birini çalıştırın.
Bu araçlar nasıl birleştirilir
Fatura, beyan edilen isteklere değil, çalışan düğümlere dayanır. Doğru boyutlandırma istekleri düşürür; bu, mevcut düğümlerde alan açar ancak hiçbirini kaldırmaz; bu nedenle bir düğüm aracı bu alanı konsolide edene kadar fatura değişmez. Düğüm araçları tek başına ayna nedenden dolayı başarısız olur: kendilerine verilen istekleri paketlerler, bu yüzden aşırı şişirilmiş istekler daha sıkı paketlenir.
Her iki katmanı da kapsamanın iki yolu:
- İki araç: İstekler için VPA, StormForge veya PerfectScale; düğümler için de Karpenter. Daha ucuzdur ve düğüm katmanı doğrudan kontrol altında kalır.
- Tek platform: CAST AI, Zesty veya Spot Ocean her ikisini de tek bir üründe yapar. Daha pahalıdır ve provisioner'ları Karpenter'ın yerini alır.
İşleri bozan beş araç kombinasyonu:
- Tek dağıtımda iki mutasyon yapan doğru boyutlandırıcı: VPA
Autoiçinde StormForge, ScaleOps, PerfectScale veya Zesty ile birlikte, aynı alana farklı sayılar yazan iki kontrolcü anlamına gelir. İş yükü başına bir mutasyon yapan kabul kontrolcüsü olmalı. - Tek düğüm grubunda Karpenter ve Cluster Autoscaler: Her ikisi de aynı zamanlanamayan pod'lara karşı sağlama yapar, böylece küme ihtiyaç duyduğunun yaklaşık iki katı düğümle sonuçlanır.
- Aynı metrikte VPA ve HPA: Kullanım artar, VPA isteği yükseltir, ölçülen kullanım düşer çünkü kullanım/istek oranıdır, HPA replikaları kaldırır, pod başına yük artar, tekrarlanır. HPA, VPA'nın dokunmadığı bir şeye (KEDA ile kuyruk derinliği gibi) göre ölçeklendiğinde güvenlidir.
- Tek ödeme hesabında iki taahhüt aracı: Her ikisi de aynı karşılanmamış harcamaya karşı satın alır ve bir ila üç yıl boyunca aşırı taahhüdü kilitler.
- İki tam platform: CAST AI, Zesty ve Spot Ocean; her biri kendi provisioner'ını kurar ve her biri ona sahip olmayı bekler.
Topladığımız tüm vaka çalışmalarını görüntüleyin:
Daha fazla bilgi
Pod yerleştirmede ustalaşmak ve bulut hesaplama harcamanızı azaltmak için daha fazlasını okuyun:
- En İyi Konteyner Orkestrasyon Araçlarını Karşılaştırın
- Karşılaştır 20+ Bulut Orkestratörleri
- En İyi Hibrit Bulut İş Zamanlayıcıları
Bu araştırmayı kaynak gösterin
Yayınlayacağınız yere uygun formatı seçin. Bağlantılı sürümü CMS'inize yapıştırmak, geri bağlantıyı korur.
@misc{simsek2026,
author = {Şimşek, Hazal},
title = {{Kubernetes Maliyet Optimizasyonu: 8 Adım, 23 Araç ve Vaka Çalışmaları}},
year = {2026},
month = sep,
howpublished = {\url{https://aimultiple.com/kubernetes-cost-optimization}},
note = {AIMultiple. Erişim tarihi: 18 Eylül 2026}
}114 veri noktasının sonuçları ve zaman damgaları. Bu makaledeki grafik ve tablolarda gösterilen özet verileri, 4 CSV dosyası içeren ZIP dosyası olarak indirin.
Arkasındaki ayrıntılı veriyi ister misiniz? Premium'a katılın
Referans Linkleri
Yorum yapan ilk kişi olun
E-posta adresiniz yayınlanmayacak. Tüm alanlar gereklidir. Yorumlar orijinal dilinde bırakılır.