Kubernetes: PV está travado na terminação após o PVC ser excluído

Muitas questões:
1) como posso sair dessa situação?
2) o PV deve ser encerrado com sucesso após o driver retornar com sucesso, mesmo quando o volume já acabou?

/ sig armazenamento

Parece que seu PV ainda tem um finalizador do anexador. Você pode verificar se o volume foi desconectado com êxito do nó?

Pode ser bom obter registros do anexo externo e também do controlador AD

cc @jsafrane

Qual versão do anexador externo você está usando?

é v0.3.0. E todos os outros carros laterais estão na v0.3.0 também. Eu estava usando a v0.4.0 anteriormente e esse problema aconteceu depois que recriei os carros laterais na v0.3.0.

Atualizado a descrição com o registro do anexo

Parece que seu PV ainda tem um finalizador do anexador. Você pode verificar se o volume foi desconectado com êxito do nó?

O volume deve ser retirado com sucesso. Uma vez que foi excluído com sucesso da AWS (não pense que poderia ser excluído sem desconectar). Também foi verificado no nó que o dispositivo desapareceu usando lsblk .

Parece que o volume foi marcado para exclusão antes que uma anexação fosse bem-sucedida. Talvez haja algum bug em lidar com esse cenário.

Você ainda vê um objeto VolumeAttachment?

Você ainda vê um objeto VolumeAttachment?

Como posso verificar isso?

kubectl get volumeattachment

Sim. Ainda está lá:

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

Lendo os logs, parece que o controlador A / D tentou anexar o volume e obteve um erro do anexador externo. Por que não excluiu o VolumeAttachment posteriormente? Você ainda tem um pod que usa o volume? Nesse caso, ele bloqueia a exclusão do PV.

Nenhum pod usa o volume. E o PVC também se foi. Como posso encontrar o log do controlador A / D?

Ele está no nó mestre, controller-manager.log. Você pode tentar filtrar procurando pelo nome do volume.

Aqui está o log do controlador:

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

A última linha foi repetida infinitamente.

Eu encontrei esse problema mais duas vezes agora. Tudo em v1.12

Eu me livrei desse problema realizando as seguintes ações:
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
Em seguida, editei manualmente pv individualmente e removi finalizers que se parecia com isto:
Finalizadores `` `:

• kubernetes.io / pv-protection```

Uma vez feito isso, os PVs que estavam na condição Terminating foram embora !!!

A resposta de @ chandraprakash1392 ainda é válida quando pvc stucks também no status Terminating .
Você só precisa editar o objeto pvc e remover finalizers object.

Remover os finalizadores é apenas uma solução alternativa. @bertinatto @leakingtapan você poderia ajudar a reproduzir este problema e salvar logs detalhados do driver CSI e do gerenciador de controlador?

exemplos de remoção para finalizadores

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

então você pode excluí-los

!!! IMPORTANTE !!!:
Leia também https://github.com/kubernetes/kubernetes/issues/78106
Os comandos de patch são uma solução alternativa e algo não está funcionando corretamente.
Os volumes ainda estão anexados: kubectl get volumeattachments!

Remover os finalizadores é apenas uma solução alternativa. @bertinatto @leakingtapan você poderia ajudar a reproduzir este problema e salvar logs detalhados do driver CSI e do gerenciador de controlador?

Consegui reproduzi-lo após algumas tentativas, embora as mensagens de log pareçam um pouco diferentes das relatadas por @leakingtapan :

Plugin (provisionador): https://gist.github.com/bertinatto/16f5c1f76b1c2577cd66dbedfa4e0c7c
Plugin (anexo): https://gist.github.com/bertinatto/25ebd591ffc88d034f5b4419c0bfa040
Gerente de controlador: https://gist.github.com/bertinatto/a2d82fdbccbf7ec0bb5e8ab65d47dcf3

Mesmo aqui, tive que deletar o finalizador, aqui está uma descrição para o 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>

Lendo os logs, parece que o controlador A / D tentou anexar o volume e obteve um erro do anexador externo. Por que não excluiu o VolumeAttachment posteriormente? Você ainda tem um pod que usa o volume? Nesse caso, ele bloqueia a exclusão do PV.

@jsafrane , só tenho um pod e excluo o PVC depois que o pod é excluído

Consigo reproduzir o problema de forma consistente. Isso acontece quando AttachVolume falha.

Para reproduzir, criei um cluster k8s de três nós. E eu crio um PV provisionado estático depois de criar um volume EBS manualmente. Implante as especificações:

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

Quando a criação do pod falhou devido à incompatibilidade de zona, exclua o pod e, em seguida, exclua o PVC. E o PV ficará preso no estado de encerramento. Eu reproduzi isso na v1.13

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

Acho que o objeto volumeattachment remanescente é causado quando csi_attacher.go não conseguiu anexar o volume, o objeto volumeattachment não foi excluído

Poderíamos deletar o objeto quando waitForVolumeAttachment falhar. Como você pensa? Terei o maior prazer em enviar a correção.

