Kubernetes 10 yaşında: Durumsuz bir şekilde yönetilen platformdan ‘platformlar oluşturmak için platform’a


Kubernetes 10 yaşında! 2024’ün ortaları, pazar lideri konteyner düzenleme platformunun 10. doğum gününe tanıklık ediyor. Ancak, SQL ve NoSQL veritabanları için açık kaynaklı ürünler geliştiren Percona’da grup ürünleri müdürü olan Sergey Pronin, her zaman bu konumda olmadığını söylüyor.

Pronin, Kubernetes’in pazara girdiği ilk yılları, neredeyse durumsuz uygulamaların düzenlenmesine kilitlenmiş halde, depolama ve veri koruma işlevselliğinin ise neredeyse hiç mevcut olmadığını hatırlıyor.

O da “Durumsuzlar için Kubernetes”in savunucusuydu. Ancak zamanla, Kubernetes Operatörleri ve StatefulSet aracılığıyla durumlu servis işlevselliğinin eklenmesiyle, orkestrasyon platformu, durumlu verilerin depolanması için gereken her şeye sahip bulut tabanlı uygulamalar için olgun bir kapsayıcı platformu isteyen geliştiriciler için tercih edilen platform haline geldi.

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üklerinin karakterize ettiği bir geleceğe doğru ilerliyoruz.

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

Sergey Pronin: Kuruluşlar giderek daha fazla mikro hizmet mimarisini benimsediğinden, çok sayıda konteyneri verimli bir şekilde yönetme ve ölçeklendirme ihtiyacı vardı. Konteyner dağıtımları ve ölçeklendirmesi manuel olarak gerçekleştiriliyordu, bu da hataya açık ve zaman alıcıydı, bu nedenle otomatik orkestrasyon araçlarına talep vardı.

2014 yılında Kubernetes, potansiyeli yüksek ancak net bir lideri olmayan bir konteyner düzenleme pazarına girdi. Docker konteyner devrimini ateşlemişti ancak konteynerleri ölçekte yönetmek karmaşık bir bulmaca olmaya devam ediyordu. Apache Mesos gibi seçenekler vardı ancak bunlar genellikle kullanışsızdı ve özel bilgi gerektiriyordu.

Kubernetes etrafındaki veri altyapısı üzerindeki çalışmalara nasıl dahil oldunuz?

Pronin: O zamanlar, çeşitli platform-hizmet-olarak çözümler oluşturan birden fazla mühendislik ekibine liderlik ediyordum. Geliştiriciler her zaman otomasyon yoluyla zahmeti ortadan kaldırmak ister ve orkestrasyonu basitleştirmek herkesin istediği bir şeydi. Kubernetes bugün olduğu kadar karmaşık değildi, ancak toplulukta yavaş yavaş ilgi görüyordu.

Merak birçok kapıyı açar ve ben bunlardan birinin arkasında Kubernetes’i gördüm. Neler içerdiğine baktığımda, takip etmem gereken bir proje olduğunu düşündüm. Gelecekteki kariyerimin ne kadar büyük bir parçası olacağını bilmiyordum.

Kubernetes’in pazarda lider konumda olduğunu nasıl fark ettiniz?

Pronin: Benim için ani bir farkındalık değildi. Yavaş yavaş gerçekleşti. Apache Mesos, Docker Swarm ve hatta AWS ECS (Elastic Container Service) gibi çözümler yaygın olarak kullanıldı. Kubernetes’in kazanmasının sebebi topluluktur. Takılabilir mimarisi ve hızlı gelişimi benimsenmesini sağladı ve diğer çözümlerin pazar payını yavaş yavaş yedi.

Kubernetes’e baktığınızda verilere nasıl yaklaştınız?

Pronin: Uzun bir süre benim için Kubernetes yalnızca durumsuz uygulamalar içindi. Hatta platformlarımızda durumlu uygulamalara Kubernetes’te izin vermediğimiz oldukça katı kalite barlarımız bile vardı. Bu, ölçeklenebilir ve dayanıklı bulut tabanlı uygulamaların nasıl tasarlanıp oluşturulacağı konusunda en iyi 12 faktörlü uygulama düşüncesiydi. Temel ilkelerden biri, durumsuz uygulama tasarımını teşvik etmek için veritabanları da dahil olmak üzere arka uç hizmetlerini bağlı kaynaklar olarak ele almaktır.

Kubernetes ile veri ve depolama konusunda ilk olarak hangi sorunlar ortaya çıktı?

Pronin: En büyük sorun olgunlaşmamışlıktı. Kalıcı Birimlerin sağlanması kutsal bir bilgi gibiydi, sadece birkaç kişi tarafından biliniyordu, tamamen otomatikleştirilmemişti ve bazı temel hacklemeler yoluyla erişilebilirdi. Depolama sağlayıcılarıyla entegrasyon yoktu, bu da kullanıcı deneyiminin oldukça hantal olduğu anlamına geliyordu.

Daha sonra 2019’da AWS EKS (Elastic Kubernetes Service) resmen AWS EBS’yi (Elastic Block Storage) desteklemeye başladı. Bu, algıları değiştirmeye başlayan dönüm noktası olabilir.

Ne değişmeliydi?

Pronin: Stateful Sets and Operators’ın yayınlanması ilk sürümden üç yıl sonraydı, bu yüzden Kubernetes’i hazır hale getirmek biraz zaman aldı. Yayınlandıktan sonra bunları dağıtma konusundaki çekingenliği aşmak hala zaman aldı. Politikalarımızı değiştirmeye hazır olmadan önce bu engeli aşmak için çok sayıda test yapılması gerekiyordu.

