Kubernetes: PV зависает при завершении после удаления PVC

Несколько вопросов:
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

Читая логи, кажется, что аналого-цифровой контроллер попытался подключить том и получил ошибку от внешнего присоединителя. Почему впоследствии он не удалил VolumeAttachment? У вас еще есть капсула, которая использует громкость? Если да, то он блокирует удаление PV.

Нет стручка использует громкость. Пропал и ПВХ. Как я могу найти журнал 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-защита

После этого все клипы, которые находились в состоянии прекращения, исчезли !!!

Ответ @ 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 получает прикрепленные тома!

Удаление финализаторов - это всего лишь временное решение. @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>

Читая логи, кажется, что аналого-цифровой контроллер попытался подключить том и получил ошибку от внешнего присоединителя. Почему впоследствии он не удалил VolumeAttachment? У вас еще есть капсула, которая использует громкость? Если да, то он блокирует удаление PV.

@jsafrane У меня только один модуль, и я удаляю PVC после удаления модуля

Я могу воспроизвести проблему последовательно. Это происходит при сбое AttachVolume.

Для воспроизведения я создал трехузловой кластер k8s. И я создаю статический подготовленный PV после создания тома EBS вручную. Разверните спецификации:

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

Если создание Pod не удалось из-за несоответствия зоны, удалите Pod, а затем удалите 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

Я воспроизвел проблему с использованием несуществующего идентификатора тома (не удается прикрепить том «Том vol-01213456789 не существует»).

Мы можем удалить объект, когда waitForVolumeAttachment не работает.

Это очень сложно. Возможны два типа сбоев подключения:

1. "постоянный", том не может быть прикреплен: том EBS не существует, у него неправильная зона, у IAM недостаточно прав, ...
2. "временный", том может быть присоединен в (ближайшем) будущем: тайм-аут, том отключается от другого узла

Когда waitForVolumeAttachment выходит из строя, АЦП не знает, что это за ошибка. Внешний аттачер по-прежнему пытается подключить том параллельно, надеясь, что в конечном итоге это удастся.

В частности, когда истекло время подключения подключенного устройства (том был «прикреплен» в течение более длительного времени), вы можете видеть, что драйвер AWS CSI не отключает том при сбое waitForAttachmentState :

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

Это означает, что AWS по-прежнему пытается подключить том, несмотря на тайм-аут, возвращенный драйвером CSI. Следующий ControllerPublish должен возобновить waitForAttachmentState где он был раньше. На этом этапе аналого-цифровой контроллер не должен удалять VolumeAttachment, поскольку это приведет к отсоединению тома. Контроллер A / D попытается повторно подключить том через короткое время (т.е. создать новое VolumeAttachment), и том начнет «Присоединение» «с нуля», и, вероятно, снова истечет время ожидания, создавая цикл создания / удаления VolumeAttachment , но никогда не ждут достаточно долго, чтобы вложение завершилось успешно.

У нас есть несколько вариантов:

1 A / D-контроллер запоминает, что том присоединяется - он ни присоединен (модуль не может быть запущен), ни отсоединен (Detach () должен быть вызван, когда том исчезает из DSW). Это может быть довольно сложно, особенно при восстановлении этого состояния после перезапуска контроллера.

1. Плагин тома CSI может удалить VolumeAttachment при сбое waitForVolumeAttachment , но тогда мы ожидаем, что 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 .
/ жизненный цикл устаревший

/ remove-жизненный цикл устаревший

просто столкнулся с этой проблемой и пришлось пользователю kubectl отредактировать pv | pvc и удалить финализаторы, чтобы удалить объекты

@pniederlag это воспроизводимо? Если да, можете ли вы предоставить подробную информацию о ПВХ? Были ли удалены все контейнеры, использующие этот PVC?

@pnegahdar просто хочет убедиться, какую версию кубернетов вы используете

@pniederlag это воспроизводимо? Если да, можете ли вы предоставить подробную информацию о ПВХ? Были ли удалены все контейнеры, использующие этот 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. Во время удаления пространства имен кажется, что deletionTimestamp на оставшихся ресурсах постоянно обновляется, вызывая конфликтные ошибки, когда контроллер пытается удалить свой финализатор. Похоже, что исправление этой проблемы находится в версии 1.14+.

Проблемы становятся устаревшими после 90 дней бездействия.
Отметьте проблему как новую с помощью /remove-lifecycle stale .
Устаревшие выпуски гниют после дополнительных 30 дней бездействия и в конечном итоге закрываются.

Если сейчас можно безопасно закрыть эту проблему, сделайте это с помощью /close .

