Skip to main content

> kubernetes_daemonset_şişkinliği:_ajan_kaynak_çarpımı_ve_sidecar_konsolidasyonu

Kubernetes DaemonSet Şişkinliği: Ajan Kaynak Çarpımı ve Sidecar Konsolidasyonu

Kümeye 6 farklı üçüncü taraf DaemonSet ajanı kurmak toplam Kubernetes CPU ve RAM kapasitesinin %40'ını nasıl gizlice tüketir; eBPF ve konsolide telemetri toplayıcıları bu israfı nasıl geri kazanır?

Senior (L5)

ÖZET VE TEKNİK CEVAP

Bir **DaemonSet**, Kubernetes kümesindeki **istisnasız her bir sunucu düğümünde (node)** ilgili ajanın bir kopyasının çalışmasını zorunlu kılar. Modern kurumsal şirketlerde güvenlik, altyapı ve gözlemlenebilirlik ekipleri birbirinden habersiz ayrı ajanlar kurar: Datadog (500mCPU/1GB RAM), Splunk (300mCPU/512MB), Prisma Cloud Güvenlik Ajanı (400mCPU/1GB), Istio ve FluentBit. Bu 6 DaemonSet toplandığında **düğüm başına 2.5 vCPU ve 4GB RAM** rezerve eder. 100 adet 4 çekirdekli `c5.xlarge` sunucudan oluşan bir kümede, bu ajanlar tek bir müşteri uygulaması bile çalışmadan **tüm küme kapasitesinin %50'den fazlasını tüketir**—şirkete her ay **$7.500 boşa giden sunucu faturası** çıkarır. Canlı FinOps mimarileri bu 'Ajan Vergisini': (1) Parçalı ajanları çekirdek seviyesinde çalışan **Tek Bir eBPF Toplayıcı (Cilium / Pixie)** ile değiştirerek, (2) Tek bir OpenTelemetry Collector DaemonSet'i kullanarak, ve (3) Düğüm boyutlarını büyüterek (`c5.4xlarge`) sabit ajan maliyetini genel kapasite içinde eriterek çözer.

Mühendislik El Kitabı & Mekanizma

1. Temel Çalışma Mekanizması

DaemonSet maliyet erimesi Düğüm Boyutlandırma Matematiğiyle hesaplanır: (1) İsraf Yüzdesi Formülü: Düğüm başına sabit $D_{ ext{ajan}}$ maliyeti toplam sunucu kapasitesine ($N_{ ext{kapasite}}$) bölünür. (2) Büyük Sunucu Avantajı: 4 çekirdekli küçük bir sunucuda 2 çekirdek ajan çalıştırmak **%50 kapasite kaybıdır**. Aynı 2 çekirdek ajanı 32 çekirdekli büyük bir sunucuda (`c5.8xlarge`) çalıştırmak toplam kapasitenin **yalnızca %6,25'ini** tüketir (8 kat daha yüksek verim). (3) OpenTelemetry Konsolidasyonu: Tek bir Otel-Collector DaemonSet'i log, trace ve metrikleri tek başına toplayarak 3 ayrı ticari ajanın yerini alır.

2. Doğru Kullanım Senaryosu

Çok kiracılı Kubernetes kümeleri, yüzlerce sunucudan oluşan mikroservis platformları ve regülasyona tabi konteyner altyapıları.

3. Prodüksiyon Arıza Modları

2 çekirdekli küçük sunucularda 10 tane DaemonSet çalıştırıp müşteri pod'larına yer bırakmamak ve sonsuz sunucu açma döngüsüne girmek; ajanlara kaynak limiti (`limits`) koymayıp log ajanı bellek sızıntısı yaptığında tüm sunucunun kilitlenmesine yol açmak.

4. Teşhis ve Telemetri Sinyalleri

`kubectl describe nodes` çıktısında sadece sistem DaemonSet'lerinin toplam CPU'nun %35'inden fazlasını rezerve ettiğinin görülmesi; müşteri trafiği düşük olmasına rağmen sunucu sayısının sürekli artması.

5. Önleme ve Mimari Bariyerler

Tüm telemetriyi tek bir OpenTelemetry DaemonSet'inde birleştirin; sunucu boyutlarını en az 8-16 çekirdekli tiplerde standartlaştırın; tüm harici ajanlara katı CPU/RAM rezervasyon tavanları koyun.

