Kubernetes 10’da: Operatörlerin yardımıyla kalıcı depolama olgunlaşıyor

Kubernetes 10 yaşında! 2024 ortası, pazar lideri konteyner düzenleme platformunun 10. yaş gününü kutluyor.

Bu, uygulamaları sanallaştırmanın yeni bir yolu olarak konteynerlerin ortaya çıkmasıyla başlayan ancak pratikte mevcut olmayan depolama ve veri korumasıyla başlayan bir on yıl. Artık Kubernetes, durum bilgisi olan verilerin depolanması için gereken tüm işlevlere sahip, bulutta yerel uygulamalar için olgun bir konteyner platformu sunuyor.

Yapay zeka (AI) iş yükleriyle karakterize edilen bir geleceği sabırsızlıkla beklerken, Kubernetes’in ilk on yılını, Kubernetes’in geliştirilmesine yardımcı olan ve Kubernetes Operatörlerinin kullanımı da dahil olmak üzere depolama ve veri korumadaki zorlukların üstesinden gelmeye yardımcı olan mühendislerle yaptığımız bir dizi röportajla kutluyoruz. .

Burada, Kubernetes’i tasarlayan Google’ın kıdemli yazılım mühendisi Saad Ali, erken dönemdeki depolama ve veri koruma zorluklarından, konteyner depolama arayüzü (CSI) sürücülerine katılımından, elastik ve taşınabilir bir ortam için durum bilgisi olan depolama açmazını çözmesinden bahsediyor ve Kubernetes Operatörlerinin bu sıkışıklığı kırma konusunda nasıl büyük bir ilerleme kaydettiğini gördük.

Kubernetes ilk piyasaya sürüldüğünde pazar nasıldı?

Saad Ali: Kubernetes ilk piyasaya sürüldüğünde geliştiriciler ve satıcılar konteynerlerle çok ilgileniyorlardı ancak nereden başlayacakları konusunda hiçbir fikirleri yoktu. Docker sektöre enerji kazandırdı ve geliştirmeyi kolaylaştırdı ve bunun geniş ölçekli dağıtımlar için nasıl faydalı hale getirilebileceğinin bulunmasına büyük ilgi vardı.

Birçok depolama satıcısı nereye yatırım yapacaklarına karar vermeye çalışırken kenarda bekliyordu. Birkaçı erkenden atladı ve Kubernetes için orijinal ağaç içi birim eklentilerini yazdı; bu, kodun doğrudan çekirdek Kubernetes deposunda kontrol edilmesini gerektiren göz korkutucu bir süreçti. Tüm belirsizliklere rağmen çoğu depolama satıcısı bekle ve gör yaklaşımını benimsedi. Eğer bu tereddütü hiç aşamamış olsaydık Kubernetes bugünkü haliyle olmazdı.

Kubernetes için depolamaya nasıl dahil oldunuz?

Ali: Depolamayla ilgili bir dizi sorunu düzelterek Kubernetes’in depolama tarafına dahil oldum. Sonunda depolama yığınında 1.0’dan beri var olan yarış koşullarını düzeltmekle görevlendirildim. Kubernetes 1.3’e hacim yaşam döngüsü yığınının büyük bir yeniden mimarisini aktardım; buna kubelet’ten takma/çıkarma mantığının çıkarılması ve yarış koşullarını azaltmak için merkezi bir denetleyiciye taşınması da dahil. Bu, birçok geliştiricinin sonraki sürümlerde yaptığı birçok ek düzeltmeyle birlikte, genel birim alt sisteminin kararlılığının iyileştirilmesine yardımcı oldu.

Kubernetes SIG oldum [Special Interest Group] Depolama eşbaşkanı ve sonraki yıllarda ana odak alanlarımdan biri, Kubernetes depolamasının nasıl daha genişletilebilir hale getirileceğini bulmaktı. Konteyner depolama arayüzünün başlatılmasına ve geliştirilmesine yardımcı oldum.

Kubernetes’in pazarda lider konumda olduğunu ne zaman fark ettiniz?

Ali: Genel olarak Kubernetes için şunu duyduğumu hatırlıyorum pokemon git Kubernetes’in üzerinde çalışıyordu. Bu inanılmaz bir andı ve Kubernetes’in yükselişe geçtiğinin farkına vardı.

CSI, depolama sağlayıcılarını eklenti oluşturmaya yatırım yapma konusunda yeterince rahat hale getirdi ve verimli bir döngüye yol açtı; Kubernetes için daha fazla sağlayıcı geliştirerek Kubernetes’i daha kullanışlı hale getirdi, Kubernetes’in benimsenmesini artırdı ve daha fazla sağlayıcının bunun için geliştirme yapmasına yol açtı

