Kubernetes v1.37: Metrics API Artık Stable
Kubernetes v1.37 sürümüyle birlikte metrics.k8s.io API’si resmi olarak stable (v1) statüsüne yükseltildi. Node ve Pod düzeyinde CPU ile bellek kullanım verilerini sunan bu API, kubectl top komutunun ve kaynak metriklerine dayalı otomatik ölçekleme mekanizmalarının arka planında çalışan temel bileşen. Bu yazıda v1’e geçişin küme operatörleri ve uygulama geliştiricileri için ne anlama geldiğini, hangi ayrıntıların değiştiğini ve geçiş sürecinde nelere dikkat edilmesi gerektiğini derledim.
Uzun soluklu bir API nihayet stable oldu
Resource Metrics API’nin geçmişi eskiye dayanıyor. API ilk olarak Kubernetes v1.6’da alpha olarak tanıtıldı, v1.8’de beta seviyesine yükseltildi. O günden bu yana yapısı büyük ölçüde değişmeden kaldı; HorizontalPodAutoscaler (HPA) ve kubectl top gibi istemciler tarafından üretim ortamlarında yıllardır kullanılıyor. Kubernetes v1.37 ile uzun süredir sahada denenmiş bu API artık resmi olarak metrics.k8s.io/v1 altında stable statüye taşınıyor.
API iki temel kaynak türü ortaya koyuyor:
- NodeMetrics: Bir node için CPU ve bellek kullanımını gösterir.
- PodMetrics: Bir Pod’un CPU ve bellek kullanımını sunar;
containersalanı üzerinden konteyner bazında kırılım verir.
API bilinçli olarak dar kapsamlı tutulmuş. Otomatik ölçekleme ve temel gözlem için gereken kaynak metriklerini sağlamaya odaklanıyor; tam kapsamlı bir izleme altyapısının ya da custom.metrics.k8s.io API’sinin yerini tutma iddiası taşımıyor.
v1.37 ile ne değişti?
Bu geçişte akılda tutulması gereken en önemli nokta şu: v1 yüzeyi, API sürümü dışında v1beta1 ile birebir aynı. Yeniden adlandırılmış alan, yeni eklenen alan veya döndürülen CPU/bellek değerlerinin anlamında bir farklılaşma yok. Yani toplanan veya sunulan metrikler değişmedi, yalnızca API sürümü olgunlaştı.
Yeni stable endpoint üzerinden node metriklerine erişmek için:
kubectl get --raw /apis/metrics.k8s.io/v1/nodesBelirli bir namespace’teki Pod’ların metriklerini almak için:
kubectl get --raw /apis/metrics.k8s.io/v1/namespaces/default/podskubectl top komutu her iki API sürümünü de destekliyor. Önce v1‘i deniyor, v1‘i henüz sunmayan kümelerde otomatik olarak v1beta1‘e geri düşüyor. Bu davranış geçiş dönemi için pratik bir güvence sağlıyor.
Öte yandan HPA controller şu an yalnızca v1beta1‘i destekliyor. v1 ile v1beta1 arasında discovery tabanlı seçim yapılabilmesi için çalışma planlanıyor ama bu yetenek Kubernetes v1.37’de henüz yok.
Küme operatörleri ne yapmalı?
İyi haber: Bu geçişi devreye almak için herhangi bir feature gate etkinleştirmenize gerek yok. Metrics API, API aggregation layer üzerinden, metrics-server gibi bir implementasyon tarafından servis ediliyor.
metrics.k8s.io‘nun herhangi bir implementasyonunu tercih edebilirsiniz; ancak kümenizde v1 metrics API’sinin kullanılabilir olması için seçtiğiniz implementasyonun v1.metrics.k8s.io API’sini sunması ve ilgili APIService kaydının yapılması gerekiyor.
Geçiş dönemi boyunca implementasyonların hem v1‘i hem v1beta1‘i sunması öneriliyor. İki sürümü birlikte erişilebilir tutmak, eski istemcilerle uyumluluğu koruyor. v1beta1 API’si Kubernetes v1.37’de hala mevcut.
Kümenizin hangi sürümleri sunduğunu görmek için:
kubectl get --raw /apis/metrics.k8s.io/ | jq.Metrics implementasyonunuz v1‘i desteklemeye başladıktan sonra APIService’in durumunu şu şekilde doğrulayabilirsiniz:
kubectl get apiservice v1.metrics.k8s.ioGeçişi planlarken dikkat edilmesi gerekenler
Özetle: v1‘e geçiş bir davranış değişikliği değil, olgunluk beyanı. API artık Kubernetes stable API garantilerini taşıyor, yani sözleşme uzun vadeli olarak sabit kalacak. İstemci geliştiricileri için v1‘i tercih etmek uzun vadede daha güvenli bir seçim. Ancak HPA controller gibi bazı bileşenlerin hala v1beta1‘e bağımlı olduğu unutulmamalı; bu yüzden küme genelinde her iki sürümün de bir süre daha paralel sunulması pratik bir yaklaşım.
Kendi ölçekleme veya gözlem araçlarınızı geliştiriyorsanız endpoint yollarınızı /apis/metrics.k8s.io/v1 altında güncelleyip, kümenin v1‘i sunup sunmadığına göre v1beta1‘e geri düşecek bir mantık eklemek şimdilik makul bir strateji. kubectl top‘un benimsediği “önce v1, gerekirse v1beta1” yaklaşımı bu konuda iyi bir örnek.
Katkı ve topluluk
Metrics API, SIG Instrumentation tarafından bakılıyor. Soru sormak, geri bildirim paylaşmak veya katkı sağlamak isterseniz Kubernetes Slack üzerindeki #sig-instrumentation kanalına katılabilir ya da SIG Instrumentation toplantılarına iştirak edebilirsiniz.
Kaynaklar ve İleri Okuma
- Kubernetes v1.37: Metrics API graduates to stable (orijinal duyuru)
- Resource metrics pipeline dokümantasyonu
- KEP-5207: Metrics API graduation önerisi
- Metrics API kaynak deposu
- metrics-server referans implementasyonu
- API aggregation layer yapılandırması
- APIService v1 referansı
- Kubernetes Custom Metrics Exporter Nasıl Yazılır?
- Kubernetes 1.36 Ön İzleme: Neler Geliyor, Neler Gidiyor?
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
3 comments