Kubernetes İzlemeyi Yapay Zeka ile Nasıl Daha Akıllı Hale Getirirsiniz?

Prometheus, n8n ve OpenAI kullanarak akıllı bir uyarı yönetim sistemi oluşturmanın pratik rehberi

Bir DevOps mühendisi olarak, gece 3'te Prometheus uyarısıyla uyanmanın acısını eminim yaşamışsınızdır. Her uyarı geldiğinde kalkmanız, pod durumunu kontrol etmeniz, logları incelemeniz, sorunu gidermeniz gerekir ve çoğu zaman basit bir yeniden başlatma ile çözülebilecek bir durum için 30 dakika harcadığınızı fark edersiniz.

Beni en çok hayal kırıklığına uğratan şey, birçok uyarının öngörülebilir sorun giderme kalıplarını izlemesiydi. Pod sağlık sorunları için her zaman logları, kaynak kullanımını ve yapılandırmayı kontrol ederiz. Her seferinde aynı adımları tekrarlarız. Bu büyük bir zaman kaybı.

Böylece merak etmeye başladım: Yapay zeka bu tekrarlayan görevlerde bize yardımcı olabilir mi? Sorunları teşhis etmek ve ilk önerileri sunmak için uzman sorun giderme mantığımızı takip edebilir mi?

Birkaç aylık deneme ve pratikten sonra, sonunda bu akıllı izleme sistemini kurdum. Bugün deneyimlerimi sizinle paylaşmak istiyorum.

Karşılaştığım Sorunlar

Konuya girmeden önce, ekibimizin karşılaştığı bazı tipik sorunları paylaşayım:

Sorun 1: Uyarı Yüklemesi (Alert Overload)

Kubernetes kümelerimiz, pod yeniden başlatmalarından node kaynak yetersizliklerine kadar günde yüzlerce uyarı üretiyor. Operasyon ekibi genellikle uyarı selinden bunalıyor ve hangi konuların acil ilgi gerektirdiğini önceliklendiremiyor.

Sorun 2: Standartlaştırılmış Ancak Manuel Sorun Giderme

Bir KubePodNotReady uyarısı için standart sürecimiz şöyledir:

Pod durumunu kontrol et (kubectl get pods)
Detaylı bilgi al (kubectl describe pod)
Logları kontrol et (kubectl logs)
Gerekirse servisi yeniden başlat

Bu iş akışı olgundur, ancak her seferinde manuel olarak yürütmek verimsizdir.

Sorun 3: Yeni Ekip Üyeleri İçin Dik Öğrenme Eğrisi

Yeni operasyon mühendisleri genellikle uyarılarla karşılaştıklarında nereden başlayacaklarını bilemezler. Dokümantasyon olsa bile, gerçek sorun giderme sırasında deneyimli meslektaşlarından rehberliğe ihtiyaç duyarlar.

Çözüm Yaklaşımım

Bu sorunlarla yüzleşirken fikrim basitti:

Yapay zekaya, ilk sorun teşhisini yapması için operasyon uzmanlarının sorun giderme zihniyetini öğretebilir miyim?

Özellikle:

AI uyarı içeriğini anlasın — Alertmanager JSON'ından anahtar bilgileri çıkarsın
AI nasıl sorun gidereceğini bilsin — Uyarı türlerine göre uygun kontrol adımlarını seçsin
AI kümeyi yönetsin — Araçlar aracılığıyla kubectl komutlarını çağırsın
AI profesyonel tavsiye versin — Kontrol sonuçlarına göre teşhis ve çözümler sunsun

Kurduğum Mimari

Yinelemeli ayarlamalardan sonra, sonunda bu teknoloji yığınını seçtim:

Sistem Mimarisi

Kubernetes Cluster → Prometheus Server → Alertmanager
↓
n8n Workflow ← OpenAI API ← Custom MCP Server
↓ ↓
Redis Cache Kibana Logs

Veri Akışı

Metrikler → Uyarı Kuralları → Uyarı Yönlendirme → İş Akışı Orkestrasyonu → AI Analizi → Küme Teşhisi → Otomatik Raporlar

Neden n8n Seçtim?

Başlangıçta doğrudan Python scriptleri yazmayı düşündüm, ancak n8n'in birkaç avantajı olduğunu keşfettim:

Açık Kaynak ve Ücretsiz: Lisans ücreti olmadan kendi sunucunuzda barındırabilirsiniz.
Görsel Orkestrasyon: Tüm işleme akışı net ve hata ayıklaması kolay.
Zengin Node'lar: Webhook, HTTP istekleri, AI çağrılarının hepsinin hazır node'ları var.
Kolay Genişletme: Yeni işleme mantığı eklemek sadece sürükle-bırak işlemi.
Ekip İşbirliği: Diğer meslektaşlar iş akışlarını anlayabilir ve değiştirebilir.

Neden Özel MCP Sunucusu Oluşturdum?

Piyasada mevcut bir Kubernetes MCP Sunucusu yoktu, bu yüzden kendim geliştirdim. Ana özellikler şunları içerir:

17 K8s Aracı: Temel kubectl get'ten gelişmiş kubectl top'a kadar.
Güvenlik Kontrolü: Yalnızca güvenli sorgulara ve sınırlı işlemlere (Deployment yeniden başlatma gibi) izin verir.
Çoklu Küme Desteği: AWS EKS ve diğerleri dahil birden fazla K8s kümesini aynı anda yönetebilir.
Çift Protokol Desteği: Hem n8n'in SSE'sini hem de diğer istemcilerin HTTP'sini destekler.

Ne Kadar İyi Çalışıyor?

Gerçek bir vaka ile göstereyim.

Vaka Çalışması: Uzun Süreli Pod NotReady

Geleneksel Yaklaşım:
1. SMS veya e-posta uyarısı al
2. Jump server'a giriş yap
3. İlgili kümeye geç
4. Sorun giderme için manuel olarak kubectl komutlarını çalıştır
5. Sonuçları analiz et, çözümler üret
6. Düzeltme işlemlerini uygula
7. Sorun çözümünü onayla
Yapay Zeka Akıllı İşleme:

Sistem bu uyarı JSON'ını aldığında:

{
  "alerts": [
    {
      "status": "firing",
      "labels": {
        "alertname": "KubePodNotReady",
        "cluster": "prod-cluster-***",
        "namespace": "production",
        "pod": "app-service-***",
        "severity": "warning"
      },
      "annotations": {
        "description": "Pod has been in a non-ready state for more than 10 minutes"
      }
    }
  ]
}

AI Sistemi Otomatik Olarak Şunları Yapar:

Adım 1: Anahtar Bilgileri Çıkar

Uyarı Tipi: KubePodNotReady Küme: prod-cluster-*** Namespace: production Pod Adı: app-service-***

Adım 2: Kontrol Stratejisini Seç

Uyarı tipine dayanarak, AI bunun bir "Pod Durum Sorunu" olduğunu bilir ve önceden ayarlanmış kontrol prosedürlerini izler.

Adım 3: Kontrol Komutlarını Çalıştır

# 1. Pod durumunu kontrol et
kubectl get pods -n production --show-labels -o wide
# 2. Durum anormalse, detaylı bilgi al
kubectl describe pod app-service-*** -n production
# 3. Gerekirse logları kontrol et
kubectl logs app-service-*** -n production --tail=20

Adım 4: AI Analizi ve Rapor Oluşturma

────────────────────────────────
🔧 K8s Alert Handler AI
🚨 KubePodNotReady - firing
Başlangıç Zamanı: 2025-01-15T10:30:00Z
Küme: prod-cluster-***
Bileşen: production/app-service-***
Hızlı Teşhis:
Pod NotReady durumunda, container 3 kez yeniden başlatıldı
Son yeniden başlatma zamanı: 5 dakika önce
Hata nedeni: Veritabanı bağlantı zaman aşımı
Analiz Sonucu:
Uygulama veritabanına bağlanamıyor, muhtemelen veritabanı servisi sorunları veya ağ problemleri nedeniyle
Önerilen İşlemler:
1. Veritabanı servis durumunu derhal kontrol edin
2. Servis ve Endpoint yapılandırmasını kontrol edin
3. Pod'u yeniden başlatmayı veya veritabanını ölçeklendirmeyi düşünün
4. Ağ politikalarını ve güvenlik duvarı kurallarını kontrol edin
────────────────────────────────

Tüm süreç 2–3 dakikada tamamlanır ve 7/24 kesintisiz çalışır!

Tasarladığım AI Mantığı

Bu sistemin çekirdeği AI'nın karar mantığıdır. Üretim ortamımızdaki çeşitli uyarıları ele almak için AI'nın sistem mesajını ince ayarlamak için çok zaman harcadım.

Desteklenen Uyarı Tipleri

Şu anda sistem, neredeyse tüm yaygın sorun senaryolarını kapsayan 45 farklı Kubernetes uyarısını akıllıca ele alabilir:

Küme Çekirdek Bileşen Uyarıları (10)

AlertmanagerClusterCrashlooping, AlertmanagerClusterDown
AlertmanagerClusterFailedToSendAlerts, AlertmanagerConfigInconsistent
AlertmanagerFailedReload, KubeAPIDown
KubeAPIErrorBudgetBurn, PrometheusBadConfig
PrometheusTargetSyncFailure, PrometheusRuleFailures

İş Yükü İle İlgili Uyarılar (12)

KubeDeploymentReplicasMismatch, KubeStatefulSetReplicasMismatch
KubePodCrashLooping, KubePodNotReady
KubeJobFailed, KubeHpaReplicasMismatch
KubeHpaMaxedOut, KubeHpaHighUtilization
KubeHpaFrequentScaling, KubeImagePullBackOff
KubeServiceEndpointsUnavailable, KubeConfigReloadFailed

Konteyner ve Kaynak Uyarıları (12)

KubeContainerOOMKilled
KubeContainerCPUNearLimit
KubeContainerMemoryNearLimit
KubeTooManyPendingPods
KubeCPUOvercommit
KubeMemoryOvercommit
KubeQuotaExceeded
KubeQuotaAlmostFull
CPUThrottlingHigh
NodeCPUHighUsage
NodeMemoryHighUtilization
NodeSystemSaturation

