Netdata ile Kubernetes Cluster İzleme

Bykomut

Kubernetes cluster’ı izlemek, production ortamında hayatta kalmanın temel koşullarından biri. Pod’lar sürekli ölüp yeniden doğuyor, node’lar kaynak açısından strese giriyor, network trafiği beklenmedik şekillerde artıyor. Bu kaotik ortamda Netdata, hem gerçek zamanlı görünürlük hem de düşük kaynak tüketimiyle öne çıkan güçlü bir alternatif. Prometheus + Grafana stack’ine kıyasla kurulumu çok daha hızlı, built-in dashboard’ları hazır kullanıma uygun ve Kubernetes için özel olarak tasarlanmış agent mimarisi sayesinde cluster’ın her köşesini izleyebiliyorsunuz.

Netdata’nın Kubernetes’teki Mimarisi

Netdata’yı Kubernetes’te çalıştırmanın iki temel bileşeni var: Netdata Agent ve Netdata Parent. Agent’lar her node üzerinde DaemonSet olarak çalışır ve o node’daki tüm container metriklerini, sistem metriklerini ve Kubernetes API metriklerini toplar. Parent ise merkezi bir Deployment olarak çalışır ve tüm agent’lardan gelen veriyi birleştirerek tek bir görünüm sunar.

Bu mimari sayesinde:

  • Her node kendi metriklerini kendi başına toplayabilir, ağır bir merkezi toplama yükü olmaz
  • Agent’lar birbirinden bağımsız çalıştığı için tek bir node arızalanınca tüm izleme sistemi çökmez
  • Netdata Cloud’a bağlanarak tüm cluster’ı tek bir arayüzden yönetebilirsiniz
  • cgroups entegrasyonu sayesinde container başına CPU, RAM, network ve disk metrikleri otomatik yakalanır

Pratik açıdan bakarsak, bir node’da 50 pod çalışsa bile Netdata Agent o node’da genellikle 100-150 MB RAM ve minimal CPU kullanır. Bu, resource-constrained ortamlarda büyük avantaj sağlıyor.

Kurulum Öncesi Hazırlık

Helm üzerinden kurulum yapacağız, dolayısıyla önce birkaç ön koşulu kontrol etmeliyiz.

# Helm versiyonunu kontrol et
helm version

# kubectl bağlantısını doğrula
kubectl cluster-info

# Namespace oluştur
kubectl create namespace netdata

# Helm repo ekle
helm repo add netdata https://netdata.github.io/helmchart/
helm repo update

Netdata Cloud’u kullanacaksanız, önce cloud.netdata.cloud adresinden bir hesap açıp claim token almanız gerekiyor. Bu token, agent’larınızı cloud hesabınıza bağlamak için kullanılıyor. Token olmadan da çalışır ama o zaman cluster dışından erişim için kendiniz bir ingress veya port-forward ayarlamanız gerekir.

Helm ile Temel Kurulum

Önce varsayılan values dosyasını indirip üzerinde çalışalım:

helm show values netdata/netdata > netdata-values.yaml

Aşağıdaki yapılandırma, production ortamı için iyi bir başlangıç noktası:

# netdata-values.yaml

replicaCount: 1

image:
  repository: netdata/netdata
  tag: stable
  pullPolicy: Always

sd:
  image:
    tag: latest
  child:
    enabled: true
    configmap:
      name: netdata-child-sd-config
      key: config.yml
    resources:
      requests:
        cpu: 50m
        memory: 100Mi
      limits:
        cpu: 200m
        memory: 300Mi

parent:
  resources:
    requests:
      cpu: 400m
      memory: 512Mi
    limits:
      cpu: 2000m
      memory: 2Gi
  database:
    storageclass: standard
    volumesize: 10Gi
  alarms:
    storageclass: standard
    volumesize: 1Gi

child:
  resources:
    requests:
      cpu: 100m
      memory: 128Mi
    limits:
      cpu: 500m
      memory: 512Mi
  configs:
    netdata:
      enabled: true
      path: /etc/netdata/netdata.conf
      data: |
        [global]
          memory mode = ram
          history = 3600
        [health]
          enabled = yes
        [plugins]
          cgroups = yes
          proc = yes
          diskspace = yes

