Crossplane ile altyapı sağlama: provider, composition ve platform API'si

Crossplane nedir, hangi sorunu çözer?

Crossplane belgelerinin tanımıyla, platform mühendisliği için bir kontrol düzlemi (control plane) çerçevesidir. Kontrol düzlemi, istenen durumu (desired state) bir API ile alan ve gerçek durumu bu duruma sürekli yaklaştıran yazılımdır; durum sapma gösterirse otomatik olarak düzeltir. Crossplane bu fikri Kubernetes üzerine kurar ve bulut kaynaklarını (veritabanı, depolama alanı, ağ) Kubernetes nesneleri gibi bildirerek yönetmenizi sağlar.

Çözdüğü sorun şudur: geliştirici bir veritabanı istediğinde ya her bulut ayrıntısını bilmek ya da altyapı ekibine talep açıp beklemek zorunda kalır. Crossplane ile platform ekibi, kurumun kurallarını içeren özel bir API tasarlar; geliştirici yalnızca 'bir veritabanı istiyorum' diyen kısa bir nesne oluşturur, gerisini kontrol düzlemi halleder. Belgelerin ifadesiyle Crossplane'in temel değeri, kendi Kubernetes özel kaynaklarınızı, onlar için denetleyici (controller) yazmadan oluşturabilmenizdir.

Temel kavramlar: provider, managed resource, composition

Crossplane'i anlamak için temel yapı taşlarına bakmak gerekir. • Provider: Crossplane'in dış bir hizmette altyapı kurmasını sağlayan paketlerdir. Belgelere göre provider kimlik doğrulamayı, dış API çağrılarını ve dış kaynaklar için Kubernetes denetleyici mantığını üstlenir. Bulut sağlayıcılarına ve Kubernetes'in kendisine ait provider örnekleri vardır. • Managed resource: Provider'ın oluşturabildiği her dış kaynağın Kubernetes API uç noktası olarak karşılığıdır. Bir bulut veritabanı, bir managed resource nesnesiyle temsil edilir. • Composition: Birden çok kaynağı tek bir birleşik kaynak olarak oluşturan şablondur. Örneğin bir sanal makine, depolama ve ağ politikasını birlikte kurar. • Composite resource (XR) ve XRD: XR, Composition'ın yönettiği özel API nesnesidir. XRD (Composite Resource Definition) ise bu API'nin şemasını tanımlar.

Özet: provider dış dünyaya bağlanır, managed resource tek bir kaynaktır, Composition birkaçını birleştirir, XRD ile XR ise geliştiricinin gördüğü kısa API'yi oluşturur.

Adım adım: ilk kaynağın sağlanması

Başlangıç akışı şu sırayı izler: • Kubernetes kümesi hazırlayın ve Crossplane'i kurun. Belgelerdeki başlangıç bölümü kurulumu açıklar; ilk deneme için yerel bir küme yeterlidir. • Provider'ı kurun. Belgelerde provider, Crossplane'in Provider nesnesinin spec.package alanına paket adresi yazılarak kurulur. Kurulum sonrası bir provider pod'u çalışır ve provider API'lerini kümeye uzlaştırır. • Kimlik bilgilerini yapılandırın. Provider'ın buluta erişebilmesi için kimlik tanımı gerekir. Bunu en az yetkiyle ve sır yönetimi araçlarıyla kurun; kimlik bilgilerini depoya düz metin olarak koymayın. • Bir managed resource oluşturun. Bulutta yaratmak istediğiniz kaynağı (örneğin depolama kovası) Kubernetes nesnesi olarak bildirin. • Durumu izleyin. Kaynağın hazır olup olmadığını kubectl ile takip edin; hata olursa nesnenin olaylarını (events) okuyun.

Provider kurulumunun kısa taslağı (paket adresi yer tutucudur):

kind: Provider metadata: name: ornek-provider spec: package: PAKET_ADRESI

Bu aşamada henüz soyutlama yoktur; geliştirici bulut ayrıntılarını bilmek zorundadır. Composition bu noktada devreye girer.

Composition ile soyutlama tasarımı

Belgelere göre Composition, birden çok Kubernetes kaynağını tek bir birleşik kaynak olarak oluşturan şablondur ve composition functions (kompozisyon fonksiyonları) boru hattıdır. Crossplane, XR değiştiğinde pipeline adımlarındaki fonksiyonları sırayla çağırır ve her fonksiyona bir öncekinin sonucunu geçirir. Fonksiyonlar da birer Crossplane paketidir; YAML tabanlı patch ve transform, Helm benzeri şablonlar, CUE, KCL ya da Python ile yazılabilir.