/ cc @jsafrane @ msau42

Reproduzi o problema usando uma identificação de volume inexistente (a anexação falha com "O volume 'vol-01213456789' não existe").

Poderíamos deletar o objeto quando waitForVolumeAttachment falhar.

Isso é muito complicado. Pode haver dois tipos de falhas de anexação:

1. "permanente", o volume nunca pode ser anexado: o volume EBS não existe, tem zona errada, IAM não tem permissões suficientes, ...
2. "temporário", o volume pode ser anexado em um futuro (próximo): tempo limite, o volume está sendo desconectado de outro nó

Quando waitForVolumeAttachment falha, o controlador A / D não sabe que tipo de falha foi. O anexador externo ainda tenta anexar o volume em paralelo, na esperança de que eventualmente tenha sucesso.

Especialmente quando o anexador expirou (o volume estava "Anexando" por um longo tempo), você pode ver que o driver AWS CSI não desconecta um volume quando waitForAttachmentState falha:

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

Isso significa que a AWS ainda tenta anexar o volume, apesar do tempo limite de retorno do driver CSI. O próximo ControllerPublish deve retomar waitForAttachmentState onde parou antes. Neste ponto, o controlador A / D não deve excluir VolumeAttachment, porque isso desconectaria o volume. O controlador A / D tentaria reconectar o volume em um curto espaço de tempo (ou seja, criar um novo VolumeAttachment) e o volume começaria "Anexando" "do zero" e provavelmente expiraria novamente, criando um loop de criação / exclusão de VolumeAttachment , mas nunca esperando o tempo suficiente para que o anexo seja bem-sucedido.

Temos várias opções:

1 O controlador A / D lembra que o volume está sendo conectado - não está nem conectado (o pod não pode ser iniciado) nem desconectado (Detach () deve ser chamado quando o volume desaparecer do DSW). Isso pode ser bastante complicado, especialmente ao reconstruir esse estado após a reinicialização do controlador.

1. O plugin de volume CSI pode deletar VolumeAttachment quando waitForVolumeAttachment falhar, mas então esperamos que ControllerPublish / Unpublish seja bastante rápido (15s por padrão) e não precise ser "retomado" conforme implementado agora e descrito acima. Aumentar o tempo limite de 15s pode ajudar neste caso (mas é codificado no plug-in de volume CSI e não é configurável).

cc @gnufied @bertinatto

@ jingxu97 , lembro-me corretamente de que havia algo na reconstrução de volume que tornava os volumes nem montados nem desmontados no VolumeManager? Talvez precisemos de algo semelhante aqui.

@jsafrane parece estar relacionado a isso https://github.com/kubernetes/kubernetes/pull/71276

@ jingxu97 Na verdade, # 71276 ajudou, muito obrigado.

Os problemas ficam obsoletos após 90 dias de inatividade.
Marque o problema como novo com /remove-lifecycle stale .
Problemas obsoletos apodrecem após 30 dias adicionais de inatividade e, eventualmente, fecham.

Se for seguro encerrar este problema agora, faça-o com /close .

Envie feedback para sig-testing, kubernetes / test-infra e / ou fejta .
/ lifecycle stale

/ remove-lifecycle stale

acabei de encontrar esse problema e tive que usar kubectl edit pv | pvc e remover os finalizadores para eliminar os objetos

@pniederlag isso é reproduzível? Em caso afirmativo, você pode fornecer detalhes de PVC? Todos os pods usando aquele PVC também foram excluídos?

@pnegahdar só quer ter certeza de qual versão do kubernetes você está usando

@pniederlag isso é reproduzível? Em caso afirmativo, você pode fornecer detalhes de PVC? Todos os pods usando aquele PVC também foram excluídos?

@ msau42 infelizmente não tenho um cenário para reproduzir isso facilmente. Ainda sou novo no kubernetes e encontrando meu caminho para lidar com volumes com pods e encontrei vários problemas para travar o pod ao anexar o volume (apoiado por um disco azul). Portanto, meu caso de uso provavelmente não era lógico (usando o painel do terraform e do kubernetes em paralelo).

exemplos de remoção para finalizadores

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

então você pode excluí-los

obrigado funciona para mim

Olhando para o erro, suspeito que ele esteja relacionado ao # 73098. Durante a exclusão do namespace, parece que o deletionTimestamp nos recursos restantes é atualizado continuamente, causando erros de conflito quando o controlador tenta remover seu finalizador. Parece que a solução para este problema está em 1.14+

Os problemas ficam obsoletos após 90 dias de inatividade.
Marque o problema como novo com /remove-lifecycle stale .
Problemas obsoletos apodrecem após 30 dias adicionais de inatividade e, eventualmente, fecham.

Se for seguro encerrar este problema agora, faça-o com /close .

Envie feedback para sig-testing, kubernetes / test-infra e / ou fejta .
/ lifecycle stale

/ remove-lifecycle stale