claiming:
  enabled: true
  token: "BURAYA_CLAIM_TOKEN_YAZIN"
  rooms: "ROOM_ID"
  url: "https://app.netdata.cloud"

Kurulumu başlatalım:

helm install netdata netdata/netdata 
  --namespace netdata 
  --values netdata-values.yaml 
  --wait 
  --timeout 5m

Kurulumun durumunu kontrol edelim:

# Pod'ların durumunu izle
kubectl get pods -n netdata -w

# DaemonSet durumunu kontrol et
kubectl get daemonset -n netdata

# Parent deployment'ı kontrol et
kubectl get deployment -n netdata

Kubernetes Metrics Server Entegrasyonu

Netdata’nın Kubernetes-spesifik metrikleri toplayabilmesi için kube-state-metrics ve metrics-server’ın cluster’da çalışıyor olması gerekiyor. Eğer henüz kurulu değilse:

# kube-state-metrics kurulumu
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update

helm install kube-state-metrics prometheus-community/kube-state-metrics 
  --namespace kube-system 
  --set resources.requests.memory=64Mi 
  --set resources.requests.cpu=10m

# Metrics server kurulumu (eğer yoksa)
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

Netdata bu bileşenleri otomatik olarak discover etmez, konfigürasyonda belirtmemiz gerekiyor. Child node konfigürasyonuna şunu ekliyoruz:

# values.yaml içindeki child.configs bölümüne ekle
child:
  configs:
    kubestatemetrics:
      enabled: true
      path: /etc/netdata/go.d/k8s_kubeproxy.conf
      data: |
        jobs:
          - name: kube-state-metrics
            url: http://kube-state-metrics.kube-system.svc.cluster.local:8080/metrics

Değişiklikleri uygulayalım:

helm upgrade netdata netdata/netdata 
  --namespace netdata 
  --values netdata-values.yaml

RBAC Konfigürasyonu

Netdata’nın Kubernetes API’sine erişmesi için doğru RBAC izinleri şart. Helm chart bu konfigürasyonu otomatik oluşturuyor ama bazı durumlarda özelleştirme gerekebiliyor. Özellikle pod metadata’sına erişim ve node bilgilerini okuma için:

# Mevcut RBAC konfigürasyonunu kontrol et
kubectl get clusterrole netdata -o yaml
kubectl get clusterrolebinding netdata -o yaml

# Eğer eksik izinler varsa patch uygula
kubectl patch clusterrole netdata --type='json' -p='[
  {
    "op": "add",
    "path": "/rules/-",
    "value": {
      "apiGroups": [""],
      "resources": ["pods", "nodes", "services", "endpoints"],
      "verbs": ["get", "list", "watch"]
    }
  }
]'

Genellikle bu adım gerekmez, ama eğer Netdata dashboard’unda pod metrikleri görünmüyorsa RBAC’ı kontrol etmek iyi bir başlangıç noktası.

Custom Alarm Tanımlamaları

Built-in alarmlar çoğu senaryo için yeterli ama production’da daha granüler kontrol istiyorsunuz. Örneğin, belirli bir namespace’deki pod’ların restart sayısını izlemek veya kritik servislerin container CPU kullanımı için özel eşikler koymak gibi.

# netdata-custom-alarms.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: netdata-custom-alarms
  namespace: netdata
data:
  k8s.conf: |
    # Pod restart sayısı alarmı
    alarm: k8s_pod_restart_rate
    on: k8s.pod.restarts
    lookup: sum -5m
    units: restarts
    every: 1m
    warn: $this > 3
    crit: $this > 10
    info: Kubernetes pod restart sayısı son 5 dakikada yüksek
    to: sysadmin

    # Node bellek kullanımı
    alarm: k8s_node_memory_high
    on: system.ram
    lookup: average -2m percentage used
    units: %
    every: 1m
    warn: $this > 80
    crit: $this > 90
    info: Node bellek kullanımı kritik seviyede
    to: sysadmin
kubectl apply -f netdata-custom-alarms.yaml

