Kubernetes: PVCが削除された後、PVが終了時にスタックする

いくつかの質問：
1）どうすればこの状況から抜け出すことができますか？
2）ボリュームがすでになくなっている場合でも、ドライバーが成功を返した後、PVを正常に終了する必要がありますか？

/ sigストレージ

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

最後の行は無限に繰り返されました。

この問題はさらに2回発生しました。 すべて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 ：
プラグイン（アタッチメント）： https ：//gist.github.com/bertinatto/25ebd591ffc88d034f5b4419c0bfa040
コントローラーマネージャー： https ：

ここでも同じですが、ファイナライザーを削除する必要がありました。これが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ポッドは1つしかなく、ポッドが削除された後に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: ""

csi_attacher.goがボリュームのアタッチに失敗した場合、ボリュームアタッチメントオブジェクトが残っていると思います。ボリュームアタッチメントオブジェクトは削除されません。

waitForVolumeAttachmentが失敗したときに、オブジェクトを削除できます。 あなたはどのように思いますか？ 修正を送信させていただきます。

/ cc @jsafrane @ msau42

存在しないボリュームIDを使用して問題を再現しました（「ボリューム 'vol-01213456789'が存在しません」で接続が失敗します）。

waitForVolumeAttachmentが失敗したときに、オブジェクトを削除できます。

これは非常に注意が必要です。 接続の失敗には次の2種類があります。

1. 「永続的」、ボリュームを接続できません：EBSボリュームが存在しない、ゾーンが間違っている、IAMに十分な権限がない、...
2. 「一時的」、ボリュームは（近い）将来接続される可能性があります：タイムアウト、ボリュームは他のノードから切り離されています

waitForVolumeAttachment障害が発生すると、A / Dコントローラーはそれがどのような障害であったかを認識しません。 外部アタッチメントは、最終的に成功することを期待して、ボリュームを並列にアタッチしようとします。

特に、アタッチメントがタイムアウトした場合（ボリュームが長時間「アタッチ中」だった場合）、 waitForAttachmentStateが失敗したときに、AWSCSIドライバーがボリュームをデタッチしないことがわかります。

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

つまり、AWSは、CSIドライバーがタイムアウトを返したにもかかわらず、ボリュームをアタッチしようとします。 次のControllerPublishは、前に残った場所からwaitForAttachmentStateを再開する必要があります。 この時点で、A / DコントローラーはVolumeAttachmentを削除し

いくつかのオプションがあります。

1 A / Dコントローラーは、ボリュームが接続されていることを記憶しています。ボリュームは接続されておらず（ポッドを開始できません）、切り離されていません（ボリュームがDSWから消えたときに、Detach（）を呼び出す必要があります）。 これは、特にコントローラーの再起動後にこの状態を再構築する場合、非常に複雑になる可能性があります。

1. CSIボリュームプラグインはwaitForVolumeAttachmentが失敗したときにVolumeAttachmentを削除できますが、ControllerPublish / Unpublishは非常に高速であり（デフォルトでは15秒）、現在実装されているように「再開」する必要はありません。 この場合、15秒のタイムアウトを増やすと役立つ場合があります（ただし、CSIボリュームプラグインにハードコードされており、構成できません）。

cc @gnufi​​ed @bertinatto

@ jingxu97 、

@jsafraneはこれに関連しているようですhttps://github.com/kubernetes/kubernetes/pull/71276

@ jingxu97確かに、＃71276は役に立ちました、どうもありがとう。

90日間操作がないと、問題は古くなります。
/remove-lifecycle staleして、問題を新規としてマークします。
古い問題は、さらに30日間操作がないと腐敗し、最終的には閉じます。

この問題を今すぐ解決できる場合は、 /close 。

SIG-テスト、kubernetes /テスト・インフラおよび/またはへのフィードバックを送信fejta 。
/ lifecycle stale

/ remove-lifecyclestale

この問題が発生し、オブジェクトをゴミ箱に移動するには、kubectl edit pv | pvcを使用し、ファイナライザーを削除する必要がありました。

@pniederlagはこれが再現可能ですか？ もしそうなら、PVCの詳細を提供できますか？ そのPVCを使用しているすべてのポッドも削除されましたか？

@pnegahdarは、使用しているkubernetesのバージョンを確認したいだけです

