Edge'de tıkanan Kubernetes dağıtımlarının çözümü fleet management

Edge'de Kubernetes teknolojide değil, operasyonda tıkandı

Edge'deki Kubernetes dağıtımları — mağazalar, fabrikalar, baz istasyonları — büyük ölçüde ölçeklenmeyi bıraktı ve yakın tarihli bir dev.to analizi, engelin platformun kendisi değil, onun yönetilme biçimi olduğunu savunuyor. Operatör tek bir veri merkezi cluster'ından yüzlerce küçük, dağıtık cluster'a geçtiğinde, önceden işe yarayan pratikler çöküyor. Önerilen ileriye giden yol fleet management: tüm cluster topluluğunu operasyon birimi olarak ele almak yerine her birini ayrı ayrı ele almamak.

Kırılan varsayımlar

dev.to yazısına göre, geleneksel cluster operasyonlarının dayandığı dört varsayım edge'de başarısız oluyor.

Birincisi, operatörler cluster'ın her zaman erişilebilir olduğunu varsayıyor. Edge lokasyonları uplink kaybediyor, güvenilir olmayan fabrika ağlarının arkasında bulunuyor ya da saatlerce çevrimdışı kalıyor; dolayısıyla merkezi bir control plane her cluster'a istenildiğinde ulaşabileceğini varsayamaz.

İkincisi, operatörler az sayıda cluster olduğunu varsayıyor. Edge'de sayı onlarca, yüzlerce ya da binlere ulaşabilir ve belirli bir cluster'a karşı insanın kubectl çalıştırmasına dayanan hiçbir workflow o ölçekte varlığını sürdüremez.

Üçüncüsü, operatörler güçlü ve kabaca tekdüze donanım varsayıyor. Edge node'ları çoğunlukla küçük, heterojen ve kaynakları kısıtlı; veri merkezine uygun control-plane ağırlıklı dağıtımlar uzak bir lokasyondaki zayıf bir makine için fazla ağır.

Dördüncüsü, operatörler lokasyonda personel olduğunu varsayıyor. Uzak bir yerde kimse bir node'u yeniden başlatmayacak; bu yüzden kurtarmanın otomatik ya da tamamen uzaktan olması gerekiyor.

Fleet management neyi değiştiriyor

dev.to yazarı, fleet management'ı operasyon biriminin cluster'dan fleet'e çevrilmesi olarak tanımlıyor ve bunun dört pratiğe dayandığını anlatıyor:

• Deklaratif, pull tabanlı yapılandırma. Cluster'lar istenen durumlarını merkezi bir kaynaktan çeker — fleet ölçeğinde GitOps — pushed değişiklikler almazlar. Çevrimdışı kalmış bir cluster yeniden bağlandığında kendini reconcile eder ve bu, erişilebilirlik varsayımını tamamen ortadan kaldırır. Yazar bunu en önemli tek kayma olarak nitelendiriyor.
• Politika tabanlı gruplama. Rollout'lar, yapılandırma ve politika, tek tek isimlendirilmiş cluster'lar yerine etiketli grupları hedefler; örneğin bir bölgedeki tüm mağazalar ya da belirli bir uygulama sürümündeki tüm cluster'lar.
• Kademeli rollout'lar. Değişiklikler önce birkaç canary cluster'a ulaşır, sonra halkalar halinde yayılır; böylece kötü bir değişiklik 300 cluster'ı etkilemek yerine beş cluster'dan sonra yakalanır.
• Fleet geneli gözlemlenebilirlik ve drift tespiti. Hangi cluster'ların sağlıklı olduğu, hangilerinin sürümlerde geri kaldığı ve hangilerinin istenen durumundan saptığını gösteren tek bir görünüm.

Araçlar zaten mevcut

Makale, operatörlerin bunu sıfırdan inşa etmesi gerekmediğine dikkat çekiyor. K3s gibi hafif dağıtımlar kısıtlı node'ları hedeflerken, Fleet, Argo CD ApplicationSets ve Flux ölçekte fleet controller'ları ile GitOps sağlıyor ve büyük bulut sağlayıcıları da yönetilen fleet hizmetleri satıyor. Hepsindeki ortak desen; deklaratif istenen durum, pull tabanlı reconciliation, etiket tabanlı gruplama ve kademeli rollout.

Maliyet körlüğü

dev.to yazısı, edge tartışmalarının genellikle atladığını söylediği bir boyutu da işaret ediyor: fleet, varsayılan olarak bir maliyet görünürlüğü sorunudur. Yüz cluster, aşırı sağlama overload provisioning'e saklanacak yüz yer sunar ve cluster düzeyindeki maliyet araçları, manuel operasyonlardan daha iyi bir şekilde fleet'e ölçeklenemez. Bu nedenle maliyet atfı ve rightsizing, fleet düzeyinde sorular haline gelmeli — fleet'in maliyeti ne ve para nerede boşa harcanıyor — ve sağlık izlemesinin ardından değil, onun yanında durmalı.

Neden önemli

Edge Kubernetes başarısız olmadı; başarısız olan tek tek cluster'ı ele alan operasyon modeli ve cluster sayıları birkaç taneden yüzlercesine çıktığında bu sonuç öngörülebilirdi. Birçok lokasyonda workload çalıştıran ekipler için fleet alışkanlıklarını erken benimsemek, sonradan eklemekten daha ucuzdur; çünkü üç cluster'da ayakta kalan pratikler, 300'de de işe yarayacak olanlardır. Yazarın kendi deneyimi pratik bir uyarı sunuyor: push tabanlı araçlar, bir lokasyon ilk kez karanlıkta kaldığında çökmeye eğilimlidir; bu yüzden genellikle ilk kırılan varsayım maliyet görünürlüğü değil, erişilebilirliktir.