Kubernetes 10 yaşında! Pazar lideri konteyner orkestrasyon platformunun 10. doğum günü 2024’ün ortalarında kutlanıyor.
VMware by Broadcom’da bulut tabanlı depolama teknolojisi lideri olan Xing Yang, 2017 yılında Kubernetes’te depolama üzerinde çalışmaya başladı ve orkestrasyon platformunun genişletilebilir bir çekirdek etrafında çalışmasını sağlayan özel kaynak tanımları (CRD’ler) etrafında oluşturulan projeler üzerinde çalıştı.
Daha sonra konteyner orkestratör platformu Kubernetes’in pazar liderliğine ulaştığını gördü ve CRD’lere dayalı, depolama ve veri koruma işlevselliğini Kubernetes’in temel özelliklerini koruyarak getiren konteyner depolama arayüzü (CSI) ve Kubernetes Operatörleri üzerinde çalıştı.
Kubernetes’in ilk on yılını, Kubernetes’i geliştirmeye yardımcı olan ve Kubernetes Operatörlerinin kullanımı da dahil olmak üzere depolama ve veri korumasındaki zorlukların üstesinden gelmeye çalışan mühendislerle yaptığımız bir dizi röportajla kutluyoruz; yapay zeka (AI) iş yükleriyle karakterize edilen bir geleceğe bakıyoruz
Kubernetes ilk piyasaya sürüldüğünde pazar nasıldı?
XingYang: Kubernetes ilk piyasaya sürüldüğünde, konteyner düzenleme pazarı henüz gelişmekteydi. Docker da yeni tanıtılmıştı ve imajlar oluşturmak için popüler bir araç haline gelmişti. Kubernetes, Docker imajlarını dağıtılmış sistemlere dağıtmayı kolaylaştıran bir konteyner düzenleme sistemidir. Bu, Kubernetes’i günümüzün fiili konteyner düzenleme sistemine dönüşen popüler bir seçim haline getirir.
Bu alana nasıl dahil oldunuz?
Hangi: 2017’de Kubernetes SIG Storage’daki VolumeSnapshot projesine katkıda bulunarak başladım ve Google’dan Jing Xu ile yakın bir şekilde çalıştım. Başlangıçta VolumeSnapshot API’sini ve denetleyicisini Kubernetes çekirdek kod tabanına tanıtmaya çalıştık ancak SIG Architecture tarafından reddedildi.
Bunun yerine CRD’leri kullanmamızı istediler. Bunun nedeni, Kubernetes’in minimum çekirdekle gerçekten modüler, genişletilebilir ve sürdürülebilir hale getirilmesi gerektiğidir. Bu nedenle, VolumeSnapshot özelliğini Kubernetes CSI altında ağaç dışı olarak uyguladık. CRD’ler olarak uygulanan ilk SIG Depolama çekirdek özelliği oldu. Hikayemizi 2019’da KubeCon China’da bir Keynote sunumunda anlattık: CRD’ler artık 2. sınıf bir şey değil!
VolumeSnapshot özelliğini Alpha’dan Beta’ya taşımak için diğer topluluk üyeleriyle çalıştık ve sonunda Kubernetes 1.20 sürümünde genel kullanıma sunduk. Kubernetes SIG Storage’da bakımcı oldum.
Kubernetes’in pazarda lider konumda olduğunu nasıl fark ettiniz?
Hangi: Kubernetes ilk olarak Haziran 2014’te Google tarafından tanıtıldı ve ardından Linux Vakfı’na bağışlanarak Bulut Yerel Bilişim Vakfı’nın (CNCF) tohum projesi haline geldi.
Diğer önde gelen genel bulut sağlayıcıları AWS ve Azure, 2017’de bulutlarında Kubernetes dağıtımlarını sunmaya başladı ve bunları 2018’de genel kullanıma sundu. Önde gelen bulut sağlayıcılarının bulutlarında Kubernetes dağıtımları olduğunda, Kubernetes’in bulutta ivme kazandığını ve kurumsal benimsemeyi başardığını fark ettim.
Kubernetes’e baktığınızda veri ve depolamaya nasıl yaklaştınız?
Hangi: Kubernetes ilk tanıtıldığında, yalnızca durumsuz iş yükleri için tasarlanmıştı. O zamanlar, konteyner uygulamaları geçici ve durumsuz olarak kabul ediliyordu ve bu nedenle verileri kalıcı hale getirmeleri gerekmiyordu.
Ancak bu durum kökten değişti. Durum bilgisi içeren iş yükleri Kubernetes’te çalışmaya başladı. Kalıcı birim talepleri, kalıcı birimler ve depolama sınıfları, Kubernetes’te çalışan uygulamalar için veri birimleri sağlamak amacıyla tanıtıldı. Durum bilgisi içeren iş yüklerini Kubernetes’te çalıştırmak için iş yükü API’si StatefulSet de tanıtıldı. Günümüzde giderek daha fazla durum bilgisi içeren iş yükü Kubernetes’te çalışmaktadır.
Kubernetes ile veri ve depolama konusunda ilk olarak hangi sorunlar ortaya çıktı?
Hangi: Kubernetes’e dahil olmaya başladığımda, CSI yeni tanıtılmıştı. Bir depolama satıcısının bir eklenti yazabilmesi ve o zamanlar Docker, Mesos, Kubernetes ve Cloud Foundry’yi içeren bir dizi düzenleme sisteminde çalışmasını sağlamak için ortak arayüzler tasarlamaya çalışıyordu.
Başlangıçtaki CSI arayüzleri çok temeldi ve birimleri oluşturma, silme, ekleme, ayırma, bağlama ve çıkarmayı içeriyordu. Ancak, durumlu iş yüklerini desteklemek için daha gelişmiş işlevlere ihtiyaç duyuluyordu. Örneğin, birim anlık görüntüsü, klonlama, birim genişletme ve topoloji başlangıçta CSI’da desteklenmiyordu.
Ne değişmeliydi?
Hangi: Kubernetes’te çalışan durumlu iş yüklerini daha etkili bir şekilde desteklemek için CSI’ın daha gelişmiş işlevlere ihtiyacı vardı.
Birim Anlık Görüntüsü, kalıcı birimlerin anlık görüntüsünün alınmasına ve veri kaybı veya veri bozulması olması durumunda verileri geri yüklemenin bir yolu olarak kullanılmasına olanak sağlamak için CSI’da tanıtıldı. Ayrıca, kalıcı bir birimde depolanan verileri kopyalayıp ondan yeni bir birim oluşturmak için kullanılabilen Birim Klonlama da CSI’a eklendi.
CSI topolojisi, dağıtılmış veritabanı iş yükleri için de çok önemli bir özelliktir. Kubernetes’in akıllı zamanlama yapmasına olanak tanır, böylece birim, pod’u çalıştırmak için en iyi yerde dinamik olarak sağlanır. Böylece, yüksek kullanılabilirlik ve hata toleransı sağlamak için iş yüklerini arıza etki alanları arasında dağıtabilir ve ölçekleyebilirsiniz.
CSI birim genişletme, durumlu iş yükleri için bir diğer önemli özelliktir. Uygulamanızın veri yazmak için daha fazla alana ihtiyacı varsa, birimi daha büyük bir boyuta genişletmenize olanak tanır.
Ayrıca, Kubernetes zamanlayıcısının planlama sırasında kapasiteyi hesaba katmasını sağlayan CSI Kapasite İzleme özelliği de bulunuyor.
Kubernetes’te veri koruma desteğinde de boşluklar var. Yedekleme ve geri yükleme için kullanılabilen birim anlık görüntüleri gibi bazı temel yapı taşları var, ancak bir felaket durumunda durum bilgisi içeren iş yüklerini korumak için daha fazlasına ihtiyaç var. 2020’nin başında Kubernetes’te veri koruma desteğini teşvik etmeyi amaçlayan bir Veri Koruma ÇG oluşturduk.
Kubernetes Operatörleri dünyasına nasıl dahil oldunuz?
Hangi:Daha gelişmiş depolama özellikleri kullanıma sunuldukça, Kubernetes, durum bilgisi olan iş yükleri için depolama sağlamak amacıyla daha olgun bir platform haline geldi; veritabanları da en önemli iş yükü türlerinden biri haline geldi.
CNCF TAG Storage’ın eş başkanı olarak, Kubernetes’te veritabanlarını çalıştırma hakkında bir teknik rapor üzerinde Data on Kubernetes Topluluğu ile iş birliği yapma fırsatım oldu. Teknik raporda tartışıldığı üzere, Operatörler, Kubernetes’te veri çalıştırırken kullanılan en önemli kalıplardan biridir.
Veri ve depolama alanında başarılı olmalarını sağlayan operatörlerin etrafında neler yaşandı?
Hangi: Operatörler, esnek ve genişletilebilir olan CRD’lerden yararlanır. Birçok geleneksel veritabanı başlangıçta Kubernetes için tasarlanmamıştır, ancak Operatörler ile karmaşık iş mantığı bu CRD’lerin altına yerleştirilebilir. Kullanıcılar için, özel bir kaynak (CR) tanımlayarak bir veritabanı kümesi talep etmek kolaydır. Operatör kontrol mantığı, Kubernetes’in bildirimsel yapısına dayanır ve veritabanının gerçek durumunu CR’de tanımlanan istenen durumla uzlaştırır ve sürekli olarak boşluğu kapatmaya ve veritabanını çalışır durumda tutmaya çalışır.
Operatörler, yedekleme ve geri yükleme, geçiş, yükseltme vb. gibi İkinci Gün işlemlerini otomatikleştirmeye yardımcı olur. Uygulamaları bulutlar arasında taşımayı veya hibrit bulutları desteklemeyi kolaylaştırırlar. Ayrıca CNCF, çok sayıda kullanılabilir araçla zengin bir ekosisteme sahiptir. Örneğin, izleme için Prometheus, kimlik doğrulama için Cert Manager, günlük işleme için Fluentd, bildirimsel sürekli teslimat için Argo CD ve daha fazlası. Operatörler, Kubernetes’te çalışan veritabanı kümelerinin yeteneklerini geliştirmek için bu üçüncü taraf araçlarını kullanabilirler.
Bu, daha fazla bulut yerel yaklaşımını nasıl destekledi? Sonuçları nelerdi?
Hangi: Bulut tabanlı bir ortamda, bir veritabanı uygulamasının parçası olarak çalışan bir Kubernetes pod’u, CPU veya bellek hatası nedeniyle sonlandırılabilir veya bir Kubernetes düğümü çöktüğü için yeniden başlatılabilir. Geçici depolama, bir pod’un yaşam döngüsüyle sıkı bir şekilde bağlantılıdır, bu nedenle yerel depolama kullanıyorsanız pod ile birlikte kaybolur. Harici depolama kullanıyorsanız, eklenen gecikme olan farklı bir sorun vardır.
Operatörler, yüksek erişilebilirlik sağlayarak, uygulamaların dağıtılmış bir şekilde çalışmasına olanak tanıyarak, dağıtımı otomatikleştirerek, izleme sağlayarak, veritabanlarının yaşam döngüsünü yöneterek ve veritabanlarının Kubernetes ortamında düzgün bir şekilde çalışmasını sağlayarak bu sorunların azaltılmasına yardımcı olabilir.
Kubernetes artık 10 yaşında. Siz bugün bunu nasıl değerlendiriyorsunuz?
Hangi: Kubernetes’in doğumundan bu yana geçen 10 yılda çok şey oldu. Veri iş yüklerini desteklemek için Kubernetes’e birçok özellik eklendi ve Kubernetes daha da olgunlaşıyor. Kubernetes’in bildirimsel API’leri var. Esnek ve genişletilebilir. Altta yatan altyapıyı soyutlamanın bir yolunu sağlıyor. Operatörler, Kubernetes kullanım durumlarını genişletmek için sihirli bir oyun kartı oldu. Veritabanlarının Kubernetes’te çalışmasını sağlayan anahtardır.
Veri ve depolama söz konusu olduğunda Kubernetes’te hala hangi sorunlar yaşanıyor?
Hangi: İkinci Gün işlemleri Kubernetes’te veri çalıştırırken hala bir zorluktur, ancak bu, Operatörler kullanılarak hafifletilebilir. Kubernetes çok karmaşıktır, hızlandırılması uzun zaman alır, Kubernetes’te veri iş yüklerini yönetmek çok çaba gerektirir ve mevcut ortamla entegre edilmesi karmaşıktır.
Ve Operatörler için, standardizasyon eksikliği hala bir sorundur. Ayrıca, çok kümeli bir ortamda durumlu iş yüklerini çalıştırmak hala bir zorluktur çünkü Kubernetes başlangıçta tek bir kümede çalışmak üzere tasarlanmıştır.
Paylaşacağınız başka anekdotlar veya bilgiler var mı?
Hangi: Kubernetes, 10 yıl önce doğduğundan bu yana uzun bir yol kat etti. Kubernetes’in geleceği önümüzdeki on yıl ve sonrasında parlak.