Kubernetes FinOps: VPA ile Doğru Kaynak Boyutlandırma

Onlarca veya yüzlerce yazılım ekibine hizmet veren bir platform ekibinde çalışıyorsanız, Kubernetes cluster’ları büyüdükçe karşınıza çıkan en büyük operasyonel yüklerden biri kontrolsüz kaynak kullanımıdır.

Geliştiriciler doğal bir refleksle uygulamalarının beklenmedik şekilde fazla trafik aldığında çökmesini ya da RAM yetersizliğinden Out Of Memory almasını istemez. Bu kaygıyla hazırlanan YAML dosyalarında CPU ve RAM değerleri genellikle “ne olur ne olmaz” denilerek gerçek ihtiyacın katbekat üzerinde tanımlanır.

Örneğin:

Anlık olarak sadece 20m CPU ve 100Mi RAM harcayan minik bir servis için 4 Core CPU ve 6Gi RAM rezerve edilmiştir. Uygulama mükemmel çalışır, kimse şikayet etmez. Ancak Kubernetes scheduler, pod'ların anlık tüketimine değil, pazarlık masasında talep ettiği kaynaklara (requests) bakarak karar verir.

Bu yüzden scheduler, node’lar üzerinde yer kalmadığını varsayar. Cloud ortamlarında gereksiz yeni sunucular açılıp ay sonu faturası kabarırken; On-Premise altyapılarda ise veri merkezindeki fiziki donanım kapasitesi hızla tüketilir, yeni sunucu yatırımları (CAPEX) tetiklenir ve gerçekten kaynağa ihtiyacı olan diğer kritik servisler dışarıda kalır.

Birilerinin kaynağı göz kararı tahmin etmesine güvenmek ya da insanları sürekli uyarmaya çalışmak sürdürülebilir bir altyapı stratejisi değildir. İşte bahsettiğimiz bu kaynak planlaması için deterministik ve otomatize bir yöntem mevcut.

Göz Kararı Tahminlerden Veriye: VPA’nın Sahneye Çıkışı

Vertical Pod Autoscaler (VPA), ister public cloud ister on-premise veri merkezinde çalışın, Kubernetes ekosistemindeki kaynak belirsizliğine son vermek üzere tasarlanmış bir optimizasyon aracıdır. Cluster içinde koşan pod’ların gerçekte ne kadar kaynağa ihtiyaç duyduğunu zamana yaygın metriklerle analiz eder ve bu pod’lar için doğru dikey boyutlandırma (requests ve limits) önerileri sunar.

Horizontal Pod Autoscaler’ın aksine pod sayısını artırıp azaltmaz; mevcut pod’un kaynak kapasitesini dikey olarak büyütür veya küçültür. Böylece insan tahmini yerine veriye dayalı bir Right-Sizing (Doğru Boyutlandırma) kültürü oturtmanızı sağlar.

VPA’nın Arka Plan Mekanizması

VPA’nın arka plandaki çalışma mekanizması aslında oldukça net ve modüler bir mimariye dayanır. Metrics-server veya Prometheus üzerinden pod’ların CPU ve RAM kullanım geçmişini sürekli toplar ve analiz eder.

Ayrıca aşağıdaki 3 bileşenle daha işlevsel bir hal kazanır :

VPA Recommender: Arka planda çalışan ana beyindir. Geçmiş kullanım verilerini işler ve ideal kaynak miktarını hesaplar. Aşağıdaki parametrelerle daha da kişiselleştirilebilir :

• Histogram Üstel Yarılanma Ömrü (--cpu-histogram-decay-half-life): VPA, CPU metriklerini bir histogramda toplar. Ancak 5 gün önceki kullanım ile son 1 saatteki kullanımın ağırlığı aynı değildir. Varsayılan olarak 24 saat olan bu parametre, geçmiş verilerin ağırlığının her 24 saatte bir yarı yarıya azalmasını sağlar, case’inize göre bu değeri değiştirebilirsiniz.
• Esnek Veri Penceresi (-history-length): Varsayılan olarak 8 günlük bir geçmiş veriyi analiz eder. Ancak bu süre tamamen konfigüre edilebilirdir; ihtiyaca ve ortam dinamiklerine göre -history-length parametresiyle (örneğin 14d, 30d veya 90d) kolayca değiştirilebilir. Varsayılan 8 günlük değerin temel amacı, uygulamanın haftalık kullanım dalgalanmalarını yakalamaktır.
• Prometheus Entegrasyonu: 30, 60 veya 90 günlük daha uzun vadeli veri pencerelerini analiz etmek istendiğinde Recommender -storage=prometheus parametresiyle doğrudan Prometheus'a bağlanabilir.

VPA Updater: Otomatik mod aktifse, belirlenen önerilere uymayan mevcut pod’ları siler (evict eder). Böylece Deployment’ın yeni kaynak değerleriyle tekrar ayağa kalkmasını tetikler.

VPA Admission Controller: API Server’ın Mutating Webhook mekanizmasını kullanır. Yeni bir pod yaratılırken henüz Node üzerine schedule edilmeden araya girer ve Recommender’ın hesapladığı ideal değerleri pod manifestine enjekte eder.

