Kubernetes: पीवीसी को हटाने के बाद पीवी समाप्त होने पर अटक जाता है

कई सवाल:
1) मैं इस स्थिति से कैसे बाहर निकल सकता हूं?
2) क्या वॉल्यूम के पहले से ही चले जाने पर भी ड्राइवर की सफलता के बाद पीवी को सफलतापूर्वक समाप्त कर दिया जाना चाहिए?

/ सिग भंडारण

ऐसा लगता है कि आप अभी भी पीवी को अटैकर से फाइनल कर रहे हैं। क्या आप सत्यापित कर सकते हैं कि वॉल्यूम नोड से सफलतापूर्वक अलग हो गया है?

बाहरी-अटैकर से लॉग प्राप्त करना अच्छा हो सकता है, और एडी नियंत्रक भी

cc @jsafrane

बाहरी-अटैकर का कौन सा संस्करण उपयोग कर रहे हैं?

यह v0.3.0 है। और अन्य सभी साइड कार v0.3.0 में भी हैं। मैं पहले v0.4.0 का उपयोग कर रहा था और यह समस्या तब हुई जब मैंने v0.3.0 में साइड कारों को फिर से बनाया।

अनुलग्नक लॉग के साथ विवरण अपडेट करें

ऐसा लगता है कि आप अभी भी पीवी को अटैकर से फाइनल कर रहे हैं। क्या आप सत्यापित कर सकते हैं कि वॉल्यूम नोड से सफलतापूर्वक अलग हो गया है?

वॉल्यूम को सफलतापूर्वक अलग किया जाना चाहिए। चूंकि यह AWS से सफलतापूर्वक हटा दिया गया है (ऐसा नहीं लगता कि इसे बिना कोचिंग के हटाया जा सकता है)। यह भी नोड पर सत्यापित किया गया है कि डिवाइस lsblk का उपयोग करके चला गया है।

ऐसा लगता है कि किसी अनुलग्नक के सफल होने से पहले मात्रा को हटाने के लिए चिह्नित किया गया था। शायद उस परिदृश्य को संभालने के साथ कुछ बग है।

क्या आपको अभी भी एक वॉल्यूमअटैचमेंट ऑब्जेक्ट दिखाई देता है?

क्या आपको अभी भी एक वॉल्यूमअटैचमेंट ऑब्जेक्ट दिखाई देता है?

मैं इसे कैसे जांच सकता हूं?

kubectl को वॉल्यूमेटाचमेंट मिलता है

हां। अभी भी वहाँ है:

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

लॉग को पढ़ना, ऐसा लगता है जैसे ए / डी नियंत्रक ने वॉल्यूम को संलग्न करने की कोशिश की और बाहरी अटैकर से त्रुटि मिली। इसने बाद में VolumeAttachment को क्यों नहीं हटाया? क्या आपके पास अभी भी एक पॉड है जो वॉल्यूम का उपयोग करता है? यदि हां, तो यह पीवी विलोपन को रोकता है।

कोई फली मात्रा का उपयोग करता है। और पीवीसी भी चला गया है। मैं ए / डी नियंत्रक लॉग कैसे पा सकता हूं?

यह मास्टर नोड, कंट्रोलर-मैनेजर.लॉग पर है। आप वॉल्यूम नाम की खोज करके फ़िल्टर करने का प्रयास कर सकते हैं।

यहाँ नियंत्रक लॉग है:

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

अंतिम पंक्ति अनंत बार दोहराई गई।

मुझे अब दो बार इस मुद्दे का सामना करना पड़ा। सभी v1.12 पर

मैंने निम्नलिखित क्रियाओं को करके इस समस्या से छुटकारा पाया:
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
फिर मैंने व्यक्तिगत रूप से pv संपादन किया और फिर finalizers को हटा दिया, जो कुछ इस तरह दिखता था:
`` `अंतिम रूप:

• kubernetes.io / pv-सुरक्षा ```

एक बार हो जाने के बाद, जो पीवी समाप्त होने की स्थिति में थे, वे सब चले गए थे !!!