Kubernetes depolaması için, CSI’yi ilk kez geliştirmeye başladığımızda, bunun hakkında konuşmak için San Francisco’daki bir toplantıya gittim ve izleyicilerden biri şunu sordu: “Bu çabayı, OpenStack topluluğunun depolamayı standartlaştırmaya yönelik geçmişte denediği pek çok çabadan farklı kılan nedir? ? Bu sefer farklı olacağını sana düşündüren ne?”

Bu, başarının garanti edilmediğinin bir hatırlatıcısıydı; bu nedenle, depolama topluluğu ve birden fazla konteyner orkestratörü ile sıkı bir şekilde çalışmak, CSI üzerinde oldukça metodik ve sürekli olarak yinelemeler oluşturmak ve birden fazla çalışan sürücüye sahip olana kadar buna 1.0 adını vermemek için CSI ile aktif bir çaba gösterdik. /entegrasyonlar.

Bu, depolama sağlayıcılarının eklenti oluşturmaya yatırım yapma konusunda yeterince rahat olmasını sağladı ve verimli bir döngüye yol açtı; Kubernetes için daha fazla sağlayıcı geliştirerek Kubernetes’i daha kullanışlı hale getirdi, Kubernetes’in benimsenmesini artırdı ve daha fazla sağlayıcının bunun için geliştirme yapmasına yol açtı. CSI sürücülerinin listesi 100 sürücüyü aştığında özel bir şey başardığımızı fark ettim.

Kubernetes’e baktığınızda veri ve depolamaya nasıl yaklaştınız?

Ali: Kubernetes platformunun (CSI gibi entegrasyonlarla) genişletilebilirliğinin ötesinde, bana göre Kubernetes depolamanın büyüsü, blok/dosya depolamayı bilgi işlemden ayırması – “endişelerin ayrılması” – ve durum bilgisi olan iş yüklerini durum bilgisi olmayan kadar esnek hale getirmesidir. iş yükleri. Durum bilgisi olan iş yüklerinin artık tedarik edildikleri düğüme sabitlenmesi gerekmediğinde, insan müdahalesi olmadan kendi kendini iyileştirmek daha kolay hale geldi.

Kubernetes 1.0 bile Kubernetes’in isteğe bağlı blok/dosya depolama birimlerini otomatik olarak bölmelere eklemesine/biçimlendirmesine/bağlamasına ve bölmeler düğümler arasında hareket ettikçe bunların bağlantısını kesmesine/ayırmasına olanak tanıyan temel bir “ağaç içi birim eklentisi” sistemi içeriyordu. Bu, durum bilgisi olan iş yükleri için planlama esnekliğinin sağlanması açısından kritik öneme sahipti. Bir hesaplama düğümünde bir şeyler ters gittiğinde bile verileriniz, insan müdahalesi olmadan otomatik olarak başka bir düğümde kullanıma sunulabilir.

Kubernetes’te veri ve depolama konusunda sizin için ilk olarak hangi sorunlar ortaya çıktı?

Ali: Kubernetes depolama alt yığını inanılmaz derecede karmaşıktır. Başlangıçta birçok yarış koşuluyla uğraştık. Depolama yığınındaki en büyük zorluklardan biri, otomatik kurtarma ile potansiyel veri kaybı ve bozulması arasındaki en kötü durumla başa çıkmak zorunda olmasıdır. Her ikisi de kabul edilebilir sonuçlar değildir; bu nedenle Kubernetes SIG Storage, bu uç durumları tespit etmek ve bu durumlardan sorunsuz bir şekilde kurtarılmasını sağlamak için inanılmaz derecede sıkı çalıştı.

Kubernetes depolamanın büyüsü, blok/dosya depolamayı bilgi işlemden ayırması ve durum bilgisi olan iş yüklerini durum bilgisi olmayan iş yükleri kadar esnek hale getirmesidir.

Neyin değişmesi gerekiyordu?

Ali: Başlangıçta Kubernetes depolama yığını, bir depolama yöneticisinin uygulama operatörlerinin kullanması için çeşitli boyutlarda blok/dosya hacimlerinden oluşan bir havuzu önceden hazırlayacağını varsayıyordu. Bu, mevcut depolama kapasitesinin verimsiz kullanılmasına yol açtı.

