‫Kubernetes ile şimdiye kadar depolama veya hacimlerden
‫bahsetmedik.
‫Docker, Compose, Swarm ve bir
‫dereceye kadar Kubernetes'te de aynı şey
‫söz konusu.
‫Konteynerleriniz var ve konteynerlerin durumsuz
‫olduğunu varsayıyoruz, yani konteyneri attığınızda
‫içindeki her şey yok oluyor.
‫Bir konteyneri güncelleme ile değiştirdiğinizde veya bir şeyi değiştirdiğinizde
‫ve bunu bir kubectl apply ile uyguladığınızda, konteyneri kaybedersiniz, içindeki her şeyi kaybedersiniz.
‫Açıkçası, Kubernetes, tıpkı diğer orkestratörler
‫gibi, kalıcı verilerin etrafta kalması için
‫bir yola sahip olmalıdır. Bu, ciltlerin kendisinden bile daha fazla.
‫Kubernetes'te konteynerler ve dağıtımlar bile StatefulSets adı
‫verilen bir şeyle farklı olabilir.
‫Bunlar dağıtımlardan farklı
‫kaynaklardır.
‫Temel olarak veritabanları ve aynı isim, aynı IP'ler gibi çok
‫daha fazla kalıcılık gerektiren şeyler
‫etrafında tasarlanmıştır.
‫Swarm ya da Docker ile bunu tam olarak
‫elde edemedik.
‫Bu farklı nitelikleri konteynerler arasında tutmanız
‫için gerçekten bir yol yoktu.
‫StatefulSets, Kubernetes'te henüz çok kısa bir
‫süre önce kullanıma sunulan yeni bir özelliktir.
‫Veritabanlarını veya isimler, IP adresleri, hacimler
‫ve kalıcı veriler gibi değişikliklere karşı çok hassas olan bir şeyi dikkate
‫alacaksanız bakacağınız şey budur.
‫Burada bir uyarıda bulunmak istiyorum.
‫Bu konuda çok fazla ayrıntıya girmeyecek olmamızın
‫nedeni, Kubernetes'in ilk dağıtımında çok fazla StatefulSet
‫kullanılmasını önermememdir.
‫Aslında
‫ideal olan, ister Swarm ister Kubernetes olsun, herhangi bir
‫orkestratörün ilk dağıtımının yalnızca stateless ile yapılması
‫ve basit tutulmasıdır. Belki sadece web önyüzlerinizi veya
‫bazı API'ları veya bazı çalışan özelliklerini ya da veritabanlarını
‫içermeyen bir şey yapın. Aslında, bulut veritabanlarını kullanabiliyorsanız,
‫bunu yapın.
‫Kendi başınıza çalıştırmaktan kaçınamayacağınız özel gereksinimleriniz
‫olmadığı sürece veritabanlarınızı her zaman dışarıdan temin
‫etmenizi öneririm. Başlangıçta orkestrasyon,
‫konteynerlerin değişmez, dağıtılmış ve değiştirilebilir olması üzerine tasarlanmıştı.
‫Bu durumsallık için yapışkanlık fikri, sizin için daha
‫fazla iş, karmaşıklık ve çok daha fazla
‫test ekleyecektir. İdeal olarak, kapıdan çıkarken bu konuda
‫endişelenmenize gerek yoktur.
‫Daha sonra, Kubernetes ile ilgili diğer tüm konularda çok daha rahat olduğunuzda,
‫geri dönebilir ve şimdi veritabanlarımı düşünmek
‫istiyorum diyebilirsiniz.
‫Bu, veritabanlarını kümeler halinde çalıştırmamanız gerektiği anlamına gelmez.
‫Sadece daha fazla iş. Bu daha zor.
‫Veritabanları ve kalıcı depolama ile çalışmak her zaman daha zor
‫ve daha ayrıntılıdır. İşte benim profesyonel tavsiyem.
‫Herhangi bir konteynerle, Swarm'da, Docker
‫ve Docker Compose'da yaptığınıza çok benzer şekilde
‫bir birim ekleyebilirsiniz. Şablona spec içinde bir birim ifadesi
‫ekleyebilirsiniz. YAML dosyasını düşünürseniz,
‫beklediğiniz gibi oraya bir birim koyabiliriz
‫ve tam biçim ve ayrıntılar kaynaklarda
‫yer alır. Docker ve Swarm'da hacmin bir
‫konteynerle birlikte olmasının aksine, bu durumda
‫teknik olarak pod ile birlikte olur. Söylediğiniz takdirde poddaki her bir konteynere ya
‫da sadece bir konteynere bağlanır.
‫Yani, onu konteyner seviyesinde kontrol ediyorsunuz, ancak kalıcılığı
‫pod seviyesinde. Kalıcı hacimler
‫olan daha yeni bir özellik var.
‫Bu, talep adı verilen başka bir şeyle çalışır.
‫Bununla ilgili ilginç fikir, bunu podların
‫dışında kullanıyor ya da tanımlıyor
‫olmanızdır. Temelde bu kaynağı kendi başına yaratıyorsunuz
‫ve daha sonra pod spesifikasyonunuzun içinde bu kaynağa karşı
‫bir talepte bulunuyorsunuz.
‫Bunun daha ilginç olmasının nedeni, Kubernetes işletmeyi
‫ele geçirdikçe, Kubernetes'i çalıştıran ekiple aynı
‫olmayan, genellikle üçüncü taraf depolama alanıyla ilgilenen kişilerin
‫olmasıdır.
‫Bu kalıcı hacimleri yönetmek ve oluşturmakla ilgilenenler
‫onlar olacak.
‫O zaman uygulama dağıtıcıları diyecek ki,
‫hey bu türden bir birime
‫ihtiyacım var. Yani, SSD talebinde bulunacağım ya
‫da RAM depolamaya ihtiyacımız olabilir ya da belki NFS'ye ihtiyacım var
‫ya da her neyse. Bu depolama alanı otomatik
‫olarak sağlanacaktır çünkü depolama ekibi Kubernetes'te
‫bunu zaten ayarlamıştır.
‫Kalıcı hacimlerle ilgili fikir de bu.
‫Pod için geçici olarak tek bir sunucuda basit bir depolama
‫alanına ihtiyacınız varsa, standart birimler özniteliğini kullanın.
‫CSI eklentilerinin oluşturulmasıyla
‫ilgili son bir şey daha var. Kubernetes tarihinde,
‫üçüncü taraf depolama alanı olan her şey, ister
‫bulut depolama alanı ister üçüncü taraf satıcı depolama
‫alanı veya özel bir şey olsun, bu şeylerden herhangi biri ağaca eklenmiştir.
‫Bu, Kubernetes'in ikili dosyalarına eklendiği ve Kubernetes ile
‫birlikte gönderildiği anlamına gelir.
‫Bu da Kubernetes'in Amazon ve Azure depolama alanlarıyla birlikte kutudan
‫çıktığı gibi geldiği anlamına geliyor.
‫Bu oldukça kullanışlıydı, ancak pek çok zorluk
‫da ekliyordu.
‫Bunların çoğu, depolama sağlayıcılarının artık sisteminizin
‫çekirdeğine muhtemelen ihtiyacınız bile olmayan kodlar eklemesiyle ilgiliydi
‫çünkü yalnızca bir depolama sağlayıcısı kullanıyor olabilirsiniz, o halde neden hepsine
‫sahip olasınız ki?
‫Ayrıca, depolama sağlayıcıları kendi sürüm döngülerini Kubernetes sürüm
‫döngüsü etrafında kontrol etmek zorundaydı ve bu çok
‫esnek bir model değildi.
‫Böylece sektör bir araya geldi ve tıpkı ağlarda,
‫Docker dosyalarında ve imajlarında olduğu gibi bir standart
‫oluşturdu. Bu standart CSI'dır.
‫Konteyner Depolama Arayüzü anlamına gelir.
‫Bu, artık eklentiler sağlayacak, böylece herhangi bir depolama
‫tedarikçisi tüm düğümlere yükleyeceğiniz bir eklenti
‫oluşturabilir ve bu, eklentiye ve talimatlarına
‫göre farklı olacaktır.
‫Ardından, CSI'ın sağladığı standart bir API üzerinde çalışacaklardır, böylece
‫konteynerlerinizden herhangi biri depolama
‫alanlarına ulaşmak için bu eklentiyi kullanabilir.
‫Bu çok daha iyi ve esnek bir model.
‫Bu Kubernetes'in geleceği gibi bir şey,
‫ancak hala oldukça yeni. Bu yüzden örneklerde sık sık ve hatta
‫depolama tedarikçileriniz, CSI'ın olgunluğuna bağlı olarak,
‫Kubernetes'te yerleşik olan ve kutudan çıktığı gibi gelen geleneksel
‫eklentilerini kullanmanızı önerebilir.