Kubernetes: PV macet saat penghentian setelah PVC dihapus

Beberapa pertanyaan:
1) Bagaimana saya bisa keluar dari situasi ini?
2) haruskah PV berhasil dihentikan setelah pengemudi kembali sukses bahkan ketika volumenya sudah hilang?

/ sig storage

Sepertinya PV Anda masih memiliki finalizer dari attacher. Dapatkah Anda memverifikasi bahwa volume berhasil dilepaskan dari node?

Mungkin bagus untuk mendapatkan log dari external-attacher, dan juga AD controller

cc @jsafrane

Versi attacher-eksternal apa yang Anda gunakan?

itu v0.3.0. Dan semua mobil samping lainnya ada di v0.3.0 juga. Saya menggunakan v0.4.0 sebelumnya dan masalah ini terjadi setelah saya membuat ulang mobil samping di v0.3.0.

Memperbarui deskripsi dengan log pelampirkan

Sepertinya PV Anda masih memiliki finalizer dari attacher. Dapatkah Anda memverifikasi bahwa volume berhasil dilepaskan dari node?

Volume harus berhasil dilepaskan. Karena itu berhasil dihapus dari AWS (jangan berpikir itu bisa dihapus tanpa melepaskannya). Juga diverifikasi pada node bahwa perangkat hilang menggunakan lsblk .

Sepertinya volume telah ditandai untuk dihapus sebelum lampiran berhasil. Mungkin ada bug dalam menangani skenario itu.

Apakah Anda masih melihat objek VolumeAttachment?

Apakah Anda masih melihat objek VolumeAttachment?

Bagaimana cara memeriksa ini?

kubectl mendapatkan lampiran volume

Ya. Masih ada:

>> kubectl get volumeattachment
NAME                                                                   CREATED AT
csi-3b15269e725f727786c5aec3b4da3f2eebc2477dec53d3480a3fe1dd01adea53   2018-10-10T22:30:09Z

Membaca log, sepertinya pengontrol A / D mencoba memasang volume dan mendapat kesalahan dari attacher eksternal. Mengapa tidak menghapus VolumeAttachment sesudahnya? Apakah Anda masih memiliki pod yang menggunakan volume? Jika demikian, itu memblokir penghapusan PV.

Tidak ada pod yang menggunakan volume. Dan PVC juga hilang. Bagaimana cara menemukan log pengontrol A / D?

Ini ada di node master, controller-manager.log. Anda dapat mencoba memfilter dengan mencari nama volume.

Berikut adalah log pengontrol:

E1011 19:14:10.336074       1 daemon_controller.go:304] default/csi-node failed with : error storing status for daemon set &v1.DaemonSet{TypeMeta:v1.TypeMeta{Kind:"", APIVersion:""}, O
bjectMeta:v1.ObjectMeta{Name:"csi-node", GenerateName:"", Namespace:"default", SelfLink:"/apis/apps/v1/namespaces/default/daemonsets/csi-node", UID:"d4e56145-cd89-11e8-9e90-0abab70c948
0", ResourceVersion:"467814", Generation:1, CreationTimestamp:v1.Time{Time:time.Time{wall:0x0, ext:63674882050, loc:(*time.Location)(0x5b9b560)}}, DeletionTimestamp:(*v1.Time)(nil), De
letionGracePeriodSeconds:(*int64)(nil), Labels:map[string]string(nil), Annotations:map[string]string{"deprecated.daemonset.template.generation":"1"}, OwnerReferences:[]v1.OwnerReferenc
e(nil), Initializers:(*v1.Initializers)(nil), Finalizers:[]string(nil), ClusterName:""}, Spec:v1.DaemonSetSpec{Selector:(*v1.LabelSelector)(0xc4233ac360), Template:v1.PodTemplateSpec{O
bjectMeta:v1.ObjectMeta{Name:"", GenerateName:"", Namespace:"", SelfLink:"", UID:"", ResourceVersion:"", Generation:0, CreationTimestamp:v1.Time{Time:time.Time{wall:0x0, ext:0, loc:(*t
ime.Location)(nil)}}, DeletionTimestamp:(*v1.Time)(nil), DeletionGracePeriodSeconds:(*int64)(nil), Labels:map[string]string{"app":"csi-node"}, Annotations:map[string]string(nil), Owner
References:[]v1.OwnerReference(nil), Initializers:(*v1.Initializers)(nil), Finalizers:[]string(nil), ClusterName:""}, Spec:v1.PodSpec{Volumes:[]v1.Volume{v1.Volume{Name:"kubelet-dir",
VolumeSource:v1.VolumeSource{HostPath:(*v1.HostPathVolumeSource)(0xc4233ac380), EmptyDir:(*v1.EmptyDirVolumeSource)(nil), GCEPersistentDisk:(*v1.GCEPersistentDiskVolumeSource)(nil), AW
SElasticBlockStore:(*v1.AWSElasticBlockStoreVolumeSource)(nil), GitRepo:(*v1.GitRepoVolumeSource)(nil), Secret:(*v1.SecretVolumeSource)(nil), NFS:(*v1.NFSVolumeSource)(nil), ISCSI:(*v1
.ISCSIVolumeSource)(nil), Glusterfs:(*v1.GlusterfsVolumeSource)(nil), PersistentVolumeClaim:(*v1.PersistentVolumeClaimVolumeSource)(nil), RBD:(*v1.RBDVolumeSource)(nil), FlexVolume:(*v
1.FlexVolumeSource)(nil), Cinder:(*v1.CinderVolumeSource)(nil), CephFS:(*v1.CephFSVolumeSource)(nil), Flocker:(*v1.FlockerVolumeSource)(nil), DownwardAPI:(*v1.DownwardAPIVolumeSource)(
nil), FC:(*v1.FCVolumeSource)(nil), AzureFile:(*v1.AzureFileVolumeSource)(nil), ConfigMap:(*v1.ConfigMapVolumeSource)(nil), VsphereVolume:(*v1.VsphereVirtualDiskVolumeSource)(nil), Quobyte:(*v1.QuobyteVolumeSource)(nil), AzureDisk:(*v1.AzureDiskVolumeSource)(nil), PhotonPersistentDisk:(*v1.PhotonPersistentDiskVolumeSource)(nil), Projected:(*v1.ProjectedVolumeSource)(nil), PortworxVolume:(*v1.PortworxVolumeSource)(nil), ScaleIO:(*v1.ScaleIOVolumeSource)(nil), StorageOS:(*v1.StorageOSVolumeSource)(nil)}}, v1.Volume{Name:"plugin-dir", VolumeSource:v1.VolumeSource{HostPath:(*v1.HostPathVolumeSource)(0xc4233ac3a0), EmptyDir:(*v1.EmptyDirVolumeSource)(nil), GCEPersistentDisk:(*v1.GCEPersistentDiskVolumeSource)(nil), AWSElasticBlockStore:(*v1.AWSElasticBlockStoreVolumeSource)(nil), GitRepo:(*v1.GitRepoVolumeSource)(nil), Secret:(*v1.SecretVolumeSource)(nil), NFS:(*v1.NFSVolumeSource)(nil), ISCSI:(*v1.ISCSIVolumeSource)(nil), Glusterfs:(*v1.GlusterfsVolumeSource)(nil), PersistentVolumeClaim:(*v1.PersistentVolumeClaimVolumeSource)(nil), RBD:(*v1.RBDVolumeSource)(nil), FlexVolume:(*v1.FlexVolumeSource)(nil), Cinder:(*v1.CinderVolumeSource)(nil), CephFS:(*v1.CephFSVolumeSource)(nil), Flocker:(*v1.FlockerVolumeSource)(nil), DownwardAPI:(*v1.DownwardAPIVolumeSource)(nil), FC:(*v1.FCVolumeSource)(nil), AzureFile:(*v1.AzureFileVolumeSource)(nil), ConfigMap:(*v1.ConfigMapVolumeSource)(nil), VsphereVolume:(*v1.VsphereVirtualDiskVolumeSource)(nil), Quobyte:(*v1.QuobyteVolumeSource)(nil), AzureDisk:(*v1.AzureDiskVolumeSource)(nil), PhotonPersistentDisk:(*v1.PhotonPersistentDiskVolumeSource)(nil), Projected:(*v1.ProjectedVolumeSource)(nil), PortworxVolume:(*v1.PortworxVolumeSource)(nil), ScaleIO:(*v1.ScaleIOVolumeSource)(nil), StorageOS:(*v1.StorageOSVolumeSource)(nil)}}, v1.Volume{Name:"device-dir", VolumeSource:v1.VolumeSource{HostPath:(*v1.HostPathVolumeSource)(0xc4233ac3c0), EmptyDir:(*v1.EmptyDirVolumeSource)(nil), GCEPersistentDisk:(*v1.GCEPersistentDiskVolumeSource)(nil), AWSElasticBlockStore:(*v1.AWSElasticBlockStoreVolumeSource)(nil), GitRepo:(*v1.GitRepoVolumeSource)(nil), Secret:(*v1.SecretVolumeSource)(nil), NFS:(*v1.NFSVolumeSource)(nil), ISCSI:(*v1.ISCSIVolumeSource)(nil), Glusterfs:(*v1.GlusterfsVolumeSource)(nil), PersistentVolumeClaim:(*v1.PersistentVolumeClaimVolumeSource)(nil), RBD:(*v1.RBDVolumeSource)(nil), FlexVolume:(*v1.FlexVolumeSource)(nil), Cinder:(*v1.CinderVolumeSource)(nil), CephFS:(*v1.CephFSVolumeSource)(nil), Flocker:(*v1.FlockerVolumeSource)(nil), DownwardAPI:(*v1.DownwardAPIVolumeSource)(nil), FC:(*v1.FCVolumeSource)(nil), AzureFile:(*v1.AzureFileVolumeSource)(nil), ConfigMap:(*v1.ConfigMapVolumeSource)(nil), VsphereVolume:(*v1.VsphereVirtualDiskVolumeSource)(nil), Quobyte:(*v1.QuobyteVolumeSource)(nil), AzureDisk:(*v1.AzureDiskVolumeSource)(nil), PhotonPersistentDisk:(*v1.PhotonPersistentDiskVolumeSource)(nil), Projected:(*v1.ProjectedVolumeSource)(nil), PortworxVolume:(*v1.PortworxVolumeSource)(nil), ScaleIO:(*v1.ScaleIOVolumeSource)(nil), StorageOS:(*v1.StorageOSVolumeSource)(nil)}}}, InitContainers:[]v1.Container(nil), Containers:[]v1.Container{v1.Container{Name:"csi-driver-registrar", Image:"quay.io/k8scsi/driver-registrar:v0.3.0", Command:[]string(nil), Args:[]string{"--v=5", "--csi-address=$(ADDRESS)"}, WorkingDir:"", Ports:[]v1.ContainerPort(nil), EnvFrom:[]v1.EnvFromSource(nil), Env:[]v1.EnvVar{v1.EnvVar{Name:"ADDRESS", Value:"/csi/csi.sock", ValueFrom:(*v1.EnvVarSource)(nil)}, v1.EnvVar{Name:"KUBE_NODE_NAME", Value:"", ValueFrom:(*v1.EnvVarSource)(0xc4233ac400)}}, Resources:v1.ResourceRequirements{Limits:v1.ResourceList(nil), Requests:v1.ResourceList(nil)}, VolumeMounts:[]v1.VolumeMount{v1.VolumeMount{Name:"plugin-dir", ReadOnly:false, MountPath:"/csi", SubPath:"", MountPropagation:(*v1.MountPropagationMode)(nil)}}, VolumeDevices:[]v1.VolumeDevice(nil), LivenessProbe:(*v1.Probe)(nil), ReadinessProbe:(*v1.Probe)(nil), Lifecycle:(*v1.Lifecycle)(nil), TerminationMessagePath:"/dev/termination-log", TerminationMessagePolicy:"File", ImagePullPolicy:"Always", SecurityContext:(*v1.SecurityContext)(0xc422ccc050), Stdin:false, StdinOnce:false, TTY:false}, v1.Container{Name:"ebs-plugin", Image:"quay.io/bertinatto/ebs-csi-driver:testing", Command:[]string(nil), Args:[]string{"--endpoint=$(CSI_ENDPOINT)", "--logtostderr", "--v=5"}, WorkingDir:"", Ports:[]v1.ContainerPort(nil), EnvFrom:[]v1.EnvFromSource(nil), Env:[]v1.EnvVar{v1.EnvVar{Name:"CSI_ENDPOINT", Value:"unix:/csi/csi.sock", ValueFrom:(*v1.EnvVarSource)(nil)}, v1.EnvVar{Name:"AWS_ACCESS_KEY_ID", Value:"", ValueFrom:(*v1.EnvVarSource)(0xc4233ac460)}, v1.EnvVar{Name:"AWS_SECRET_ACCESS_KEY", Value:"", ValueFrom:(*v1.EnvVarSource)(0xc4233ac480)}}, Resources:v1.ResourceRequirements{Limits:v1.ResourceList(nil), Requests:v1.ResourceList(nil)}, VolumeMounts:[]v1.VolumeMount{v1.VolumeMount{Name:"kubelet-dir", ReadOnly:false, MountPath:"/var/lib/kubelet", SubPath:"", MountPropagation:(*v1.MountPropagationMode)(0xc422c717e0)}, v1.VolumeMount{Name:"plugin-dir", ReadOnly:false, MountPath:"/csi", SubPath:"", MountPropagation:(*v1.MountPropagationMode)(nil)}, v1.VolumeMount{Name:"device-dir", ReadOnly:false, MountPath:"/dev", SubPath:"", MountPropagation:(*v1.MountPropagationMode)(nil)}}, VolumeDevices:[]v1.VolumeDevice(nil), LivenessProbe:(*v1.Probe)(nil), ReadinessProbe:(*v1.Probe)(nil), Lifecycle:(*v1.Lifecycle)(nil), TerminationMessagePath:"/dev/termination-log", TerminationMessagePolicy:"File", ImagePullPolicy:"Always", SecurityContext:(*v1.SecurityContext)(0xc422ccc0f0), Stdin:false, StdinOnce:false, TTY:false}}, RestartPolicy:"Always", TerminationGracePeriodSeconds:(*int64)(0xc422d68b30), ActiveDeadlineSeconds:(*int64)(nil), DNSPolicy:"ClusterFirst", NodeSelector:map[string]string(nil), ServiceAccountName:"csi-node-sa", DeprecatedServiceAccount:"csi-node-sa", AutomountServiceAccountToken:(*bool)(nil), NodeName:"", HostNetwork:true, HostPID:false, HostIPC:false, ShareProcessNamespace:(*bool)(nil), SecurityContext:(*v1.PodSecurityContext)(0xc42325ec60), ImagePullSecrets:[]v1.LocalObjectReference(nil), Hostname:"", Subdomain:"", Affinity:(*v1.Affinity)(nil), SchedulerName:"default-scheduler", Tolerations:[]v1.Toleration(nil), HostAliases:[]v1.HostAlias(nil), PriorityClassName:"", Priority:(*int32)(nil), DNSConfig:(*v1.PodDNSConfig)(nil), ReadinessGates:[]v1.PodReadinessGate(nil), RuntimeClassName:(*string)(nil)}}, UpdateStrategy:v1.DaemonSetUpdateStrategy{Type:"RollingUpdate", RollingUpdate:(*v1.RollingUpdateDaemonSet)(0xc424139a40)}, MinReadySeconds:0, RevisionHistoryLimit:(*int32)(0xc422d68b38)}, Status:v1.DaemonSetStatus{CurrentNumberScheduled:2, NumberMisscheduled:0, DesiredNumberScheduled:3, NumberReady:0, ObservedGeneration:1, UpdatedNumberScheduled:2, NumberAvailable:0, NumberUnavailable:3, CollisionCount:(*int32)(nil), Conditions:[]v1.DaemonSetCondition(nil)}}: Operation cannot be fulfilled on daemonsets.apps "csi-node": the object has been modified; please apply your changes to the latest version and try again
I1011 19:15:14.740106       1 pv_controller.go:601] volume "pvc-069128c6ccdc11e8" is released and reclaim policy "Delete" will be executed
I1011 19:15:14.756316       1 pv_controller.go:824] volume "pvc-069128c6ccdc11e8" entered phase "Released"
I1011 19:15:14.759557       1 pv_controller.go:1294] isVolumeReleased[pvc-069128c6ccdc11e8]: volume is released
I1011 19:15:14.939461       1 pv_controller.go:1294] isVolumeReleased[pvc-069128c6ccdc11e8]: volume is released
I1011 19:15:14.954828       1 pv_controller.go:1294] isVolumeReleased[pvc-069128c6ccdc11e8]: volume is released

