Headlamp Knative Eklentisi: Serverless’ı Görsel Takip

Knative’i uzun süredir kullananların malum bir sıkıntısı var: bir şeyi anlamak için üç dört pencere arasında gidip geliyorsunuz. Bir yanda kn ile revizyonlara bakıyorsunuz, bir yanda kubectl describe ile pod durumunu kurcalıyorsunuz, öte tarafta da tarayıcıda dashboard açık dürüyor; yanı işin özü biraz dağılıyor, trafik niye yeni revizyona gitmiyor, autoscaler niye fazla gazlıyor gibi soruların cevabı tek yerde durmuyor.

İtiraf edeyim, Neyse. Kubernetes ekibi geçen gün Headlamp için Knative eklentisini duyurdu ve ilk bakışta küçük duran bu haber, aslında serverless işini Kubernetes üzerinde baya rahatlatıyor. Tahmin eder mısınız? LFX mentorluğu kapsamında geliştirilen bu eklenti, KService’ten Revision’a kadar Knative CRD’lerini Headlamp’in alışık olduğumuz arayüzüne taşıyor.

Durun, bir saniye.

Ben bu yazıda hem eklentinin ne getirdiğini anlatacağım hem de sahada Knative’e bakan biri olarak “bu araç günlük hayatı değiştirir mi?” sorusuna cevap arayacağım. Açık konuşayım, bazı yerleri baya hoşuma gitti, bazı yerlerde işe “hmm, burası hâlâ biraz ham” dedim.

Knative ve Headlamp: Kısaca Kim Kimdir?

Konuya dalmadan önce bir saniye duralım. Belki Headlamp’i hiç denemediniz. Headlamp, CNCF/Kubernetes SIĞ çatısı altında geliştirilen açık kaynak bir UI; yanı sıradan bir “bir dashboard daha” değil, genişleyebiliyor, eklenti alabiliyor ve hem web hem masaüstü olarak çalışıyor (buna dikkat edin). Daha önce Headlamp Cluster API Eklentisi: CAPI Artık Görsel Arayüzde yazımda benzer bir eklenti yapısını incelemiştim, oradaki mantık burada da aynen geçerli.

Knative işe Kubernetes üzerinde serverless çalıştırmanın en oturmuş yollarından biri (buna dikkat edin). İki ana parçası var: Serving (HTTP tabanlı iş yükleri, otomatik ölçekleme, trafik yönetimi) ve Eventing (event-driven mimarı). Bu eklenti şimdilik ağırlığı Serving tarafına veriyor — ki günlük operasyonda zaten en çok gözümüzün takıldığı kısım tam burası.

Kısa bir not düşeyim buraya.

Peki neden bir UI’a ihtiyaç duyuyoruz?

Araya gireyim: Şöyle söyleyeyim: kn service describe çıktısını okumak ayrı bir hüner. YAML içinde traffic: altında 3-4 tag varsa, hangisinin nereye aktığını terminalde çözmek göz yoruyor; üstüne bir de config-autoscaler ConfigMap’ını açıp cluster default’larıyla kıyaslamaya kalkınca insan biraz dağılıyor. İşin aslı şu: Knative baya işe yarıyor (yanlış duymadınız). Observability tarafında hâlâ CLI’a yaslanıyoruz. Bu eklenti tam da o boşluğu doldurmaya çalışıyor.

Map View: Kaynaklar Arasındaki Bağı Görmek

Bence Headlamp’in en kullanışlı taraflarından biri map view idi zaten. Yanı kaynakların birbirine nasıl bağlandığını graf şeklinde gösteren ekran. Yeni eklenti bunu Knative CRD’lerine de taşımış: KService, Revision, DomainMapping, Route, Configuration… E peki, sonuç ne öldü? hepsi tek grafın içinde dolaşıyor.

Bunun neden önemli olduğunu bir örnekle anlatayım. Diyelim ki müşteri gelip “yeni deploy ettiğim bir düşüneyim… revizyon canlıya çıkmıyor” dedi. Klasik yol belli: kn revision list, ready mi bak, kn route describe, trafik yüzdesini kontrol et, sonra kubectl get pods, container ayakta mı diye yokla. Map view’da işe bunların üçünü aynı ekranda görüyorsunuz; hangi revizyona kaç yüzde trafik gittiğini oklarla, pod’ların durumunu da renklerle takip edebiliyorsunuz.

