Konteyner tabanlı uygulamaların karmaşık ekosisteminde kaynak kullanılabilirliği iki ucu keskin bir kılıç gibidir. Kubernetes esnek ölçeklendirme için tasarlanmış olsa da, Pod tanımlarında tanımlanan CPU ve bellek kotaları aracılığıyla sıkı sınırlamalar uygular. Bu sınırlara ulaşıldığında sistem iki farklı şekilde tepki verir: sessizce performansı düşüren sınırlama (throttling) ve podları ani olarak sonlandıran Bellek Tükenmesi (OOM) öldürmeleri. Bu sorunları erken tespit etmek, Hizmet Seviyesi Hedeflerini (SLO) korumak için kritiktir.
Çoğu kuruluş varsayılan izleme panolarına güvense de, bunlar genellikle üretim seviyesinde uyarılandırma için gereken özelliğe sahip değildir. Varsayılan kurallar bir pod'un kapalı olduğunu söyleyebilir, ancak nedenini açıklamazlar veya bir kesintiye yol açmadan önce CPU sınırlaması nedeniyle oluşan sessiz performans düşüşü hakkında sizi uyarmazlar. Bu kılavuz, kaynak rekabeti ve bellek tükenmesi olaylarını özellikle hedeflemek için özel Prometheus uyarı kuralları oluşturmanın detaylarını anlatmaktadır.
Sınırlama için Metrikleri Anlamak
CPU sınırlaması hakkında uyarı vermek için kubelet tarafından maruz bırakılan konteyner çalışma zamanı metriklerine bakmamız gerekir. En yaygın kullanılan metrik, container_metrics API'sinden gelen container_cpu_cfs_throttled_seconds_total'dir. Bu sayaç, bir konteyner CPU kotasını aştığı için sınırlandığında yalnızca artar.
Basit bir eşik genellikle yetersizdir. Sınırlamada bir artış başlangıç aşamasında geçici olabilir, bu nedenle belirli bir pencere boyunca değişim oranına bakmamız gerekir. Kaybedilen CPU süresini belirlemek için sınırlanmış saniyelerin oranını hesaplarız. Eğer oran tanımlanmış bir eşiği (örneğin, 5 dakikalık pencerede saniyede 0.1 saniye kayıp) aşarsa, bu muhtemelen gecikme patlamalarına yol açacak kalıcı bir kaynak kıtlığını gösterir.
Sessiz OOM Risklerini Tespit Etmek
OOM öldürme açıkça bellidir (pod yeniden başlatılır), ancak gerçekleşmeden önce OOM öldürme riskini tespit etmek SRE uygulamalarının altın standardıdır. Kubernetes container_memory_working_set_bytes gibi bellek kullanım metriklerini maruz bırakır. Ancak sadece bellek yüksek olduğunda uyarı vermek istemiyoruz; bellek limite yaklaştığında uyarı vermek istiyoruz.
Strateji, mevcut bellek kullanımını tanımlanan limit ile karşılaştırmayı içerir. Bir pod'un bellek kullanımı, limitinin %85'i üzerinde sürekli olarak 10 dakikadan fazla kalırsa, uygulamanın yakında bir OOM öldürme tetiklemesi yüksek olasılıktır. Bu "ön-ölüm" uyarısı, operatörlerin uygulama çökmeden önce kaynak talebini ölçeklendirmesine, limiti artırmasına veya bir bellek sızıntısını incelemesine olanak tanır.
Prometheus Uyarı Kurallarını Oluşturma
Bunu uygulamaya koymak için bir prometheus_alerts.yaml yapılandırması tanımlayalım. Bu kural kümesi hem CPU sınırlaması hem de bellek baskısı senaryolarını hedefler.
groups:
- name: k8s-resource-alerts
interval: 30s
rules:
# CPU Sınırlaması için Uyarı
- alert: HighCPUThrottling
expr: |
rate(container_cpu_cfs_throttled_seconds_total{namespace="prod"}[5m])
/
rate(container_cpu_cfs_period_seconds_total{namespace="prod"}[5m])
> 0.05
for: 5m
labels:
severity: warning
team: platform
annotations:
summary: "{{ $labels.pod }} içinde yüksek CPU sınırlaması tespit edildi"
description: "{{ $labels.namespace }} adlı ad uzayındaki {{ $labels.pod }} pod'u önemli ölçüde CPU sınırlaması yaşıyor."
# Bellek Baskısı (OOM Riski) için Uyarı
- alert: HighMemoryUsage
expr: |
(container_memory_working_set_bytes{namespace="prod"}
/
container_spec_memory_limit_bytes{namespace="prod"}) * 100 > 85
for: 10m
labels:
severity: critical
team: platform
annotations:
summary: "{{ $labels.pod }} içinde bellek baskısı tespit edildi"
description: "{{ $labels.pod }} pod'u bellek limitinin %{{ $value }}'ini kullanıyor."Doğruluk İçin İnce Ayar
CPU kuralında rate() işlevinin kullanımına dikkat edin. Veriyi düğümün CPU mimarisinden bağımsız olarak normalleştirmek için sınırlanmış saniyeleri periyot saniyelerine böleriz. Bellek kuralında, limitlerin sonsuz olabileceği durumu ele alıyoruz; payda geçerli olduğundan emin olarak, ancak Prometheus sıfıra bölme durumunu birçok sürümde zarifçe NaN döndürerek yönetir ve gerekirse ek mantıkla bunu filtreleyebiliriz.
Ayrıca, geliştirme ortamlarından gelen uyarı yorgunluğunu önlemek için kurallarınızı her zaman belirli ad alanlarına veya etiketlere (örneğin prod) göre sınırlayın. Koşul devam ediyorsa uyarıların yalnızca tetiklenmesini sağlamak için for ifadelerini kullanın; bu da genellikle zararsız olan geçici patlamaları filtreler.
Sonuç
Özel uyarılandırma kuralları oluşturmak, izleme yığınınızı altyapınızın pasif bir gözlemcisinden aktif bir koruyucusuna dönüştürür. CPU sınırlama oranlarına ve bellek baskısı yüzdelerine özellikle odaklanarak, kesintilere tepki vermekten onları önlemeye geçiş yaparsınız. Bu özel kurallar, Kubernetes ortamlarında yüksek kullanılabilirliği korumak için gereken granüler görünürlüğü sağlar ve uygulamalarınızın yük altında performanslı ve kararlı kalmasını garanti eder. Bu metrikleri ayarlamak için zaman ayırın ve SRE ekibiniz azalan gürültü ve daha hızlı olay müdahale süreleri için size teşekkür edecektir.