Baris terakhir diulang tanpa batas.

Saya mengalami masalah ini dua kali lagi sekarang. Semua di v1.12

Saya menyingkirkan masalah ini dengan melakukan tindakan berikut:
Chandras-MacBook-Pro:kubernetes-kafka chandra$ kubectl get pv | grep "kafka/" pvc-5124cf7a-e9dc-11e8-93a1-02551748eea0 1Gi RWO Retain Bound kafka/data-pzoo-0 kafka-zookeeper 21h pvc-639023b2-e9dc-11e8-93a1-02551748eea0 1Gi RWO Retain Bound kafka/data-pzoo-1 kafka-zookeeper 21h pvc-7d88b184-e9dc-11e8-93a1-02551748eea0 1Gi RWO Retain Bound kafka/data-pzoo-2 kafka-zookeeper 21h pvc-9ea68541-e9dc-11e8-93a1-02551748eea0 100Gi RWO Delete Terminating kafka/data-kafka-0 kafka-broker 21h pvc-ae795177-e9dc-11e8-93a1-02551748eea0 100Gi RWO Delete Terminating kafka/data-kafka-1 kafka-broker 21h
Kemudian saya secara manual mengedit pv satu finalizers yang terlihat seperti ini:
`` finalisator:

• kubernetes.io / pv-protection```

Setelah selesai, PV yang berada dalam kondisi Menghentikan semuanya hilang !!!

Jawaban dari @ chandraprakash1392 masih berlaku jika pvc juga dalam status Terminating .
Anda hanya perlu mengedit objek pvc dan menghapus objek finalizers .

Menghapus finalizer hanyalah solusi. @bertinatto @leakingtapan dapatkah Anda membantu memperbaiki masalah ini dan menyimpan log driver CSI dan manajer pengontrol secara mendetail?

contoh penghapusan untuk finalisator

kubectl patch pvc db-pv-claim -p '{"metadata":{"finalizers":null}}'
kubectl patch pod db-74755f6698-8td72 -p '{"metadata":{"finalizers":null}}'

lalu Anda dapat menghapusnya

!!! PENTING !!!:
Baca juga https://github.com/kubernetes/kubernetes/issues/78106
Perintah patch adalah solusi dan ada sesuatu yang tidak berfungsi dengan baik.
Ada volume yang masih terpasang: kubectl get volumeattachments!

Menghapus finalizer hanyalah solusi. @bertinatto @leakingtapan dapatkah Anda membantu memperbaiki masalah ini dan menyimpan log driver CSI dan manajer pengontrol secara mendetail?

Saya berhasil mereproduksinya setelah beberapa kali mencoba, meskipun pesan log tampak sedikit berbeda dari yang dilaporkan oleh @leakingtapan :

Plugin (penyedia): https://gist.github.com/bertinatto/16f5c1f76b1c2577cd66dbedfa4e0c7c
Plugin (attacher): https://gist.github.com/bertinatto/25ebd591ffc88d034f5b4419c0bfa040
Manajer pengontrol: https://gist.github.com/bertinatto/a2d82fdbccbf7ec0bb5e8ab65d47dcf3

Sama di sini, harus menghapus finalizer, berikut penjelasan untuk pv:

[root@ip-172-31-44-98 stateful]# k describe pv pvc-1c6625e2-1157-11e9-a8fc-0275b365cbce Name: pvc-1c6625e2-1157-11e9-a8fc-0275b365cbce Labels: failure-domain.beta.kubernetes.io/region=us-east-1 failure-domain.beta.kubernetes.io/zone=us-east-1a Annotations: kubernetes.io/createdby: aws-ebs-dynamic-provisioner pv.kubernetes.io/bound-by-controller: yes pv.kubernetes.io/provisioned-by: kubernetes.io/aws-ebs Finalizers: [kubernetes.io/pv-protection] StorageClass: default Status: Terminating (lasts <invalid>) Claim: monitoring/storage-es-data-0 Reclaim Policy: Delete Access Modes: RWO Capacity: 12Gi Node Affinity: <none> Message: Source: Type: AWSElasticBlockStore (a Persistent Disk resource in AWS) VolumeID: aws://us-east-1a/vol-0a20e4f50b60df855 FSType: ext4 Partition: 0 ReadOnly: false Events: <none>

Membaca log, sepertinya pengontrol A / D mencoba memasang volume dan mendapat kesalahan dari attacher eksternal. Mengapa tidak menghapus VolumeAttachment sesudahnya? Apakah Anda masih memiliki pod yang menggunakan volume? Jika demikian, itu memblokir penghapusan PV.

@jsafrane Saya hanya memiliki satu pod, dan saya menghapus PVC setelah Pod dihapus

Saya dapat mereproduksi masalah tersebut secara konsisten. Ini terjadi saat AttachVolume gagal.

Untuk mereproduksi, saya membuat cluster tiga node k8s. Dan saya membuat PV yang disediakan statis setelah membuat volume EBS secara manual. Terapkan spesifikasi:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-test2
  annotations:
    pv.kubernetes.io/provisioned-by: ebs.csi.aws.com
spec:
  accessModes:
    - ReadWriteOnce
  capacity:
    storage: 1Gi
  csi:
    driver: ebs.csi.aws.com
    fsType: ext3
    volumeHandle: vol-0e850f49c7f6aeff0
  persistentVolumeReclaimPolicy: Delete
  volumeMode: Filesystem
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: claim1
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: ""
  resources:
    requests:
      storage: 1Gi
---
apiVersion: v1
kind: Pod
metadata:
  name: app
spec:
  containers:
  - name: app
    image: centos:7
    command: ["/bin/sh"]
    args: ["-c", "while true; do echo $(date -u) >> /data/out.txt; sleep 5; done"]
    volumeMounts:
    - name: persistent-storage
      mountPath: /data
  volumes:
  - name: persistent-storage
    persistentVolumeClaim:
      claimName: claim1

Jika pembuatan Pod gagal karena ketidakcocokan zona, hapus Pod tersebut, lalu hapus PVC. Dan PV akan macet di status penghentian. Saya mereproduksi ini di v1.13

Objek VolumeAttachment:

apiVersion: v1
items:
- apiVersion: storage.k8s.io/v1
  kind: VolumeAttachment
  metadata:
    annotations:
      csi.alpha.kubernetes.io/node-id: i-056c2441224e9988f
    creationTimestamp: 2019-01-07T20:41:36Z
    finalizers:
    - external-attacher/ebs-csi-aws-com
    name: csi-92e3ad4dcfc45346bd1efae253530bb83f34c7cf0ecb3e58da0cf97645de2e54
    resourceVersion: "390447"
    selfLink: /apis/storage.k8s.io/v1/volumeattachments/csi-92e3ad4dcfc45346bd1efae253530bb83f34c7cf0ecb3e58da0cf97645de2e54
    uid: a0632702-12bc-11e9-844f-0a6817dc5d60
  spec:
    attacher: ebs.csi.aws.com
    nodeName: ip-172-20-106-186.ec2.internal
    source:
      persistentVolumeName: pv-test2
  status:
    attachError:
      message: PersistentVolume "pv-test2" is marked for deletion
      time: 2019-01-07T21:17:27Z
    attached: false
kind: List
metadata:
  resourceVersion: ""
  selfLink: ""

Saya pikir objek volumeattachment yang tersisa disebabkan ketika csi_attacher.go gagal memasang volume, objek volumeattachment tidak dihapus

Kita bisa menghapus objek ketika waitForVolumeAttachment gagal. Bagaimana menurut Anda? Saya akan dengan senang hati mengirimkan perbaikannya.

/ cc @jsafrane @ msau42

Saya mereproduksi masalah menggunakan id volume yang tidak ada (lampirkan gagal dengan "Volume 'vol-01213456789' tidak ada").

Kita bisa menghapus objek ketika waitForVolumeAttachment gagal.

Ini sangat rumit. Ada dua jenis kegagalan lampiran:

1. "permanen", volume tidak dapat dipasang: volume EBS tidak ada, memiliki zona yang salah, IAM tidak memiliki cukup izin, ...
2. "sementara", volume mungkin dipasang di (dekat) masa depan: waktu habis, volume sedang dilepaskan dari node lain

Ketika waitForVolumeAttachment gagal, pengontrol A / D tidak tahu apa jenis kegagalan itu. Attacher eksternal masih mencoba memasang volume secara paralel, berharap pada akhirnya akan berhasil.

Terutama saat attacher kehabisan waktu (volume "Melampirkan" untuk waktu yang lebih lama), Anda dapat melihat bahwa driver CSI AWS tidak melepaskan volume saat waitForAttachmentState gagal:

https://sourcegraph.com/github.com/kubernetes-sigs/aws-ebs-csi-driver@ff1fe8e1399784657c10d67649146429dcb93515/ - / blob / pkg / cloud / cloud.go # L300

Itu berarti AWS masih mencoba memasang volume meskipun driver CSI mengembalikan waktu tunggu. ControllerPublish berikutnya harus melanjutkan waitForAttachmentState tempat yang ditinggalkan sebelumnya. Pada titik ini pengontrol A / D tidak boleh menghapus VolumeAttachment, karena itu akan melepaskan volume. Pengontrol A / D akan mencoba memasang kembali volume dalam waktu singkat (yaitu membuat VolumeAttachment baru) dan volume akan mulai "Melampirkan" "dari awal" dan kemungkinan akan kehabisan waktu lagi, membuat putaran pembuatan / penghapusan VolumeAttachment , tetapi tidak pernah menunggu cukup lama hingga keterikatan berhasil.

Kami memiliki beberapa opsi:

1 Pengontrol A / D mengingat bahwa volume sedang dipasang - tidak terpasang (pod tidak dapat dimulai) atau terlepas (Detach () harus dipanggil ketika volume menghilang dari DSW). Ini bisa jadi cukup rumit, terutama saat merekonstruksi status ini setelah pengontrol dimulai ulang.

1. Plugin volume CSI dapat menghapus VolumeAttachment ketika waitForVolumeAttachment gagal, tetapi kemudian kami berharap ControllerPublish / Unpublish cukup cepat (15 detik secara default) dan tidak perlu "dilanjutkan" seperti yang diterapkan sekarang dan dijelaskan di atas. Meningkatkan batas waktu 15 detik mungkin membantu dalam kasus ini (tetapi itu di-hardcode dalam plugin volume CSI dan tidak dapat dikonfigurasi).

cc @gnufied @bertinatto

@ jingxu97 , apakah saya ingat dengan benar bahwa ada sesuatu dalam rekonstruksi volume yang membuat volume tidak di-mount atau di-unmount di VolumeManager? Mungkin kita membutuhkan yang serupa di sini.

@jsafrane sepertinya terkait dengan https://github.com/kubernetes/kubernetes/pull/71276 ini

@ jingxu97 Memang, # 71276 membantu, terima kasih banyak.

Masalah menjadi basi setelah 90d tidak ada aktivitas.
Tandai terbitan sebagai baru dengan /remove-lifecycle stale .
Masalah basi membusuk setelah 30 hari tambahan tidak aktif dan akhirnya ditutup.

Jika masalah ini aman untuk ditutup sekarang, lakukan dengan /close .

Kirimkan masukan ke sig-testing, kubernetes / test-infra dan / atau fejta .
/ siklus hidup basi

/ remove-lifecycle basi

baru saja mengalami masalah ini dan harus menggunakan kubectl edit pv | pvc dan menghapus finalizer untuk membuang objek

@pniederlag apakah ini dapat direproduksi? Jika ya, dapatkah Anda memberikan detail PVC? Apakah semua pod yang menggunakan PVC tersebut juga dihapus?

@pnegahdar hanya ingin memastikan versi kubernetes yang Anda gunakan

@pniederlag apakah ini dapat direproduksi? Jika ya, dapatkah Anda memberikan detail PVC? Apakah semua pod yang menggunakan PVC tersebut juga dihapus?

@ msau42 sayangnya saya tidak memiliki skenario untuk mereproduksi ini dengan mudah. Saya masih baru mengenal kubernetes dan menemukan cara saya menangani volume dengan pod dan mengalami banyak masalah saat pod macet saat memasang volume (didukung oleh disk biru). Jadi kasus penggunaan saya mungkin tidak waras (menggunakan terraform dan dasbor kubernetes secara paralel).

contoh penghapusan untuk finalisator

kubectl patch pvc db-pv-claim -p '{"metadata":{"finalizers":null}}'
kubectl patch pod db-74755f6698-8td72 -p '{"metadata":{"finalizers":null}}'

lalu Anda dapat menghapusnya

terima kasih, ini berhasil untuk saya

Melihat kesalahannya, saya curiga ini terkait dengan # 73098. Selama penghapusan namespace, tampaknya deletionTimestamp pada sumber daya yang tersisa terus diperbarui, menyebabkan error konflik saat pengontrol mencoba menghapus finalizernya. Sepertinya perbaikan untuk masalah ini ada di 1,14+

Masalah menjadi basi setelah 90d tidak ada aktivitas.
Tandai terbitan sebagai baru dengan /remove-lifecycle stale .
Masalah basi membusuk setelah 30 hari tambahan tidak aktif dan akhirnya ditutup.

Jika masalah ini aman untuk ditutup sekarang, lakukan dengan /close .

Kirimkan masukan ke sig-testing, kubernetes / test-infra dan / atau fejta .
/ siklus hidup basi

/ remove-lifecycle basi

Mengalami v1.14.6. melaporkan masalah saya di sini pada awalnya: https://github.com/longhorn/longhorn/issues/722 karena saya juga menggunakan Longhorn. Longhorn tampaknya melakukan apa yang seharusnya dilakukan dengan menghapus volume. Mencoba menghapus pvc melalui hasil API di pod macet di removing status waiting on kubernetes.io/pv-protection

"name": "pvc-dadb69dd-04a2-11ea-9e5f-005056a36714",
"persistentVolumeReclaimPolicy": "Delete",
"removed": "2019-11-12T16:46:04Z",
"removedTS": 1573577164000,
"state": "removing",
"status": {
"phase": "Bound",
"type": "/v3/cluster/schemas/persistentVolumeStatus"
},
"storageClassId": "longhorn-new",
"transitioning": "error",
"transitioningMessage": "waiting on kubernetes.io/pv-protection",
"type": "persistentVolume",
"uuid": "dc89634d-04a2-11ea-98c4-005056a34210",
"volumeMode": "Filesystem"
}

Saya menyingkirkan masalah ini dengan melakukan tindakan berikut:

pvc-5124cf7a-e9dc-11e8-93a1-02551748eea0   1Gi        RWO            Retain           Bound         kafka/data-pzoo-0                                         kafka-zookeeper             21h
pvc-639023b2-e9dc-11e8-93a1-02551748eea0   1Gi        RWO            Retain           Bound         kafka/data-pzoo-1                                         kafka-zookeeper             21h
pvc-7d88b184-e9dc-11e8-93a1-02551748eea0   1Gi        RWO            Retain           Bound         kafka/data-pzoo-2                                         kafka-zookeeper             21h
pvc-9ea68541-e9dc-11e8-93a1-02551748eea0   100Gi      RWO            Delete           Terminating   kafka/data-kafka-0                                        kafka-broker                21h
pvc-ae795177-e9dc-11e8-93a1-02551748eea0   100Gi      RWO            Delete           Terminating   kafka/data-kafka-1                                        kafka-broker                21h

Kemudian saya secara manual mengedit pv satu finalizers yang terlihat seperti ini:

  - kubernetes.io/pv-protection```

Once done, the PVs those were in Terminating condition were all gone!!!

Gunakan perintah di bawah ini untuk mengedit pv dan kemudian hapus objek finalizers di definiton
kubectl edit pv pv-name-id

Ada solusi nyata sejauh ini? Saya ingat melihat masalah ini di bulan-bulan pertama tahun 2019, dan masih melihat penambalan finalizer sebagai satu-satunya solusi. Sayangnya, "bug" ini melarang saya mengotomatiskan beberapa hal.

Apakah seseorang memiliki diagnosis tentang ini? Ada wawasan? Setelah 7 bulan, hal ini masih liar dan saya tidak mendapat info lagi 7 bulan kemudian.

Ada berbagai akar penyebab berbeda yang telah diperbaiki.

Untuk men-debug masalah tambahan apa pun, kami memerlukan langkah repro, log yang lebih mendetail dari kube-controller-manager untuk melihat apa yang dilakukan pengontrol perlindungan pv, dan kemungkinan lebih banyak log dari pengontrol / driver lain untuk di-debug lebih lanjut.

Masalah menjadi basi setelah 90d tidak ada aktivitas.
Tandai terbitan sebagai baru dengan /remove-lifecycle stale .
Masalah basi membusuk setelah 30 hari tambahan tidak aktif dan akhirnya ditutup.