Çok konuştum, örnekle göstereyim.

Küçük bir not düşeyim: graf çok büyük cluster’larda karışmaya başlıyor. 50+ KService varsa filtreleme şart oluyor. Umarım sonraki sürümlerde namespace bazlı odaklanma daha iyi hâle gelir.

KService Yönetimi: Edit Mode Gerçekten İşe Yarıyor mu?

Dürüst olmak gerekirse, KService, Knative’in en üst seviye kaynağı. Route da bunun altında kalıyor, Configuration da, Revision da; yanı merkez burası. Eklentinin en dikkat çeken tarafı burada devreye giriyor: Edit Mode. Sayfada bir toggle var; açınca trafik yüzdelerini, autoscaling annotation’larını ve tag’leri arayüzden değiştirebiliyorsunuz. YAML’a girmeden iş bitiyor.

Burada küçük bir parantez açmam lazım. UI üzerinden production kaynağını düzenlemek çoğu zaman “hayır kardeşim GitOps yap” tepkisi alır; haklılık payı da var (ben de ilk duyduğumda şaşırmıştım). Ama pratikte şöyle bir gerçek çıkıyor karşınıza: acil durumda trafiği %10’dan %0’a çekmek için PR açıp merge beklemek 10 dakikayı bulabiliyor ve o 10 dakikada müşteri tarafında tatsızlık çıkabiliyor. Yanı Edit Mode aslında break glass senaryoları için mantıklı; kalıcı işi yine GitOps ile yürütürsünüz.

Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.

Header’da sık kullanılan aksiyonlar da dürüyor: YAML görüntüle, log aç, yeniden deploy tetikle, pod restart et. Bunların hepsi RBAC izinlerinize göre filtreleniyor; yanı custom rol tanımlı kullanıcıda yetki yoksa buton zaten görünmüyor bile. Bu detay hoşuma gitti açıkçası.

Trafik Yönetimi: Canary ve A/B Testi İçin Görsel Kontrol

Sorun genelde burada başlıyor ya da düzeliyor diyelim (inanın bana). Knative’in en sevdiğim yanı trafik yönetimi; aynı servisin farklı revizyonları arasında yüzde bazlı dağıtım yapabiliyorsunuz. Canary release var, gradual rollout var, tagged preview URL var, A/B test var (ben de ilk duyduğumda şaşırmıştım). hepsi mümkün ama YAML içinde bunları idare etmek açık konuşayım biraz yorucu.

Eklentide her Revision için şu bilgiler tek tabloda görünür:

Edit mode açıkken yüzdeleri satır içinde değiştirebiliyorsunuz. Toplamın 100 olmasını ve tag’lerin benzersiz kalmasını arayüz doğruluyor; kaydetmeden önce hata varsa önünüze çıkarıyor. Bu da YAML’da elle yüzde toplamaya çalışırken yapılan klasik saçmalıkları büyük ölçüde azaltıyor.

Küçük ama can sıkan bir detay: Tag’li URL’ler

Bak şimdi, tag’li route’lar (mesela canary-my-service.example.com) DomainMapping ya da ingress tarafında düzgün ayarlanmadıysa eklentide URL boş görünebiliyor. Bu eklentinin hatası değil; cluster ayarunun yansıması sadece. Ama yeni başlayan biri için kafa karıştırıcı olabilir doğrusu. Bir tooltip olsa fena olmazmış.

Austoscaler Ayarları: Efektif Değeri Görebilmek Önemli mi?

Evet, önemliymiş meğer. Knative’de autoscaler ayarları hem KService seviyesindeki annotation’lardan hem de cluster-wide ConfigMap’lerden (config-autoscaler ve config-defaults) geliyor; yanı bir workload’un efektif ayarı ikisinin birleşimi oluyor.

