Bugün sizler için bana en çok gelen sorulardan biri olan Red Hat OCP’deki depolama birimi kavramlarını açıklayıcı bir yazı yazmaya karar verdim. Temel aldığımı Red Hat OCP sürümü 4.7’dir.
Öncelikle pod’larımız için geçici veya kalıcı depolama alanları kullanabiliriz. Geçici depolama alanları, “ephemeral” kelimesiyle ifade ediliyor. Geçici depolamanın ömrü, “pod”un ömrünü geçmez. Kalıcı volümlerin aksine, geçici depolama alanları bir “node” üzerinde çalışan tüm “pod”lar tarafından kullanılır. Elbette bu kullanıma ek olarak, sistem tarafından, konteyner çalışma zamanı ve OCP tarafından da kullanılır. Geçici depolama sayesinde, “node”ların aşırı yerel disk alanı kullanımının önüne geçilebilir. Geçici depolama yapısı, sistem yöneticilerin ve geliştiricilerin yerel disk alanını yönetmesine olanak sağlarken, elbette I/O işlem hacmi ve I/O gecikmesiyle ilgili bir vaatte bulunmaz.
Geçici depolama türleri nelerdir? Geçici yerel depolama her zaman “primary partition”da sağlanır. “Primary partition” oluşturmanın iki temel yöntemi vardır: “root” ve “runtime”.
“Root”:
Bu bölümleme, varsayılan olarak kubelet kök dizinini, “/var/lib/kubelet/” ve “/var/log/” dizinini tutar. Kullanıcı “pod”ları, işletim sistemi ve Kubernetes “daemon”lar arasında paylaşılabilir. Bu bölümlemedeki alan, “pod”lar tarafından EmptyDir volümleri aracılığıyla tüketilirler. Konteyner günlükleri, imaj katmanları ve konteyner yazılabilir katmanları bu alanı tüketen işlemlere örnektirler. Kubelet, bu bölümlemenin paylaşımlı erişimini ve izolasyonunu yönetir. Bu bölümleme geçici olduğu için uygulamalar, bu bölümlemeden disk IOPS gibi herhangi bir performans SLA’sı bekleyemez.
“Runtime”:
Opsiyonel bir bölümlemedir. “Overlay” dosya sistemi yapısı için kullanılır. Bu bölümleme için OCP’nin kendisi izolasyonla birlikte paylaşılan erişimi belirlemeye ve sağlamaya çalışır. Konteyner imaj katmanları ve yazılabilir imaj katmanları burada saklanır. “Runtime” bölümlemesi varsa, “root” herhangi bir imaj katmanını tutmaz.
“Cluster” yöneticileri, bir proje içinde geçici depolamayı yönetebilirler. Kota konfigürasyonu yapabilirler, depolama alanına gelen istek sayısını belirleyebilirler. Geliştiriciler de, gerek “pod” seviyesinde gerekse konteyner seviyesinde isteklerin ve sınırların konfigürasyonunu yapabilirler. Geçici konteyner verisinin bulunduğu volümdeki alanın kullanımını (“/var/lib/kubelet ve /var/lib/containers”) izlemek için “df” komutunu kullanabilirsiniz.
Evet gelelim kalıcı volüm kavramına (“persistent volume”). OCP, “cluster” yöneticilerinin bir “cluster” için kalıcı depolama sağlamasına olanak tanımak için “Kubernetes Persistent Volume” fonksiyonunu kullanır. Geliştiriciler, temel depolama altyapısı hakkında özel bilgiye sahip olmadan PV kaynaklarını talep etmek için PVC’leri (“Persistent Volume Claims”) kullanabilir.
PVC’ler bir projeye özeldir ve geliştiriciler tarafından bir PV (“persistent volume”) kullanmak için bir araç olarak oluşturulur ve kullanılır. PV kaynakları tek başlarına herhangi bir projeye dahil edilmemiştir; tüm OCP “cluster”ında paylaşılabilir ve herhangi bir projeden alınabilir. Bir PV, PVC’ye bağlandıktan sonra, bu PV ek PVC’lere bağlanamaz. Bu sayede PV, ilgili “namespace”e bağlanmış olur.
PV’ler, “cluster” yöneticisi tarafından statik veya bir “StorageClass” nesnesi sayesinde dinamik olarak PersistentVolume API nesnesiyle tanımlanmaktadır. PVC’ler belirli bir depolama kapasitesi ve erişim modları talep edebilir. Örneğin, bir kez okuma-yazma veya çoğu kez salt okunur olarak “mount” edilebilirler.
Bu noktada PV ve PVC kavramlarını çok iyi öğrenmemiz gerekiyor. PV’ler “Cluster” içindeki kaynaklardır. PVC’ler ise bu kaynaklar için gelen isteklerdir. Bir PVC oluşturduğunuzda, belirli bir depolama alanı talep edersiniz, gerekli erişim modunu belirtirsiniz ve depolamayı açıklamak ve sınıflandırmak için bir depolama sınıfı (“storage class”) oluşturursunuz. “Pod”lar, istekleri/talepleri (“claims”), volüm olarak kullanırlar.
Veri kaybı yaşamamamız için faydalı bir özellik mevcut: “Storage Object in Use Protection”. Varsayılan olarak bu özellik aktiftir. Bir kullanıcı, bir “pod” tarafından aktif kullanımda olan bir PVC’yi silerse, PVC hemen silinmez. PVC silme işlemi, PVC artık herhangi bir “pod” tarafından aktif olarak kullanılmayana kadar ertelenir. Ayrıca, bir “cluster” yöneticisi bir PVC’ye bağlı bir PV’yi silerse, PV hemen silinmez. PV’nin silinmesi, PV artık bir PVC’ye bağlı kalmayıncaya kadar ertelenir.
Bir volüme ihtiyacınız kalmadığında, PVC nesnesini API’den silebilirsiniz, bu da kaynağın yeniden talep edilmesini sağlar. Diğer taraftan, volüm, talep silindiğinde serbest bırakılmış olarak kabul edilir, ancak henüz başka bir talep için kullanılabilir durumda değildir. Önceki talebin/isteğin verileri tanımlanan politikaya göre ele alınır (“retain”, “recycle”, “delete”). Dinamik olarak sağlanan birimler her zaman silinir.
“Persistentvolume” nesne tanımı nasıl yapılır? Oldukça kolay. Yaml dosyaları şeklinde yapılandırabilirsiniz.
Aşağıda bir örnek görüyoruz.
1- Kalıcı volümün adını tanımlar.
2- Volüm için kullanılabilir depolama miktarını belirler.
3- Erişim modunu tanımlar.
4- Volümün serbest bırakıldıktan sonra nasıl kullanılması gerektiğini belirten geri alma politikasını ifade eder.
Red Hat OCP, hangi volüm “plug-in”lerini destekler? Gerçekten çok sayıda var: AWS’den GCE’ye, iSCSI’den NFS’e, Red Hat OCS’den VMware vSphere’a kadar pek çok.
“Persistent volume” ile ilgili en önemli kavramlardan birisi, bu volüme nasıl erişileceğidir.
“persistent volume”, kaynak sağlayıcı tarafından desteklenen herhangi bir şekilde “host”a bağlanabilir. Sağlayıcıların farklı yetenekleri vardır ve her PV’nin erişim modları, o volüm tarafından desteklenen belirli modlara ayarlanır. Örneğin, NFS birden çok okuma-yazma istemcisini destekleyebilir, ancak belirli bir NFS PV, sunucuda salt okunur olarak dışa aktarılmak istenebilir.
NFS, bizim eski emektar, her üç erşimi modunu desteklemektedir. Red Hat OCS, “ReadWriteOnce” ve “ReadWriteMany”i desteklemektedir. VMware vSphere, ReadWriteOnce desteklemektedir. Ek açıklama (“annotation”) kullanarak bir PV’nin “mount” opsiyonlarını belirleyebilirsiniz.
annotations:
volume.beta.kubernetes.io/mount-options: rw,nfsvers=4,noexec
Her PV türü mount opsiyonlarını desteklemez. Örneğin, “Fibre Channel” ve “HostPath” PV’ler, “mount” opsiyonlarını desteklemez.
PersistentVolumeClaim nesne tanımı örneğine bir bakalım.
1- PVC’nin ismini belirtir.
2- PVC için erişim modunu tanımlar.
3- PVC’nin kullanabileceği alanı belirtir.
4- Talebin gerektirdiği “StorageClass”ın ismi.
“StorageClass” şu ana kadar bir kaç cümle içinde geçti. Nedir “StorageClass”? StorageClass, yöneticilerin sundukları depolama “sınıflarını” tanımlamaları için bir yöntem sağlamaktadır. Farklı sınıflar, hizmet kalitesi düzeyleriyle veya yedekleme ilkeleriyle veya küme yöneticileri tarafından belirlenen rastgele ilkelerle eşleştirilebilir. Her “StorageClass”, PV’lerin sağlanması için hangi volüm eklentisinin kullanılacağını belirleyen bir provizyona (“provisioner”) sahiptir.
Elbette, asıl amacımızı unutmayalım, asıl amacımız, “pod”ların kalıcı volümleri kullanmasını sağlayabilmek. “Pod”lar, talebi bir volüm olarak kullanarak depolama alanına erişir. Talepler (“claims”), “pod”larla aynı isim alanında (“namespace”) olmalıdır. Aşağıda bir “pod” örneği görüyoruz.
1- “Pod”a “mount” edeceğimiz adresi tanımlar.
2- “Mount” edeceğimizin volümün ismini belirtir.
3- Aynı ad alanında/isim alanında/”namespace” de buluna PVC’nin ismini tanımlar.
OpenShift Container Platform, “raw” blok volümlerini statik olarak sağlayabilir. Bu volümlerin bir dosya sistemi yoktur ve doğrudan diske yazan veya kendi depolama hizmetlerini uygulayan uygulamalar için performans avantajları sağlayabilmektedir. “Raw” blok volümleri, PV ve PVC spesifikasyonunda volumeMode: Block belirtilerek sağlanır. Örneğin Red Hat OCS ve VMware vSphere bu yapıyı destekler.
Son olarak CSI’dan bahsedeceğim. İkinci bölümde, bu yazımda teorik olarak aktardıklarımı GUI üzerinden örneklerle aktarmak istiyorum. CSI konteyner ortamlarda artık olmaz ise olmaz kavramlardan birisi. Yedekleme yapılarını bile yapılandırırken depolama birimini CSI desteği var mı diye sormamız gerekiyor. “Container Storage Interface (CSI)”, Kubernetes gibi “Container Orchestration Systems” yapılarda rastgele blok ve dosya depolama sistemlerini, konteyner hale getirilmiş iş yüklerine sağlamaya yönelik bir standarttır. Üçüncü taraf depolama sağlayıcıları, CSI kullanarak, çekirdek Kubernetes koduna dokunmak zorunda kalmadan Kubernetes’te çalışacak şekilde eklentiler yazabilirler. “OpenShift Container Platform”, belirli CSI sürücülerini varsayılan olarak yükleyerek kullanıcılara “in-tree volume” eklentileriyle mümkün olmayan depolama seçenekleri sunabilmektedir. “OpenShift Container Platform”, varsayılan olarak gerekli CSI sürücü Operatörünü, CSI sürücüsünü ve gerekli depolama sınıfını (“StorageClass”) yükler. CSI’ın sağladığı özellikler sayesinde, “snapshot” oluşturabilir, klon çıkarabilir ve volümün büyüklüğünü değiştirebilirsiniz.
Kalıcı depolamanın dinamik olarak sağlanması, CSI sürücüsünün yeteneklerine ve temel alınan depolama arka ucuna (“back-end”) bağlıdır. CSI sürücüsünün sağlayıcısı, “OpenShift Container Platform”da bir depolama sınıfının (“StorageClass”) nasıl oluşturulacağını ve yapılandırma için kullanılabilen parametreleri döküman şeklinde sunmalıdır.
“Node”larda çalıştırılan CSI sürücü arka plan programları (“daemon set”), OCP’nin CSI sürcüsü tarafından sağlanan depolama alanını, “node”lara “mount” etmesini sağlar. Bu sayede, “pod”lar iş yüklerinde kullanmak için bu alanları kalıcı volümler olarak kullanabilir.
Umarım Red Hat OCP için depolama birimleri kavramları bu yazımda sizler için bir anlam bulmuştur. İkinci bölümde görüşmek üzere.
Sarav Asiye Yiğit – 9 Mayıs 2021 – Anneler Günü
Leave A Comment