Kubernetes kümelerinde pod depolamayı yönetme

Tamamlandı

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ü

1.

Contoso geliştiricileri durum bilgisi olan iş yüklerini kapsayıcılı hale getirmek için çalıştığından, Azure Stack HCI üzerinde AKS dağıtımınızı kullanarak kalıcı pod depolamanın uygulanmasını test etmek istiyorsunuz. Önce neyi tanımlamanız gerekiyor?