Crossplane + ArgoCD ile Self-Service Platform

Kurumsal altyapının en eski ritüeli: geliştirici ticket açar, altyapı ekibi üç gün sonra VM verir. Platform mühendisliğinin tüm amacı bu ritüeli öldürmek — geliştiricinin git push ile dakikalar içinde, kurallara uygun altyapı almasını sağlamak.

Bu yazı, Kubernetes üzerinde Crossplane + ArgoCD ile kurduğum self-service desenin özeti: neyi neden böyle yaptık, nerede duvara tosladık.

Kontrol düzlemi bir üründür

Anahtar zihniyet değişikliği şu: platform bir script koleksiyonu değil, API'si olan bir üründür. Crossplane'in XRD + Composition ikilisi tam bunu sağlıyor:

• XRD — geliştiriciye sunduğun sade API: "bana bir PostgresInstance ver, boyutu small olsun."
• Composition — o sade isteğin arkasındaki kurumsal gerçek: doğru ağda, şifrelenmiş, yedeklemesi tanımlı, etiketleri tam bir veritabanı.

Geliştirici 6 satırlık YAML yazar; güvenlik, ağ ve maliyet kuralları composition'da yaşar. Sızdırmazsın: kural API'nin arkasında olduğu için, kuralı atlayan istek fiziksel olarak mümkün değildir.

GitOps döngüsü: niyet repoda, gerçeklik kümede

ArgoCD denklemin diğer yarısı. Tüm claim'ler bir Git deposunda yaşar; ArgoCD repoyu izler, Crossplane gerçekliği sürekli o niyete yakınsar.

Bu ikilinin en az konuşulan faydası drift'in ölümü: elle yapılan her değişiklik, dakikalar içinde repodaki niyete geri çekilir. "Kim değiştirdi?" sorusu yerini "PR nerede?" sorusuna bırakır — audit, yan ürün olarak bedavaya gelir.

Sahada öğrenilen tuzaklar

1. Composition sürümlemesi ciddi iştir. Composition'ı değiştirdiğinizde mevcut yüzlerce kaynağı da değiştirirsiniz. Yeni davranışı yeni bir XRD sürümüyle yayınlayın, eskisini kademeli taşıyın. Bunu ihmal edenin "küçük düzeltmesi", cuma akşamı toplu restart olur.

2. Provider yetkisi = blast radius. Crossplane provider'ının cloud hesabındaki yetkisi neyse, platformunuzun silebileceği şey de odur. Provider'a en az yetkiyi verin ve üretim hesaplarını ayrı provider config'lerle izole edin.

3. Self-service, sınırsız değildir. Kota, isimlendirme, maliyet etiketi — hepsi composition'a gömülmeli. "Önce açalım, sonra kural koyarız" diyen herkes, ay sonu faturasında aynı dersi alıyor.

4. Geliştirici deneyimi tek YAML'a sığmalı. Altı satırlık claim vaadi, üç sayfalık açıklama gerektiriyorsa ürün başarısız demektir. İyi varsayılanlar + kısa şablonlar, dokümantasyondan daha değerli.

Nereden başlamalı

Tek bir hizmetle başlayın — en çok ticket üreten neyse o (çoğu yerde: veritabanı). Onu XRD'leştirin, on ekibe verin, geri bildirimle composition'ı olgunlaştırın. Platform ürünleri de ürün gibi büyür: küçük, geri beslemeli, adım adım.

Ticket kuyruğu bir kültür alışkanlığıdır; API'si güzel bir platform, o alışkanlığı tartışmayla değil, daha iyi bir deneyimle bitirir. İşler konuşsun.