Kubernetes PVC Pending: Disk Neden Bağlanmıyor?

Uygulamanızı yayımladınız ama Pod başlamıyor, depolama talebi de Pending durumunda bekliyor. Önce talebin neden karşılanmadığını bulmanız gerekir. Olay kayıtları, ayarları rastgele değiştirmeden sorunun depolama sınıfında mı, disk oluşturma işleminde mi yoksa düğüm seçiminde mi olduğunu ayırt etmenize yardımcı olur.

Örnek senaryoda, mevcut bir Amazon EKS kümesinde yanlış depolama sınıfı adı nedeniyle bekleyen talebi ele alacağız. Önce talebin boş ve hiçbir diskle eşleşmemiş olduğunu kontrol edecek, ardından doğru sınıfla yeniden oluşturacağız. Siz de bu akışı izleyerek yalnız durum etiketinin değiştiğini değil, uygulamanın diske dosya yazıp okuyabildiğini kontrol edebileceksiniz.

PVC Pending durumunu olay kayıtlarıyla ayırt edin

Kubernetes PVC Pending, kalıcı depolama talebinin henüz bir depolama kaynağıyla eşleşmediğini gösterir. PVC (PersistentVolumeClaim), uygulamanızın kapasite ve erişim biçimi gibi ihtiyaçlarını bildiren taleptir. PV (PersistentVolume), bu talebi karşılayan diski veya başka bir depolama kaynağını Kubernetes içinde temsil eder. PVC’nin Bound olması, PV ile eşleştiği anlamına gelir; diskin uygulama içinde kullanılabildiğini tek başına kanıtlamaz.

Pod, uygulama kapsayıcılarının çalıştığı birimdir. Pod başlamıyorsa önce talebin mi karşılanamadığını, yoksa eşleşmiş diskin mi kullanılamadığını ayırın. Bu ayrım, yanlış kaynağı değiştirmenizi önler. Kubernetes'in temel çalışma mantığı kaynaklar arasındaki ilişkiyi anlamanızı kolaylaştırır.

Önce doğru küme ve namespace’i kontrol edin

Örnek senaryoda Linux işçi düğümleri bulunan mevcut bir Amazon EKS, yani AWS’nin yönetilen Kubernetes hizmeti üzerindeki kümeyi kullanıyoruz; küme kurulumu kapsam dışında. Aşağıdaki komutları kubectl erişimi olan yönetici terminalinizde çalıştırın. Bağlam, komutların hangi kümeye ve hangi kullanıcı kimliğiyle gönderildiğini; namespace ise kaynakların bulunduğu ad alanını belirler.

kubectl config current-context
kubectl config view --minify
kubectl get namespace pvc-demo
kubectl get pvc -n pvc-demo

İlk iki komutun çıktısındaki küme ve kullanıcı bilgilerinin hedef EKS ortamınıza ait olduğundan emin olun. Son iki komutta ad alanını ve içindeki talepleri görmelisiniz. Örnekte talep adı app-data, namespace pvc-demo. Kendi sorununuzu inceliyorsanız bunları mevcut kaynak adlarınızla değiştirin. NotFound veya boş liste gördüğünüzde disk hatası aramadan önce ad alanının doğru ve kaynağın oluşturulmuş olup olmadığını kontrol edin. Forbidden ise komutu çalıştıran kimliğin ilgili kaynağa erişim yetkisi olmadığını gösterir.

PVC olaylarından ilk ayrımı yapın

Doğru talebi bulduktan sonra ayrıntılarını ve olay kayıtlarını okuyun. İlk komut talebin mevcut durumunu, ikincisi bu talebe ait olayları oluşturulma zamanına göre listeler. Bu komutlar kaynakları değiştirmez:

kubectl describe pvc app-data -n pvc-demo
kubectl get events -n pvc-demo --field-selector involvedObject.kind=PersistentVolumeClaim,involvedObject.name=app-data --sort-by=.metadata.creationTimestamp

describe çıktısında Status talebin durumunu, StorageClass depolama sınıfını, Volume ise eşleşen PV adını gösterir. Depolama sınıfı, diskin hangi sürücü ve ayarlarla sağlanacağını belirler. Events, yani olay kayıtları bölümünde olayın nedenini ve açıklamasını birlikte okuyun:

• storageclass.storage.k8s.io "gp3-typo" not found: Talepte belirtilen depolama sınıfı bulunamıyor. Önce talepteki sınıf adının kümede tanımlı bir sınıfla eşleşip eşleşmediğine bakın.
• WaitForFirstConsumer: Disk tahsisi, talebi kullanacak Pod’un hangi düğümde çalışacağı belirlenene kadar bekliyor olabilir. Bu bekleme tek başına arıza değildir; talebi kullanan Pod’un varlığını ve yerleşim durumunu kontrol edin.
• ProvisioningFailed: Disk oluşturma veya tahsis işlemi başarısız olmuş. Hangi düzeltmenin gerektiğini mesajın devamındaki yetki, kapasite veya sürücü açıklaması belirler.

Olaylar sınırlı süre tutulur; boş Events listesi sorun olmadığı anlamına gelmez. PVC Bound olduğu hâlde uygulama başlamıyorsa talep eşleşmesini geçmişsiniz demektir. Sıradaki ipucunu Pod olaylarında arayın:

kubectl describe pod disk-check -n pvc-demo

Bu komut örnekteki tüketici Pod’u inceler; kendi ortamınızda talebi kullanan Pod’un adını kullanın. Pod henüz oluşturulmadıysa bulunamadığını belirten yanıt almanız bir disk bağlama hatası değildir.

Pod mevcutsa FailedAttachVolume diskin düğüme takılması, FailedMount ise depolamanın Pod’a bağlanması aşamasındaki soruna işaret eder. Olay mesajının devamı hangi disk veya bağlama işleminin etkilendiğini açıklar. Bunları PVC Pending ile aynı sorun saymayın; bu aşamada eşleşmiş talebi silmek yerine Pod olayındaki nedene göre ilerleyin.

Örnek ortamı doğrulayın ve StorageClass hatasını düzeltin

Olay kaydı gp3-typo not found diyorsa talepte yazan depolama sınıfı bulunamıyor demektir. Doğru sınıfı oluşturmadan önce kullanacağı sürücünün hazır olduğundan emin olun. Bu örnek senaryo, standart Amazon EKS üzerinde Linux EC2 işçi düğümleri içindir; EKS Auto Mode veya yalnız Fargate kullanan kümelerde aynı ayarlar geçerli değildir.

EKS, sürücü ve yetkileri kontrol edin

Komutları kubectl ve AWS CLI, yani AWS komut satırı aracı bulunan yönetici terminalinizde çalıştırın. AWS kimliğiniz hedef kümeyi ve eklentilerini okuyabilmeli. Aşağıdaki örnek küme adı ile bölgeyi kendi değerlerinizle değiştirin; ardından AWS’nin gösterdiği küme adresini kubectl bağlantısıyla karşılaştırın:

export CLUSTER=my-eks
export AWS_REGION=eu-central-1
aws sts get-caller-identity
aws eks describe-cluster --name "$CLUSTER" --region "$AWS_REGION" --query 'cluster.{Status:status,Endpoint:endpoint}'
kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}'
kubectl get nodes -L kubernetes.io/os,topology.kubernetes.io/zone
kubectl auth can-i create storageclasses.storage.k8s.io
kubectl auth can-i create persistentvolumeclaims -n pvc-demo
kubectl auth can-i delete persistentvolumeclaims -n pvc-demo
kubectl auth can-i list persistentvolumes

Kümenin durumu ACTIVE, iki çıktıda görünen API adresleri aynı ve uygun Linux düğümleri Ready olmalı. Yetki kontrolleri de yes dönmeli. Böylece değişikliği doğru kümede yapacağınızı ve listelenen işlemlere izniniz olduğunu görürsünüz. Yetki eksikse geniş yönetici erişimi istemek yerine ilgili kaynak ve işlem için küme yöneticinizden izin isteyin.

CSI, Kubernetes ile depolama sistemi arasındaki sürücü arayüzüdür. Örnekte AWS EBS CSI eklentisinin ve disk oluşturmak için gereken IAM rolünün mevcut olduğu varsayılıyor. IAM, AWS kaynaklarına erişimi belirleyen yetki sistemidir. Aşağıdaki komutlarla eklentinin durumunu, rol bağlantısını ve Kubernetes tarafındaki sürücü bileşenlerini inceleyin:

aws eks describe-addon --cluster-name "$CLUSTER" --addon-name aws-ebs-csi-driver --region "$AWS_REGION" --query 'addon.{Status:status,Role:serviceAccountRoleArn,PodIdentity:podIdentityAssociations,Health:health.issues}'
aws eks list-pod-identity-associations --cluster-name "$CLUSTER" --namespace kube-system --service-account ebs-csi-controller-sa --region "$AWS_REGION"
kubectl get csidriver ebs.csi.aws.com
kubectl -n kube-system get deployment ebs-csi-controller
kubectl -n kube-system get daemonset ebs-csi-node
kubectl get csinode -o yaml