Kubernetes operatörlerine nasıl dahil oldunuz?

Pronin: 3,5 yıl önce Percona’ya Operatörler ve bulut yerel uygulama dağıtımlarından sorumlu ürün yönetim ekibine liderlik etmek için katıldım. O zamanlar çok fazla belirsizlik ve nispeten küçük bir toplulukla tamamen yeşil bir alandı. “Durumsuz için Kubernetes”e güçlü bir şekilde inanıyordum, bu yüzden fikri kavramak oldukça zordu. Percona’nın liderlik ekibi bir fırsat gördü ve ana akıma dönüşmesinden çok önce pazar eğilimini sezdi.

Veri ve depolama alanında başarılı olmalarını sağlayan operatörlerin etrafında neler yaşandı?

Pronin:Birçok olayın birleşimidir.

Mikroservisler çağında, kullanıcılar Kubernetes dışında Docker kapsayıcılarında veritabanlarını çalıştırmayı denediler. Bu karmaşık bir görevdir, özellikle de dağıtımlarda kümeleme varsa, ki buna veritabanları için ihtiyaç duyabilirsiniz.

Kubernetes, mikro hizmetleri çalıştırmak ve platformlar oluşturmak için fiili bir standart haline geliyordu. “Platformlar oluşturmak için bir platform” olarak tanımlanıyordu ve bence bu tanım artık doğru.

Kubernetes karmaşıklık sorunlarının bazılarını çözmeyi vaat etti, ancak veritabanlarını yönetmek zordur. Tüm Kubernetes ilkellerini öğrenmek ve kavramları kavramak cesurlar içindir. Operatörler tüm bu karmaşıklığı soyutladı ve giriş engelini önemli ölçüde düşürdü.

Sadece bu değil, Operatörler ikinci gün operasyonlarının sorununu çözdü. Veritabanı karmaşıklığının çoğu buradan kaynaklanır – devam eden bakım, yükseltmeler, yedekleme ve geri yüklemeler, güvenlik vb. gibi görevler. Kubernetes, altyapıyı ne kadar hızlı uygulayabileceğinizi iyileştirmenize yardımcı olabilir, ancak sizin için bir veritabanı sorgusunu üstlenemez.

Bu, daha fazla bulut yerel yaklaşımını nasıl destekledi? Sonuçları nelerdi?

Pronin: Operatörler (özellikle veritabanları için) Kubernetes ve CNCF ekosistemine ek bir ivme kazandırdı ve bu açık kaynaklı seçeneklerin benimsenmesini kolaylaştırdı.

Tedarikçi kilitlenmesi genel bulutta bir sorundu, Kubernetes ise tek tip bir API kullanarak uygulamaları her yerde çalıştırmanın bir yolunu sağladı. Kubernetes, durumsuz uygulamalar ve Operatörler için mükemmel bir şekilde çalışabileceğini göstermişti ve bu nedenle veritabanları da aynı şekilde çalışma şansına sahip oldu.

Kubernetes artık 10 yaşında. Siz bugün bunu nasıl değerlendiriyorsunuz?

Pronin: Son 10 yılda Kubernetes endüstri standardı haline geldi ve uygulamaların nasıl geliştirilip dağıtıldığını temelden değiştirdi. Etkisi yadsınamaz. İnovasyonu teşvik etti ve mikro hizmet mimarisinin yükselişini yönlendirdi.

Karmaşıklık ve güvenlik gibi zorluklar devam ederken, Kubernetes’in geleceği parlaktır. Büyüyen topluluk ve gerçekleşen tüm yenilikler, yeni trendlere uyum sağlamasını sağlayacaktır.

Veri ve depolama söz konusu olduğunda Kubernetes’te hala hangi sorunlar yaşanıyor?

Pronin: Operatörler veri ve depolama kaynaklarını yönetmeyi kolaylaştırsa bile karmaşıklık hala bir sorundur. Çoğunlukla, çeşitli Konteyner Depolama Arayüzleri (CSI’ler) arasında standardizasyon eksikliğinden ve farklı depolama sağlayıcılarıyla entegrasyonların karmaşıklığından kaynaklanmaktadır.

Birden fazla bulut veya hibrit ortamda veri ve depolamayı yönetmek, depolama API’leri ve yapılandırmalarındaki farklılıklar nedeniyle zorlayıcı olabilir. Federasyon veya çok kümeli kontrol düzlemleri aracılığıyla bunu basitleştirmeye yönelik çeşitli girişimler vardır.

MySQL veya PostgreSQL gibi veritabanı motorları mikroservislerden çok önce tasarlanmıştı. Mühendisler bunları Kubernetes’te çalışacak şekilde uyarladılar, ancak bazen bunları çalıştırmak için hack benzeri geçici çözümlere ihtiyaç duyuluyor.

Paylaşacağınız başka anekdotlar veya bilgiler var mı?

Pronin: Kubernetes’teki operatörler ve veritabanları, işleri yürütmek için yapılan sıfırdan hack’lerden kurumsal düzeyde olmaya hızla geçti. Artık farklı seviyelerdeki kuruluşlar için “neden”den ziyade “nasıl” daha önemli. Kubernetes’teki veriler artık “sadece cesurlar için” değil. Ana akım.



Source link