Отправьте отзыв в sig-testing, kubernetes / test-infra и / или fejta .
/ жизненный цикл устаревший

/ remove-жизненный цикл устаревший

Опыт работы на v1.14.6. сначала сообщил о моей проблеме здесь: https://github.com/longhorn/longhorn/issues/722, поскольку я также использую Longhorn. Longhorn, похоже, делает то, что должен, удаляя том. Попытка удалить pvc через API приводит к тому, что модуль застревает в 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"
}

Я избавился от этой проблемы, выполнив следующие действия:

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 месяцев спустя я не получил больше информации.

Были устранены различные основные причины.

Для отладки любых дополнительных проблем нам нужны шаги по воспроизведению, более подробные журналы от kube-controller-manager, чтобы увидеть, что делает контроллер pv-защиты, и, возможно, больше журналов от других контроллеров / драйверов для дальнейшей отладки.

Проблемы становятся устаревшими после 90 дней бездействия.
Отметьте проблему как новую с помощью /remove-lifecycle stale .
Устаревшие выпуски гниют после дополнительных 30 дней бездействия и в конечном итоге закрываются.

Если сейчас можно безопасно закрыть эту проблему, сделайте это с помощью /close .

Отправьте отзыв в sig-testing, kubernetes / test-infra и / или fejta .
/ жизненный цикл устаревший

/ remove-жизненный цикл устаревший

Все еще происходит в 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

Меня тоже это поразило. В клипе есть финализатор "foregroundDeletion". Редактирование PV и удаление финализатора позволили завершить PV.

Перестанем ли мы в конечном итоге возиться с этими финализаторами с ручным редактированием?

Если есть модули или задания, которые в настоящее время используют PV, я обнаружил, что их удаление решает проблему для меня.

та же проблема, пришлось вручную удалить - kubernetes.io/pv-protection чтобы удалить PV. Это случилось с AKS на k8s 1.17.9

такая же проблема произошла. Я удалил ebs вручную из aws, а затем попытался удалить pv, но он застрял в статусе завершения.

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

У меня только что случилась почти такая же проблема. Я использую Kubernetes 1.19.0 на Centos 7, монтирую общий ресурс TerraMaster NAS через NFS. Я только что удалил все PV и PVC, поскольку я тестировал создание этих двух типов элементов при подготовке к установке Helm. Когда я пытался их удалить, они зависли. Мне также пришлось вручную отредактировать pv, чтобы удалить финализатор (также kubernetes.io/pv-protection как 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 в состоянии «завершения» путем удаления используемого модуля.

Нет, когда это происходит с моим клипом, пода больше не существует.

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

Решена проблема зависания PVC и PV в состоянии «завершения» путем удаления используемого модуля.

-
Вы получили это, потому что оставили комментарий.
Ответьте на это письмо напрямую, просмотрите его на GitHub или откажитесь от подписки.

У меня было несколько ПВХ, застрявших в статусе завершения.
kubectl describe pvcname (чтобы прикрепить модуль к нему.)
kubectl patch pvc pvcname -p '{"metadata": {"finalizers": null}}'
kubectl patch pod podname -p '{"metadata": {"finalizers": null}}'
Это сработало в моем кластере K8S

Спасибо, что разместили эти команды, чтобы избавиться от пвх

@wolfewicz @DMXGuru, если стручки удалены, ПВХ не должен застревать в конечных состояниях. Пользователю не нужно удалять финализатор вручную.
Не могли бы вы воспроизвести ваш случай и дать некоторые подробности здесь, чтобы мы могли помочь в сортировке?

Как и какие подробности вам нужны? Команды и выходные данные kubectl, показывающие это поведение, а затем kubectl describe и kubectl get -o yaml для результирующего PV?

отправлено из моего Айфона

8 октября 2020 года в 14:30 Цзин Сюй [email protected] написал:

Взаимодействие с другими людьми
@wolfewicz @DMXGuru, если стручки удалены, ПВХ не должен застревать в конечных состояниях. Пользователю не нужно удалять финализатор вручную.
Не могли бы вы воспроизвести ваш случай и дать некоторые подробности здесь, чтобы мы могли помочь в сортировке?

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub или откажитесь от подписки.

@DMXGuru Первое, что я хочу проверить, это то, что не работают поды и не делается снимков VolumeSnapshots во время завершения PVC / PV.

kubectl description pod | grep ClaimName
kubectl описать объемы снимок | grep persistentVolumeClaimName

Во-вторых, не могли бы вы описать, в какой последовательности вы выполняли удаление pod или pvc? Благодаря!