Eklenti ACTIVE olmalı; denetleyici ve düğüm bileşenlerinin hazır sayıları beklenen sayılarla eşleşmeli. Hedef düğümlerin CSINode kayıtlarında ebs.csi.aws.com bulunması, sürücünün bu düğümlere kaydolduğunu gösterir.

IAM rolü, servis hesabı rolü veya Pod Identity ilişkilendirmesi üzerinden sağlanabilir. Pod Identity, Pod’lara AWS rolü atama yöntemidir; iki yöntemin aynı anda tanımlı olması gerekmez. Rolün görünmesi disk oluşturma iznini tek başına kanıtlamaz; bu izin gerçek tahsis sırasında sınanır. Eklenti eksikse veya hazır değilse önce bu sorunu çözün; depolama sınıfı oluşturmak sürücüyü kurmaz.

Örneğe özel StorageClass oluşturun

StorageClass, diskin hangi sürücü ve ayarlarla oluşturulacağını belirleyen depolama sınıfıdır. Önce kubectl get storageclass gp3-demo -o yaml ile mevcut tanımı kontrol edin. Sınıf bulunmuyorsa terminalde aşağıdaki dosyayı oluşturup uygulayın. Sınıf zaten varsa alanlarını örnekle karşılaştırın; farklı ayarların üzerine yazmayın. Oluşturma adımını atlıyorsanız sonraki dosyaları kaydetmek için çalışma dizininizde pvc-demo klasörünün bulunduğundan emin olun.

mkdir -p ./pvc-demo
cat > ./pvc-demo/storageclass.yaml <<'EOF'
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: gp3-demo
provisioner: ebs.csi.aws.com
parameters:
  type: gp3
volumeBindingMode: WaitForFirstConsumer
reclaimPolicy: Retain
EOF
kubectl apply -f ./pvc-demo/storageclass.yaml
kubectl get storageclass gp3-demo -o yaml

Son komutun çıktısında sürücü ve ayar alanları dosyayla eşleşmeli. WaitForFirstConsumer, disk oluşturmayı diski kullanacak Pod’un yerleşimi belirlenene kadar erteler. Retain ise talep silindiğinde diskin otomatik silinmesini önler. Bu seçim diski korur ancak disk oluşturulduktan sonra bulut maliyeti doğabilir; kullanım bitince elle temizlik gerekir.

Yalnız boş ve eşleşmemiş talebi yeniden oluşturun

Bu örnekteki yanlış sınıf adı mevcut PVC üzerinde doğrudan değiştirilemez. Talebi yeniden oluşturmak gerekir; ancak önce mevcut tanımı kaydedip talebin herhangi bir disk veya veriyle ilişkili olmadığını kontrol edin:

kubectl get pvc app-data -n pvc-demo -o yaml > ./pvc-demo/pvc-before.yaml
kubectl get pvc app-data -n pvc-demo -o jsonpath='{.status.phase}{"\n"}{.spec.volumeName}{"\n"}{.metadata.uid}{"\n"}'
kubectl get pv -o custom-columns='NAME:.metadata.name,NS:.spec.claimRef.namespace,CLAIM:.spec.claimRef.name,UID:.spec.claimRef.uid,DISK:.spec.csi.volumeHandle'
kubectl describe pvc app-data -n pvc-demo
PVC_UID=$(kubectl get pvc app-data -n pvc-demo -o jsonpath='{.metadata.uid}')
aws ec2 describe-volumes --region "$AWS_REGION" --filters "Name=tag:CSIVolumeName,Values=pvc-$PVC_UID" --query 'Volumes[].VolumeId'

İlerlemek için durum Pending, volumeName değeri boş olmalı. PV listesinde talebin adı ve benzersiz kimliğiyle eşleşen kayıt bulunmamalı; Used By alanında da talebi kullanan bir Pod görünmemeli. Bu koşulların tamamını birlikte değerlendirin.

Son komut, standart sürücü etiketleri üzerinden AWS’de disk arar. Geçmişte tahsis denemesi varsa boş sonuç tek başına disk oluşmadığını kanıtlamaz. Sürücü kayıtlarını ve aynı AWS hesabı ile bölgedeki disk envanterini de inceleyin; disk bulunursa veya durum belirsiz kalırsa silme adımına geçmeyin.

Kontroller uygunsa yeni talebi aşağıdaki dosyaya yazın. Talep, az önce kontrol ettiğiniz depolama sınıfını kullanır. 5Gi istenen kapasiteyi, ReadWriteOnce tek düğümden yazılabilir erişimi, Filesystem ise diskin dosya sistemi olarak kullanılacağını belirtir:

cat > ./pvc-demo/pvc.yaml <<'EOF'
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: app-data
  namespace: pvc-demo
