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
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?
| Ihtiyaç | clusterctl / kubectl | Headlamp CAPI Plugin |
|---|---|---|
| Hızlı sağlık kontrolü | Orta | Çok iyi |
| Toplu manifest apply | Çok iyi | Sınırlı |
| Ekip içi paylaşım / demo | Zor | Kolay |
| Automation / CI-CD | Şart | Uygun değil |
| Debug / condition okuma | Detaylı ama yorucu |
Yanı ikisi de yerinde. Ben production’da clusterctl‘i bırakmam, ama debugging ve day-2 operations için Headlamp yanımda olsun isterim.
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 historyalanı 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
- Bir test/dev management cluster’ınız yoksa,
kindile local’de bir tane ayağa kaldırın; sonraclusterctl init --infrastructure dockerile CAPI’yi kurun. Yanı işin temelini atmak için 15 dakika falan yeter, abartmıyorum. - 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.
- Plugin Catalog’dan Cluster API eklentisini kurun ve bir
MachineDeploymentoluş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
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.
3 comments