# ConfigMap'i agent pod'una mount etmek için values.yaml'ı güncelle
# child.configs altına ekle:
# alarms:
#   enabled: true
#   path: /etc/netdata/health.d/k8s.conf
#   data: |
#     # alarm içeriği buraya

Slack Entegrasyonu ile Alarm Bildirimleri

Alarm geldiğinde doğrudan Slack’e bildirim gitmesi için notification konfigürasyonu yapalım. Bu kısım production’da hayat kurtarıyor:

# values.yaml içine eklenecek parent konfigürasyonu
parent:
  configs:
    netdata:
      enabled: true
      path: /etc/netdata/netdata.conf
      data: |
        [global]
          hostname = k8s-netdata-parent
        [health]
          enabled = yes
          default recipient = admin
    alarms:
      enabled: true
      path: /etc/netdata/health_alarm_notify.conf
      data: |
        SEND_SLACK="YES"
        SLACK_WEBHOOK_URL="https://hooks.slack.com/services/XXXX/YYYY/ZZZZ"
        DEFAULT_RECIPIENT_SLACK="#alerts-kubernetes"
        
        SEND_EMAIL="NO"
        
        # Sadece kritik alarmlar için pagerduty
        SEND_PAGERDUTY="YES"
        PAGERDUTY_SERVICE_KEY="buraya_pagerduty_key"

Değişiklikleri push ettikten sonra alarm testi yapalım:

# Parent pod'una gir
kubectl exec -it -n netdata 
  $(kubectl get pod -n netdata -l app=netdata,role=parent -o jsonpath='{.items[0].metadata.name}') 
  -- /bin/bash

# Alarm testi gönder
/usr/libexec/netdata/plugins.d/alarm-notify.sh test slack

Log ve Troubleshooting

İzleme sisteminde bir şeyler ters gittiğinde nereye bakacağınızı bilmek çok önemli:

# Parent loglarını kontrol et
kubectl logs -n netdata 
  $(kubectl get pod -n netdata -l app=netdata,role=parent -o jsonpath='{.items[0].metadata.name}') 
  --tail=100 -f

# Belirli bir node'daki child agent loglarını gör
kubectl logs -n netdata 
  $(kubectl get pod -n netdata -l app=netdata,role=child -o jsonpath='{.items[0].metadata.name}') 
  --tail=100

# Tüm child pod'larının durumunu listele
kubectl get pods -n netdata -l role=child -o wide

# Agent'ın topladığı metrikleri doğrula
kubectl port-forward -n netdata 
  $(kubectl get pod -n netdata -l app=netdata,role=parent -o jsonpath='{.items[0].metadata.name}') 
  19999:19999

# Tarayıcıda aç: http://localhost:19999

Sık karşılaşılan bir sorun: child agent’lar parent’a bağlanamıyor. Bu durumda genellikle network policy sorunları veya service DNS çözümlemesi hataları oluyor. Kontrol listesi:

  • NetworkPolicy: netdata namespace’ine gelen trafiği bloke eden bir policy var mı?
  • Service DNS: kubectl exec ile agent pod’una girip nslookup netdata.netdata.svc.cluster.local çalıştırın
  • Port Çakışması: 19999 portu başka bir uygulama tarafından kullanılıyor olabilir
  • Resource Limits: Child agent’lar memory limit’e çarpıyorsa kubectl describe pod çıktısında OOMKilled göreceksiniz

Gerçek Dünya Senaryosu: Memory Leak Tespiti

Production’da sık yaşanan bir senaryo: belirli bir deployment’ın pod’ları zamanla artan bellek tüketiyor, eventual olarak OOMKilled alıyor ve restart ediyor. Bu pattern’i Netdata ile nasıl tespit edip izolasyonu yapıyoruz?

Önce namespace bazında aggregate bellek kullanımını izliyoruz. Netdata’nın Kubernetes dashboard’unda container başına memory grafiklerini açın. Belirli bir container’ın grafiği düzenli artış gösteriyorsa ve restart sonrası sıfırlanıyorsa klasik memory leak belirtisi.

Bu durumda şu alarm konfigürasyonunu ekliyoruz:

# memory-leak-detection.conf
alarm: container_memory_growth
on: k8s.cgroup.mem_usage
lookup: max -30m, min -1h
units: MiB
every: 5m
warn: $this > 100
crit: $this > 200
info: Container bellek kullanımı son 30 dakikada hızla artıyor, memory leak şüphesi
to: sysadmin

Bu alarm, son 30 dakikanın maksimum değeri ile önceki saatin minimum değeri arasındaki farkı ölçüyor. Fark 100 MiB’ı geçerse warning, 200 MiB’ı geçerse critical alarm tetikleniyor.

Ingress Kontrolcüsü Metrikleri

NGINX Ingress Controller veya Traefik kullanan cluster’larda HTTP request metrics’i de izlemek isteyebilirsiniz. Netdata’nın go.d plugin’i bu konuda oldukça yetenekli:

# ingress-nginx-monitoring.yaml
child:
  configs:
    nginxvts:
      enabled: true
      path: /etc/netdata/go.d/nginx.conf
      data: |
        jobs:
          - name: ingress-nginx
            url: http://ingress-nginx-controller-metrics.ingress-nginx.svc.cluster.local:10254/metrics

Bu konfigürasyon sayesinde Netdata’nın dashboard’unda şunları görebilirsiniz:

  • Saniyedeki istek sayısı (RPS)
  • HTTP durum kodu dağılımı (2xx, 4xx, 5xx)
  • Upstream response time
  • Active connection sayısı

PersistentVolume ve Depolama İzleme

Storage sorunları Kubernetes’te sıkça can sıkıyor, özellikle PVC’ler dolarsa pod’lar crash loop’a giriyor. Netdata disk metrikleri bu konuda yardımcı olabilir ama doğrudan PVC kapasitesi için kube-state-metrics’ten veri almak daha güvenilir:

# kube-state-metrics'in PVC metriklerini expose ettiğini doğrula
kubectl port-forward svc/kube-state-metrics -n kube-system 8080:8080 &
curl -s http://localhost:8080/metrics | grep kube_persistentvolumeclaim_resource_requests_storage_bytes | head -5

# Netdata'nın bu metrikleri çektiğini kontrol et
kubectl exec -it -n netdata 
  $(kubectl get pod -n netdata -l role=child -o jsonpath='{.items[0].metadata.name}') 
  -- curl -s http://localhost:19999/api/v1/charts | python3 -m json.tool | grep -i "pvc|persistent"

Performans Tuning

Büyük cluster’larda (50+ node) Netdata Parent pod’u ciddi kaynak tüketebilir. Birkaç optimizasyon önerisi:

Retention süresi ayarı: Parent’ta veri ne kadar süre tutulacak? Uzun retention = daha fazla disk ve RAM.

parent:
  configs:
    netdata:
      data: |
        [global]
          # RAM'de 4 saat, disk'te 1 ay tut
          memory mode = dbengine
          page cache size = 256
          dbengine multihost disk space = 10240
        [db]
          storage tiers = 3
          # Tier 0: saniyede bir nokta, 14 gün
          # Tier 1: dakikada bir nokta, 3 ay
          # Tier 2: saatte bir nokta, 2 yıl

Streaming compression: Agent ile parent arasındaki veri akışını sıkıştırarak network kullanımını azaltabilirsiniz:

child:
  configs:
    stream:
      enabled: true
      path: /etc/netdata/stream.conf
      data: |
        [stream]
          enabled = yes
          destination = netdata:19999
          api key = BURAYA_API_KEY
          send charts matching = *
          compression algorithms order = lz4 zstd brotli gzip

Scrape interval optimizasyonu: Her şeyi saniyede bir toplamak gerekmeyebilir. Önemsiz metrikler için intervali artırın:

child:
  configs:
    netdata:
      data: |
        [plugins]
          python.d = no
          charts.d = no
        [plugin:cgroups]
          update every = 2
        [plugin:proc:/proc/diskstats]
          update every = 5

Netdata Cloud ile Merkezi Yönetim