spec:
  storageClassName: gp3-demo
  accessModes:
    - ReadWriteOnce
  volumeMode: Filesystem
  resources:
    requests:
      storage: 5Gi
EOF
kubectl delete pvc app-data -n pvc-demo
kubectl apply -f ./pvc-demo/pvc.yaml
kubectl describe pvc app-data -n pvc-demo

Silme tamamlanmıyorsa işlemi zorlamayın veya koruma alanlarını kaldırmayın; yeni talebi uygulamadan önce silmenin neden beklediğini inceleyin. Yeni talebin ayrıntılarında sınıf gp3-demo görünmeli. Henüz diski kullanacak Pod olmadığı için WaitForFirstConsumer nedeniyle Pending kalması beklenir; bu aşamada aynı durum etiketi artık sınıf adının yanlış olduğunu göstermez.

Geri dönüş gerekirse yeni talebin de yukarıdaki disk ve veri bulunmadığını gösteren kontrolleri geçtiğinden emin olun. Kaydettiğiniz pvc-before.yaml dosyasının bir kopyasını düzenleyin: üst düzeydeki status alanını; metadata altındaki uid, resourceVersion, creationTimestamp, managedFields ile denetleyicinin eklediği annotations ve finalizers alanlarını çıkarın. Bu düzenleme yalnız dosya kopyası içindir; canlı kaynağın koruma alanlarını kaldırmayın.

Ardından boş yeni talebi silip temizlenmiş dosyayı uygulayın. Bu işlem yalnız eski talep tanımını geri getirir; gp3-typo hatasını çözmez. Normal akışta sıradaki adım, düzeltilmiş talebi kullanacak Pod’u oluşturmaktır.

Tüketici Pod’u oluşturun ve diskin kullanılmasını doğrulayın

app-data artık doğru sınıfı kullanıyorsa bu talebi kullanacak Pod’u oluşturabilirsiniz. WaitForFirstConsumer ayarında zamanlayıcı, yani Pod’un çalışacağı düğümü seçen bileşen, önce uygun yerleşimi belirler. CSI sürücüsü de diski bu yerleşime uygun oluşturur. Böylece disk, Pod’un çalışamayacağı bir erişilebilirlik alanında önceden oluşturulmaz.

Talebi kullanan Pod’u başlatın

Yönetici terminalinizde aşağıdaki dosyayı oluşturup uygulayın. Pod, PVC ile aynı pvc-demo ad alanında çalışır; claimName: app-data kullanılacak talebi seçer, mountPath: /data ise diskin dosya sistemini kapsayıcı içinde bu yoldan erişilebilir yapar. Örnekte kullanılan BusyBox imajının indirilebilmesi için düğümlerin ilgili imaj deposuna erişimi olmalı. Son komut, talebin durumundaki değişiklikleri ekranda izlemenizi sağlar.

cat > ./pvc-demo/pod.yaml <<'EOF'
apiVersion: v1
kind: Pod
metadata:
  name: disk-check
  namespace: pvc-demo
spec:
  nodeSelector:
    kubernetes.io/os: linux
  containers:
    - name: check
      image: busybox:1.36
      command: ["sh", "-c", "sleep 86400"]
      volumeMounts:
        - name: data
          mountPath: /data
  volumes:
    - name: data
      persistentVolumeClaim:
        claimName: app-data
EOF
kubectl apply -f ./pvc-demo/pod.yaml
kubectl get pvc app-data -n pvc-demo -w

Beklenen geçiş Pending durumundan Bound durumunadır. İzlemeyi Ctrl+C ile kapatmak kaynakları silmez. Pod tanımına nodeName eklemeyin: doğrudan düğüm atamak zamanlayıcıyı atlar ve bu bekleme modunda talebin Pending kalmasına yol açabilir.

AWS bölgesi ile erişilebilirlik alanı aynı şey değildir: eu-central-1 bir bölge, eu-central-1a onun içindeki bir erişilebilirlik alanıdır. EBS diski, onu kullanacak EC2 düğümüyle aynı erişilebilirlik alanında olmalıdır. Örnekte alanı elle sabitlemiyoruz; zamanlayıcı uygun Linux düğümünü seçerken depolamanın hangi alanda kullanılabileceğini de dikkate alır.

Eşleşmeyi ve dosya erişimini doğrulayın

İzlemeyi kapattıktan sonra aynı terminalde aşağıdaki komutları çalıştırın. İlk komut Pod’un hazır olmasını bekler; diğerleri talebin durumunu ve Pod’un hangi düğüme yerleştiğini gösterir. Buradaki 180s yalnız komutun bekleme sınırıdır; disk oluşturma süresi garantisi değildir.

