Kubernetes: PVC가 삭제 된 후 PV가 종료시 멈춤

몇 가지 질문 :
1)이 상황에서 어떻게 벗어날 수 있습니까?
2) 볼륨이 이미 없어도 드라이버가 성공한 후 PV가 성공적으로 종료되어야합니까?

/ 시그 스토리지

PV에 아직 연결기의 종료자가있는 것 같습니다. 볼륨이 노드에서 성공적으로 분리되었는지 확인할 수 있습니까?

외부 연결자 및 AD 컨트롤러에서 로그를 가져 오는 것이 좋습니다.

cc @jsafrane

어떤 버전의 외부 첨부자를 사용하고 있습니까?

v0.3.0입니다. 그리고 다른 모든 측면 자동차도 v0.3.0에 있습니다. 이전에 v0.4.0을 사용하고 있었는데이 문제는 v0.3.0에서 사이드카를 다시 만든 후에 발생합니다.

첨부 파일 로그로 설명 업데이트

PV에 아직 연결기의 종료자가있는 것 같습니다. 볼륨이 노드에서 성공적으로 분리되었는지 확인할 수 있습니까?

볼륨이 성공적으로 분리되어야합니다. AWS에서 성공적으로 삭제되었으므로 분리하지 않고 삭제할 수 있다고 생각하지 마십시오. 또한 노드에서 lsblk 사용하여 장치가 사라진 것을 확인했습니다.

연결이 성공하기 전에 볼륨이 삭제 표시된 것 같습니다. 해당 시나리오를 처리하는 데 버그가있을 수 있습니다.

VolumeAttachment 개체가 계속 표시됩니까?

VolumeAttachment 개체가 계속 표시됩니까?

어떻게 확인할 수 있습니까?

kubectl get volumeattachment

네. 여전히 거기 :

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

로그를 읽으면 A / D 컨트롤러가 볼륨을 연결하려고하는데 외부 연결기에서 오류가 발생한 것 같습니다. 나중에 VolumeAttachment를 삭제하지 않은 이유는 무엇입니까? 볼륨을 사용하는 포드가 아직 있습니까? 그렇다면 PV 삭제를 차단합니다.

볼륨을 사용하는 포드가 없습니다. 그리고 PVC도 사라졌습니다. A / D 컨트롤러 로그는 어떻게 찾을 수 있습니까?

마스터 노드 인 controller-manager.log에 있습니다. 볼륨 이름을 검색하여 필터링을 시도 할 수 있습니다.