Experimentando em v1.14.6. relatou meu problema aqui inicialmente: https://github.com/longhorn/longhorn/issues/722, pois também estou usando o Longhorn. O Longhorn parece fazer o que deveria, excluindo o volume. A tentativa de excluir o pvc por meio da API resulta no pod preso em 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"
}

Eu me livrei desse problema realizando as seguintes ações:

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

Em seguida, editei manualmente pv individualmente e removi finalizers que se parecia com isto:

  - kubernetes.io/pv-protection```

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

Use o comando abaixo para editar o pv e então deletar o objeto finalizadores na definição
kubectl edit pv pv-name-id

Alguma solução real até agora? Lembro-me de ter visto esse problema nos primeiros meses de 2019 e ainda vejo o patching dos finalizadores como a única solução alternativa. Infelizmente, esse "bug" me proíbe de automatizar certas coisas.

Alguém tem um diagnóstico sobre isso? Alguma ideia? Depois de 7 meses, essa coisa ainda está em liberdade e não recebi mais informações 7 meses depois.

Várias causas raízes diferentes foram corrigidas.

Para depurar quaisquer problemas adicionais, precisamos de etapas de reprodução, registros mais detalhados de kube-controller-manager para ver o que o controlador de proteção pv está fazendo e, potencialmente, mais registros de outros controladores / drivers para depurar mais.

Os problemas ficam obsoletos após 90 dias de inatividade.
Marque o problema como novo com /remove-lifecycle stale .
Problemas obsoletos apodrecem após 30 dias adicionais de inatividade e, eventualmente, fecham.

Se for seguro encerrar este problema agora, faça-o com /close .

Envie feedback para sig-testing, kubernetes / test-infra e / ou fejta .
/ lifecycle stale

/ remove-lifecycle stale

Ainda acontecendo em 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

Eu também fui atingido por isso. O PV tinha o finalizador "foregroundDeletion" no lugar. Editar o PV e remover o finalizador permitiu que o PV terminasse.

Será que vamos parar de brincar com esses finalizadores com edição manual?

Se houver pods ou trabalhos usando o PV, descobri que excluí-los resolve o problema para mim

mesmo problema, tive que remover manualmente - kubernetes.io/pv-protection para que os PVs fossem excluídos. Isso aconteceu com AKS em k8s 1.17.9

mesmo problema aconteceu. Excluí o ebs manualmente do aws e tentei excluir o PV, mas ele travou no status de encerramento.

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

Acabei de ter um problema quase idêntico acontecendo comigo. Estou no Kubernetes 1.19.0 no Centos 7, montando um compartilhamento TerraMaster NAS via NFS. Eu tinha acabado de remover todo PV e PVC enquanto testava a criação desses dois tipos de itens em preparação para a instalação do leme. Quando tentei removê-los, eles travaram. Também tive que editar manualmente o pv para remover o finalizador (também kubernetes.io/pv-protection como andrei-dascalu) e, em seguida, ele finalmente excluiu.

O mesmo problema aqui:

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

Resolvido o problema de PVC e PV travados no estado de "encerramento", excluindo o pod usando-o.

Não, quando isso acontecer com meu PV, o pod não existe mais.

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

Resolvido o problema de PVC e PV travados no estado de "encerramento", excluindo o pod usando-o.

-
Você está recebendo isto porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub ou cancele a inscrição.

Tive vários pvcs presos no status de encerramento.
kubectl describe pvcname (para obter o pod ao qual está anexado.)
kubectl patch pvc pvcname -p '{"metadados": {"finalizadores": null}}'
kubectl patch pod podname -p '{"metadata": {"finalizers": null}}'
Isso funcionou no meu cluster K8S

Obrigado por postar esses comandos para se livrar do pvc

@wolfewicz @DMXGuru se os pods forem excluídos, o pvc não deve ficar preso nos estados de encerramento. O usuário não deve precisar remover o finalizador manualmente.
Você poderia reproduzir seu caso e dar alguns detalhes aqui, para que possamos ajudar na triagem?

Como e quais detalhes você gostaria? Os comandos e a saída kubectl mostrando esse comportamento e, em seguida, um kubectl describe e kubectl get -o yaml para o PV resultante?

Enviado do meu iPhone

Em 8 de outubro de 2020, às 14:30, Jing Xu [email protected] escreveu:

@wolfewicz @DMXGuru se os pods forem excluídos, o pvc não deve ficar preso nos estados de encerramento. O usuário não deve precisar remover o finalizador manualmente.
Você poderia reproduzir seu caso e dar alguns detalhes aqui, para que possamos ajudar na triagem?

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub ou cancele a inscrição.

@DMXGuru A primeira coisa que quero verificar é se não há pods em execução e nenhum VolumeSnapshots é tirado durante o encerramento de PVC / PV.

kubectl describe pod | grep ClaimName
kubectl describe volumesnapshot | grep persistentVolumeClaimName

Em segundo lugar, você poderia descrever em que sequência você executou a exclusão de pod ou pvc? Obrigado!