Jika masalah ini aman untuk ditutup sekarang, lakukan dengan /close .

Kirimkan masukan ke sig-testing, kubernetes / test-infra dan / atau fejta .
/ siklus hidup basi

/ remove-lifecycle basi

Masih terjadi di 1.17.5

kube-controller-manager-ip-172-16-113-117.us-west-2.compute.internal kube-controller-manager E0421 23:53:59.806754       1 aws.go:2567] Error describing volume "vol-0a2f0e84304490c43": "InvalidVolume.NotFound: The volume 'vol-0a2f0e84304490c43' does not exist.\n\tstatus code: 400, request id: 58776735-a463-40f3-ae7b-95d602e2a466"
kube-controller-manager-ip-172-16-113-117.us-west-2.compute.internal kube-controller-manager E0421 23:53:59.806791       1 aws.go:2299] InvalidVolume.NotFound: The volume 'vol-0a2f0e84304490c43' does not exist.
kube-controller-manager-ip-172-16-113-117.us-west-2.compute.internal kube-controller-manager    status code: 400, request id: 58776735-a463-40f3-ae7b-95d602e2a466
kube-controller-manager-ip-172-16-113-117.us-west-2.compute.internal kube-controller-manager I0421 23:53:59.806802       1 aws.go:1965] Releasing in-process attachment entry: bd -> volume vol-0a2f0e84304490c43
kube-controller-manager-ip-172-16-113-117.us-west-2.compute.internal kube-controller-manager E0421 23:53:59.806809       1 attacher.go:86] Error attaching volume "aws://us-west-2a/vol-0a2f0e84304490c43" to node "ip-172-16-112-89.us-west-2.compute.internal": InvalidVolume.NotFound: The volume 'vol-0a2f0e84304490c43' does not exist.
kube-controller-manager-ip-172-16-113-117.us-west-2.compute.internal kube-controller-manager    status code: 400, request id: 58776735-a463-40f3-ae7b-95d602e2a466

Saya juga terkena ini. PV memiliki finalizer "foregroundDeletion" di tempatnya. Mengedit PV dan menghapus finalizer memungkinkan PV dihentikan.

Akankah kita akhirnya berhenti bermain-main dengan finalizer ini dengan pengeditan manual?

Jika ada pod atau pekerjaan yang saat ini menggunakan PV, saya menemukan bahwa menghapusnya menyelesaikan masalah bagi saya

masalah yang sama, harus menghapus secara manual - kubernetes.io/pv-protection agar PV dihapus. Ini terjadi dengan AKS pada k8s 1.17.9

masalah yang sama terjadi. Saya telah menghapus ebs secara manual dari aws dan kemudian saya mencoba untuk menghapus pv tetapi terjebak dalam status penghentian.

pvc-60fbc6ab-8732-4d1e-ae32-b42295553fa1 95Gi RWO Delete Terminating ray-prod/data-newcrate-1 gp2 5d4h

Saya baru saja mengalami masalah yang hampir sama terjadi pada saya. Saya menggunakan Kubernetes 1.19.0 di Centos 7, memasang share NAS TerraMaster melalui NFS. Saya baru saja menghapus semua PV dan PVC saat saya menguji pembuatan kedua jenis item tersebut sebagai persiapan untuk pemasangan helm. Ketika saya mencoba untuk melepaskannya, mereka digantung. Saya juga harus mengedit pv secara manual untuk menghapus finalizer (juga kubernetes.io/pv-protection sebagai andrei-dascalu), dan akhirnya dihapus.

Masalah yang sama di sini:

Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.2", GitCommit:"52c56ce7a8272c798dbc29846288d7cd9fbae032", GitTreeState:"clean", BuildDate:"2020-04-16T11:56:40Z", GoVersion:"go1.13.9", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.6", GitCommit:"dff82dc0de47299ab66c83c626e08b245ab19037", GitTreeState:"clean", BuildDate:"2020-07-15T16:51:04Z", GoVersion:"go1.13.9", Compiler:"gc", Platform:"linux/amd64"}

storageClass: longhorn

Memecahkan masalah PVC dan PV yang terjebak dalam status "menghentikan" dengan menghapus pod yang menggunakannya.

Tidak, saat ini terjadi pada PV saya, pod tersebut sudah tidak ada lagi.

On Friday, September 25, 2020, 04:26:04 AM CDT, lsambolino <[email protected]> wrote:

Memecahkan masalah PVC dan PV yang terjebak dalam status "menghentikan" dengan menghapus pod yang menggunakannya.

-
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub, atau berhenti berlangganan.

Saya memiliki beberapa PVC yang terjebak dalam status penghentian.
kubectl mendeskripsikan pvcname (Untuk mendapatkan pod yang dilampirkan.)
kubectl patch pvc pvcname -p '{"metadata": {"finalizers": null}}'
kubectl patch pod podname -p '{"metadata": {"finalizers": null}}'
Ini bekerja di cluster K8S saya

