Geliştiriciler ve platform ekipleri Kubernetes self-servisini istiyor, sahipliğinde anlaşamıyor

Geliştiriciler Kubernetes ortamlarını ihtiyaç duydukları anda istiyor; bir hafta talep kuyruğunda bekledikten sonra değil. Platform ekipleri ise bu ortamların maliyetini, erişimi ve şirket politikasına uygunluğu yönetiyor. HPE ürün yöneticileri Marius Bogoevici ve Karthik Subramanian, The New Stack'e bu gerilimi anlattı.

Açık kaynak Kubernetes orkestrasyon ve bildirimsel API'ler sunuyor ama eksiksiz bir işletim modeli sunmuyor. Subramanian'a göre kendi self-servis katmanını kuran ekipler iki tekrarlayan sorunla karşılaşıyor. Birincisi araç ve paket çokluğu: üretime hazır Kubernetes, ağ (CNI), depolama (CSI), ingress, kimlik ve politika için sürekli değişen bir CNCF proje kümesini ayakta tutmayı gerektiriyor.

Kendi kurulan self-servis nerede tıkanıyor

İkincisi, kurulum sonrası yaşam döngüsü ve hibrit altyapının karmaşıklığı. Küme kurmak kolay kısım; onu geliştirme, QA, staging ve üretim ortamlarında güncel tutmak asıl yükün biriktiği yer ve HPE'ye göre her yükseltme çevresindeki bileşenlere karşı kontrol edilmeli. Kümeler fiziksel sunuculara, özel ve genel bulutlara ve edge lokasyonlarına yayıldığında sapma büyüyor; ham API vermek bu işi yalnızca yerinden ediyor.

Sınırsız erişim değil, döşenmiş bir yol

Pratik yanıt sınırsız erişim değil, döşenmiş bir yol: geliştiricilerin kendi talebiyle aldığı onaylı Kubernetes servisleri; erişim, yapılandırma ve yaşam döngüsü ise platform ekibinin tanımladığı kurallara bağlı. Bogoevici'ye göre self-servis için en iyi adaylar tekrarlanabilir, düşük riskli ve iyi anlaşılmış talepler: geliştirici talep açmadan bir geliştirme kümesi alabiliyor ya da namespace oluşturabiliyor.

Geliştirici ardından onaylı Kubernetes sürümlerini ve küme boyutlarını, CPU, bellek ve depolama kotalarını ve geçici ortamların kiralama süresini seçiyor. Ağ izolasyonu, kimlik sağlayıcı entegrasyonu, güvenlik politikası ve maliyet dağıtımı platformda kalıyor. Üretim dağıtımları da aynı yolu izliyor: RBAC, denetim ve sürüm kontrolleri platform tarafında, istisnalar için resmi inceleme var.

Hızın kendi başarısızlık biçimi var

Geleneksel IT'de yeni bir proje için ayrı ortam sağlamak, altyapı, ağ, güvenlik ve depolama ekipleri arasında talep devirlerinden geçiyor ve günlerden haftalara uzayabiliyor. HPE'ye göre orkestrasyon, rol tabanlı erişim ve çok kiracılılığı tek bir operasyon deneyiminde birleştirmek bu süreçleri dakikalara ya da saatlere indiriyor. "Sağlama süresini haftalardan saatlere indirdiğinizde bu çok somut ve anlamlı oluyor" diyor Bogoevici.

Hızın kendi riski de var: ekipler neyin neden kurulduğunu takip etmeyi bırakabiliyor. Dengeyi kullanım ve maliyet görünürlüğü ile süresi dolduğunda geçici kümeleri kapatan kontroller sağlıyor. Bogoevici talep sayısını kötü bir başarı ölçüsü olarak niteliyor; dağıtım başarısı, istisna oranı ve kaynak kullanımı daha iyi göstergeler. Güvenliğin de servis tasarımının parçası olması gerektiğini ekliyor; kimlik, RBAC, kiracı izolasyonu ve politika ortamla birlikte gelmeli.