Kubernetes mimarisinde uygulamalar verilerin pod’ların yaşam döngüsüne bağlı olmaksızın tutulmasına ihtiyaç duyabilirler. Söz konusu veriyi barındırma olduğunda burada göz önünde bulundurulması gereken en önemli durum verinin kalıcı olup olmadığıdır.
Normal şartlarda pod’un yaşam döngüsü sonlandığında üzerinde tuttuğu data da silinir. Datanın kalıcı olması için verilerin pod’lara attach edilmiş olan volume’lerde tutulmaları gerekir.
Tabi bazı verilerin tutulmalarının önemi yoktur, bu sebeple pod’lar yaşam döngülerini tamamladıktan sonra verilerin silinmesi önemsenmez. Bu veriler genellikle hızlı olması açısından node’lar üzerindeki geçici disk’lere yazılıp,oradan okunurlar. Ancak bazen verilinin kalıcı olması hatta bu verilere birden fazla pod üzerinden erişilmesi önemli olabilir.
Bu gereksinimler göz önünde bulundurulduğunda volume mantığının Kubernetes cluster üzerindeki pod’lara attach edilmeleri gerekliliği ortaya çıkar.
Azure Kubernetes Service (AKS) üzerinde volume’leri barındırabileceğin bir kaç farklı storage tipi bulunur.
Peki Volume tam olarak nedir ve Azure üzerinde hangi bileşenleri volume’ler için kullanmalıyız?
Volume, pod’lar için verinin depolanmasını, belli durumlarda bu veriye erişilmesini ve pod’un yaşam döngüsüne bağlı kalmaksızın verinin kalıcı olmasını sağlayan birimdir.
Azure mimarisinde Kubernetes cluster için Azure Disk ve Azure Files volume olarak kullanılan resource’lardır.
- Azure Disk: Data volume olarak bu resource tipi kullanıldığında, volume sadece bir pod tarafından erişilebilir durumda olur. Birden çok pod eş zamanlı olarak bu data volume’üne erişecekse bu resource tipi uygun değildir. Bu resource tipi kullanılarak Kubernetes üzerinde DataDisk(Managed Disk) resource tipi oluşturulur. Diskler premium yada standard olarak konfigüre edilebilir. Bu alt yapıda kullanılacak olan diskin SSD yada HDD olup olmamasını belirler.
- Azure Files: Azure storage account üzerinde bulunan ve SMB 3.0 ile erişilebilen storage tipidir. Bu tipteki resource kullanılarak oluşturulan volume’ler birden çok pod ve node arasında share edilebilir. Yine bu resource tipinde de performans ihtiyaçlarına bağlı olarak standard veya premium storage kullanılabilir. Buda yine alt yapıda kullanılacak olan diskin SSD yada HDD olmasını belirler. Azure files altyapısında premium storage kullanılmak istenirse Kubernetes versiyonunun minimum 1.13 seviyesine getirilmesi gerekir.
Kubernetes mimarisinde volume’ler hostPath olarak node’un üzerinde bir lokasyondan, yada emptyDir olarak pod’un dosyalarının bulunduğu lokasyondan (pod öldüğünde bu kısımda bulunan dosyalarda silinecektir) da verilebilirler. hostPath kullanılarak node üzerinden volume ataması yapıldığında, pod’lar tüm node’lar üzerinde aynı volume’ü arayacaklardır. Bu dizinler aynı olmazsa uygulamada tutarsızlık yaşanması olağandır. Bu bahsettiğimiz volume tipleri daha çok logging ve cache mekanizmaları için uygundur. Bu sebeple uygulamalar için network storage kullanılması daha doğrudur.
Çok geniş organizasyonlarda bir çok pod’un bulunduğu mimarilerde her bir pod için ayrı ayrı volume definition’ı yapılması gerekir. Bu işlemi bir storage pool’undan uygulama gereksinimine göre otomatik olarak atamak için persistent volume ve persistent volume claim yapılarını kullanmak gerekir.
Persistent Volume kavramını biraz daha açıklayalım,
Administrator’lar tarafından kullanıcıların uygulamalarınu deploy ederken kullanmaları için yapılandırılan kalıcı storage birimleridir. Kubernetes mimarisinde bu storage birimlerine Persistent Volume ismi verilir.
Bu resource Kubernetes API tarafından oluşturulur. Azure platformu üzerinde yukarıda da bahsettiğim gibi Azure Disk ve Azure Files resource’ları persistent volume olarak kullanılabilirler. Bu birimler cluster dışında, storage olarak kullanılabilecek Azure Resource’larıdır. Burada hangi resource tipinin seçileceğini belirleyen en temel unsur, tutulan dataya birden çok pod’un eş zamanlı erişip erişmeyeceğidir.
Azure platformu üzerine oluşturulan persistent volume’ler cluster’ı yöneten admin tarafından statik olarak yada Kubernetes API tarafından dinamik olarak oluşturulabilir.
Eğer pod belli bir storage türüne gerek duyacak şekilde oluşturulursa (Yani pod definition file’ı üzerinde bir persistent volume tanımlaması yapıldıysa) fakay böyle bir volume hali hazırda bulunmuyorsa Kubernetes otomatik olarak belirtilen storage class’ına göre Azure disk yada Azure Files oluşturup ilgili pod’a attach eder. Bu yapılan işlem dynamic provisioning olarak isimlendirilir. Burada hangi tipte resource’un attach edileceğini StorageClass belirler.
Storage Class ne işe yarar?
Persistent volume olarak kullanılacak storage’ların tier’larını belirlemek için (premium yada standard) storage class’lar kullanılır. Kubernetes mimarisi üzerinde persistent volume oluştururken kullanılan bir attribute bulunur. Bu attribute’un ismi reclaimPolicy’dir. Bu policy pod’un yaşam döngüsüne bağlı olarak persistent volume’un ne olacağına karar verir. Bu attribute üzerinde yapılan konfigürasyon ile kullanılan storage pod ile birlikte silinir yada başka bir pod tarafından kullanılmasına izin verilir.
AKS mimnarisinde default olarak iki adet storage class bulunur. Bunları aşağıdaki gibi görüntüleyebilirsiniz.
Bu storage class’ları birer cümle ile açıklayacak olursak:
- Default: Kullanılacak managed disk oluşturulurken Azure standard storage kullanılır. Kubernetes üzerindeki persistent volume objesi silindiğinde reclaimPolicy tarafından Azure üzerindeki disk otomatik olarak silinir.
- Managed-premium: Managed disk oluşturulurken premium storage kullanılır. Burada da aynı şekilde persistent volume Kubernetes üzerinde silindiğinde, oluşturulan managed premium disk otomatik olarak silinir.
Eğer persistent volume oluşturulurken herhangi bir storage class belirtilmezse default storageclass otomatik olarak seçilir.
Özet olarak AKS mimarisindeki storage kullanımından bahsetmiş olduk.
Fırat