SIG Storage, Kubernetes 1.6’da dinamik provizyon kavramını tanıttı. Bu, blok/dosya depolamanın uygun ölçekte kullanılabilirliği açısından ezber bozan bir gelişmeydi ve depolama birimi yaşam döngüsünün otomasyonunu tamamladı çünkü iş yüklerinin ihtiyaç duyduğu şekilde depolamayı isteğe bağlı olarak sağladı, insan müdahalesini ortadan kaldırdı ve depolama kapasitesinin verimli kullanımına olanak sağladı.

Kubernetes Operatörlerinin veri ve depolama alanında başarıya ulaşmasını sağlayan neler oldu?

Ali: Yapı taşları yerine oturdukça (StorageClass, PersistentVolumeClaim (PVC) ve PersistentVolume (PV) arayüzleri, CSI, dinamik provizyon), daha yüksek düzeydeki durum bilgisi olan temel öğelerin orkestrasyonu odak noktası haline geldi.

Kubernetes, durum bilgisi olan iş yükleri için bir yapı taşı olarak StatefulSets’i sundu. Ancak birçok karmaşık durum bilgisi olan uygulamanın, çoğaltma, ölçeklendirme vb. şeyleri mümkün kılmak için verilerinin daha dikkatli bir şekilde düzenlenmesini gerektirdiği ortaya çıktı.

Kubernetes Operatörleri tam da bu noktada devreye girdi. Yüksek kullanılabilirlik sağlamak amacıyla verilerin parçalanması, tüm kopyaların aynı anda kullanılamaz hale gelmesinin önlenmesi vb. gibi uygulamaya duyarlı operasyonları mümkün kılmak üzere Kubernetes’i genişletmenin kolay bir yolunu sundular.

Bu, daha fazla bulut tabanlı yaklaşımları nasıl destekledi? Sonuçları nelerdi?

Ali: Kubernetes Operatörleriyle birlikte Kubernetes depolama yığını, mevcut bilgi işlem kaynaklarının gerçekten esnek bir şekilde kullanılmasına olanak tanır. Bana göre bulutta inşa edilmenin özü budur; tüm iş yükleriniz tarafından kullanılabilecek, isteğe bağlı olarak, insan müdahalesi olmadan ölçeği büyütüp küçülterek en üst düzeye çıkarabileceğiniz geniş bir bilgi işlem kaynakları havuzuna sahip olmak. Kullanılabilirliği artırın ve maliyetleri azaltın.

10 yaşında olan Kubernetes, dağıtılmış bilgi işlem açısından Linux’a benzemeye başlıyor. Yaygın olarak benimsenen güçlü ve genişletilebilir bir açık kaynak aracıdır ve modern dağıtılmış bilgi işlem altyapısı için önemli bir yapı taşıdır.

Kubernetes artık 10 yaşında. Bugün bunu nasıl düşünüyorsunuz?

10 yaşında olan Kubernetes, dağıtılmış bilgi işlem açısından Linux’a benzemeye başlıyor. Yaygın olarak benimsenen güçlü ve genişletilebilir bir açık kaynak aracıdır ve modern dağıtılmış bilgi işlem altyapısı için önemli bir yapı taşıdır.

Veri ve depolama söz konusu olduğunda Kubernetes’te hâlâ hangi sorunlar var?

Ali: Kubernetes, blok ve dosya depolamadan yararlanan taşınabilir, ölçeklenebilir, durum bilgisi olan uygulamalar geliştirmeyi çok daha kolay hale getirdi. Ancak depolama, farklı veritabanlarının nasıl çalıştığı, eşzamansız ve eşzamanlı çoğaltma arasındaki farklar, çeşitli depolama artıklık profillerinin değiş tokuşu vb. konularda endişelenmek istemeyen birçok geliştirici için hâlâ zordur.

Bu, Kubernetes’in çözmesi gereken bir sorun olmayabilir, ancak bir endüstri olarak, satıcıdan bağımsız taşınabilirliği korurken, değişen ölçek, yedeklilik ve performans gereksinimlerine sahip her türden geliştirici için durum bilgisi olan uygulamalar oluşturmayı kolaylaştırmalıyız.

Paylaşacak başka anekdot veya bilgi var mı?

Ali: Kubernetes gibi açık kaynaklı projeler, dünyanın dört bir yanından gelen birçok harika katkıda bulunanlar sayesinde mümkün. Sürekli bakım ve iyileştirmeye ihtiyaçları var. İlgilenen herkesin bize katılmasını tavsiye ederim. Depolamayla ilgileniyorsanız Kubernetes SIG Storage’a katılın. Verilerle ilgileniyorsanız Kubernetes’teki Veriler topluluğuna katılın. Katılın ve yeni nesil iyileştirmeleri yönlendirmemize yardımcı olun.