Sahada en sık gördüğüm dert tam olarak bu zaten. Ekipler bir KService’e autoscaling.knative.dev/target: "50" yazıyor sonra “beklediğim gibi ölçeklemiyor” diye dönüyorlar bana. Bakıyoruz ki cluster-wide default başka bir metric’e göre ayarlanmış (concurrency yerine rps mesela), dolayısıyla annotation ile ConfigMap birbirini pek dinlemiyor.

Eklenti burada baya düzgün iş çıkarıyor: her KService için dahilî/efektif konfigürasyon‘u gösteriyor ve hangi değerin nereden geldiğini açıkça ayırıyor. Bunu YAML’da gözle bulmak bazen dakikalar sürer; burada işe direkt önünüzde dürüyor.

# Örnek annotation seti
autoscaling.knative.dev/class: "kpa.autoscaling.knative.dev"
autoscaling.knative.dev/metric: "concurrency"
autoscaling.knative.dev/target: "80"
autoscaling.knative.dev/min-scale: "1"
autoscaling.knative.dev/max-scale: "20"
autoscaling.knative.dev/scale-down-delay: "3m"

Bunları arayüzde gördüğünüzde hangi ayarın cluster default’tan farklı olduğunu vurguluyor. Küçük gibi dürüyor ama debug sürecini ciddi hızlandırıyor (inanın bana)

Pekii Prometheus Entegrasyonu Ne Durumda?

İlginç olan şu ki, Eğer Headlamp’in Prometheus eklentisi kuruluysa, Knative eklentisi de otomatik şekilde KService. Revision sayfalarında request rate, latency ve resource utilization grafiklerini çiziyor. Yanı ayrı Grafana açmadan sağ panelde revizyon bazlı p50/p95 latency görmek mümkün oluyor.

Ama şunu peşinen söyleyeyim: Prometheus eklentisi yoksa bu grafikler bomboş kalır. Bir de Prometheus’u cluster’a kurmak ve doğru servisleri scrape edecek şekilde ayarlamak ayrı uğraş; yanı “kurdum öldü” diye düşünmeyin sakın. Küçük ekiplerde Azure Monitör ya da benzeri managed çözümler bu tarafta hâlâ daha az emek istiyor olabilir.

Tam Türkiye Gerçeği: Serverless Adaptasyonu Nasıl Gidiyor?

Sahada gördüğüm kadarıyla Türkiye’de Knative benimsenmesi biraz farklı akıyor. AWS Lambda ya da Azure Functions gibi managed serverless çözümler daha popüler; kurumlar genelde “kendi serverless platformumuzu Kubernetes üzerinde kuralım ve yöneteceğiz” fikrine sıcak bakmıyorlar çünkü operasyon yükü hemen kapıya dayanıyor.

Zaten mesele de orada çıkıyor ortaya: Knative önce Kubernetes istiyor, üstüne Istio ya da Kourier gibi networking katmanı istiyor, üstüne Prometheus istiyor, üstüne autoscaler tuning istiyor… Kağıt üstünde serverless kolay görünüyor ama altyapı ekibinin harcadığı emek hiç de az değil yanı. İşte böyle anlarda Headlamp Knative eklentisi gibi araçlar operasyon yükünü hafifletip adaptasyonu artırabiliyor; görsel araç olmayan platform ne kadar yetenekli olsa da yayılmakta zorlanıyor.

Küçük ekip mi daha rahat eder, kurumsal mı?

İtiraf edeyim, Ayrımı net yapalım:

• Küçük ekip / startup:: Eğer 5 kişilik bir ekipseniz Knative + Headlamp kombinasyonu cloud provider’ın managed serverless çözümüne göre daha masraflı kaçabilir. Cloud lock-in kaygınız yoksa Functions/Lambda tarafında kalın derim; enerjinizi ürüne verin.
• Orta ölçek:: Zaten Kubernetes’ınız varsa ve birkaç iş yükünü serverless pattern’iyle koşturuyorsanız Knative + bu eklenti gayet mantıklı dürüyor. Görsel yönetim ekip verimini hissedilir şekilde artırır.
• Kurumsal / regüle sektör:: On-prem zorunluluğunuz varsa ya da veri egemenliği kritikse Knative zaten seçeneklerden biri oluyor ister istemez; bu eklenti sizin için opsiyonel değil, günlük operasyonun parçasına dönüşür.

Serverless’ın gerçek maliyeti kod yazmak değil; o kodu doğru gözleyip yönetmektir.
Bir UI bazen altyapı ekibinin ayda kazandığı 10-15 saati rahat rahat ikiye katlayabiliyor.

Peki Kurulum Nereden Başlıyor?

Eklentiyi denemek istiyorsanız ilk adımlar kabaca şöyle:

1. Pazarlamadan falan bağımsız olarak Headlamp’i cluster’a kurun (Helm chart veya desktop app olarak).
2. `kubectl get pods -n knative-serving` ile Knative Serving’in yüklü ve çalışır durumda olduğunu kontrol edin.
3. .Headlamp plugin katalogundan Knative eklentisini aktif edin.
4. .İsteğe bağlı olarak Prometheus eklentisini de kurun; grafikler için buna ihtiyaç duyuyorsunuz.
5. .Bir test KService deploy edin ve map view’da görünüyor mu bakın.
   

   Sıkça Sorulan Sorular

   Headlamp Knative eklentisi ücretli mi?

   Hayır, hiç öyle bir şey yok. Headlamp zaten CNCF ekosisteminde açık kaynak, Knative eklentisi de aynı şekilde ücretsiz ve açık kaynak. Aslında tek ödediğiniz şey cluster kaynaklarınızın maliyeti.

   Knative kurmadan bu eklentiyi kullanabilir mıyım?

   Hayır, mümkün değil. Eklenti Knative CRD’lerini okuyor, yanı cluster’da Knative Serving yüklü değilse KService, Revision gibi kaynakları bulamıyor ve boş kalıyor. Önce Knative Serving kurulumunu halletmeniz gerekiyor (şaşırtıcı ama gerçek)

   Bu eklenti Azure Container Apps için de çalışır mı?

   Doğrudan hayır. Azure Container Apps arka planda Knative kullanıyor,. Managed servis olduğu için altındaki KService kaynaklarına erişim vermiyor. Bence bu biraz can sıkıcı bir kısıt, hani her şeyi görüp kontrol etmek istiyorsunuz. Yönetilen servis o kapıyı kapatıyor. Bu eklenti kendi yönettiğiniz Knative kurulumları için tasarlanmış. ACA’da benzer görünürlük istiyorsanız Azure Portal ve Log Analytics ikilisi hâlâ ana yolunuz.

   Production’da Edit Mode’u kapatmak mümkün mü?

   Doğrudan bir toggle yok. Ama RBAC ile aynı sonucu alıyorsunuz, mesela kullanıcıya sadece read izni verirseniz Edit Mode butonları zaten görünmüyor. Tecrübeme göre break glass senaryoları için ayrı bir admin rolü tanımlamak en temiz yöntem.

   Prometheus eklentisi olmadan grafik gösteren alternatif var mı?

   Ne yalan söyleyeyim, Şu an yok açıkçası. Eklenti metrik verisi için Prometheus’a bağımlı. Managed Prometheus da kabul edilebilir, yanı mesela Azure Monitör managed Prometheus gibi çözümler de işe yarıyor,. Headlamp Prometheus eklentisinin desteklediği endpoint yapısına uygun olması şart.

   Kaynaklar ve İleri Okuma

   Kubernetes Blog: Introducing the Headlamp plugin for Knative

   Headlamp Resmî Sitesi ve Dokümantasyon

   Knative Resmî Dokümantasyonu

   Headlamp Plugins GitHub Repo (evet, doğru duydunuz)

Aşkın KILIÇYazar

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.

AZ-305AZ-104AZ-500AZ-400DP-203AI-102

İlgili Yazılar

Azure Cosmos DB’de Partition Key Değiştirmek: Artık Daha Az Acı Veriyor10 Haz 2026

Java OpenJDK Nisan 2026 Güncellemesi: Bellek, Güvenlik ve Sürprizler5 May 2026

Diff Satırlarını Hızlandırmak: Büyük PR’larda Sınır Nerede?5 Nis 2026

Kubelet API Yetkilendirmesi GA Oldu: Güvenlik Devrimi26 Nis 2026