Soyutlamayı şu adımlarla tasarlayın: • Geliştiricinin sorusunu belirleyin: 'Hangi bilgiye gerçekten ihtiyaç var?' Örneğin veritabanı boyutu ve ortam adı yeterliyse bulutun diğer onlarca ayarını gizleyin. • XRD ile şemayı yazın: alan adları, tipleri ve varsayılanları. Şema, platformunuzun sözleşmesidir. • Composition'da kurum kurallarını gömün: şifreleme, yedekleme, ağ ayarı ve etiketleme gibi her kaynakta bulunması gereken standartlar. • Fonksiyonları sade tutun. Karmaşık koşullu mantık için YAML yama yerine KCL gibi bir programlama dili tercih edilebilir. • Composition'ı sürümleyin. Değişikliğin mevcut kaynaklara nasıl yayıldığını kontrol edin.

Geliştirici deneyimi: claim'den namespace kapsamlı XR'a

Geliştiricinin altyapı istemesi, Crossplane'in sürümüne göre farklı biçimler alır. Eski anlatımlarda bu yol 'claim' ile tarif edilir: geliştirici, kendi namespace'inde claim adlı bir nesne oluşturur ve Crossplane arka planda küme kapsamlı XR'ı yaratır. Crossplane'in belgelerine göre Crossplane v2 ile XR'lar varsayılan olarak namespace kapsamlıdır ve bu nedenle claim ihtiyacı kalkmıştır; yeni namespace kapsamlı ve küme kapsamlı XR'lar claim desteklemez. Önceki sürümün XR biçimi ise geriye dönük uyumlulukla desteklenmeye devam eder.

Bu farklı yaklaşımların bilinmesi pratikte önemlidir. Eski bir kurulumu devralıyorsanız claim yapısıyla karşılaşırsınız; yeni bir platform kuruyorsanız belgelerin güncel yaklaşımını inceleyin. Hangisi olursa olsun hedef aynıdır: geliştirici bulut sağlayıcısını değil, platform ekibinin sunduğu kısa ve anlaşılır API'yi görsün. İyi bir deneyim için şema alanlarına açıklayıcı adlar verin, durum alanlarında bağlantı bilgisi ve hata nedenini paylaşın, örnek manifestleri dokümante edin.

Yönetişim, güvenlik ve işletim

Kontrol düzlemi bulutta kaynak oluşturma yetkisine sahip olduğu için güvenliği ilk tasarım konusudur: • En az yetki: Provider kimliğine yalnızca gereken bulut izinlerini verin; ortam başına ayrı kimlik kullanmak etkiyi sınırlar. • Kubernetes erişim kontrolü: Geliştiricilerin yalnızca kendi namespace'lerindeki kaynakları oluşturabilmesini rol tabanlı erişimle sağlayın; managed resource nesnelerine doğrudan erişimi platform ekibine ayırın. • Politika denetimi: Composition kuralları standartları gömer, ancak bir politika motoruyla kümeye giren nesneleri ayrıca doğrulamak ek güvenlik katmanıdır. • Sürümleme ve devreye alma: Provider, fonksiyon ve Crossplane sürüm yükseltmelerini önce deneme ortamında test edin; değişiklikleri aşamalı yayın ve geri alma planıyla yapın. • Gözlemlenebilirlik: Kaynakların hazır olma süresi, hata oranı ve uzlaştırma gecikmesi için ölçüm ve uyarı kurun. • Silme davranışı: Bir XR silindiğinde dış kaynağın ne olacağını önceden bilin; veri barındıran kaynaklarda silme politikasını dikkatle belirleyin.

Sık hatalar ve Mindset programlarında karşılığı

En sık hatalar: soyutlamayı çok erken ve çok geniş tasarlamak, geliştiricinin gerçek ihtiyacını sormadan şema yazmak, kimlik bilgilerine fazla yetki vermek ve Crossplane'i yeni bir altyapı betik aracı gibi görüp Kubernetes uzlaştırma modelini anlamamak. Bir başka tuzak, her şeyi tek bir dev Composition'a koymaktır; küçük, test edilebilir Composition'lar bakımı kolaylaştırır.

Mindset kataloğundaki Crossplane ile Kubernetes Üzerinden Altyapı Sağlama eğitiminin modül başlıkları platform mühendisliği ve Crossplane mimarisi, provider kurulumu ve kimlik yönetimi, Composition ve soyutlama tasarımı, claim akışı ve geliştirici deneyimi, yönetişim, politika ve güvenlik, işletim, sürümleme ve devreye almadır. Platform mühendisleri, DevOps ekipleri ve bulut altyapısını geliştirici self-servisine açmak isteyen kurumlar için yapılandırılmış bir yoldur. Daha geniş bağlam için Platform Mühendisliği ve Terraform eğitimleri tamamlayıcıdır.