Bu podcast’te, SQL ve NoSQL veritabanları için açık kaynaklı ürünler geliştiren Percona’da grup ürün yöneticisi olan Sergey Pronin ile Kubernetes 1.31’de beklenen depolama özelliklerine bakıyoruz.
Pronin, bu haftanın 1.31 sürümünde beklenen depolama işlevselliğinden bahsediyor, ancak aynı zamanda veritabanları ve daha genel olarak Kubernetes’teki depolama açısından gördüğü bazı boşluklardan da bahsediyor. Ayrıca, Kubernetes’te hala ele alınması gerektiğini düşündüğü uyumluluk ve güvenlik açıklarından da bahsediyor.
Veri depolama ile uğraşan kişilerin ilgisini çekebilecek Kubernetes’e gelecek yenilikleri nasıl özetlersiniz?
Sergey Pronin: Depolamayla ilgili çok fazla iyileştirme olduğuna inanmıyorum çünkü 1.31 sürümü büyük ölçüde eski kodun büyük ölçüde kaldırılmasına odaklanmıştı. Çekirdek kod tabanından yaklaşık 1,5 milyon satır kod kaldırıldı, ancak bu kod tabanı çoğunlukla çeşitli bulut sağlayıcıları tarafından oluşturulan eski konteyner depolama arayüzleri (CSI’ler) için oluşturuldu ve sonra eklenti yapısına geçtiler. Bu sürümün ana odağı buydu.
Bazı depolama iyileştirmeleri var. Bence en büyüğü ve benim için en ilgi çekici olanı volume nitelikleri sınıfı. Kullanıcıların mevcut birimleri anında değiştirmesine olanak tanır, örneğin birimin IOPS sayısını değiştirmek istiyorsanız – Amazon’da EBS birimleriniz ve onların IOPS’ları olduğunu biliyorsunuz. Daha önce, bunu Kubernetes’te yapmak için yeni bir depolama sınıfı oluşturur ve ardından uygulamanızı bu yeni depolama birimine taşırdınız.
Oldukça uzun bir süreçti. Şimdilik, Kubernetes aracılığıyla, sadece bu belirli birim için IOPS’u değiştirebilirsiniz ve hepsi bu, ancak bu özellik alfa aşamasındaydı ve şimdi 1.31’de betaya geçiyor, bu yüzden GA veya kararlı sürüme yaklaşıyor.
Değişen önemli bir depolama özelliği bu. 1.31’de başka özellikler var mı?
Kalıcı birim durumuna bazı eklemeler var. 1.31’de kalıcı birimlere yeni bir “durum son faz geçiş zamanı” durumu eklendi.
Bu, kalıcı birimin çeşitli durumları arasındaki zamanı ölçmenizi sağlar. Bekleme durumunda olabilir, gelen olabilir, hata durumunda olabilir, vb. Ve şimdi, bu son aşama geçiş zamanı durumu eklendiğinden, çeşitli küme yöneticileri tarafından çeşitli hizmet seviyesi hedeflerini ölçmek için çok daha kolay bir şekilde kullanılabilir.
Tekrar ediyorum, bu çok büyük bir gelişme değil, ancak topluluğun uzun zamandır beklediği bir şeydi. Özellikle küme yöneticileri, çünkü kalıcı birimler Kubernetes ortamında olgunlaşıyor ve sıfırıncı günden itibaren bekleyeceğiniz bir şey yok. Ve şimdi eklendi, bu yüzden iyi bir şey.
Bunlara ekleyebileceğiniz başka eklemeler var mı?
Birkaç tane var ama çok önemli değiller ve GA’da da değiller, bu yüzden onlardan bahsetmeye değmeyeceğini düşünüyorum.
Depolama yönetmek isteyen kişiler için Kubernetes’te kalan zorlukların neler olduğunu düşünüyorsunuz?
Gördüğüm sorunlardan birinin otomatik ölçekleme ve depolama alanında yattığını düşünüyorum. Tarihsel olarak, Kubernetes yöneticilerin zahmetini ortadan kaldıran bir araç olarak tasarlanmıştı ve CPU veya RAM gibi çeşitli hesaplama kaynakları için, bunlar için otomatik ölçeklemeyi uygulamak oldukça kolaydır.
Belirli bir eşiğe ulaştığınızı görürseniz, resme daha fazla düğüm ekleyebilir veya konteynera daha fazla CPU kaynağı veya RAM ekleyerek dikey ölçekleme gerçekleştirebilirsiniz.
Ancak depolama için durum pek de böyle değil. Oysa, bulut sağlayıcılarının çoğuna bakarsanız – Amazon RDS veya Aurora gibi genel bulut sağlayıcılarını kastediyorum [databases]örneğin – sıfırdan itibaren otomatik depolama ölçeklendirmesi yaptılar ve şu anda Kubernetes’te buna benzer hiçbir şeyin olmaması benim için oldukça şaşırtıcı.
Şirketler tarafından geliştirilen bazı özel çözümler var, ancak bunlar ya çok sınırlı ya da artık sürdürülmüyor. Daha çok, “Hey, bir POC oluşturdum. Hadi topluluk, gidip çözün!” gibi.
Ve benim için çeşitli geliştiriciler olarak [Kubernetes] Veritabanları için operatörler, Kubernetes’teki kullanıcılarıma kesinlikle aynı düzeyde kullanıcı deneyimi sağlamak istiyorum, çünkü bazen “Tamam, Amazon’daki bu güzel Aurora’dan Operatörlere geçersem, ne gibi tavizler vereceğim?” diye düşünüyorlar. Bu da onlardan biri.
Kubernetes’te bu yönde bir gelişme var mı, yoksa hiçbir şey yok mu?
Kubernetes’te çeşitli alanlarda her zaman bazı aktiviteler oluyor, ancak maalesef şimdilik sadece tartışmalar var. Bunun için oluşturulmuş tek bir satır kod görmedim.
Ayrıca, bunun Kubernetes topluluğu tarafından yönlendirilmesi gerektiğinden %100 emin değilim veya örneğin Keda projesi gibi CNCF ekosistemindeki bir şey olabilir.
Keda, Kubernetes Event-driven Autoscaling’dir. CNCF bunu bulut tabanlı bir kuluçka merkezinden kuluçkaya yatırdı ve ölçeklemeyi oldukça başarılı bir şekilde hesaplıyorlar. Bu yüzden, neden depolama alanı eklemeyelim ki diye düşündüm. Bunu bir süre önce onlarla konuştuk ancak henüz hiçbir yere taşınmadı.
Depolama açısından Kubernetes’te henüz çözülmediğini düşündüğünüz başka önemli alanlar var mı?
Çeşitli Operatörlerin depolamayla nasıl etkileşime girdiği konusunda genel bir standardizasyonun kesinlikle yardımcı olacağını düşünüyorum. Ancak yine de bunun Kubernetes topluluğunun çözmesi gereken bir şey olduğuna inanmıyorum. Çeşitli SIG’leri içeren daha geniş bir topluluk olmalı çünkü yine çeşitli Kubernetes Operatörlerinin veya çeşitli Kubernetes projelerinin depolamayla nasıl etkileşime girdiğine bakarsam, bazıları durum kümeleri kullanıyor, bunların çoğu, bazıları dağıtımlar oluşturuyor ve PVC’leri bağlıyor.
Yani teknik açıdan bakıldığında çok farklı ve bunun sebebi bu uygulamanın gücünün altında yatan bir teknoloji, yani MySQL veya MongoDB veritabanı olabilir ve bu durumda depolama ile biraz farklı oynamak isteyebilirsiniz.
Ancak elde etmeniz gereken nihai sonuç sadece istikrar olmalıdır. Depolamanız her zaman kullanılabilir olmalı, verileriniz tutarlı olmalı ve kullanıcılara, Kubernetes’te depolama ile ilgili bir şey çalıştırırsanız bunun işe yarayacağına dair güven aşılayabilmelisiniz. Bunun için bir vudu büyüsü değil.
Bu alanda uzun süredir çalışıyorum ve hala şirketlerin, işletmelerin “Evet, veritabanlarını Kubernetes’te çalıştırmak bizim için. Bunun ileriye giden yol olduğuna inanıyoruz.” diyebileceği bir noktaya gelmediğimizi düşünüyorum. Hala çok fazla soru var [like] Ne kadar kararlı, çözümler ne kadar sağlam ve bunların yapacağı takaslar neler?
Kubernetes’te depolamanın hala oldukça karmaşık olduğu düşünülüyor mu? Söylediğiniz bu mu?
Evet, yaklaşık üç veya dört yıl önce Kubernetes’te veritabanları çalıştırmanın yeni bir şey olduğunu söyleyebilirim. Oysa bazı büyük kuruluşlar K8’lerde veritabanları çalıştırmaya cesaret edebilirdi. [Kubernetes]artık Kubernetes’teki genel depolama ve CNCF ekosistemindeki Operatörler ve diğer araçların Kubernetes’teki depolamayı destekleyecek şekilde olgunlaştığını görüyoruz.
Ancak bu, işletmelerin Kubernetes’teki verileri incelemeye başladıklarında mevcut düşünce sürecini uygulamak istemeleri gerçeğiyle sonuçlanıyor [about] veritabanlarının nasıl görünmesi gerektiği. Yani, bugün VM’lerde bir şeyler çalıştırıyorlar ve LDAP entegrasyonu, çeşitli şifreleme seviyeleri, standartları vb. var ve bunları henüz orada olmayan Kubernetes’teki veritabanlarına yansıtmaya çalışıyorlar.
İşletmelerin “Ah, bu sıfırıncı günde orada olmalıydı. Neden orada değil?” diye düşüneceği bazı eksik işlevler hala var. Ama yavaş yavaş yaklaşıyoruz. Yavaş yavaş yetişiyoruz ve istikrar ve performans yönlerini ele aldığımıza inanıyorum, bu yüzden şu anda veritabanlarını K8’lerde çalıştıran SLA’ları veya çalışma süresi olan herhangi biri için herhangi bir sorun görmüyorum
Ancak güvenlik ve uyumluluk açısından kesinlikle bazı boşluklar veya hatta bu dış ölçekleme olayında anlattığım gibi bazı zorlu özellikler mevcut. [It’s] hala orada değil [and] birisi bunun hemen orada olmasını beklerdi. Yani evet, her geçen yıl daha iyiye gittiğimizi düşünüyorum ama hala yapılacak çok iş var.
Peki uyumluluk ve güvenlik açısından hangi boşlukların olduğunu düşünüyorsunuz?
Veritabanları için veri-hareketsiz şifreleme. Bazıları için mevcut olduğunu görürsünüz. PostgreSQL gibi bazıları içinse daha çok bir arzudur. PostgreSQL’in topluluk sürümünde mevcut değildir. [It’s] sadece EnterpriseDB gibi bazı kurumsal sürümlerde var, örneğin, onlar bunu kullanıyor. Bunu çatalladılar, vb.
Yedeklemeler için de benzer. Örneğin, genel olarak iş sürekliliğini nasıl ele alıyorsunuz. Yedeklemelerinizi şifreliyor musunuz, nasıl saklanıyorlar vb. Çoğu Operatör bunu zaten çözdü ancak örneğin, veritabanınızı farklı veri merkezlerinde çalıştırmak ve SLA’larınız dahilinde otomatik bir devralma yapmak istediğiniz felaket kurtarma gibi şeyler; henüz orada değil.