다음은 컨트롤러 로그입니다.

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-protection```

완료되면 종료 상태에 있던 PV가 모두 사라졌습니다 !!!

@ chandraprakash1392의 답변은 pvc 이 Terminating 상태에서도 멈춘 경우에도 여전히 유효합니다.
pvc 개체를 편집하고 finalizers 개체를 제거하기 만하면됩니다.

종료자를 제거하는 것은 해결 방법 일뿐입니다. @bertinatto @leakingtapan 이 문제를 재현하고 자세한 CSI 드라이버 및 컨트롤러 관리자 로그를 저장하는 데 도움을 줄 수 있습니까?

종료자를 위해 제거하는 예

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 get volumeattachments!

종료자를 제거하는 것은 해결 방법 일뿐입니다. @bertinatto @leakingtapan 이 문제를 재현하고 자세한 CSI 드라이버 및 컨트롤러 관리자 로그를 저장하는 데 도움을 줄 수 있습니까?

로그 메시지가 @leakingtapan이 보고 한 메시지와 약간 다른 것처럼 보이지만 몇 번 시도한 후 재현 할 수

플러그인 (프로 비 저너) : https://gist.github.com/bertinatto/16f5c1f76b1c2577cd66dbedfa4e0c7c
플러그인 (첨부 자) : 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>

로그를 읽으면 A / D 컨트롤러가 볼륨을 연결하려고하는데 외부 연결기에서 오류가 발생한 것 같습니다. 나중에 VolumeAttachment를 삭제하지 않은 이유는 무엇입니까? 볼륨을 사용하는 포드가 아직 있습니까? 그렇다면 PV 삭제를 차단합니다.

@jsafrane 포드가 하나만 있고 포드가 삭제 된 후 PVC를 삭제합니다.

문제를 일관되게 재현 할 수 있습니다. 이것은 AttachVolume이 실패 할 때 발생합니다.

재현하기 위해 3 노드 k8s 클러스터를 만들었습니다. 그리고 수동으로 EBS 볼륨을 생성 한 후 정적 프로비저닝 된 PV를 생성합니다. 사양 배포 :

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

영역 불일치로 인해 포드 생성에 실패한 경우 포드를 삭제 한 다음 PVC를 삭제합니다. 그리고 PV는 종료 상태에서 멈 춥니 다. 나는 이것을 v1.13에서 재현했다

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

나는 때 느린 volumeattachment 개체가 발생 생각 csi_attacher.go는 볼륨을 연결하는 데 실패는 volumeattachment 개체가 삭제되지 않습니다

waitForVolumeAttachment 가 실패하면 개체를 삭제할 수 있습니다. 당신은 어떻게 생각하십니까? 수정 사항을 보내 드리겠습니다.

/ cc @jsafrane @ msau42

존재하지 않는 볼륨 ID를 사용하여 문제를 재현했습니다 ( "볼륨 'vol-01213456789'가 존재하지 않습니다."로 연결 실패).

waitForVolumeAttachment 가 실패하면 개체를 삭제할 수 있습니다.

이것은 매우 까다 롭습니다. 다음과 같은 두 가지 유형의 연결 실패가있을 수 있습니다.

1. "영구", 볼륨을 연결할 수 없음 : EBS 볼륨이 존재하지 않고 잘못된 영역이 있으며 IAM에 충분한 권한이 없습니다. ...
2. "임시", 볼륨이 (가까운) 미래에 연결될 수 있음 : 시간 초과, 볼륨이 다른 노드에서 분리됨

waitForVolumeAttachment 가 실패하면 A / D 컨트롤러는 그것이 어떤 종류의 실패인지 알지 못합니다. 외부 연결자는 여전히 볼륨을 병렬로 연결하려고 시도하며 결국 성공하기를 기대합니다.

특히 연결 시간이 초과 된 경우 (볼륨이 더 오랜 시간 동안 "연결 중"이었음) waitForAttachmentState 가 실패 할 때 AWS CSI 드라이버가 볼륨을 분리하지 않음을 알 수 있습니다.

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

즉, CSI 드라이버가 시간 초과를 반환 했음에도 불구하고 AWS는 여전히 볼륨 연결을 시도합니다. 다음 ControllerPublish는 이전에 남은 waitForAttachmentState 재개해야합니다. 이 시점에서 A / D 컨트롤러 는 볼륨을 분리 할 수 ​​있으므로 VolumeAttachment를 삭제

몇 가지 옵션이 있습니다.

1 A / D 컨트롤러는 볼륨이 연결되고 있음을 기억합니다. 연결되지 않았거나 (포드를 시작할 수 없음) 분리되지 않았습니다 (볼륨이 DSW에서 사라질 때 Detach ()를 호출해야 함). 이것은 특히 컨트롤러를 다시 시작한 후이 상태를 재구성 할 때 매우 복잡 할 수 있습니다.

1. CSI 볼륨 플러그인은 waitForVolumeAttachment 실패시 VolumeAttachment를 삭제할 수 있지만 ControllerPublish / Unpublish는 매우 빠르며 (기본적으로 15 초) 지금 구현되고 위에서 설명한대로 "재개"할 필요가 없습니다. 이 경우 시간 제한을 15 초 늘리면 도움이 될 수 있습니다 (그러나 CSI 볼륨 플러그인에 하드 코딩되어 구성 할 수 없음).

cc @gnufied @bertinatto

@ jingxu97 , VolumeManager에서 볼륨을 마운트하거나 마운트 해제하지 않은 볼륨 재구성에 무언가가 있다는 것을 올바르게 기억합니까? 여기에 비슷한 것이 필요할 수도 있습니다.

@jsafrane 이 https://github.com/kubernetes/kubernetes/pull/71276 과 관련된 것 같습니다.

@ jingxu97 실제로 # 71276이 도움이되었습니다.

90 일 동안 활동이 없으면 문제가 부실해집니다.
/remove-lifecycle stale 하여 최신 문제로 표시합니다.
비활성 문제는 추가로 30 일 동안 사용하지 않으면 썩고 결국 종료됩니다.

이 문제를 지금 종료해도 안전하다면 /close 하여 종료하세요.

sig-testing, kubernetes / test-infra 및 / 또는 fejta에 피드백을
/ lifecycle stale

/ remove-lifecycle stale

이 문제가 발생하여 사용자 kubectl edit pv | pvc 및 종료자를 제거하여 개체를 삭제해야했습니다.

@pniederlag 이 재현 가능합니까? 그렇다면 PVC 세부 정보를 제공 할 수 있습니까? 해당 PVC를 사용하는 모든 포드도 삭제 되었습니까?

@pnegahdar 는 사용중인 kubernetes의 버전을 확인하고 싶습니다.

@pniederlag 이 재현 가능합니까? 그렇다면 PVC 세부 정보를 제공 할 수 있습니까? 해당 PVC를 사용하는 모든 포드도 삭제 되었습니까?

@ msau42 불행히도 이것을 쉽게 재현 할 수있는 시나리오가 없습니다. 나는 아직 kubernetes를 처음 접했고 pod로 볼륨을 처리하는 방법을 찾고 있으며 pod가 볼륨을 연결하지 못하게하는 데 많은 문제가 발생합니다 (푸른 디스크 지원). 따라서 내 사용 사례는 아마도 정상적이지 않았을 것입니다 (terraform 및 kubernetes 대시 보드를 병렬로 사용).

종료자를 위해 제거하는 예

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

그런 다음 삭제할 수 있습니다.

감사합니다.

오류를 살펴보면 # 73098과 관련된 것 같습니다. 네임 스페이스를 삭제하는 동안 남은 리소스의 deleteTimestamp가 지속적으로 업데이트되어 컨트롤러가 종료자를 제거하려고 할 때 충돌 오류가 발생합니다. 이 문제에 대한 수정 사항은 1.14+에있는 것 같습니다.

90 일 동안 활동이 없으면 문제가 부실해집니다.
/remove-lifecycle stale 하여 최신 문제로 표시합니다.
비활성 문제는 추가로 30 일 동안 사용하지 않으면 썩고 결국 종료됩니다.

이 문제를 지금 종료해도 안전하다면 /close 하여 종료하세요.

sig-testing, kubernetes / test-infra 및 / 또는 fejta에 피드백을
/ lifecycle stale

/ remove-lifecycle stale

v1.14.6에서 경험하십시오. 처음에 여기에 내 문제를보고했습니다 : https://github.com/longhorn/longhorn/issues/722 나는 Longhorn도 사용하고 있기 때문에. Longhorn은 볼륨을 삭제하여 예정된 작업을 수행하는 것으로 보입니다. API를 통해 pvc를 삭제하려고하면 포드가 removing 상태 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"
}

다음 작업을 수행하여이 문제를 제거했습니다.

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를 편집 한 다음 definiton에서 종료 자 개체를 삭제합니다.
kubectl edit pv pv-name-id

지금까지 실제 해결책이 있습니까? 2019 년 첫 달에이 문제를 본 기억이 있지만, 여전히 유일한 해결 방법으로 파이널 라이저 패치를 봅니다. 안타깝게도이 "버그"로 인해 특정 항목을 자동화 할 수 없습니다.

누군가 이것에 대한 진단이 있습니까? 통찰력이 있습니까? 7 개월이 지난 후에도이 문제는 여전히 야생에 있으며 7 개월 후에는 더 이상 정보를 얻지 못했습니다.

수정 된 다양한 근본 원인이 있습니다.

추가 문제를 디버깅하려면 재현 단계, pv 보호 컨트롤러가 수행하는 작업을 확인하기위한 kube-controller-manager의 더 자세한 로그, 추가 디버깅을위한 다른 컨트롤러 / 드라이버의 더 많은 로그가 필요합니다.

90 일 동안 활동이 없으면 문제가 부실해집니다.
/remove-lifecycle stale 하여 최신 문제로 표시합니다.
비활성 문제는 추가로 30 일 동안 사용하지 않으면 썩고 결국 종료됩니다.

이 문제를 지금 종료해도 안전하다면 /close 하여 종료하세요.

sig-testing, kubernetes / test-infra 및 / 또는 fejta에 피드백을
/ lifecycle stale

/ remove-lifecycle stale

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

나도 이것에 맞았다. PV에는 종료 자 "foregroundDeletion"이 있습니다. PV를 편집하고 종료자를 제거하면 PV가 종료됩니다.

우리는 결국 수동 편집을 통해 이러한 파이널 라이저를 사용하는 것을 중단할까요?

현재 PV를 사용하는 포드 또는 작업이있는 경우 삭제하면 문제가 해결된다는 것을 알았습니다.

같은 문제, PV를 삭제하려면 - kubernetes.io/pv-protection 를 수동으로 제거해야했습니다. 이것은 k8s 1.17.9의 AKS에서 발생했습니다.

같은 문제가 발생했습니다. aws에서 ebs를 수동으로 삭제 한 다음 pv를 삭제하려고했지만 종료 상태에서 멈췄습니다.

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

저에게 거의 동일한 문제가 발생했습니다. 저는 Centos 7의 Kubernetes 1.19.0에서 NFS를 통해 TerraMaster NAS 공유를 마운트하고 있습니다. 헬름 설치를 준비하기 위해이 두 가지 유형의 항목 생성을 테스트하면서 PV와 PVC를 모두 제거했습니다. 내가 그들을 제거하려고 할 때 그들은 매달렸다. 또한 종료자를 제거하기 위해 pv를 수동으로 편집해야했고 (또한 kubernetes.io/pv-protection as andrei-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

PVC 및 PV를 사용하여 포드를 삭제하여 "종료"상태로 멈춰있는 문제를 해결했습니다.

아니요, 내 PV에 이런 일이 발생하면 포드가 더 이상 존재하지 않습니다.

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

PVC 및 PV를 사용하여 포드를 삭제하여 "종료"상태로 멈춰있는 문제를 해결했습니다.

—
댓글을 달았 기 때문에 수신 한 것입니다.
이 이메일에 직접 답장하거나 GitHub에서 확인하거나 구독을 취소하세요.

종료 상태에서 여러 개의 PVC가 붙어 있습니다.
kubectl describe pvcname (포드를 연결하려면)
kubectl patch pvc pvcname -p '{ "metadata": { "finalizers": null}}'
kubectl 패치 포드 podname -p '{ "metadata": { "finalizers": null}}'
이것은 내 K8S 클러스터에서 작동했습니다.

pvc를 제거하기 위해 이러한 명령을 게시 해 주셔서 감사합니다.

@wolfewicz @DMXGuru 포드가 삭제되면 pvc가 종료 상태에
케이스를 재현하고 여기에 몇 가지 세부 정보를 제공하여 분류에 도움을 주시겠습니까?

어떻게 그리고 어떤 세부 사항을 원하십니까? 이 동작을 보여주는 kubectl 명령 및 출력과 결과 PV에 대해 kubectl describe 및 kubectl get -o yaml?

내 iPhone에서 보냄

2020 년 10 월 8 일 14:30에 Jing Xu [email protected] 은 다음과 같이 썼습니다.

,,,,,,,,, 무,,,,,,,,,,,.
@wolfewicz @DMXGuru 포드가 삭제되면 pvc가 종료 상태에
케이스를 재현하고 여기에 몇 가지 세부 정보를 제공하여 분류에 도움을 주시겠습니까?

—
당신이 언급 되었기 때문에 이것을 받고 있습니다.
이 이메일에 직접 답장하거나 GitHub에서 확인하거나 구독을 취소하세요.

@DMXGuru 먼저 확인하고 싶은 것은 실행중인 포드가없고 PVC / PV 종료 중에 VolumeSnapshot이 촬영되지 않는다는 것입니다.

kubectl 설명 포드 | grep ClaimName
kubectl describe volumesnapshot | grep persistenceVolumeClaimName

둘째, pod 또는 pvc 삭제를 어떤 순서로 수행했는지 설명해 주시겠습니까? 감사!