Terima kasih telah memposting perintah ini untuk menyingkirkan pvc

@wolfewicz @DMXGuru jika pod dihapus, pvc seharusnya tidak terjebak dalam status penghentian. Pengguna tidak perlu menghapus finalizer secara manual.
Dapatkah Anda mereproduksi kasus Anda dan memberikan beberapa detail di sini, sehingga kami dapat membantu menentukan urutannya?

Bagaimana dan detail apa yang Anda inginkan? Perintah kubectl dan output menunjukkan perilaku ini dan kemudian kubectl mendeskripsikan dan kubectl get -o yaml untuk PV yang dihasilkan?

dikirim dari iPhone saya

Pada 8 Oktober 2020, pukul 14:30, Jing Xu [email protected] menulis:

</s> </s> </s> </s> </s> </s> </s> </s> </s> </s> </s> </s> </s> </s> </s> </s> </s> </s> </s> </s> </s> </s> </s> </s> </s> </s> </s> orang </s>
@wolfewicz @DMXGuru jika pod dihapus, pvc seharusnya tidak terjebak dalam status penghentian. Pengguna tidak perlu menghapus finalizer secara manual.
Dapatkah Anda mereproduksi kasus Anda dan memberikan beberapa detail di sini, sehingga kami dapat membantu menentukan urutannya?

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub, atau berhenti berlangganan.

@DMXGuru Hal pertama yang ingin saya verifikasi adalah tidak ada pod yang berjalan dan tidak ada VolumeSnapshots yang diambil selama penghentian PVC / PV.

kubectl mendeskripsikan pod | grep ClaimName
kubectl mendeskripsikan volumesnapshot | grep persistentVolumeClaimName

Kedua, dapatkah Anda menjelaskan dalam urutan apa Anda melakukan penghapusan pod atau pvc? Terima kasih!