Node ve Depolama Uyarıları (10)

KubeletDown, KubeNodeNotReady
NodeFileDescriptorLimit, KubePersistentVolumeErrors
KubePersistentVolumeFillingUp, KubePersistentVolumeInodesFillingUp
KubeVolumeMountFailed, NodeFilesystemAlmostOutOfSpace
NodeFilesystemSpaceFillingUp, KubeStateMetricsDown

Sertifika ve İzleme Uyarıları (5)

KubeClientCertificateExpiration
KubeletClientCertificateExpiration
KubeletServerCertificateExpiration
KubeStateMetricsListErrors
Watchdog

Her uyarı tipinin karşılık gelen kontrol stratejileri vardır, AI uyarı tipine göre en uygun sorun giderme sürecini otomatik olarak seçer.

AI Karar Mantığı Tasarımı

1. Parametre Çıkarma Kuralları

AI'ya karmaşık JSON'dan anahtar bilgileri nasıl bulacağını söyleyin:

Çıkarılması Zorunlu: cluster, alertType (en önemlisi, yanlış olamaz)
İsteğe Bağlı Çıkarma: namespace, pod, container, deployment, vb.
Durum Yargısı: Durumun firing mi yoksa resolved mu olduğu

2. Sorun Sınıflandırma Mantığı

45 uyarıyı, her biri karşılık gelen kontrol stratejilerine sahip birkaç ana sınıfa ayırdım:

HPA Sorunları:
- Önce HPA durumunu, sonra Deployment'ı kontrol et
- Maksimum 2 kubectl çağrısı
Pod Sorunları:
- Önce Pod listesini kontrol et, sonra belirli Pod'u tanımla, gerekirse logları kontrol et
- Maksimum 3 kubectl çağrısı
Node Sorunları:
- Önce node listesini kontrol et, sonra belirli node'u tanımla
- Maksimum 2 kubectl çağrısı
Kaynak Sorunları:
- Kaynak kullanımını kontrol etmek için kubectl top kullan
- Maksimum 2 kubectl çağrısı

3. Hız Sınırı Koruması (Rate Limit)

Bu önemli! AI'nın API'yi bunaltmasını önlemek için her uyarıyı maksimum 3 kubectl komutuyla sınırlıyorum.

Strateji:
- İlk sefer: Birleşik sorgu, genel bilgileri bir kerede al
- İkinci sefer: Hedefli tanımlama, sorunlara derinlemesine bakış
- Üçüncü sefer: Log görüntüleme veya diğer tamamlayıcı bilgiler

4. Akıllı Atlama Mantığı

İlk kontrol durumun normal olduğunu bulursa, sonraki derin kontroller yürütülmez, kaynak tasarrufu sağlanır.

Karşılaştığım Tuzaklar

Tuzak 1: AI "Aşırı Düşünmeye" Meyilli

Başlangıçta Rate Limit olmadan, AI genellikle düzinelerce komut yürüterek K8s API'sini bunaltıyordu. Daha sonra sınırlar ekleyerek, sınırlı çağrı sayıları içinde teşhisi tamamlamaya zorladım.

Tuzak 2: Uyarı Adı Karışıklığı

Alertmanager JSON hem alertname hem de summary alanlarına sahiptir, AI bazen kafası karışır. Sistem mesajında alertname kullanmayı özellikle vurguladım.

Tuzak 3: Küme Kimlik Doğrulama Sorunları

Birden fazla GKE kümemiz ve Amazon EKS kümelerimiz var, her birinin farklı kimlik doğrulama yöntemleri var. Sonunda MCP Sunucusuna otomatik kimlik doğrulama mantığı ekledim, böylece AI'nın bu ayrıntıları ele alması gerekmiyor.

Tuzak 4: Yetersiz Hata İşleme

Başlangıçta kubectl komut hatalarını dikkate almadım, genellikle izin veya ağ sorunları nedeniyle takılıyordu. Daha sonra tam hata işleme ve yeniden deneme mekanizmaları ekledim.

Gerçek Performans Sonuçları

3 aylık operasyondan sonra sonuçlar oldukça iyi:

Veri Karşılaştırması

Uyarı İşleme Süresi: Ortalama 20 dakikadan 3 dakikaya düştü
Gece Müdahalesi: 7/24 otomatik işleme, artık gece yarısı uyanmaları yok
Yeni Çalışan Eğitimi: Yeni meslektaşlar öğrenmek için doğrudan AI teşhis raporlarına başvurabilir
İşleme Doğruluğu: Yaygın sorunların %90'ı doğru teşhis yönünü alıyor

Bu sistem, Docker konteynerleri ve orkestrasyon sorunlarıyla uğraşırken verimliliğimizi önemli ölçüde artırdı. Jenkins veya diğer CI/CD araçlarını kullanıyor olun, AI'yı izleme yığınıza entegre etmek oyunun kurallarını değiştirir.