Kubernetes Maliyet Optimizasyonu: 8 Adım ve 23 Araç
Kubernetes kümeleri fatura artarken tamamen sağlıklı görünebilir. Otomatik ölçeklendirme yapılandırılmıştır, panolar yeşildir ve harcama yine de yükselir. Bir ankette, %42 oranında 455 platform mühendisi, maliyeti bir numaralı Kubernetes sorunu olarak gösterdi; %88 ise toplam sahip olma maliyetinin yıldan yıla arttığını gördü.1
68 Kubernetes maliyet optimizasyonu vaka çalışmasını topladık ve sözü edilen her kullanım senaryosunu, bunu yayımlayan her satıcıyla eşleştirdik:
Koyu hücreler daha çok bahsedildiği anlamına gelir. Boş hücreler, o aracın o kullanım senaryosu için yayımlanmış bir vakası olmadığı anlamına gelir.
Küme harcamasını azaltmaya yönelik gerçek hayattan örnekler içeren 8 adımlı rehber ve Kubernetes maliyet optimizasyonu aracının karşılaştırması için aşağı kaydırın.
1. Hiçbir şeyi değiştirmeden önce ölçün
Bu rehberin geri kalanındaki her sayı bir deltadır ve delta bir başlangıç noktasına ihtiyaç duyar. İlk değişiklikten önce yakalanan bir temel olmadan, 1. adımın işe yarayıp yaramadığını söylemenin ve 3. adımın tasarrufunu, ondan önce yapılan doğru boyutlandırmaya değil konsolidasyona atfetmenin hiçbir yolu yoktur. Bu, çoğu mühendislik işinden daha önemlidir; çünkü altı eylemin tümü aynı faturayı azaltır ve tasarrufları toplanmaz. 1. adımda kapasiteyi boşaltmak, 3. adım düğümleri kaldırana kadar faturada hiçbir sonuç üretmez.
Dört şeyi ölçün:
- İş yükü başına talep edilen ile kullanılan CPU ve bellek. Fark, boyuta göre sıralanmış 1. adım birikiminizdir.
- Namespace ve iş yükü başına maliyet. Bu, 2. adım kotalarını dayatma değil müzakere haline getiren şeydir.
- Bin-packing verimliliği, düğüm başına ayrılabilir ile talep edilen. 3. adımın hedefi.
- Üretim dışı ortamda günün saatine ve haftanın gününe göre atıl maliyet. Siz kurmadan önce 5. adımı boyutlandırır.
En az bir tam iş döngüsü boyunca ölçün. Yedi gün minimumdur ve otuz daha iyidir. Bu pencere yöntemsel bir ihtiyat değildir. 1. adım bellek isteklerini gözlemlenen maksimuma ayarlar ve gözlemlenen bir maksimum, onu gözlemleyen pencere kadar iyidir. 48 saat üzerinden alınan bir maksimum, haftalık bir toplu işi kaçırır ve sonraki Pazar günü OOMKill üretir.
Araç seti
- Maliyet tahsisi: Tahsis modelinin arkasındaki CNCF projesi OpenCost, ücretsiz tabandır. Kubecost'un ücretsiz katmanı aynı motoru 250 çekirdeğe kadar bir arayüzle sarar.
- Kullanım: kube-state-metrics ile Prometheus altlıktır. Robusta KRR, küme içine hiçbir şey kurmadan doğrudan okur.
- Daha geniş harcama: Kubernetes'in, finansın da açıklamak zorunda olduğu bir faturanın parçası olduğu durumlarda CloudZero, Vantage ve Finout bu katmanı değiştirmek yerine üzerinde yer alır.
Her iki maliyet aracı da etiketle atıf yapar; bu nedenle etiketleme önce gelir. Etiketlenmemiş harcama, üç hafta sonra bir temelin 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ı içerir.
2. Namespace kotalarını koruma rayı olarak belirleyin
Tasarruflar, ekipler istek belirtmeden yeni iş yükleri dağıttıkça azalır. LimitRange, istek belirtmeyen konteynerlere varsayılan istekler sağlar; ResourceQuota ise bir namespace'in toplamda tüketebileceği miktarı üstten sınırlar.
LimitRange'ı ResourceQuota'dan önce dağıtın. Bir kota bir kaynağı sınırladığında, o kaynak için isteği olmayan herhangi bir pod kabul sırasında reddedilir; dolayısıyla ters sıra dağıtımları bozar.2
Her yük dengeleyici, bulut sağlayıcısı tarafından ayrıca faturalandırılır ve sahipsiz kalan birimler, pod'ları ortadan kalktıktan 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, ödediği 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 üzerindeki 23.000 üretim kümesini inceleyen bir analiz; ortalama CPU kullanımını %8, belleği %20 ve GPU kullanımını %5 buldu. 3
CPU isteklerini gözlemlenen kullanımın 95th yüzdelik dilimine yakın ayarlayın. Bellek isteklerini yüzdelik dilim yerine gözlemlenen maksimuma ayarlayın ve bellek limitini isteğe eşit ayarlayın. Yüzdelik dilim, kalan trafik sırasında konteyneri yetersiz bırakır; limit isteğe eşit olduğundan bu eksiklik yavaşlama yerine OOMKill olarak ortaya çıkar.
CPU limitini atlayın. CPU kısıtlaması pod'u öldürmeden gecikmeyi bozar ve istek, iş yükünün ihtiyaç duyduğu kaynağı rezerve eder.
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 hayat vaka çalışması: Tryg Insurance
Tryg Insurance, Kuzey bölgesindeki en büyük genel sigorta şirketidir ve Kubernetes'i Oracle Cloud Infrastructure üzerinde ç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 kaynaklı autoscaler'larla Kubernetes bulut maliyetlerini %50 düşürdü.4
4. Karpenter ile düğümleri konsolide edin ve atıl iş yüklerini sıfıra ölçekleyin
Doğru boyutlandırma kapasiteyi boşaltır ama bu kapasite, bir şey onları kaldırana kadar çalışmaya devam eden düğümlerde durur. Karpenter zamanında instance sağlar ve iş yüklerini daha az düğüme yeniden paketler. KEDA, kuyruk odaklı iş yüklerini standart bir Horizontal Pod Autoscaler'ın yapamayacağı şekilde sıfır çoğaltmaya ölçekler.
Konsolidasyon ilkesini WhenEmptyOrUnderutilized olarak ayarlayın. Alternatif olan WhenEmpty, bozulmayı hiç iş yükü pod'u tutmayan düğümlerle sınırlar; bu düğümler ise müdahale olmadan nadiren oluşur. 5
Dar bir instance listesi bunu boşa çıkarır; çünkü Karpenter ucuz aykırı değerleri bulamaz ve spot dayanıklılığınız düşer. Tüm instance aileleri arasından seçim yapmasına izin vermelisiniz.
Gerçek hayat vaka çalışması: Adidas
Adidas, AWS EKS üzerinde birden çok Kubernetes kümesi çalıştırır. Platform mühendisliği ekibi, düğüm sağlama için Karpenter'ı benimsedi, olay odaklı ölçekleme için KEDA ekledi, Kyverno ilkeleri aracılığıyla otomatik oluşturulan Vertical Pod Autoscaler nesneleri ekledi ve atıl ortamlar için kube-downscaler kullandı. Tamamen açık kaynaklı bir yığın kullanarak AWS üzerindeki Kubernetes kümelerini çalıştırma maliyetini %50 kadar düşürdüler.6
5. İş yüklerini spot'a taşımadan önce doğru şekilde hazırlanın
Spot instance'lar mevcut en büyük indirimi ve en dar uygulanabilirliği sunar. PodDisruptionBudget'lar, instance çeşitlendirmesi, topoloji yayılımı ve sonlandırma yönetimi yerli yerine oturana kadar hiçbir şey spot'a taşınmamalıdır.
Hiç boşluk bırakmayan bir PodDisruptionBudget, Karpenter konsolidasyonu da dahil olmak üzere tüm gönüllü kesintileri engeller; bu nedenle değerlerde esneklik olması gerekir. 7
Gerçek hayat vaka çalışması: Delivery Hero
Delivery Hero, 390 uygulamayı 43 ülkede işletiyor ve iş yüklerinin yaklaşık %90'i AWS EKS üzerinde çalışıyor. Ekip, kapasite türlerini doğrudan değiştirmek yerine sürece sonlandırma yönetimi ve bir descheduler inşa ederek yaklaşık altı ayda Spot Instances'a geçti.
- Altyapı maliyetleri yaklaşık %70 düştü
- Spot indirimleri isteğe bağlı fiyatlandırmaya göre %90'a kadar ulaştı
- Platform, normal hacmin 4 ila 5 katı trafik ani artışlarını emer.8
6. Üretim dışını bir programa göre kapatın
Geliştirme ve staging ortamları gece boyunca ve hafta sonları çok az yük taşır ya da hiç taşımaz. Zamanlanmış kapatma teknik olarak basittir ve politik olarak tartışmasızdır; bu da onu, daha zor değişikliklerin daha sonra destek gerektireceği durumlarda sunulması en hızlı tasarruf ve faydalı bir ilk eylem haline getirir.
Programı üretim dışı namespace'lerde varsayılan olarak uygulayın ve ekiplerin açıkça devre dışı bırakmasını isteyin. Katılmak için eylem gerektiren bir ilke, ayrılmak için eylem gerektiren bir ilkeden daha az ekibe ulaşır.
Tasarruf, düğüm konsolidasyonu çalışıyorsa faturaya yansır; çünkü küçültülmüş dağıtımlar arkalarında boş düğümler bırakır.
Gerçek hayat 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. Ekip, günlük yeniden dengelemenin yanı sıra gece ve hafta sonları küme düğümlerini küçültmek için zamanlanmış duraklatma ve devam ettirme kullandı.
- Yalnızca zamanlama değişikliğinden maliyetler %47 düştü
- Program, haftada 80 saat küme çalışmasını ortadan kaldırdı
- Kaynak kullanımı %90'in üzerine çıktı.9
7. Uyumlu iş yüklerini ARM'a taşıyın
ARM tabanlı instance'lar, yukarıdaki eylemler gibi aynı atıl kapasite için rekabet etmek yerine birim fiyatı değiştirir; bu nedenle bu tasarruflar gerçekten de diğerleriyle toplanır. Engelleyiciler, ARM64 yapıları olmayan bağımlılıklar olacaktır.
Kullanıcılar bunu tüm ortam yerine iş yükü başına kapsamlandırmalı ve herhangi bir şey zamanlamadan önce çok mimarili imajlar oluşturmalıdır.
Gerçek hayat vaka çalışması: Pinterest
Pinterest, hem maliyet hem de karbon azaltma motivasyonuyla, ARM64 üzerinde çalışan AWS Graviton instance'larına web API iş yükünü taşıdı.
- Maliyetler %47 düştü
- İşlem tüketimi %38 düştü
- Karbon emisyonları %62 düştü.10
8. Ayar yapmanın sonu geldiğ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 yapmayı değil mimari değişikliği gerektirir.
Yayımlanmış iki sonuç pratik sınırı işaret eder. InCred Finance, ekibinin optimize edilmiş saydığı kümelerde harcamayı %30 düşürdü11; Yotpo ise iş yüklerinin %80'ini spot instance'larda ç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 control plane ücreti taşır ve bin-packing'in geçemeyeceği bir zamanlama adası oluşturur.
Çoklu kiracılık her iki maliyeti de ortadan kaldırır. Her müşteriye, ekibe veya ortama bir küme ayırmak yerine sanal kümeler paylaşılan fiziksel altyapı üzerinde çalışır. Düğümler havuza alınırken her kiracı kendi API sunucusunu ve sanal control plane'ini alır. Bu, küme başına control plane ücretini ortadan kaldırır ve yalıtılmış alanlar içinde değil, paylaşılan düğüm havuzu genelinde bin-packing yapılmasına olanak tanır.
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ışmaya göre yapılır.
- Namespace'ler tek bir kümeyi bölümlere ayırır ve kendi control plane'lerini eklemez. Kiracılar birbirine güvendiğinde ve bir API sunucusu ile bir CRD setini 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ğı yalıtım gereksinimleri.
Gerçek hayat vaka çalışması: Atlan
Atlan, müşterilerinin yaklaşık %95'ine platformu barındıran bir veri kataloğu şirketidir; bu müşterilerin çoğu, veri yalıtımının sözleşmeye dayalı olduğu sağlık ve finans sektörlerindedir. Müşteri başına tam bir EKS kümesi çalıştırdı ve 100 kümenin üzerine çıktı; bu, gün boyu çalıştırması pahalı ve bakımı zor bir altyapıydı. 2022'nin ilk çeyreğinden itibaren çoklu kiracılık seçeneklerini değerlendirdi ve vCluster üzerine yeniden kurarak her müşteriye fiziksel yerine sanal bir küme verdi.
- Fiziksel EKS kümeleri 100'den fazladan 20'ye düştü ve hâlâ 100+ müşteriye hizmet verdi
- Kubernetes harcaması $600,000 düştü.13
Tercih edilen kaynak olarak ekleUygulama sırası
Taahhütler en kolay eylem olmalarına rağmen en sonda yer alır. Doğru boyutlandırmadan önce satın almak, doğru boyutlandırmanın kaldırmak üzere olduğu israfın bir ila üç yılını kilitler. Bu, mevcut en pahalı sıralama hatasıdır ve yaygındır; çünkü mühendislik çalışması yerine bir satın alma gerektirir.
Eylem 7 bir adım değil, bir daldır. İlk altı tamamlandığında ve sonuç hâlâ yetersiz olduğunda uygulayın; çünkü her birinin ne kadar verimli çalıştığından çok, kaç kümenin çalıştığını değiştirir.
Kubernetes maliyet optimizasyonu araçları
Veri setindeki 68 vaka çalışmasının 47'sini kapsayan, üç veya daha fazla yayımlanmış vaka çalışmasına sahip araçları grafiğe döktük:
- Yatay: her aracın kaç vaka çalışması olduğu; her biri bir kez sayılır.
- Dikey: Bu vakaların on üzerinden kaç farklı kullanım senaryosu kategorisini kapsadığı. Bir araç, bir kategoride ne sıklıkta geçerse geçsin kategori başına yalnızca bir kez sayılır; bu nedenle CAST AI'nın 12 ayrı doğru boyutlandırma sözü 10 puanına 1 katkı sağlar.
- 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ükseltmeleri, sürüm değişimini, Prometheus saklama faturasını ve ticari bir önericinin onlar adına yapacağı muhakeme kararlarını üstlenir.
Bunların her biri farklı bir alana sahiptir; bu nedenle birkaçı aynı anda çalışır.
- Robusta KRR veya VPA,
updateMode: "Off"içinde 1. adım birikimini üretir. Hiçbir şey yazmaz. - Karpenter düğümleri sahiplenir: dağıtım, konsolidasyon, instance seçimi, spot çeşitlendirmesi, mimari. 3, 4 ve 6. adımları taşır.
- KEDA çoğaltma sayılarına sahiptir; yalnızca HPA'nın yapamayacağı sıfıra ölçekleme dahil.
- py-kube-downscaler veya kube-green üretim dışı programı sahiplenir. Listedeki en ucuz tasarruf.
- OpenCost baştan sona ölçer ve hiçbir şeye katılmaz.
Ticari platformlar
Her ticari araç, düğüm katmanında üç konumdan birini alır. Karar budur ve fiyattan veya özellik sayısından daha önemlidir; çünkü 3. adımın NodePool manifest'i ya ayakta kalır ya da kalmaz.
- Kendi haline bırakın: StormForge, PerfectScale, Sedai ve Kubex iş yüklerini doğru boyutlandırır. Altta Karpenter veya Cluster Autoscaler'a ihtiyaç duyar ve ona asla dokunmaz. Mevcut kuruluma en güvenli ekleme.
- Onunla çalışın: ScaleOps, Karpenter'ın üzerine bin packing ekler. nOps, kendi provisioner'ını koymak yerine mevcut Cluster Autoscaler veya Karpenter'ı ayarlar. Daha fazla kapsam, provisioner yine sizde.
- Yerini değiştirin: CAST AI ve Spot Ocean kendi provisioner'ını kurar ve manifest'i devre dışı bırakır. 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ışmaz ve özgürce üst üste kullanılabilir. Benimsenen diğer her şeyden bağımsız olarak 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 boşaltır ama hiçbirini kaldırmaz; bu nedenle fatura, bir düğüm aracı o alanı konsolide edene kadar değişmez. Yalnızca düğüm araçları ise ayna nedenle başarısız olur: kendilerine verilen istekleri paketler; bu nedenle aşırı şişirilmiş istekler daha da sıkı paketlenir.
Her iki katmanı da kapsamanın iki yolu:
- İki araç: İstekler için VPA, StormForge veya PerfectScale; düğümler için artı Karpenter. Daha ucuzdur ve düğüm katmanı doğrudan kontrol altında kalır.
- Tek platform: CAST AI, Zesty veya Spot Ocean ikisini de tek bir üründe yapar. Daha pahalıdır ve provisioner'ları Karpenter'ın yerini alır.
Bir şeyleri bozan beş araç kombinasyonu:
- Tek dağıtımda iki mutasyona uğratan doğru boyutlandırıcı:
Autoiçinde VPA; StormForge, ScaleOps, PerfectScale veya Zesty ile birlikte aynı alana farklı sayılar yazan iki denetleyici anlamına gelir. İş yükü başına bir mutasyonlu kabul denetleyicisi. - Bir düğüm grubunda Karpenter ve Cluster Autoscaler: Her ikisi de aynı zamanlanamayan pod'lara karşı provision 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 üzerinden hesaplanır, HPA çoğaltmaları kaldırır, pod başına yük artar, tekrar eder. HPA, VPA'nın dokunmadığı bir şeye (KEDA aracılığıyla kuyruk derinliği gibi) göre ölçeklediğinde güvenlidir.
- Tek ödeme yapan hesapta 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:
Cloud Maliyetleri hakkında ek okumalar
Pod yerleşiminde ustalaşmak ve bulut işlem harcamanızı azaltmak için daha fazlasını okuyun:
- En İyi Konteyner Orkestrasyon Araçlarını Karşılaştırın
- 20+ Bulut Orkestratörünü Karşılaştırın
- 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 ve 23 Araç}},
year = {2026},
month = sep,
howpublished = {\url{https://aimultiple.com/kubernetes-cost-optimization}},
note = {AIMultiple. Erişim tarihi: 18 Eylül 2026}
}249 veri noktasının sonuçları ve zaman damgaları. Bu makaledeki grafik ve tablolarda gösterilen özet verileri, 6 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.