@pniederlagはこれが再現可能ですか？ もしそうなら、PVCの詳細を提供できますか？ そのPVCを使用しているすべてのポッドも削除されましたか？

@ msau42残念ながら、これを簡単に再現するシナリオはありません。 私はまだkubernetesに慣れておらず、ポッドを使用してボリュームを処理する方法を見つけており、ボリューム（紺碧のディスクに裏打ちされている）を接続してポッドをスタックさせる際に多くの問題に遭遇します。 したがって、私のユースケースはおそらく正気ではありませんでした（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-テスト、kubernetes /テスト・インフラおよび/またはへのフィードバックを送信fejta 。
/ lifecycle stale

/ remove-lifecyclestale

v1.14.6での体験。 私はLonghornも使用しているので、最初にここで問題を報告しました： https ： 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を編集してから、定義内のファイナライザーオブジェクトを削除します
kubectl edit pv pv-name-id

これまでのところ、実際の解決策はありますか？ 2019年の最初の数か月にこの問題が発生したことを覚えていますが、それでもファイナライザーのパッチ適用が唯一の回避策であると考えています。 残念ながら、この「バグ」により、特定のものを自動化することができなくなります。

誰かがこれについて診断を持っていますか？ 何か洞察はありますか？ 7か月後、このことはまだ進行中であり、7か月後にはそれ以上の情報が得られませんでした。

修正されたさまざまな根本原因があります。

追加の問題をデバッグするには、再現手順、pv保護コントローラーが実行していることを確認するためのkube-controller-managerからのより詳細なログ、さらにデバッグするための他のコントローラー/ドライバーからのより多くのログが必要です。

90日間操作がないと、問題は古くなります。
/remove-lifecycle staleして、問題を新規としてマークします。
古い問題は、さらに30日間操作がないと腐敗し、最終的には閉じます。

この問題を今すぐ解決できる場合は、 /close 。

SIG-テスト、kubernetes /テスト・インフラおよび/またはへのフィードバックを送信fejta 。
/ lifecycle stale

/ remove-lifecyclestale

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を手動で削除する必要がありました。 これは、k8s1.17.9のAKSで発生しました

同じ問題が発生しました。 ebsをawsから手動で削除してから、pvを削除しようとしましたが、終了ステータスのままになりました。

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

ほぼ同じ問題が発生しました。 Centos7のKubernetes1.19.0を使用しており、NFS経由でTerraMasterNAS共有をマウントしています。 ヘルムの取り付けに備えて、これら2種類のアイテムの作成をテストしていたときに、PVとPVCをすべて取り外したところです。 私がそれらを取り除こうとしたとき、彼らはぶら下がった。 また、ファイナライザーを削除するために手動でpvを編集する必要があり（andrei-dascaluとしてkubernetes.io/pv-protectionも）、最終的に削除されました。

ここで同じ問題：

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（podをアタッチするため）
kubectl patch pvc pvcname -p '{"metadata"：{"finalizers"：null}}'
kubectl patch pod podname -p '{"metadata"：{"finalizers"：null}}'
これは私のK8Sクラスターで機能しました

これらのコマンドを投稿して、PVCを削除していただきありがとうございます

@wolfewicz @DMXGuruポッドが削除された場合、pvcは終了状態でスタックしないはずです。 ユーザーはファイナライザーを手動で削除する必要はありません。
トリアージを支援できるように、ケースを再現してここに詳細を記入していただけますか？

どのように、どのような詳細が必要ですか？ この動作を示すkubectlコマンドと出力、そしてkubectldescribeとkubectlget -o yaml for the result PV？

私のiPhoneから送信された

2020年10月8日14：30、JingXunotifications @ github.comは次のように書いています。

@wolfewicz @DMXGuruポッドが削除された場合、pvcは終了状態でスタックしないはずです。 ユーザーはファイナライザーを手動で削除する必要はありません。
トリアージを支援できるように、ケースを再現してここに詳細を記入していただけますか？

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示するか、登録を解除してください。

@DMXGuruで最初に確認したいのは、実行中のポッドがなく、PVC / PVの終了中にVolumeSnapshotsが取得されないことです。

kubectldescribeポッド| grep ClaimName
kubectlはvolumesnapshotを説明します| greppersistentVolumeClaimName

次に、ポッドまたはPVCの削除をどのような順序で実行しましたか。 ありがとう！