@ Chandraprakash1392 का उत्तर तब भी मान्य है जब pvc अटक Terminating स्थिति में भी हो।
आपको बस पीवीसी ऑब्जेक्ट को संपादित करने और finalizers ऑब्जेक्ट को निकालने की आवश्यकता है।

फाइनलर्स को हटाना सिर्फ एक वर्कअराउंड है। @bertinatto @leakingtapan क्या आप इस समस्या को

उदाहरण के लिए अंतिम रूप से हटाने वाले

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

तो आप उन्हें हटा सकते हैं

!!! जरूरी !!!:
ये भी पढ़ें https://github.com/kubernetes/kubernetes/issues/78106
पैच कमांड एक वर्कअराउंड है और कुछ ठीक से काम नहीं कर रहा है।
कई खंड अभी भी संलग्न हैं: kubectl volumeattachments प्राप्त करें!

फाइनलर्स को हटाना सिर्फ एक वर्कअराउंड है। @bertinatto @leakingtapan क्या आप इस समस्या को

मैं कुछ प्रयासों के बाद इसे पुन: पेश करने में कामयाब रहा, हालांकि लॉग संदेश @leakingtapan द्वारा

प्लगइन (प्रावधानकर्ता): https://gist.github.com/bertinatto/16f5c1f76b1c2577cd6666dbedfa4e0c7c
प्लगइन (संलग्नक): https://gist.github.com/bertinatto/25ebd591ffc88d034f5b4419c0bfa040
नियंत्रक प्रबंधक: https://gist.github.com/bertinatto/a2d82fdbccbf7ec0bb5e8ab65d47dcf3

यहाँ भी, फाइनल को हटाना पड़ा, यहाँ 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>

लॉग को पढ़ना, ऐसा लगता है जैसे ए / डी नियंत्रक ने वॉल्यूम को संलग्न करने की कोशिश की और बाहरी अटैकर से त्रुटि मिली। इसने बाद में VolumeAttachment को क्यों नहीं हटाया? क्या आपके पास अभी भी एक पॉड है जो वॉल्यूम का उपयोग करता है? यदि हां, तो यह पीवी विलोपन को रोकता है।

@jsafrane मेरे पास केवल एक पॉड है, और मैं पॉड को हटाने के बाद पीवीसी को हटा देता हूं

मैं इस मुद्दे को लगातार दोहराने में सक्षम हूं। यह तब होता है जब AttachVolume विफल हो जाता है।

पुन: पेश करने के लिए, मैंने तीन नोड k8s क्लस्टर बनाया। और मैं मैन्युअल रूप से ईबीएस वॉल्यूम बनाने के बाद एक स्थिर प्रोविज्ड पीवी बनाता हूं। चश्मा तैनात करें:

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

जब जोन मिसमैच के कारण पॉड निर्माण विफल हो गया, तो पॉड को हटा दें और फिर पीवीसी को हटा दें। और PV राज्य को समाप्त करने पर अटक जाएगा। मैंने इसे v1.13 में पुन: पेश किया

वॉल्यूमअटैचमेंट ऑब्जेक्ट:

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: ""

मुझे लगता है कि जब csi_attacher.go वॉल्यूम संलग्न करने में विफल रहा है, तो वॉल्यूमाइजिंग ऑब्जेक्ट को हटा दिया जाता है

waitForVolumeAttachment विफल होने पर हम ऑब्जेक्ट को हटा सकते हैं। तुम कैसे सोचते हो? मुझे फिक्स भेजकर खुशी होगी।

/ cc @jsafrane @ msau42