kubectl wait -n pvc-demo --for=condition=Ready pod/disk-check --timeout=180s
kubectl get pvc app-data -n pvc-demo
kubectl get pod disk-check -n pvc-demo -o wide
kubectl get nodes -L topology.kubernetes.io/zone

PVC Bound, Pod Running ve hazır kapsayıcı sayısı 1/1 olmalı. Pod çıktısındaki NODE sütununda görünen düğümü, düğüm listesinde bulun; alan etiketi Pod’un hangi erişilebilirlik alanında çalıştığını gösterir. Bekleme zaman aşımına uğrarsa kaynakları yeniden oluşturmak yerine aşağıdaki çıktılardaki olay kayıtlarına bakarak işlemin hangi aşamada kaldığını belirleyin:

kubectl describe pvc app-data -n pvc-demo
kubectl describe pod disk-check -n pvc-demo

Pod hazırsa dosya erişimini sınamak için terminalinizden aşağıdaki komutu çalıştırın. Komut, kapsayıcının diske bağlı /data dizinine bir dosya yazar ve yazma başarılıysa içeriğini okur. set -C, aynı adlı dosya varsa üzerine yazılmasını engeller.

kubectl exec -n pvc-demo disk-check -- sh -c 'set -C; printf "disk kontrolu tamam\n" > /data/check.txt && cat /data/check.txt'

Beklenen çıktı disk kontrolu tamam metnidir. Dosya zaten varsa kubectl exec -n pvc-demo disk-check -- cat /data/check.txt ile içeriğini okuyun; bu durumda yeni bir yazma işlemi yapılmadığını dikkate alın. Başarılı yazma ve okuma, PVC eşleşmesinin yanında bağlı dosya sisteminin kullanılabildiğini de gösterir. Ancak bu kontrol, Pod yeniden oluşturulduktan sonra verinin korunmasını veya yedekten dönüşü sınamaz.

Pending sürüyorsa CSI, kapasite ve erişim modunu inceleyin

Kubernetes PVC Pending durumu sürüyorsa bütün ayarları değiştirmek yerine olay mesajının işaret ettiği nedeni inceleyin. Aşağıdaki komutları aynı yönetici terminalinde çalıştırın. Her düzeltmeden sonra kubectl describe pvc app-data -n pvc-demo çıktısındaki yeni olaylara bakın; eski hata satırları hemen kaybolmayabilir.

CSI kayıtlarında yetki hatasını ayırın

ExternalProvisioning tek başına yetki hatası değildir; disk sağlayan bileşenin beklendiğini belirtir. ProvisioningFailed varsa CSI denetleyicisinin disk işlemlerini ve tahsis sürecini yöneten bileşenin kayıtlarını okuyun. Aşağıdaki komutlar son 15 dakikanın kayıtlarını getirir:

kubectl logs -n kube-system deployment/ebs-csi-controller -c ebs-plugin --since=15m
kubectl logs -n kube-system deployment/ebs-csi-controller -c csi-provisioner --since=15m

Bu komutlar birden fazla denetleyici Pod’unun tüm kayıtlarını toplamaz; başka denetleyici Pod’ları varsa onların kayıtlarını da inceleyin. UnauthorizedOperation veya AccessDenied gördüğünüzde, mesajdaki reddedilen işlem ve kaynak hangi iznin eksik olduğunu anlamanızı sağlar.

AWS konsolunda IAM – Roles (roller) bölümünden daha önce doğruladığınız CSI rolünü açın. Rolün izin politikasının bir kopyasını saklayın, ardından yalnız hata mesajındaki işlem ve kaynak için gereken izni düzeltin. Mesajda AWS’nin anahtar yönetimi hizmeti KMS’ye ait bir şifreleme anahtarı geçiyorsa anahtar politikasını da kontrol edin. Yönetici kullanıcınıza izin eklemek CSI rolünü düzeltmez. Yeni tahsis denemesinde aynı reddin tekrarlanmadığını kontrol edin; değişikliği geri almak gerekirse sakladığınız politikayı kullanın.

Kota ile gerçek kapasite sorununu ayırın

exceeded quota Kubernetes kotasına, VolumeLimitExceeded ise AWS tarafındaki sınıra işaret edebilir. Kota, kullanımınıza izin verilen üst sınırdır; sağlayıcının o anda disk oluşturabilecek kapasiteye sahip olmasıyla aynı şey değildir. Önce namespace kotalarındaki kullanılan ve izin verilen değerleri karşılaştırın:

kubectl describe resourcequota -n pvc-demo

Çıktıdaki Used kullanılan miktarı, Hard ise izin verilen sınırı gösterir. Kubernetes kotası çoğunlukla talebin oluşturulmasını veya büyütülmesini reddeder; bu nedenle mevcut bir Pending talebi tek başına açıklamaz. AWS sınırı için aynı bölgeyi seçerek Service Quotas (hizmet kotaları) ekranını açın ve Amazon EBS kotalarını inceleyin. Hata mesajında belirtilen sınıra ulaşıldıysa ilgili kota için artış isteyin; disk silerek yer açmayı ilk çözüm yapmayın.

InsufficientCapacity gibi sağlayıcı kapasite hatalarında kota artışı çözüm olmayabilir. Mesajdaki erişilebilirlik alanını kontrol edin; hata geçiciyse sürücünün sonraki tahsis denemelerini izleyin. Başka alana geçişi ancak Pod’un yerleşim koşulları ve verinin konumu buna uygunsa değerlendirin. Düzeltmenin işe yaradığını yeni tahsis olaylarından ve PVC’nin Bound olmasından anlayabilirsiniz.

Erişim modu ve statik PV eşleşmesini kontrol edin

unsupported access mode veya uygun disk bulunamadığını belirten olaylarda talebi ve mevcut kalıcı disk kayıtlarını karşılaştırın. Burada amaç, talebin istediği erişim biçimini ve kapasiteyi depolamanın karşılayıp karşılamadığını bulmaktır:

kubectl get pvc app-data -n pvc-demo -o yaml
kubectl get pv -o yaml

Örnekteki gp3 diski ReadWriteMany, yani birden fazla düğümden yazma talebini karşılamaz. Bu örneğin erişim modu ReadWriteOnce olmalıdır; bu tek Pod değil, tek düğümden yazılabilir erişim anlamına gelir. Yanlış talebi yalnız önceki bölümdeki kontrollerle PV, disk ve veri oluşmadığını doğruladıysanız yeniden oluşturun. Uygulamanız gerçekten birden fazla düğümden paylaşımlı erişim istiyorsa talebi daraltmak yerine bu ihtiyacı karşılayan depolama seçin.

Statik, yani önceden oluşturulmuş PV kullanıyorsanız bu örnekte kapasite en az 5Gi olmalı; sınıf ve volumeMode dosya sistemi ya da blok cihaz kullanım biçimiyle eşleşmelidir. PV’nin erişim modları da talebi karşılamalıdır. Ayrıca selector etiket seçimini, volumeName belirli bir PV’ye yönlendirmeyi, claimRef ise PV’nin hangi talebe ayrıldığını gösterir.

Başka talebe ayrılmış veya Released durumundaki PV otomatik olarak yeniden kullanıma hazır sayılmaz; üzerinde eski veri bulunabilir. Verinin hangi uygulamaya ait olduğu ve yeniden kullanımın güvenli olduğu doğrulanmadan claimRef silmeyin. Uygun ve başka talebe ayrılmamış PV ile eşleşme sağlandığında PVC’nin Bound durumuna geçtiğini kontrol edin.

Topoloji engelini Pod olaylarından bulun

kubectl describe pod disk-check -n pvc-demo
kubectl get storageclass gp3-demo -o yaml
kubectl get nodes -L topology.kubernetes.io/zone

Bu çıktılar Pod’un neden yerleşemediğini, depolama sınıfının yerleşim sınırlarını ve düğümlerin erişilebilirlik alanlarını karşılaştırmanızı sağlar. FailedScheduling genel bir yerleşim hatasıdır; mesajda volume node affinity conflict de varsa Pod için uygun düğümlerle diskin kullanılabildiği düğümler uyuşmuyor olabilir.

Pod’un nodeSelector etiket seçimini ve affinity yerleşim koşullarını, sınıfın allowedTopologies izin verilen depolama konumlarıyla karşılaştırın. Eşleşmiş bir PV varsa onun nodeAffinity alanındaki düğüm koşullarını da inceleyin. Böylece engelin Pod kısıtından mı, sınıftan mı yoksa mevcut diskin konumundan mı kaynaklandığını ayırabilirsiniz.

Yalnız yanlış olduğu doğrulanan Pod kısıtını düzeltin. Örnek Pod için önce pod.yaml dosyasının kopyasını saklayın; dosyadaki hatalı yerleşim koşulunu düzenleyin. Yazma işlemleri varsa güvenli biçimde durdurduktan sonra yalnız disk-check Pod’unu silip düzenlenmiş dosyayı yeniden uygulayın; PVC’yi silmeyin. Geri dönüş gerekirse aynı işlemi sakladığınız Pod tanımıyla yapabilirsiniz.

Diskin erişilebilirlik alanında uygun düğüm yoksa o alanda düğüm kapasitesi sağlayın. Düğümün alan etiketini değiştirmek diski veya düğümü taşımaz ve sorunu çözmez. Son kontrolde Pod’a bir düğüm atanmış olmalı ve yeni zamanlama hatası oluşmamalıdır; ardından önceki bölümdeki dosya erişimi kontrolüne dönebilirsiniz.

Sık Sorulan Sorular

PVC başka bir namespace’ten kullanılabilir mi?

Hayır. Pod, yalnız kendi namespace’i, yani ad alanı içindeki PVC’yi doğrudan kullanabilir. Örnekte disk-check Pod’u ve app-data talebi bu nedenle pvc-demo içinde bulunur. Başka namespace’te aynı adla PVC oluşturmanız mevcut diske erişim sağlamaz; ayrı bir depolama talebi oluşturur. PV küme genelinde tanımlansa da aynı anda yalnız bir PVC ile eşleşir.

Uygulamayı başka namespace’e taşıyacaksanız hedefte ayrı depolama oluşturup veriyi kontrollü biçimde aktarmayı planlayın. Aynı EBS diskini iki ayrı PV kaydıyla paylaşmaya çalışmak güvenli bir kısayol değildir.

StorageClass değişikliği mevcut diski taşır mı?

Hayır. StorageClass, yani depolama sınıfı, diskin nasıl sağlanacağını tanımlar; mevcut veriyi başka diske veya erişilebilirlik alanına taşımaz. Bağlanmış bir PVC’nin storageClassName alanını normal bir güncellemeyle değiştiremezsiniz. Varsayılan sınıfı değiştirmeniz de sınıfı zaten belirlenmiş mevcut talepleri dönüştürmez.

Farklı sınıfa geçmeniz gerekiyorsa hedef sınıfı kullanan yeni bir PVC oluşturun. Uygulamaya uygun yedekleme ve geri yükleme ya da veri kopyalama yöntemiyle aktarım yapın. Son veri aktarımı sırasında uygulamanın yazmalarını durdurun veya uygulamanızın desteklediği bir eşitleme yöntemi kullanın. Hedefte verinin eksiksiz ve okunabilir olduğunu kontrol ettikten sonra uygulamayı yeni talebe yönlendirin. Geri dönüş için eski diski, yeni depolamayla uygulamanın çalıştığını doğrulayana kadar koruyun.

Pod silinince diskteki veri kalır mı?

Bu örnekte evet: yalnız disk-check Pod’unu silmeniz, ayrı oluşturduğunuz app-data PVC’sini ve EBS diskini silmez. Yeniden oluşturulan Pod aynı PVC’yi /data yoluna bağlarsa diske yazılmış dosyalara erişebilir. Kapsayıcının bu yol dışındaki geçici dosyaları için aynı güvence yoktur; henüz diske aktarılmamış, bellekte bekleyen yazmalar da kaybolabilir.

PVC’yi silmek farklı bir işlemdir. Örnekteki Retain politikası diski korur ancak eski veriyi yeni bir talebe otomatik olarak bağlamaz. Delete politikasında ise PVC silindikten sonra disk de silinebilir. Pod silerek kalıcılığı sınayacaksanız önce uygulamanın yazmalarını güvenli biçimde durdurun ve bekleyen yazmaların diske aktarılmasını sağlayın.

Uygulama yedeği için disk anlık görüntüsü yeterli mi?

Her zaman değil. Disk anlık görüntüsü, depolamanın belirli bir andaki durumunu saklar; çalışan veritabanının belleğinde bekleyen verileri kapsamaz ve birden fazla diske yayılan işlemlerin tutarlılığını tek başına garanti etmez. Geri yüklemede veritabanının kurtarma işlemi yapması gerekebilir.

Veritabanınızın desteklediği yedekleme yöntemini kullanın veya anlık görüntü öncesinde yazmaları uygulamanın desteklediği biçimde duraklatıp bekleyen verilerin diske aktarılmasını sağlayın. Ayrıca Kubernetes manifestlerini, yani kaynak tanım dosyalarını, gerekli ayarları ve gizli bilgileri güvenli biçimde yedekleyin. Yedeği ayrı bir ortamda geri yükleyin; uygulamanın açıldığını ve beklediğiniz verileri okuyabildiğini kontrol edin.

Kapanış kontrol listesi: Depolamayı uygulamaya teslim edin

Depolamayı uygulamaya teslim etmeden önce yalnız PVC’nin eşleştiğini değil, Pod’un diski kullanabildiğini de kontrol edin. Aynı yönetici terminalinde şu listeyi tamamlayın:

• PVC/PV eşleşmesi: kubectl get pvc app-data -n pvc-demo -o wide çıktısında durum Bound, kapasite 5Gi, sınıf gp3-demo olmalı. VOLUME sütununda görünen PV’yi PV listesinde bulun; bu kaydın CLAIM alanı da pvc-demo/app-data talebini göstermeli.
• Pod yerleşimi: kubectl get pod disk-check -n pvc-demo -o wide çıktısında durumun Running olduğunu ve bir düğüm atandığını kontrol edin. Daha önce topoloji hatası gördüyseniz düğümün erişilebilirlik alanıyla PV’nin yerleşim koşullarını karşılaştırın; bunlar birbiriyle uyumlu olmalı.
• Yazma ve okuma: Önceki dosya kontrolünde /data/check.txt içine yazdığınız değeri kubectl exec -n pvc-demo disk-check -- cat /data/check.txt ile yeniden okuyun. Beklenen içerik görünmeli; yalnız Pod’un çalışması yazma yetkisini kanıtlamaz.
• Yeni olaylar: kubectl describe pvc app-data -n pvc-demo ve kubectl describe pod disk-check -n pvc-demo çıktılarındaki olayların zamanına bakın. Eski uyarıların listede kalmasından çok, düzeltmeden sonra aynı hatanın tekrarlanıp tekrarlanmadığına odaklanın.

Talep hâlâ Pending ise depolama sınıfı, tüketici bekleme veya CSI sürücüsünün disk tahsis işlemiyle ilgili kontrollere dönün. Talep Bound olduğu hâlde Pod başlayamıyorsa Pod olaylarındaki zamanlama, disk takma ve dosya sistemi bağlama hatalarını izleyin.

Pod çalışıyor ama yazamıyorsa önce bağlama yolunu, salt okunur ayarını ve dosya izinlerini inceleyin; PVC’yi yeniden oluşturmayın. Çalışan depolama akışındaki sorunları takip etmek için Kubernetes izleme kurulumu ile devam edebilirsiniz.

Deneme kaynaklarını veriyi koruyarak temizleyin

Deneme kaynaklarını kaldıracaksanız önce diskin kimliğini ve PV üzerinde geçerli olan silme politikasını kaydedin. Aşağıdaki komutları yalnız PVC Bound olduktan sonra yönetici terminalinde çalıştırın; PV adı boşsa silmeye geçmeyin:

PV=$(kubectl get pvc app-data -n pvc-demo -o jsonpath='{.spec.volumeName}')
kubectl get pv "$PV" -o yaml > ./pvc-demo/pv-before-cleanup.yaml
kubectl get pv "$PV" -o jsonpath='{.spec.persistentVolumeReclaimPolicy}{"\n"}{.spec.csi.volumeHandle}{"\n"}'

Çıktının ilk satırında beklenen politika Retain, ikinci satırında EBS disk kimliği bulunur. YAML kaydı yalnız kaynak tanımını saklar; veri yedeği değildir. Saklanacak veri varsa silmeden önce uygulamaya uygun yedeğini alın ve bu yedekten geri dönebildiğinizi kontrol edin. Politikada Delete görüyorsanız aşağıdaki silme adımlarına geçmeyin: bu durumda PVC’nin silinmesi diski de silebilir ve burada anlatılan diski koruma akışı geçerli olmaz.

Politikanın diski koruduğunu ve yalnız artık gerekmeyen deneme verisi kaldığını kontrol ettikten sonra önce tüketici Pod’u, ardından talebi kaldırın:

kubectl delete pod disk-check -n pvc-demo
kubectl delete pvc app-data -n pvc-demo
kubectl get pv "$PV"

Retain ile PV’nin Released durumuna geçmesi beklenir; EBS diski kalır ve ücret oluşmaya devam edebilir. Bu aşama diski silmez, ancak eski veriyi yeni bir talebe otomatik olarak da bağlamaz.

Kalıcı temizlik için AWS konsolunda EC2 – Volumes (diskler) bölümünü açın ve örnekte kullandığınız bölgede kaydettiğiniz disk kimliğini bulun. Diskin bağlantısız ve artık gereksiz olduğunu kontrol ettikten sonra Actions – Delete volume (işlemler – diski sil) ile silin. Bu işlem diskteki veriyi kaldırır; saklamanız gereken veri varsa yedekten dönüşünüz hazır olmadan ilerlemeyin.

Diskin silindiğini gördükten sonra kubectl delete pv "$PV" ile Kubernetes kaydını temizleyin. Başka talep kullanmıyorsa örneğe özel sınıfı da kubectl delete storageclass gp3-demo ile kaldırabilirsiniz.