Kubernetes kümelerinde pod depolamayı yönetme
Azure Stack HCI üzerinde AKS'ye dağıtmayı planladığınız uygulamaların çoğu durum bilgisi olmasa da, Contoso geliştiricileri kapsayıcı oluşturmayı planladıkları durum bilgisi olan birkaç iş yükü belirledi. Bu gereksinimi karşılamak için Kubernetes kalıcı birimlerini kullanarak çalışan podların durumunu koruma desteğini keşfetmeniz gerekir.
Azure Stack HCI üzerinde AKS için kalıcı birimler uygulama
Varsayılan olarak, tek tek podlar durum bilgisi olmayan kaynaklar olarak çalışır. Dağıtımın parçası olan bir pod bir nedenden dolayı başarısız olursa Kubernetes scheduler otomatik olarak eşleşen işlevselliği sağlayan yeni bir tane oluşturur ve kapsayıcılı uygulamanın kullanılabilir durumda kalmasını sağlar. Ancak, durumu korumak için ek hükümler olmadan, başarısız podunun üzerinde çalışmış olabileceği tüm veriler kaybolur.
Podların verilerini ve durumlarını kalıcı hale getirmek ve paylaşmak için kullanabilecekleri senaryolar vardır. Bu senaryolarda, kapsayıcılı iş yüklerinin verilerini tek tek podların kullanım ömrünün ötesinde depolamaya olanak tanıyan küme kaynakları olan kalıcı birimleri kullanabilirsiniz.
Kubernetes kümesinde birim uygulamak için belirli bir depolama sınıfı için kalıcı birim talebi tanımlamanız gerekir. Depolama sınıfı, temel alınan depolamanın performans veya paylaşılan erişim desteği gibi özelliklerini temsil eder. Kalıcı birim talebi, gerekli erişim modu ve birim boyutu hakkında bilgi içerir. Kubernetes API sunucusu, dağıtılan podlar için gerekli olduğunda uygun bir depolama birimini dinamik olarak sağlamak için kalıcı birim talep tanımını kullanır.
Dekont
Azure Stack HCI üzerinde AKS, VHDX tabanlı diskler uygulayan varsayılan depolama sınıfını sunar.
İlgili bildirim dosyalarına kalıcı birim belirtimleri ekleyerek dağıtılan podların depolama gereksinimlerini tanımlayın. Bu işlem, dinamik sağlamayı tetiklemenin yanı sıra podların içindeki birimi de otomatik olarak bağlar.
Örneğin, aşağıdaki bildirim, varsayılan depolama sınıfını kullanan 100 GB paylaşılmayan disk için kalıcı birim talebi tanımlar.
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc-akshci
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 100Gi
Bu kalıcı birim talebi uygulamak için, bu bildirimi bir YAML dosyası olarak depolayabilir ve kubectl komut satırı yardımcı programını çalıştırarak karşılık gelen kaynağı oluşturabilirsiniz (burada pvc_definition.yaml
YAML dosyasını temsil eder):
kubectl create -f pvc_definition.yaml
Pod için karşılık gelen kalıcı birimi tanımlamak için aşağıdaki bildirimi kullanabilirsiniz:
kind: Pod
apiVersion: v1
metadata:
name: win-appserver
spec:
containers:
- name: win-appserver
image: mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019
volumeMounts:
- name: akshciscsi
mountPath: "/mnt/akshciscsi"
volumes:
- name: akshciscsi
persistentVolumeClaim:
claimName: pvc-akshci
nodeSelector:
kubernetes.io/os: windows
Bu kalıcı birimi de uygulamak için pod bildirimini YAML dosyası olarak depolayabilir ve kubectl komut satırı yardımcı programını çalıştırarak birimi sağlayabilir ve bağlayabilirsiniz (burada pv_definition.yaml
YAML dosyasını temsil eder):
kubectl create -f pv_definition.yaml
Sonuçta elde edilen podun boyutu, öğenin değeri tarafından belirlenen dosya sistemi yoluna bağlanmış 100 GB'lık bir boyuta mountPath
sahip olur.
Kalıcı birim talebi silmek için, önce o anda kullanmakta olan podları ve dağıtımları silmeniz gerekir. Bu noktada, görevi tamamlamak için komutunu ve ardından kalıcı birim talebi adını kullanabilirsiniz kubectl delete PersistentVolumeClaim
.
Bilgi kontrolü
Yardıma mı ihtiyacınız var? Sorun giderme kılavuzumuza gözatın veya sorun bildirerek belirli bir konuda geri bildiriminizi paylaşın.