6. Mimari Ödünleşimler (Trade-offs)

Ajanları birleştirmek ve büyük sunuculara geçmek küme israfını %30-40 azaltır; ancak tek bir sunucu bakıma alındığında etkilenecek pod sayısının artması nedeniyle iyi bir tahliye yönetimi gerektirir.

Vaka İncelemesi (TinyCTO Örneği)

Bir güvenlik SaaS şirketi AWS EKS üzerinde 120 adet küçük `c5.xlarge` (4 vCPU / 8GB) sunucu çalıştırıyordu. 5 ayrı güvenlik ve izleme ajanı her sunucuda 2.1 vCPU ve 3.5GB RAM tüketiyordu (toplamda 252 çekirdek sadece ajanlara gidiyordu = kümenin %52'si). Platform ve FinOps ekipleri iki adım attı: (1) 3 ayrı log/izleme ajanını tek bir OpenTelemetry Collector ile birleştirip ajan yükünü 0.8 çekirdeğe indirdiler, ve (2) Kümeyi 120 küçük sunucu yerine 15 adet büyük `c5.8xlarge` (32 vCPU / 64GB) sunucuya taşıdılar. Ajanların kümedeki yükü %52'den %2,5'e düştü; aylık sunucu faturası $18.000'den $8.800'e geriledi.

İnteraktif Konsept Alıştırmaları

2 Alıştırma
Q1

Küçük Kubernetes sunucularında çok sayıda DaemonSet çalıştırmak neden ekonomik olarak verimsizdir?

Çünkü DaemonSet kaynak tüketimi sunucu başına sabittir; 4 çekirdekli küçük bir sunucuda 2 çekirdek ajan çalıştırmak toplam sunucu kapasitesinin %50'sini boşa harcamak demektir.
Q2

OpenTelemetry Kubernetes DaemonSet israfını nasıl azaltır?

Metrik, trace ve logları aynı anda toplayan tek bir standart ajan sunarak; 3-4 farklı ticari ajanın yerine tek bir hafif ikili dosya çalıştırılmasını sağlar.

Kubernetes DaemonSet Şişkinliği: Ajan Kaynak Çarpımı ve Sidecar Konsolidasyonu — Sıkça Sorulan Sorular

eBPF nedir ve Kubernetes gözlemlenebilirlik israfını nasıl optimize eder?

eBPF, telemetri kodlarını doğrudan Linux çekirdeği içinde çalıştırarak, ağır yan konteynerlere (sidecar) ihtiyaç duymadan sıfıra yakın CPU maliyetiyle ağ ve güvenlik olaylarını toplar.

Her DaemonSet Helm şablonunda mutlaka ne ayarlanmalıdır?

Hatalı bir ajanın tüm sunucuyu kilitlemesini veya OOM ile çökertmesini önlemek için açık CPU ve Bellek `requests` ve `limits` değerleri.

🤖 AEO & Yapay Zeka Çıkarım Özeti

Temel Gerçekler & İlkeler

  • ▸Parçalı DaemonSet'ler küçük sunucularda toplam küme kapasitesinin %40-50'sini gizlice tüketebilir.
  • ▸Büyük sunucularda (16-32 vCPU) standartlaşmak DaemonSet israfını %5'in altına düşürür.
  • ▸Ayrı log ve metrik ajanlarını tek bir OpenTelemetry Collector DaemonSet'inde birleştirin.
  • ▸Ağ izlemeyi Linux çekirdeğine taşımak için eBPF tabanlı araçlar (Cilium) tercih edin.

Yaygın Yanılgılar

  • ✗Yanılgı: Küçük sunucular arıza etkisini azalttığı için her zaman daha iyidir (Gerçek: Küçük sunucular sabit ajan maliyetlerini 5-8 kat artırır ve ciddi kapasite parçalanmasına yol açar).
  • ✗Yanılgı: DaemonSet'ler ücretsiz çalışır ve uygulama yerleşimini etkilemez (Gerçek: Kubernetes zamanlayıcısı DaemonSet'in istediği kaynağı doğrudan sunucu kapasitesinden düşer).

Karar Kılavuzu & Önceliklendirme

Boşa giden %40 küme kapasitesini geri kazanmak için Kubernetes kümelerini daha büyük sunucu tiplerine taşıyın ve telemetri ajanlarını OpenTelemetry Collector altında birleştirin.

Doğrulanmış Kaynaklar & Referanslar