Birden fazla Kubernetes cluster’ı yönetiyorsanız Netdata Cloud kaçınılmaz hale geliyor. Her cluster için ayrı ayrı dashboard açmak yerine tek bir arayüzde tüm cluster’ları görebiliyorsunuz.

# Claim token ile mevcut kurulumu cloud'a bağla
kubectl patch configmap netdata-conf -n netdata --type merge -p '{
  "data": {
    "claiming": "enabled = yesntoken = TOKEN_BURAYAnrooms = ROOM_IDnurl = https://app.netdata.cloudn"
  }
}'

# Pod'ları yeniden başlat
kubectl rollout restart daemonset/netdata -n netdata
kubectl rollout restart deployment/netdata -n netdata

# Bağlantı durumunu kontrol et
kubectl logs -n netdata 
  $(kubectl get pod -n netdata -l role=parent -o jsonpath='{.items[0].metadata.name}') 
  | grep -i "cloud|claim|connect"

Cloud bağlantısı kurulduktan sonra Netdata Rooms özelliğini kullanarak farklı cluster’ları veya farklı ortamları (production, staging, dev) gruplandırabilirsiniz. Her room için ayrı alarm politikaları tanımlayabilmek production operasyonlarını önemli ölçüde kolaylaştırıyor.

Monitoring Stack Karşılaştırması

Netdata’yı tercih etmek için geçerli nedenler var ama her araç gibi bazı kısıtları da mevcut:

  • Kurulum süresi: Netdata 15-20 dakika, Prometheus + Grafana 1-2 saat
  • Built-in dashboard: Netdata’da hazır gelir, Grafana’da dashboard import veya oluşturma gerekir
  • Özelleştirme esnekliği: Grafana çok daha güçlü ama karmaşıklık da o kadar fazla
  • Long-term storage: Netdata’nın TSDB’si yeterli ama Thanos veya Cortex gibi uzun vadeli depolama için Prometheus ekosistemi daha olgun
  • Mevcut ekosistem entegrasyonu: Prometheus exporter’ları zaten varsa Prometheus’u tercih etmek mantıklı

Startup veya küçük/orta ölçekli ekipler için Netdata mükemmel bir tercih. Büyük organizasyonlarda her ikisini birlikte kullanmak da mümkün; Netdata gerçek zamanlı debugging ve anomali tespiti için, Prometheus ise uzun vadeli trend analizi ve SLO takibi için.

Sonuç

Netdata ile Kubernetes cluster izlemek, kurulum kolaylığı ve düşük öğrenme eğrisiyle ciddi zaman tasarrufu sağlıyor. DaemonSet mimarisi sayesinde her node kendi metriklerini topluyor, parent pod tüm veriyi birleştiriyor ve Netdata Cloud üzerinden tüm cluster’a tek noktadan bakış imkanı sunuyor.

Bu yazıda anlattığımız adımları özetlersek:

  • Helm ile temel kurulum ve namespace hazırlığı
  • kube-state-metrics ve metrics-server entegrasyonu
  • RBAC konfigürasyonu ve erişim yönetimi
  • Custom alarm tanımlamaları ve Slack bildirimleri
  • Memory leak tespiti gibi gerçek dünya senaryoları
  • Ingress ve storage izleme
  • Büyük cluster’lar için performans optimizasyonu

Production’a geçmeden önce staging ortamında test edin, özellikle resource limit’lerini cluster boyutunuza göre ayarlayın. İlk kurulumdan sonra birkaç gün boyunca Netdata’nın kendi kaynak tüketimini de gözlemleyin; bazı ortamlarda child agent’ların memory limit’lerini biraz artırmanız gerekebilir.

En kritik nokta: alarmları doğru eşiklerle yapılandırmak. Çok hassas alarmlar alarm yorgunluğu yaratır, çok gevşek alarmlar sorunları gözden kaçırmanıza neden olur. İlk birkaç hafta baseline metrikleri toplayın, sonra gerçek eşikleri belirleyin. Netdata’nın anomaly detection özelliği de bu konuda yardımcı olabilir; makine öğrenimi tabanlı analizle normal davranıştan sapmalar otomatik olarak raporlanıyor.

Benzer Konular

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir