Headlamp Cluster API Eklentisi: CAPI Artık Görsel Arayüzde

Cluster API ile uğraşan varsa bilir. İşin büyük kısmı kubectl get, kubectl describe ve bir de kafada tuttuğunuz sahiplik zinciriyle geçiyor; “Bu Machine hangi MachineSet’e bağlıydı, o da hangi MachineDeployment’ın altındaydı, bootstrap config’i nerede tanımladık?” diye dönüp duruyorsunuz, sonra YAML çıktılarının arasında küçük bir iz sürme oyunu başlıyor. Pek keyifli değil, açık konuşayım.

İşte Headlamp ekibi bu dertle biraz uğraşmış. Cluster API plugin adında yeni bir eklenti yayınladılar. CAPI kaynaklarını görsel tarafta yönetmeyi mümkün kılıyor. Kısa süre önce Headlamp’e Volcano Eklentisi: Batch İşlerini Tek Ekranda İncele yazısında Headlamp’in eklenti mimarisinden bahsetmiştim; şimdi aynı yaklaşımın CAPI tarafına da uzandığını görüyoruz, güzel tarafı şu ki ekran kalabalığı azalıyor ama işin mantığı yine yerinde dürüyor. Evet.

Lafı gevelemeden anlatayım — bu eklenti bence Kubernetes platform ekipleri için baya iş görüyor. Ama dur bir saniye, her yeni araçta olduğu gibi burada da eksik kalan yerler var. Sihirli değnek değil, sadece operasyonu biraz daha okunur hâle getiriyor. Aşağıda hem ne getirdiğini hem de sahada nasıl kullanılır önü konuşalım.

Cluster API neden dertli bir konu?

Cluster API, Kubernetes cluster’larını yine Kubernetes mantığıyla (declarative, CRD tabanlı) yönetmenizi sağlayan bir alt proje. Yanı elinizde bir management cluster oluyor, oradan başka cluster’ları YAML manifestleriyle doğuruyor, yükseltiyor, ölçekliyorsunuz. Fikir temiz, hatta ilk bakışta baya iş görüyor.

İşte tam da bu noktada devreye giriyor.

Pratikte işe işler biraz dallanıp budaklanıyor. Bir Cluster objesi var, altında KubeadmControlPlane, onun altında Machine‘ler, bir tarafta MachineDeployment, onun altında MachineSet, altında yine Machine‘ler, bir de MachinePool‘lar, sonra InfrastructureRef‘ler, BootstrapRef‘ler… İnsan bir noktada “dur bir dakika, ben şu an neye bakıyorum” demeye başlıyor. Evet.

Kendi deneyimimden konuşuyorum, Sahada bunu şöyle sık görüyorum: Bir MachineDeployment ölçekleniyor ama beklenen node ayağa kalkmıyor (ben de ilk duyduğumda şaşırmıştım). Sebebi? Bootstrap tarafında bir KubeadmConfig hatası. Ama bunu bulmak için 4-5 farklı kaynağı describe‘lamak, condition’ları okumak, event’lere bakmak lazım; yanı terminalde oturup tek tek iz sürüyorsunuz, kolay değil. Açık konuşayım, ilk kez gören biri için biraz göz korkutuyor.

Görselleşmenin değeri nerede?

İlginç olan şu ki, Şimdi burada bir parantez açayım. Bazı arkadaşlar “biz. clusterctl describe cluster ile ağaç yapısını görüyoruz, ne gerek var UI’ya?” diyebilir. Haklılar bir yere kadar. Ama iş platform ekibinde 10-15 kişiye yayılınca, herkesin CLI ile aynı rahatlıkta çalışması beklenemez; SRE’ler terminalde uçuyor olabilir,. Uygulama ekibindeki bir developer’a “şu cluster ayakta — en azından ben öyle düşünüyorum — mı hâlâ” dedirtmenin en kısa yolu çoğu zaman basit bir dashboard oluyor (buna dikkat edin). Bakın, peki neden?

Durun, bir saniye.

Bence asıl mesele hız değil sadece. Bir ekranın üstünde ilişkileri görüyorsanız, hata da daha çabuk göze çarpıyor (özellikle bootstrap ile infrastructure tarafı birbirine girdiğinde), yoksa komut üstüne komut atıp sonunda “ha tamam sorun şuradaymış” diyorsunuz. Şey gibi; teknik olarak her şey dokümanda yazıyor ama insan gözü bazen düz metinden daha hızlı yakalıyor (şaşırtıcı ama gerçek)

Neyse uzatmayayım, konunun özü şu: Cluster API güçlü ama katman sayısı arttıkça okunabilirlik düşüyor. Bu yüzden görselleştirme çoğu ekipte lüks değil, baya ihtiyaç oluyor. Şimdi, sız ne dersiniz?

Eklenti tam olarak ne getiriyor?

Headlamp’e “Cluster API” diye yeni bir bölüm ekliyor bu eklenti. Oradan bakınca temel CAPI kaynaklarının hepsini liste. Detay görünümüyle tek yerde görebiliyorsunuz; ama işin aslı sadece “liste göstermek” değil, condition’ları, sahiplik hiyerarşisini ve topoloji ilişkilerini gözün önüne sermesi. Kıymetli tarafı biraz burada, yanı.

Özellikleri madde madde toparlarsam:

• Cluster overview: Cluster’ların canlı control plane ve worker replica durumunu gösteriyor
• Machine görünürlüğü: MachineDeployment, MachineSet, Machine ve MachinePool’ları status/condition’larıyla birlikte görüyorsunuz
• CAPI dashboard: Kaynak sağlığı, aktif sorunlar, provider bilgisi ve iyileştirme önerilerini bir arada veriyor — ciddi fark yaratıyor
• Control plane izleme: KubeadmControlPlane replica’larını, versiyonlarını ve bağlı Machine’leri takip edebiliyorsunuz
• UI’dan ölçekleme: MachineDeployment ve MachineSet’leri doğrudan Headlamp içinden scale edebiliyorsunuz
• Owned resource hiyerarşisi: Cluster -> Deployment -> Set -> Machine ilişkisini izlemek baya kolaylaşıyor (bence en önemlisi)
• KubeadmConfig inceleme: Bootstrap config’leri, dosyalar, kubelet argümanları, join/init ayarlarını tek ekranda görüyorsunuz
• Topology farkındalığı: ClusterClass ile yönetilen kaynakları otomatik etiketleyip ayırıyor
• Map view: Cluster, control plane ve worker ilişkilerini görsel harita gibi sunuyor (bence en önemlisi)
• Dinamik API versiyonlama: Hem v1beta1 hem v1beta2 destekleniyor; eski-yeni karışınca çok can sıkmıyor açıkçası
• Prometheus metrikleri: Headlamp Prometheus eklentisi kuruluysa, kaynak detay sayfasında inline metrikler de geliyor — bunu es geçmeyin

Evet. Daha fazla bilgi için Pure Virtual C++ 2026 Konuşmaları Açıklandı: Program Belli yazımıza bakabilirsiniz.

Garip gelecek ama, Bu son madde bence en tatlı olanı. Bir Machine’e tıkladığınızda hem YAML’ını hem condition’ını hem de altında canlı CPU/RAM grafiğini görmek var ya, bunu eskiden Grafana sekmeleri arasında gidip gelerek yapıyorduk; şimdi tek ekran oluyor. Küçük gibi dürüyor ama gün sonunda ciddi vakit kazandırıyor.

Tuhaf ama, Peki neden?

Açık konuşayım, çünkü operasyonda en sınır bozucu şey parçalı görüntü. Bir yerde status var, başka yerde — ki bu tartışılır — event var, öbür tarafta topology var; sonra sız kafada birleştirmeye çalışıyorsunuz. Bu eklenti o dağınıklığı biraz toparlıyor — kusursuz mu? Değil. Ama iş görüyor mu? Evet, bayağı iş görüyor.

Tam da öyle.

Dashboard nasıl bir şey?

Dashboard, management cluster’ınızın CAPI tarafındaki genel sağlığını topluca gösteriyor. Kısacası tek ekranda bakıp geçiyorsunuz; cluster’ların, Machine’lerin, MachineDeployment’ların, MachinePool’ların, MachineSet’lerin ve control plane’lerin durumunu bir araya getiriyor. Güzel tarafı bu, ama dur bir saniye — iş sadece listelemek değil, biraz da neyin ters gittiğini sezdiriyor (inanın bana)

Bir cluster’a tıkladığınızda daha derin bir sağlık görünümü açılıyor (bu beni çok şaşırttı). Control plane. Worker durumu, machine bilgileri, altyapı detayları ve resource condition’ları orada karşınıza çıkıyor; sorun tespit edildiğinde — ki CAPI’de sorun çıkması pek şaşırtıcı değil, açık konuşayım — dashboard size remediation guidance yanı iyileştirme önerileriyle diagnostic komutları da veriyor. Bu kadar mı? Değil, çünkü bazen doğrudan nereden başlayacağınızı bile söylemesi baya iş görüyor.

İşte tam da bu noktada devreye giriyor.

Bir Machine’in NodeHealthy condition’ı False dönmüşse, dashboard size hem sebebi (mesela KubeletNotReady) hem de yapabileceğiniz kubectl komutlarını gösteriyor. Junior bir SRE için bu bir öğrenme aracı bile diyebilirim.

Map view — bence en çok konuşulacak özellik

Açık konuşayım, Burada işin rengi değişiyor. Cluster, control plane. Worker ilişkilerini gösteren bir harita görünümü var; özellikle karmaşık topolojilerde (birden fazla failure domain, farklı infrastructure provider’lar, MachinePool ile MachineDeployment’ın iç içe geçtiği senaryolar) gerçekten eli yüzü düzgün dürüyor (inanın bana). YAML’a bakıp kafanızda ağacı kurmaya çalışıyorsunuz ya, işte önü grafik olarak önünüze seriyor; hani bazen “nerede kopmuş bu zincir” diye düşünürsünüz, tam o noktada işe yarıyor.

Şunu fark ettim: Sadece şunu söyleyeyim: Çok büyük cluster’larda (yüzlerce Machine olduğunda) map view performansını ben henüz tam sınamadım. Kâğıt üstünde iyi görünüyor, pratikte işe biraz bekleyip görmek lazım; %100 doğru olmayabilir ama ilk izlenim fena değil. Sız ne dersiniz?

Evet.

Türkiye’deki durum: kurumsal ekipler için ne anlama geliyor?

Burada biraz yerel taraftan bakmak lazım, çünkü CAPI’nın Türkiye’de yayılışı Batı’daki kadar düz gitmedi. Türk kurumsal ekipleri Kubernetes’i çoğunlukla AKS, EKS gibi managed servislerle alıyor; açık konuşayım, “management cluster kurup ondan cluster üretmek” fikri işe daha çok belli bir olgunluğa gelmiş platform ekiplerinde konuşuluyor. Peki neden? Çünkü işin içinde hem operasyon yükü var hem de ekiplerin alışkanlıkları, yanı mesele sadece teknoloji değil.

Ne zaman ihtiyaç doğuyor, derseniz? Şey, birkaç senaryo hemen öne çıkıyor. Kendi veri merkezinde (bare metal ya da vSphere üstünde) çok sayıda Kubernetes cluster çalıştıran kamu ve finans kurumları var; bir de multi-tenant SaaS tarafı var ki her müşteriye izole cluster veren ekipler burada baya uğraşıyor. Edge ya da şube ağı üzerinde onlarca küçük cluster işleten perakende ve telekom ekiplerini de unutmayalım. E sonra? İş büyüyünce tablo değişiyor.

1. Kendi veri merkezinde (bare metal veya vSphere üzerinde) çok sayıda Kubernetes cluster çalıştıran kamu/finans kurumları
2. Multi-tenant SaaS platformları — her müşteriye izole cluster verenler
3. Edge / şube ağı üzerinde onlarca küçük cluster işletenler (perakende, telekom)

Hani, Bu senaryolardaki ortak dert şu: CAPI fena değil, ama görünürlük kısmı biraz zayıf kalıyor. Yönetim cluster’ında 40 tane workload cluster varsa, bunların her birinin sağlığını CLI’dan tek tek kovalamak ekibi yoruyor; uzun uzun bakınca insanın kafası dağılıyor, kısa cevap vereyim: zor iş. İşte Headlamp’in CAPI eklentisi tam bu boşluğu dolduruyor (ve bunu yaparken şaşırtıcı biçimde sade kalıyor), bir yönetici gelip “bugün cluster’lar nasıl” dediğinde ekrana dashboard açıp gösterebilmek sanılandan daha kıymetli oluyor. Daha fazla bilgi için .NET 8 ve.NET 9 İçin Son Tarih: 10 Kasım 2026 yazımıza bakabilirsiniz. Daha fazla bilgi için Gemini 2.5 Pro ve Gemini 3 Flash Copilot’tan Çıkıyor yazımıza bakabilirsiniz.

Evet.

Kurulum ve ilk adımlar

Bi saniye — Eklentiyi kurmadan önce Headlamp’in kendisi lazım, bu kısmı atlayınca tabiî iş yürümüyor. Headlamp’i ister masaüstünde Electron uygulaması olarak kullanın, ister Kubernetes içine deploy edin; ben çoğu zaman production yönetim cluster’larında in-cluster kurulumu seçiyorum, çünkü RBAC tarafı daha toparlanmış oluyor ve SSO entegrasyonu da biraz daha az uğraştırıyor. Git’te NTLM Kapanıyor: Azure DevOps Server İçin Kritik Uyarı yazımızda bu konuya da değinmiştik.

Basit bir kurulum akışı:

# Headlamp'i Helm ile kur
helm repo add headlamp https://kubernetes-sigs.github.io/headlamp/
helm repo update
helm install headlamp headlamp/headlamp --namespace headlamp --create-namespace
# Cluster API eklentisini yükle
# Headlamp Plugin Catalog üzerinden veya
# manuel olarak plugin dizinine kopyalayarak
# CAPI provider'ları yüklü değilse
clusterctl init --infrastructure aws # veya azure, vsphere, docker...

Eklenti yüklendikten sonra Headlamp’i yeniden başlattığınızda sol menüde “Cluster API” bölümü beliriyor. Belirmiyorsa, burada ilk bakacağım yer RBAC olur. Bu ne anlama geliyor? Kullanıcının en azından cluster.x-k8s.io API grubuna okuma yetkisi olması gerekiyor, yoksa arayüz sessizce bozulmuş gibi davranıyor (en azından benim deneyimim böyle)

RBAC — küçük ama önemli bir not

Scale butonuna basacaksanız machinedeployments/scale ve machinesets/scale yetkileri de lazım. Sadece read verirseniz UI’da düğme görünür, sonra tıklayınca hata alırsınız; hani dışarıdan bakınca her şey tamam gibi durur. Içeride eksik izin yüzünden patlar. Açık konuşayım, kullanıcıyı böyle yarı yolda bırakmamak için custom bir ClusterRole tanımlamak en temiz yol oluyor.

Karşılaştırma: CLI mi, UI mi, yoksa ikisi de mi?

Yanı ikisi de yerinde. Ben production’da clusterctl‘i bırakmam, ama debugging ve day-2 operations için Headlamp yanımda olsun isterim. Cosmos DB Built-in Connector for Logic Apps Standard GA Oldu yazımızda bu konuya da değinmiştik.

Startup vs Enterprise — hangi ölçekte anlamlı?

Küçük bir startup’sanız ve tek bir cluster ile dönüyorsanız, açık konuşayım, CAPI tarafına çoktan dalmamış oluyorsunuz. AKS/EKS işinizi görüyor. Bu eklenti? Biraz fazla kaçıyor.

Araya gireyim: Ama orta-büyük bir kurumsal yapıdaysanız — özellikle 5+ cluster yönettiğiniz, ekipte 3+ platform mühendisi olduğu bir yerdeyseniz — bu eklenti günlük işi baya hafifletiyor. Terminal’de saat harcayan mühendislerin eli rahatlıyor, kafa da biraz boşalıyor; zaman = para kısmı klişe gibi dürüyor ama burada gerçekten oturuyor.

Bir de işin AI tarafı var. Kubernetes ekosisteminde bu işlerin hızlandığını Kubernetes AI Politikası: Açık Kaynak Sürdürücülüğü Yeni Çağda yazısında anlatmıştım, orada da değinmiştim zaten. Yakın zamanda bu tip UI eklentilerinin AI destekli teşhis motorlarıyla birleşmesi bence hiç şaşırtıcı olmayacak — mesela “bu cluster neden unhealthy” diye sorduğunuzda condition’ları didik didik eden bir asistan çıkarsa, kimse dönüp bakmaz bile. Headlamp de o tarafa doğru küçük küçük ilerliyor.

Eksik bulduğum yanlar

Her şey güllük gülistanlık değil tabiî. Birkaç not düşeyim:

• Multi-management-cluster desteği: Birden fazla yönetim cluster’ı olan ekiplerde tablo biraz dağınık kalıyor. Context değiştirmeniz gerekiyor, yanı tek ekranda akıp giden bir deneyim yok; açık konuşayım, burada hâlâ iş var. (bence en önemlisi)
• ClusterClass düzenleme: Detaylı ClusterClass template’lerini görebiliyorsunuz, bu iyi. Ama in-place düzenleme tarafı biraz ham kalmış, hani insan bakınca “olmuş ama tam olmamış” diyor. (bence en önemlisi)
• Audit log entegrasyonu: UI’dan scale ettiğinizde bunun kim tarafından yapıldığı Kubernetes audit log’una düşüyor tabiî. Yine de Headlamp içinde bir operation history alanı olsa fena olmazdı, çünkü sonra dönüp bakarken insanın eli daha rahat ediyor.

Burada, garip gelecek ama, Bunlar zamanla gelir muhtemelen. Proje aktif geliştiriliyor, GitHub’daki issue akışına bakınca ekibin geri bildirime hızlı yanıt verdiğini görüyorsunuz; hatta bazen şaşırdım açıkçası, çünkü tempo idare eder değil baya canlı.

Aksiyon önerisi: Denemek isteyene 3 adım

1. Bir test/dev management cluster’ınız yoksa, kind ile local’de bir tane ayağa kaldırın; sonra clusterctl init --infrastructure docker ile CAPI’yi kurun. Yanı işin temelini atmak için 15 dakika falan yeter, abartmıyorum.
2. Headlamp’i desktop uygulaması olarak indirin, cluster’ınıza bağlayın. Basit dürüyor, ama ilk bağlantıda insan biraz “tamam da şimdi ne olacak” diye düşünüyor.
3. Plugin Catalog’dan Cluster API eklentisini kurun ve bir MachineDeployment oluşturup UI’dan scale etmeyi deneyin. Evet, burası biraz oyuncak gibi geliyor; ama aslında en hızlı fikir veren kısım da bu oluyor.

Bence, Bu üç adımdan sonra “kendi ekibimize kurar mıyız” kararını çok daha net verebilirsiniz. Hatta bazen cevap beklediğinizden farklı çıkıyor,. Ekran güzel diye değil, gerçekten operasyonu hafifletiyor mu ona bakınca tablo değişiyor.

Sıkça Sorulan Sorular

Headlamp Cluster API eklentisi hangi CAPI versiyonlarını destekliyor?

Eklenti hem v1beta1 hem de v1beta2 API sürümlerini destekliyor. Yanı dinamik versiyonlama sayesinde management cluster’ınızda hangi CRD sürümü kurulu olursa olsun, sorunsuz çalışıyor.

UI üzerinden yeni bir cluster oluşturabilir mıyım?

İlk sürümde odak daha çok görünürlük ve day-2 operasyonlar üzerine. Ölçekleme yapabiliyorsunuz, ama sıfırdan cluster oluşturmak için hâlâ clusterctl generate cluster ya da GitOps yaklaşımı öneriliyor (şaşırtıcı ama gerçek). Aslında bu iş akışlarının ilerleyen sürümlerde genişlemesi bekleniyor.

Prometheus metriklerini görmek için ne yapmam gerekiyor?

Şimdi, i̇lginç olan şu ki, Headlamp’in ayrı bir Prometheus eklentisi var. Önü kurup management (söylemesi ayıp) cluster’ınızdaki Prometheus servisini tanımladığınızda, CAPI kaynak detay sayfalarında ilgili metrikler otomatik olarak inline görünüyor. Tecrübeme göre ekstra bir konfig gerekmiyor genelde, oldukça kolay.

Kısa bir not düşeyim buraya.

Bu eklenti production için yeterince olgun mu?

Bakın, Görünürlük ve read-only işlemler için bence gönül rahatlığıyla kullanılabilir. Yazma işlemleri, mesela scale gibi şeyler için de kullanılıyor. Sız ne dersiniz? Açıkçası önemli değişikliklerde ekibinizin GitOps akışına bağlı kalmasını tavsiye ederim — hem audit hem rollback açısından çok daha güvenli (en azından benim deneyimim böyle) (bu beni çok şaşırttı)

RBAC izinleri neler olmalı?

En azından cluster.x-k8s.io, bootstrap.cluster.x-k8s.io. controlplane.cluster.x-k8s.io API gruplarına get, list, watch yetkileri gerekiyor. Scale gibi işlemler yapacaksanız da machinedeployments/scale alt kaynağına update yetkisini de eklemeniz lazım.

Kaynaklar ve İleri Okuma

Kubernetes Blog: Introducing the Cluster API plugin for Headlamp

Headlamp Resmî Sitesi ve Dokümantasyonu

Cluster API (CAPI) Resmî Dokümantasyonu

Headlamp GitHub Repository

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 SDK for Rust GA: Beta’dan Stabil Üretime Geçiş20 May 2026

Azure Developer CLI Mayıs-Haziran 2026: azd tool ve exec Devrimi26 Haz 2026

Yaş Doğrulama Yasaları: Geliştiriciler Neden Dikkat Etmeli?8 May 2026

vcpkg Nisan 2026: Kilitler, Hız ve Küçük Ama Kritik Dokunuşlar9 May 2026