मैंने गैर-मौजूद वॉल्यूम आईडी का उपयोग करके समस्या को पुन: प्रस्तुत किया ("वॉल्यूम 'वॉल्यूम-01213456789 के साथ विफल रहता है" मौजूद नहीं है ")।

waitForVolumeAttachment विफल होने पर हम ऑब्जेक्ट को हटा सकते हैं।

यह बहुत मुश्किल है। दो प्रकार की विफलताएं हो सकती हैं:

1. "स्थायी", वॉल्यूम को कभी संलग्न नहीं किया जा सकता है: ईबीएस वॉल्यूम मौजूद नहीं है, इसमें गलत ज़ोन है, आईएएम के पास पर्याप्त अनुमतियाँ नहीं हैं ...
2. "अस्थायी", वॉल्यूम भविष्य में (निकट) संलग्न किया जा सकता है: समय के साथ, वॉल्यूम को अन्य नोड से अलग किया जा रहा है

जब waitForVolumeAttachment विफल हो जाता है, तो ए / डी नियंत्रक को नहीं पता होता है कि यह किस प्रकार की विफलता थी। बाहरी अनुचर अभी भी वॉल्यूम को समानांतर में संलग्न करने की कोशिश करता है, उम्मीद करता है कि यह अंततः सफल होने जा रहा है।

विशेष रूप से जब अटैकर का समय समाप्त हो गया (वॉल्यूम अधिक समय के लिए "अटैचिंग" था), तो आप देख सकते हैं कि AWS CSI ड्राइवर waitForAttachmentState विफल होने पर कोई वॉल्यूम अलग नहीं करता है:

https://sourcegraph.com/github.com/kubernetes-sigs/aws-ebs-csi-driver@ff1fe8e1399784657c10d67649146429dcb93515/ - / ब्लॉब / pkg / बादल / cloud.go # L300

इसका मतलब है कि CSI ड्राइवर के समय समाप्त होने के बावजूद AWS अभी भी वॉल्यूम संलग्न करने की कोशिश करता है। अगला नियंत्रकप्रकाश को waitForAttachmentState फिर से शुरू करना चाहिए, जहां उसने पहले छोड़ा था। इस बिंदु पर ए / डी नियंत्रक को वॉल्यूमटैचमेंट चाहिए , क्योंकि इससे वॉल्यूम अलग हो जाएगा। ए / डी कंट्रोलर थोड़ी देर में वॉल्यूम को फिर से संलग्न करने की कोशिश करेगा (यानी नया वॉल्यूमअटैचमेंट बनाएगा) और वॉल्यूम शुरू होगा "स्क्रैच से" "संलग्न" और फिर से समय समाप्त होने की संभावना है, जिससे वॉल्यूमअटैचमेंट का एक लूप बन जाता है। , लेकिन लगाव के सफल होने के लिए लंबे समय तक इंतजार नहीं किया।

हमारे पास कई विकल्प हैं:

1 ए / डी नियंत्रक को याद है कि वॉल्यूम संलग्न किया जा रहा है - यह न तो संलग्न है (पॉड शुरू नहीं किया जा सकता है) और न ही अलग (डिटैच) को तब कहा जाना चाहिए जब वॉल्यूम डीएसडब्ल्यू से गायब हो जाता है)। यह काफी जटिल हो सकता है, खासकर जब नियंत्रक पुनः आरंभ करने के बाद इस राज्य को फिर से बनाना।

1. जब waitForVolumeAttachment विफल हो जाता है, तो CSI वॉल्यूम प्लगइन हटा सकता है, लेकिन फिर हम उम्मीद करते हैं कि नियंत्रकप्रकाशक / अप्रकाशित काफी तेज़ है (डिफ़ॉल्ट रूप से 15s) और अब इसे फिर से लागू करने के रूप में "फिर से शुरू" होने की आवश्यकता नहीं है। इस मामले में 15s टाइमआउट बढ़ने से मदद मिल सकती है (लेकिन यह CSI वॉल्यूम प्लगइन में हार्डकोड है और कॉन्फ़िगर करने योग्य नहीं है)।

cc @gnufied @bertinatto

@ jingxu97 , क्या मुझे सही ढंग से याद है कि वॉल्यूम पुनर्निर्माण में कुछ ऐसा था जो वॉल्यूम को न तो माउंट किया गया था और न ही वॉल्यूममैन में अनमाउंट किया गया था? शायद हमें यहाँ भी कुछ ऐसा ही चाहिए।

@jsafrane को ऐसा लगता है कि यह इस https://github.com/kubernetes/kubernetes/p/7/77676 से संबंधित है

@ jingxu97 वास्तव में, # 71276 ने मदद की, बहुत बहुत धन्यवाद।

90 डी निष्क्रियता के बाद मुद्दे बासी हो जाते हैं।
/remove-lifecycle stale साथ ताज़ा अंक को चिह्नित करें।
अतिरिक्त 30 डी निष्क्रियता के बाद बासी मुद्दे सड़ जाते हैं और अंततः बंद हो जाते हैं।

यदि यह समस्या अब बंद करने के लिए सुरक्षित है, तो कृपया /close साथ ऐसा करें।

सिग-टेस्टिंग, कुबेरनेट्स / टेस्ट-इन्फ्रा और / या फ़ेज्टा पर प्रतिक्रिया भेजें।
/ जीवनचक्र बासी

/ हटाने-जीवन चक्र बासी

बस इस मुद्दे में भाग गया और kubectl को pv | pvc | को संपादित करना पड़ा और ऑब्जेक्ट्स को ट्रैश करने के लिए फाइनल निकालें

@pniederlag क्या यह प्रजनन योग्य है? यदि ऐसा है तो आप पीवीसी विवरण प्रदान कर सकते हैं? सभी फली उस पीवीसी का उपयोग कर के रूप में अच्छी तरह से नष्ट कर दिया गया था?

@pnegahdar बस यह सुनिश्चित करना चाहते हैं कि आपके द्वारा उपयोग किए जा रहे कुबेरनेट का कौन सा संस्करण है

@pniederlag क्या यह प्रजनन योग्य है? यदि ऐसा है तो आप पीवीसी विवरण प्रदान कर सकते हैं? सभी फली उस पीवीसी का उपयोग कर के रूप में अच्छी तरह से नष्ट कर दिया गया था?

@ msau42 दुर्भाग्य से मेरे पास आसानी से इसे पुन: पेश करने के लिए एक परिदृश्य नहीं है। मैं अभी भी कुबेरनेट्स के लिए नया हूं और पॉड्स के साथ वॉल्यूम को संभालने पर अपना रास्ता ढूंढ रहा हूं और पॉड अटैच वॉल्यूम (एज़्योर डिस्क द्वारा समर्थित) प्राप्त करने पर कई समस्याओं में भाग लेता हूं। इसलिए मेरा उपयोग मामला शायद एक सेंस वन (टेराफॉर्म और समानांतर में कुबेरनेट्स डैशबोर्ड का उपयोग करके) नहीं था।

उदाहरण के लिए अंतिम रूप से हटाने वाले

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

तो आप उन्हें हटा सकते हैं

धन्यवाद, यह मेरे लिए काम करता है

त्रुटि को देखते हुए, मुझे संदेह है कि यह # 73098 से संबंधित है। नेमस्पेस विलोपन के दौरान, यह विलोपन दिखाई देता है। बचे हुए संसाधनों पर टिम्स्टैम्प लगातार अपडेट किया जाता है, जिससे संघर्ष की त्रुटियां उत्पन्न होती हैं, जब नियंत्रक अपने अंतिम रूप को हटाने की कोशिश करता है। ऐसा लगता है कि इस समस्या का हल 1.14+ में है

90 डी निष्क्रियता के बाद मुद्दे बासी हो जाते हैं।
/remove-lifecycle stale साथ ताज़ा अंक को चिह्नित करें।
अतिरिक्त 30 डी निष्क्रियता के बाद बासी मुद्दे सड़ जाते हैं और अंततः बंद हो जाते हैं।

यदि यह समस्या अब बंद करने के लिए सुरक्षित है, तो कृपया /close साथ ऐसा करें।

सिग-टेस्टिंग, कुबेरनेट्स / टेस्ट-इन्फ्रा और / या फ़ेज्टा पर प्रतिक्रिया भेजें।
/ जीवनचक्र बासी

/ हटाने-जीवन चक्र बासी

V1.14.6 पर अनुभव। यहाँ शुरू में मेरे मुद्दे की सूचना दी: https://github.com/longhorn/longhorn/issues/722 जैसा कि मैं भी Longhorn का उपयोग कर रहा हूँ। लॉन्गहॉर्न वह करता है जो वॉल्यूम को हटाकर माना जाता है। removing स्थिति waiting on kubernetes.io/pv-protection फंसे में API परिणाम के माध्यम से पीवीसी को हटाने का प्रयास

"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"
}

मैंने निम्नलिखित क्रियाओं को करके इस समस्या से छुटकारा पाया:

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

फिर मैंने व्यक्तिगत रूप से pv संपादन किया और फिर finalizers को हटा दिया, जो कुछ इस तरह दिखता था:

  - kubernetes.io/pv-protection```

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

Pv को संपादित करने के लिए नीचे दिए गए कमांड का उपयोग करें और फिर फ़ाइनलिट्स ऑब्जेक्ट को निश्चित में हटाएं
kubectl संपादित करें pv pv-name-id

अब तक कोई वास्तविक समाधान? मुझे याद है कि 2019 के पहले महीनों में इस मुद्दे को देखना है, और अभी भी केवल वर्कअराउंड के रूप में अंतिम रूप से पैचिंग देखना है। दुर्भाग्य से, यह "बग" मुझे कुछ सामानों को स्वचालित करने से रोकता है।

क्या किसी को इस बारे में पता है? कोई अंतर्दृष्टि? 7 महीने के बाद, यह बात अभी भी जंगली पर है और मुझे 7 महीने बाद कोई और जानकारी नहीं मिली।

कई अलग-अलग मूल कारण हैं जो तय किए गए हैं।

किसी भी अतिरिक्त मुद्दों को डीबग करने के लिए, हमें repro चरणों की आवश्यकता होती है, क्यूब-कंट्रोलर-मैनेजर से अधिक विस्तृत लॉग देखने के लिए कि पीवी प्रोटेक्शन कंट्रोलर क्या कर रहा है, और संभावित रूप से अन्य नियंत्रकों / ड्राइवरों से और डीबग करें।

90 डी निष्क्रियता के बाद मुद्दे बासी हो जाते हैं।
/remove-lifecycle stale साथ ताज़ा अंक को चिह्नित करें।
अतिरिक्त 30 डी निष्क्रियता के बाद बासी मुद्दे सड़ जाते हैं और अंततः बंद हो जाते हैं।

यदि यह समस्या अब बंद करने के लिए सुरक्षित है, तो कृपया /close साथ ऐसा करें।

सिग-टेस्टिंग, कुबेरनेट्स / टेस्ट-इन्फ्रा और / या फ़ेज्टा पर प्रतिक्रिया भेजें।
/ जीवनचक्र बासी

/ हटाने-जीवन चक्र बासी

अभी भी 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

मैं भी इसकी चपेट में आ गया। पीवी के स्थान पर फाइनल "फोरग्राउंडडेलियन" था। पीवी को संपादित करने और फाइनल को हटाने से पीवी को समाप्त करने की अनुमति मिली।

क्या हम अंततः इन फाइनल के साथ मैनुअल एडिट के साथ खेलना बंद कर देंगे?

यदि वर्तमान में पीवी का उपयोग करके पॉड्स या जॉब्स हैं, तो मैंने पाया कि उन्हें हटाने से मेरे लिए समस्या हल हो जाती है

उसी समस्या, को पीवी के डिलीट होने के लिए - kubernetes.io/pv-protection को मैन्युअल रूप से हटाना पड़ा। यह AKS के साथ k8s 1.17.9 पर हुआ

एक ही मुद्दा हुआ। मैंने मैन्युअल रूप से एब्स से एब्स को हटा दिया है और फिर मैंने पीवी को हटाने की कोशिश की लेकिन यह स्थिति को समाप्त करने में अटक गया।

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

मेरे पास बस लगभग एक जैसा मुद्दा था। मैं सेंटोस 7 पर कुबेरनेट्स 1.19.0 पर हूं, जो एनएफएस के माध्यम से टेरामास्टर एनएएस शेयर बढ़ रहा है। मैंने सभी पीवी और पीवीसी को हटा दिया था क्योंकि मैं एक हेल्म इंस्टाल करने की तैयारी में उन दो प्रकार की वस्तुओं के निर्माण का परीक्षण कर रहा था। जब मैंने उन्हें हटाने की कोशिश की, तो उन्होंने लटका दिया। मुझे अंतिम रूप से निकालने के लिए pv को भी मैन्युअल रूप से संपादित करना पड़ा (यह भी kubernetes.io/pv-protection as andi-dascalu के रूप में), और फिर अंततः इसे हटा दिया गया।

यहाँ एक ही मुद्दा:

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

पीवीसी और पीवी के मुद्दे को हल करते हुए फली को हटाकर "समाप्त" अवस्था में फंस गया।

नहीं, जब यह मेरे पीवी के साथ होता है, तो फली अब मौजूद नहीं है।

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

पीवीसी और पीवी के मुद्दे को हल करते हुए फली को हटाकर "समाप्त" अवस्था में फंस गया।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की है।
इस ईमेल का उत्तर सीधे दें, इसे GitHub पर देखें, या सदस्यता समाप्त करें।

मैं कई pvcs को समाप्त करने की स्थिति में फंस गया था।
kubectl pvcname का वर्णन करें (पॉड को इसके साथ संलग्न करने के लिए।)
kubectl पैच pvc pvcname -p '{"मेटाडेटा": {"फाइनल": null}}
kubectl पैच फली पोडनाम -p '{"मेटाडेटा": {"फाइनल": null}}'
यह मेरे K8S क्लस्टर में काम किया

परमवीर चक्र से छुटकारा पाने के लिए इन आदेशों को पोस्ट करने के लिए धन्यवाद

@wolfewicz @DMXGuru यदि फली को हटा दिया जाता है, तो पीवीसी को समाप्त करने वाले राज्यों में नहीं अटकना चाहिए। उपयोगकर्ता को मैन्युअल रूप से अंतिम रूप से हटाने की आवश्यकता नहीं होनी चाहिए।
क्या आप अपने मामले को पुन: पेश कर सकते हैं और यहां कुछ विवरण दे सकते हैं, ताकि हम ट्राइएज में मदद कर सकें?

आप कैसे और क्या विवरण चाहेंगे? Kubectl कमांड और आउटपुट इस व्यवहार को दिखाता है और फिर एक kubectl वर्णन करता है और परिणामी PV के लिए kubectl get -o yaml?

मेरे आईफोन से भेजा गया

8 अक्टूबर, 2020 को 14:30 बजे, जिंग जू सूचनाएँ @github.com ने लिखा:

उन्होंने कहा कि इस तरह की घटनाओं को रोकने के लिए सरकार ने कई कदम उठाए हैं।
@wolfewicz @DMXGuru यदि फली को हटा दिया जाता है, तो पीवीसी को समाप्त करने वाले राज्यों में नहीं अटकना चाहिए। उपयोगकर्ता को मैन्युअल रूप से अंतिम रूप से हटाने की आवश्यकता नहीं होनी चाहिए।
क्या आप अपने मामले को पुन: पेश कर सकते हैं और यहां कुछ विवरण दे सकते हैं, ताकि हम ट्राइएज में मदद कर सकें?

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का उत्तर सीधे दें, इसे GitHub पर देखें, या सदस्यता समाप्त करें।

@DMXGuru पहली बात मैं यह सत्यापित करना चाहता हूं कि कोई पॉड्स नहीं चल रहे हैं और पीवीसी / पीवी टर्मिनेटिंग के दौरान कोई वॉल्यूमस्नापोट्स नहीं लिया गया है।

kubectl वर्णन फली | grep दावा
kubectl का वर्णन वॉलनैपशॉट | grep persistentVolumeClaimName

दूसरा, क्या आप बता सकते हैं कि आपने पॉड या पीवीसी विलोपन किस क्रम में किया था? धन्यवाद!