Demo: Savurgan Bir Uygulamanın Teşhisi ve Adım Adım Right-Sizing

Gelin VPA’in bu analiz yeteneğini canlı bir senaryo üzerinde deneyimleyelim. Senaryomuzda hiçbir iş yapmadığı halde fazla miktarda kaynak kilitleyen bir uygulamayı deploy edecek, VPA ile gerçek ihtiyacını tespit edip doğru boyutlandıracağız.

• Maliyet İsrafı Oluşturan Uygulamanın Dağıtılması

Aşağıdaki Deployment, arka planda sadece bekleyen (sleep) ve neredeyse sıfır kaynak tüketen bir alpine imajıdır. Ancak konfigürasyonunda 500m CPU ve 512Mi RAM talep ederek altyapı kapasitesini sömürür.

cat <<EOF | kubectl apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: oversized-app
  namespace: finops-vpa-lab
spec:
  replicas: 2
  selector:
    matchLabels:
      app: oversized-app
  template:
    metadata:
      labels:
        app: oversized-app
    spec:
      containers:
      - name: app
        image: alpine:latest
        command: ["sh", "-c", "while true; do sleep 3600; done"]
        resources:
          requests:
            cpu: "500m"
            memory: "512Mi"
          limits:
            cpu: "1000m"
            memory: "1Gi"
EOF

• VPA Bileşenlerinin Kurulumu

git clone https://github.com/kubernetes/autoscaler.git
cd autoscaler/vertical-pod-autoscaler
./hack/vpa-up.sh

# Kurulum Kontrolü
kubectl get pods -n kube-system | grep vpa

• VPA Analizcisini (updateMode: “Off”) Devreye Alma

Uygulamamıza müdahale etmeden sadece metrik toplaması için VPA kuralımızı tanımlıyoruz:

cat <<EOF | kubectl apply -f -
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: app-vpa-analyser
  namespace: finops-vpa-lab
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: oversized-app
  updatePolicy:
    updateMode: "Off"
EOF

• FinOps Raporunu Okuma ve Teşhis

Metrics-server verilerinin işlenmesi için bir süre bekledikten sonra VPA’in çıkardığı analiz raporuna bakıyoruz:

kubectl get vpa app-vpa-analyser -n finops-vpa-lab -o yaml

Çıktıdaki recommendation bloğu bize gerçeği söyler:

  recommendation:
    containerRecommendations:
    - containerName: app
      lowerBound:
        cpu: 25m
        memory: 250Mi
      target:
        cpu: 25m
        memory: 250Mi
      upperBound:
        cpu: 150m
        memory: 500Mi

Buradaki değerleri şu şekilde yorumlayabiliriz:

• **Target**: VPA'in uygulama için hesapladığı ideal kaynak miktarıdır.
• **Lower Bound**: Uygulamanın güvenli bir şekilde çalışabileceği tahmini alt kaynak sınırıdır.
• **Upper Bound**: Uygulamanın yük artışlarında ihtiyaç duyabileceği tahmini üst kaynak sınırıdır.

Bu değerleri başlangıçta tanımladığımız kaynaklarla karşılaştırdığımızda ortaya çıkan fark oldukça dikkat çekici:

Başlangıçta her pod için 500m CPU ve 512Mi RAM rezerve ettiğimiz uygulama için VPA, Target olarak 25m CPU ve 250Mi RAM öneriyor. Yani uygulamanın mevcut kaynak talebi ile gerçek ihtiyacı arasında 475m CPU ve 262Mi RAM fark bulunuyor.

Sonuç: Kaynak İsrafına Veda!

Kubernetes ortamlarında kaynakların nasıl gereğinden fazla rezerve edilebildiğini ve bunun cluster genelinde nasıl bir kapasite problemine dönüşebileceğini gördük. Göz kararı belirlenen requests ve limits değerleri yerine, gerçek kullanım verilerini analiz ederek daha doğru kaynak değerleri belirlemenin mümkün olduğunu inceledik.

VPA ile bu süreci otomatikleştirerek uygulamalarınızın gerçek kaynak ihtiyacını gözlemleyebilir, gereksiz kaynak rezervasyonlarını tespit edebilir ve platform genelinde daha sağlıklı bir Right-Sizing yaklaşımı oluşturabilirsiniz.

Sonuçta amacımızın yalnızca maliyetleri azaltmak değil; mevcut altyapıyı daha verimli kullanmak, kapasiteyi doğru planlamak ve kaynakları gerçekten ihtiyaç duyan uygulamalara ayırabilmek olduğunu unutmamalıyız. Küçük görünen bu optimizasyonlar, cluster ölçeği büyüdükçe altyapı verimliliği ve kapasite yönetimi açısından önemli kazanımlara dönüşebilir.

Umarım yazı, Kubernetes ortamlarında kaynak yönetimine farklı bir perspektiften bakmanıza yardımcı olmuştur. Bir sonraki yazımızda görüşmek üzere! 👋