@ kubernetes / sig-aws @ kubernetes / sig-scheduling

Normalmente, a limpeza do volume e da rede consome mais tempo no encerramento. Você consegue descobrir em que fase seu pod está preso? Limpeza de volume, por exemplo?

Normalmente, a limpeza do volume e da rede consome mais tempo no encerramento.

Corrigir. Eles são sempre suspeitos.

@igorleao Você pode tentar kubectl delete pod xxx --now também.

Olá @resouer e @dixudx
Não tenho certeza. Olhando os registros do kubelet para um pod diferente com o mesmo problema, descobri:

Sep 02 15:31:57 ip-172-16-30-208 kubelet[9620]: time="2017-09-02T15:31:57Z" level=info msg="Releasing address using workloadID" Workload=my-pod-969733955-rbxhn
Sep 02 15:31:57 ip-172-16-30-208 kubelet[9620]: time="2017-09-02T15:31:57Z" level=info msg="Releasing all IPs with handle 'my-pod-969733955-rbxhn'"
Sep 02 15:31:57 ip-172-16-30-208 kubelet[9620]: time="2017-09-02T15:31:57Z" level=warning msg="Asked to release address but it doesn't exist. Ignoring" Workload=my-pod-969733955-rbxhn workloadId=my-pod-969733955-rbxhn
Sep 02 15:31:57 ip-172-16-30-208 kubelet[9620]: time="2017-09-02T15:31:57Z" level=info msg="Teardown processing complete." Workload=my-pod-969733955-rbxhn endpoint=<nil>
Sep 02 15:31:57 ip-172-16-30-208 kubelet[9620]: I0902 15:31:57.496132    9620 qos_container_manager_linux.go:285] [ContainerManager]: Updated QoS cgroup configuration
Sep 02 15:31:57 ip-172-16-30-208 kubelet[9620]: I0902 15:31:57.968147    9620 reconciler.go:201] UnmountVolume operation started for volume "kubernetes.io/secret/GUID-default-token-wrlv3" (spec.Name: "default-token-wrlv3") from pod "GUID" (UID: "GUID").
Sep 02 15:31:57 ip-172-16-30-208 kubelet[9620]: I0902 15:31:57.968245    9620 reconciler.go:201] UnmountVolume operation started for volume "kubernetes.io/secret/GUID-token-key" (spec.Name: "token-key") from pod "GUID" (UID: "GUID").
Sep 02 15:31:57 ip-172-16-30-208 kubelet[9620]: E0902 15:31:57.968537    9620 nestedpendingoperations.go:262] Operation for "\"kubernetes.io/secret/GUID-token-key\" (\"GUID\")" failed. No retries permitted until 2017-09-02 15:31:59.968508761 +0000 UTC (durationBeforeRetry 2s). Error: UnmountVolume.TearDown failed for volume "kubernetes.io/secret/GUID-token-key" (volume.spec.Name: "token-key") pod "GUID" (UID: "GUID") with: rename /var/lib/kubelet/pods/GUID/volumes/kubernetes.io~secret/token-key /var/lib/kubelet/pods/GUID/volumes/kubernetes.io~secret/wrapped_token-key.deleting~818780979: device or resource busy
Sep 02 15:31:57 ip-172-16-30-208 kubelet[9620]: E0902 15:31:57.968744    9620 nestedpendingoperations.go:262] Operation for "\"kubernetes.io/secret/GUID-default-token-wrlv3\" (\"GUID\")" failed. No retries permitted until 2017-09-02 15:31:59.968719924 +0000 UTC (durationBeforeRetry 2s). Error: UnmountVolume.TearDown failed for volume "kubernetes.io/secret/GUID-default-token-wrlv3" (volume.spec.Name: "default-token-wrlv3") pod "GUID" (UID: "GUID") with: rename /var/lib/kubelet/pods/GUID/volumes/kubernetes.io~secret/default-token-wrlv3 /var/lib/kubelet/pods/GUID/volumes/kubernetes.io~secret/wrapped_default-token-wrlv3.deleting~940140790: device or resource busy
--
Sep 02 15:33:04 ip-172-16-30-208 kubelet[9620]: I0902 15:33:04.778742    9620 reconciler.go:363] Detached volume "kubernetes.io/secret/GUID-wrapped_default-token-wrlv3.deleting~940140790" (spec.Name: "wrapped_default-token-wrlv3.deleting~940140790") devicePath: ""
Sep 02 15:33:04 ip-172-16-30-208 kubelet[9620]: I0902 15:33:04.778753    9620 reconciler.go:363] Detached volume "kubernetes.io/secret/GUID-wrapped_token-key.deleting~850807831" (spec.Name: "wrapped_token-key.deleting~850807831") devicePath: ""
Sep 02 15:33:04 ip-172-16-30-208 kubelet[9620]: I0902 15:33:04.778764    9620 reconciler.go:363] Detached volume "kubernetes.io/secret/GUID-wrapped_token-key.deleting~413655961" (spec.Name: "wrapped_token-key.deleting~413655961") devicePath: ""
Sep 02 15:33:04 ip-172-16-30-208 kubelet[9620]: I0902 15:33:04.778774    9620 reconciler.go:363] Detached volume "kubernetes.io/secret/GUID-wrapped_token-key.deleting~818780979" (spec.Name: "wrapped_token-key.deleting~818780979") devicePath: ""
Sep 02 15:33:04 ip-172-16-30-208 kubelet[9620]: I0902 15:33:04.778784    9620 reconciler.go:363] Detached volume "kubernetes.io/secret/GUID-wrapped_token-key.deleting~348212189" (spec.Name: "wrapped_token-key.deleting~348212189") devicePath: ""
Sep 02 15:33:04 ip-172-16-30-208 kubelet[9620]: I0902 15:33:04.778796    9620 reconciler.go:363] Detached volume "kubernetes.io/secret/GUID-wrapped_token-key.deleting~848395852" (spec.Name: "wrapped_token-key.deleting~848395852") devicePath: ""
Sep 02 15:33:04 ip-172-16-30-208 kubelet[9620]: I0902 15:33:04.778808    9620 reconciler.go:363] Detached volume "kubernetes.io/secret/GUID-wrapped_default-token-wrlv3.deleting~610264100" (spec.Name: "wrapped_default-token-wrlv3.deleting~610264100") devicePath: ""
Sep 02 15:33:04 ip-172-16-30-208 kubelet[9620]: I0902 15:33:04.778820    9620 reconciler.go:363] Detached volume "kubernetes.io/secret/GUID-wrapped_token-key.deleting~960022821" (spec.Name: "wrapped_token-key.deleting~960022821") devicePath: ""
Sep 02 15:33:05 ip-172-16-30-208 kubelet[9620]: I0902 15:33:05.081380    9620 server.go:778] GET /stats/summary/: (37.027756ms) 200 [[Go-http-client/1.1] 10.0.46.202:54644]
Sep 02 15:33:05 ip-172-16-30-208 kubelet[9620]: I0902 15:33:05.185367    9620 operation_generator.go:597] MountVolume.SetUp succeeded for volume "kubernetes.io/secret/GUID-calico-token-w8tzx" (spec.Name: "calico-token-w8tzx") pod "GUID" (UID: "GUID").
Sep 02 15:33:07 ip-172-16-30-208 kubelet[9620]: I0902 15:33:07.187953    9620 kubelet.go:1824] SyncLoop (DELETE, "api"): "my-pod-969733955-rbxhn_container-4-production(GUID)"
Sep 02 15:33:13 ip-172-16-30-208 kubelet[9620]: I0902 15:33:13.879940    9620 aws.go:937] Could not determine public DNS from AWS metadata.
Sep 02 15:33:20 ip-172-16-30-208 kubelet[9620]: I0902 15:33:20.736601    9620 server.go:778] GET /metrics: (53.063679ms) 200 [[Prometheus/1.7.1] 10.0.46.198:43576]
Sep 02 15:33:23 ip-172-16-30-208 kubelet[9620]: I0902 15:33:23.898078    9620 aws.go:937] Could not determine public DNS from AWS metadata.

Como você pode ver, este cluster tem Calico para CNI.
As seguintes linhas chamam minha atenção:

Sep 02 15:31:57 ip-172-16-30-208 kubelet[9620]: I0902 15:31:57.968245    9620 reconciler.go:201] UnmountVolume operation started for volume "kubernetes.io/secret/GUID-token-key" (spec.Name: "token-key") from pod "GUID" (UID: "GUID").
Sep 02 15:31:57 ip-172-16-30-208 kubelet[9620]: E0902 15:31:57.968537    9620 nestedpendingoperations.go:262] Operation for "\"kubernetes.io/secret/GUID-token-key\" (\"GUID\")" failed. No retries permitted until 2017-09-02 15:31:59.968508761 +0000 UTC (durationBeforeRetry 2s). Error: UnmountVolume.TearDown failed for volume "kubernetes.io/secret/GUID-token-key" (volume.spec.Name: "token-key") pod "GUID" (UID: "GUID") with: rename /var/lib/kubelet/pods/GUID/volumes/kubernetes.io~secret/token-key /var/lib/kubelet/pods/GUID/volumes/kubernetes.io~secret/wrapped_token-key.deleting~818780979: device or resource busy
Sep 02 15:31:57 ip-172-16-30-208 kubelet[9620]: E0902 15:31:57.968744    9620 nestedpendingoperations.go:262] Operation for "\"kubernetes.io/secret/GUID-default-token-wrlv3\" (\"GUID\")" failed. No retries permitted until 2017-09-02 15:31:59.968719924 +0000 UTC (durationBeforeRetry 2s). Error: UnmountVolume.TearDown failed for volume "kubernetes.io/secret/GUID-default-token-wrlv3" (volume.spec.Name: "default-token-wrlv3") pod "GUID" (UID: "GUID") with: rename 

Existe uma maneira melhor de descobrir em que fase um pod está preso?

kubectl delete pod xxx --now parece funcionar muito bem, mas eu realmente desejo descobrir sua causa raiz e evitar a interação humana.

rename /var/lib/kubelet/pods/GUID/volumes/kubernetes.io~secret/token-key /var/lib/kubelet/pods/GUID/volumes/kubernetes.io~secret/wrapped_token-key.deleting~818780979: device or resource busy

Parece que kubelet/mount falhou ao montar o configmap como um volume devido à renomeação do arquivo.

@igorleao Isso é reproduzível? Ou simplesmente não é tão estável, acontecendo ocasionalmente. Já conheci esses erros antes, só para ter certeza.

@dixudx acontece várias vezes ao dia para um determinado cluster. Outros clusters criados com a mesma versão de kops e kubernetes, na mesma semana, funcionam bem.

@igorleao Como o log mostra que o gerenciador de volume falhou ao remover o diretório secrete porque o dispositivo está ocupado.
Você poderia verificar se o diretório /var/lib/kubelet/pods/GUID/volumes/kubernetes.io~secret/token-key ainda está montado ou não? Obrigado!

@igorleao como você executa o kubelet? no recipiente? Em caso afirmativo, você pode postar sua unidade do systemd ou configuração do docker para kubelet?

Vemos um comportamento semelhante. Executamos o kubelet como contêiner e o problema foi parcialmente mitigado montando /var/lib/kubelet como compartilhado (por padrão, o docker monta o volume como rslave). Mas ainda vemos problemas semelhantes, mas menos frequentes. Atualmente, suspeito que algumas outras montagens devem ser feitas de maneira diferente (por exemplo, /var/lib/docker ou /rootfs )

@stormltf Você pode postar a configuração do seu contêiner kubelet?

@stormltf você está executando o kubelet no container e não usa a flag --containerized (que faz alguns truques com montagens ). O que basicamente significa que todas as montagens que o kubelet faz serão feitas no namespace de montagem do contêiner. Ainda bem que eles serão propostos de volta ao namespace da máquina host (já que você tem / var / lib / kubelet compartilhado), mas não tenho certeza do que acontece se o namespace for removido (quando o contêiner do kubelet for removido).

Para pods presos, faça o seguinte:

no nó onde o pod está sendo executado

• docker exec -ti /kubelet /bin/bash -c "mount | grep STUCK_POD_UUID"
• e o mesmo no próprio nó mount | grep STUCK_POD_UUID .

Faça também o mesmo para o pod recém-criado. Espero ver algumas montagens /var/lib/kubelet (por exemplo, default-secret)

@stormltf você reiniciou o kubelet depois que os dois primeiros pods foram criados?

@stormltf Você pode tentar tornar /var/lib/docker e /rootfs como ponto de montagem compartilhado (o que não vejo em seu docker inspecionar, mas vejo dentro do contêiner).

/ sig armazenamento

Para alguns, pode ajudar. Estamos executando o kubelet no contêiner do docker com a bandeira --containerized e conseguimos resolver esse problema montando /rootfs , /var/lib/docker e /var/lib/kubelet como montagens compartilhadas. As montagens finais são assim

      -v /:/rootfs:ro,shared \
      -v /sys:/sys:ro \
      -v /dev:/dev:rw \
      -v /var/log:/var/log:rw \
      -v /run/calico/:/run/calico/:rw \
      -v /run/docker/:/run/docker/:rw \
      -v /run/docker.sock:/run/docker.sock:rw \
      -v /usr/lib/os-release:/etc/os-release \
      -v /usr/share/ca-certificates/:/etc/ssl/certs \
      -v /var/lib/docker/:/var/lib/docker:rw,shared \
      -v /var/lib/kubelet/:/var/lib/kubelet:rw,shared \
      -v /etc/kubernetes/ssl/:/etc/kubernetes/ssl/ \
      -v /etc/kubernetes/config/:/etc/kubernetes/config/ \
      -v /etc/cni/net.d/:/etc/cni/net.d/ \
      -v /opt/cni/bin/:/opt/cni/bin/ \

Para mais alguns detalhes. Isso não resolve o problema de maneira adequada, pois para cada montagem de bind você obterá 3 montagens dentro do contêiner kubelet (2 parasitas). Mas pelo menos a montagem compartilhada permite desmontá-los facilmente com um tiro.

CoreOS não tem esse problema. Porque o uso rkt e não docker para kubelet container. No caso de nosso kubelet ser executado no Docker e cada montagem dentro do Kubelet continer for proposta em /var/lib/docker/overlay/... e /rootfs é por isso que temos duas montagens parasitas para cada volume de montagem bind:

• um de /rootfs em /rootfs/var/lib/kubelet/<mount>
• um de /var/lib/docker em /var/lib/docker/overlay/.../rootfs/var/lib/kubelet/<mount>

-v /dev:/dev:rw 
-v /etc/cni:/etc/cni:ro 
-v /opt/cni:/opt/cni:ro 
-v /etc/ssl:/etc/ssl:ro 
-v /etc/resolv.conf:/etc/resolv.conf 
-v /etc/pki/tls:/etc/pki/tls:ro 
-v /etc/pki/ca-trust:/etc/pki/ca-trust:ro
-v /sys:/sys:ro 
-v /var/lib/docker:/var/lib/docker:rw 
-v /var/log:/var/log:rw
-v /var/lib/kubelet:/var/lib/kubelet:shared 
-v /var/lib/cni:/var/lib/cni:shared 
-v /var/run:/var/run:rw 
-v /www:/www:rw 
-v /etc/kubernetes:/etc/kubernetes:ro 
-v /etc/os-release:/etc/os-release:ro 
-v /usr/share/zoneinfo/Asia/Shanghai:/etc/localtime:ro

Tenho o mesmo problema com o Kubernetes 1.8.1 no Azure - depois que a implantação é alterada e novos pods são iniciados, os pods antigos ficam presos no encerramento.

Tenho o mesmo problema no Kubernetes 1.8.2 no IBM Cloud. Depois que novos pods são iniciados, os pods antigos param de terminar.

versão kubectl
Server Version: version.Info{Major:"1", Minor:"8+", GitVersion:"v1.8.2-1+d150e4525193f1", GitCommit:"d150e4525193f1c79569c04efc14599d7deb5f3e", GitTreeState:"clean", BuildDate:"2017-10-27T08:15:17Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"}

Usei kubectl delete pod xxx --now assim como kubectl delete pod foo --grace-period=0 --force sem sucesso.

Se a causa raiz ainda for a mesma (montagens propostas incorretamente), então este é o bug específico da distribuição.

Descreva como você executa o kubelet run na nuvem IBM. unidade systemd? tem a bandeira --containerized ?

ele é executado com o sinalizador --containerized definido como falso.

systemctl status kubelet.service kubelet.service - Kubernetes Kubelet Loaded: loaded (/lib/systemd/system/kubelet.service; enabled; vendor preset: enabled) Active: active (running) since Sun 2017-11-19 21:48:48 UTC; 4 days ago

- sinalizador contêinerizado: Não

ok, preciso de mais informações, por favor, veja meu comentário acima https://github.com/kubernetes/kubernetes/issues/51835#issuecomment -333090349

e também mostre o conteúdo de /lib/systemd/system/kubelet.service e se houver algo sobre kubelet em /etc/systemd/system , compartilhe também.

Em particular, se o kubelet for executado no docker, quero ver todas as montagens de bind -v .

Hoje encontrei um problema que pode ser igual ao descrito, em que tínhamos pods em um de nossos sistemas de cliente travando no estado de encerramento por vários dias. Também víamos os erros sobre "Erro: UnmountVolume.TearDown falhou para o volume" com "dispositivo ou recurso ocupado" repetido para cada um dos pods presos.

Em nosso caso, parece ser um problema com docker em sistemas baseados em RHEL / Centos 7.4 coberto neste problema moby: https://github.com/moby/moby/issues/22260 e este PR moby: https: // github .com / moby / moby / pull / 34886 / files

Para nós, assim que definirmos a opção sysctl fs.may_detach_mounts = 1 em alguns minutos, todos os nossos pods de terminação serão limpos.

Também estou enfrentando este problema: os pods travaram no estado de terminação em 1.8.3.

Registros de kubelet relevantes do nó:

Nov 28 22:48:51 <my-node> kubelet[1010]: I1128 22:48:51.616749    1010 reconciler.go:186] operationExecutor.UnmountVolume started for volume "nfs-mtkylje2oc4xlju1ls9rdwjlcmxhyi1ydw" (UniqueName: "kubernetes.io/nfs/58dc413c-d4d1-11e7-870d-3c970e298d91-nfs-mtkylje2oc4xlju1ls9rdwjlcmxhyi1ydw") pod "58dc413c-d4d1-11e7-870d-3c970e298d91" (UID: "58dc413c-d4d1-11e7-870d-3c970e298d91")
Nov 28 22:48:51 <my-node> kubelet[1010]: W1128 22:48:51.616762    1010 util.go:112] Warning: "/var/lib/kubelet/pods/58dc413c-d4d1-11e7-870d-3c970e298d91/volumes/kubernetes.io~nfs/nfs-mtkylje2oc4xlju1ls9rdwjlcmxhyi1ydw" is not a mountpoint, deleting
Nov 28 22:48:51 <my-node> kubelet[1010]: E1128 22:48:51.616828    1010 nestedpendingoperations.go:264] Operation for "\"kubernetes.io/nfs/58dc413c-d4d1-11e7-870d-3c970e298d91-nfs-mtkylje2oc4xlju1ls9rdwjlcmxhyi1ydw\" (\"58dc413c-d4d1-11e7-870d-3c970e298d91\")" failed. No retries permitted until 2017-11-28 22:48:52.616806562 -0800 PST (durationBeforeRetry 1s). Error: UnmountVolume.TearDown failed for volume "nfs-mtkylje2oc4xlju1ls9rdwjlcmxhyi1ydw" (UniqueName: "kubernetes.io/nfs/58dc413c-d4d1-11e7-870d-3c970e298d91-nfs-mtkylje2oc4xlju1ls9rdwjlcmxhyi1ydw") pod "58dc413c-d4d1-11e7-870d-3c970e298d91" (UID: "58dc413c-d4d1-11e7-870d-3c970e298d91") : remove /var/lib/kubelet/pods/58dc413c-d4d1-11e7-870d-3c970e298d91/volumes/kubernetes.io~nfs/nfs-mtkylje2oc4xlju1ls9rdwjlcmxhyi1ydw: directory not empty
Nov 28 22:48:51 <my-node> kubelet[1010]: W1128 22:48:51.673774    1010 docker_sandbox.go:343] failed to read pod IP from plugin/docker: NetworkPlugin cni failed on the status hook for pod "<pod>": CNI failed to retrieve network namespace path: Cannot find network namespace for the terminated container "f58ab11527aef5133bdb320349fe14fd94211aa0d35a1da006aa003a78ce0653"

O Kubelet está sendo executado como uma unidade systemd (não no contêiner) no Ubuntu 16.04.
Como você pode ver, houve uma montagem no servidor NFS e, de alguma forma, o kubelet tentou excluir o diretório de montagem porque considera esse diretório como não montado.

Especificação de volumes do pod:

volumes:
  - name: nfs-mtkylje2oc4xlju1ls9rdwjlcmxhyi1ydw
    nfs:
      path: /<path>
      server: <IP>
  - name: default-token-rzqtt
    secret:
      defaultMode: 420
      secretName: default-token-rzqtt

UPD : Eu também enfrentei esse problema antes no 1.6.6

Experimentando o mesmo no Azure ..

NAME                        READY     STATUS        RESTARTS   AGE       IP             NODE
busybox2-7db6d5d795-fl6h9   0/1       Terminating   25         1d        10.200.1.136   worker-1
busybox3-69d4f5b66c-2lcs6   0/1       Terminating   26         1d        <none>         worker-2
busybox7-797cc644bc-n5sv2   0/1       Terminating   26         1d        <none>         worker-2
busybox8-c8f95d979-8lk27    0/1       Terminating   25         1d        10.200.1.137   worker-1
nginx-56ccc998dd-hvpng      0/1       Terminating   0          2h        <none>         worker-1
nginx-56ccc998dd-nnsvj      0/1       Terminating   0          2h        <none>         worker-2
nginx-56ccc998dd-rsrvq      0/1       Terminating   0          2h        <none>         worker-1

versão kubectl

Client Version: version.Info{Major:"1", Minor:"8", GitVersion:"v1.8.0", GitCommit:"6e937839ac04a38cac63e6a7a306c5d035fe7b0a", GitTreeState:"clean", BuildDate:"2017-09-28T22:57:57Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"8", GitVersion:"v1.8.0", GitCommit:"6e937839ac04a38cac63e6a7a306c5d035fe7b0a", GitTreeState:"clean", BuildDate:"2017-09-28T22:46:41Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"}

descrever pod nginx-56ccc998dd-nnsvj

Name:                      nginx-56ccc998dd-nnsvj
Namespace:                 default
Node:                      worker-2/10.240.0.22
Start Time:                Wed, 29 Nov 2017 13:33:39 +0400
Labels:                    pod-template-hash=1277755488
                           run=nginx
Annotations:               kubernetes.io/created-by={"kind":"SerializedReference","apiVersion":"v1","reference":{"kind":"ReplicaSet","namespace":"default","name":"nginx-56ccc998dd","uid":"614f71db-d4e8-11e7-9c45-000d3a25e3c0","...
Status:                    Terminating (expires Wed, 29 Nov 2017 15:13:44 +0400)
Termination Grace Period:  30s
IP:
Created By:                ReplicaSet/nginx-56ccc998dd
Controlled By:             ReplicaSet/nginx-56ccc998dd
Containers:
  nginx:
    Container ID:   containerd://d00709dfb00ed5ac99dcd092978e44fc018f44cca5229307c37d11c1a4fe3f07
    Image:          nginx:1.12
    Image ID:       docker.io/library/nginx<strong i="12">@sha256</strong>:5269659b61c4f19a3528a9c22f9fa8f4003e186d6cb528d21e411578d1e16bdb
    Port:           <none>
    State:          Terminated
      Exit Code:    0
      Started:      Mon, 01 Jan 0001 00:00:00 +0000
      Finished:     Mon, 01 Jan 0001 00:00:00 +0000
    Ready:          False
    Restart Count:  0
    Environment:    <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-jm7h5 (ro)
Conditions:
  Type           Status
  Initialized    True
  Ready          False
  PodScheduled   True
Volumes:
  default-token-jm7h5:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-jm7h5
    Optional:    false
QoS Class:       BestEffort
Node-Selectors:  <none>
Tolerations:     <none>
Events:
  Type    Reason   Age   From               Message
  ----    ------   ----  ----               -------
  Normal  Killing  41m   kubelet, worker-2  Killing container with id containerd://nginx:Need to kill Pod

sudo journalctl -u kubelet | grep "nginx-56ccc998dd-nnsvj"

Nov 29 09:33:39 worker-2 kubelet[64794]: I1129 09:33:39.124779   64794 kubelet.go:1837] SyncLoop (ADD, "api"): "nginx-56ccc998dd-nnsvj_default(6171e2a7-d4e8-11e7-9c45-000d3a25e3c0)"
Nov 29 09:33:39 worker-2 kubelet[64794]: I1129 09:33:39.160444   64794 reconciler.go:212] operationExecutor.VerifyControllerAttachedVolume started for volume "default-token-jm7h5" (UniqueName: "kubernetes.io/secret/6171e2a7-d4e8-11e7-9c45-000d3a25e3c0-default-token-jm7h5") pod "nginx-56ccc998dd-nnsvj" (UID: "6171e2a7-d4e8-11e7-9c45-000d3a25e3c0")
Nov 29 09:33:39 worker-2 kubelet[64794]: I1129 09:33:39.261128   64794 reconciler.go:257] operationExecutor.MountVolume started for volume "default-token-jm7h5" (UniqueName: "kubernetes.io/secret/6171e2a7-d4e8-11e7-9c45-000d3a25e3c0-default-token-jm7h5") pod "nginx-56ccc998dd-nnsvj" (UID: "6171e2a7-d4e8-11e7-9c45-000d3a25e3c0")
Nov 29 09:33:39 worker-2 kubelet[64794]: I1129 09:33:39.286574   64794 operation_generator.go:484] MountVolume.SetUp succeeded for volume "default-token-jm7h5" (UniqueName: "kubernetes.io/secret/6171e2a7-d4e8-11e7-9c45-000d3a25e3c0-default-token-jm7h5") pod "nginx-56ccc998dd-nnsvj" (UID: "6171e2a7-d4e8-11e7-9c45-000d3a25e3c0")
Nov 29 09:33:39 worker-2 kubelet[64794]: I1129 09:33:39.431485   64794 kuberuntime_manager.go:370] No sandbox for pod "nginx-56ccc998dd-nnsvj_default(6171e2a7-d4e8-11e7-9c45-000d3a25e3c0)" can be found. Need to start a new one
Nov 29 09:33:42 worker-2 kubelet[64794]: I1129 09:33:42.449592   64794 kubelet.go:1871] SyncLoop (PLEG): "nginx-56ccc998dd-nnsvj_default(6171e2a7-d4e8-11e7-9c45-000d3a25e3c0)", event: &pleg.PodLifecycleEvent{ID:"6171e2a7-d4e8-11e7-9c45-000d3a25e3c0", Type:"ContainerStarted", Data:"0f539a84b96814651bb199e91f71157bc90c6e0c26340001c3f1c9f7bd9165af"}
Nov 29 09:33:47 worker-2 kubelet[64794]: I1129 09:33:47.637988   64794 kubelet.go:1871] SyncLoop (PLEG): "nginx-56ccc998dd-nnsvj_default(6171e2a7-d4e8-11e7-9c45-000d3a25e3c0)", event: &pleg.PodLifecycleEvent{ID:"6171e2a7-d4e8-11e7-9c45-000d3a25e3c0", Type:"ContainerStarted", Data:"d00709dfb00ed5ac99dcd092978e44fc018f44cca5229307c37d11c1a4fe3f07"}
Nov 29 11:13:14 worker-2 kubelet[64794]: I1129 11:13:14.468137   64794 kubelet.go:1853] SyncLoop (DELETE, "api"): "nginx-56ccc998dd-nnsvj_default(6171e2a7-d4e8-11e7-9c45-000d3a25e3c0)"
Nov 29 11:13:14 worker-2 kubelet[64794]: E1129 11:13:14.711891   64794 kuberuntime_manager.go:840] PodSandboxStatus of sandbox "0f539a84b96814651bb199e91f71157bc90c6e0c26340001c3f1c9f7bd9165af" for pod "nginx-56ccc998dd-nnsvj_default(6171e2a7-d4e8-11e7-9c45-000d3a25e3c0)" error: rpc error: code = Unknown desc = failed to get task status for sandbox container "0f539a84b96814651bb199e91f71157bc90c6e0c26340001c3f1c9f7bd9165af": process id 0f539a84b96814651bb199e91f71157bc90c6e0c26340001c3f1c9f7bd9165af not found: not found
Nov 29 11:13:14 worker-2 kubelet[64794]: E1129 11:13:14.711933   64794 generic.go:241] PLEG: Ignoring events for pod nginx-56ccc998dd-nnsvj/default: rpc error: code = Unknown desc = failed to get task status for sandbox container "0f539a84b96814651bb199e91f71157bc90c6e0c26340001c3f1c9f7bd9165af": process id 0f539a84b96814651bb199e91f71157bc90c6e0c26340001c3f1c9f7bd9165af not found: not found
Nov 29 11:13:15 worker-2 kubelet[64794]: I1129 11:13:15.788179   64794 kubelet.go:1871] SyncLoop (PLEG): "nginx-56ccc998dd-nnsvj_default(6171e2a7-d4e8-11e7-9c45-000d3a25e3c0)", event: &pleg.PodLifecycleEvent{ID:"6171e2a7-d4e8-11e7-9c45-000d3a25e3c0", Type:"ContainerDied", Data:"d00709dfb00ed5ac99dcd092978e44fc018f44cca5229307c37d11c1a4fe3f07"}
Nov 29 11:13:15 worker-2 kubelet[64794]: I1129 11:13:15.788221   64794 kubelet.go:1871] SyncLoop (PLEG): "nginx-56ccc998dd-nnsvj_default(6171e2a7-d4e8-11e7-9c45-000d3a25e3c0)", event: &pleg.PodLifecycleEvent{ID:"6171e2a7-d4e8-11e7-9c45-000d3a25e3c0", Type:"ContainerDied", Data:"0f539a84b96814651bb199e91f71157bc90c6e0c26340001c3f1c9f7bd9165af"}
Nov 29 11:46:45 worker-2 kubelet[42337]: I1129 11:46:45.384411   42337 kubelet.go:1837] SyncLoop (ADD, "api"): "nginx-56ccc998dd-nnsvj_default(6171e2a7-d4e8-11e7-9c45-000d3a25e3c0), kubernetes-dashboard-7486b894c6-2xmd5_kube-system(e55ca22c-d416-11e7-9c45-000d3a25e3c0), busybox3-69d4f5b66c-2lcs6_default(adb05024-d412-11e7-9c45-000d3a25e3c0), kube-dns-7797cb8758-zblzt_kube-system(e925cbec-d40b-11e7-9c45-000d3a25e3c0), busybox7-797cc644bc-n5sv2_default(b7135a8f-d412-11e7-9c45-000d3a25e3c0)"
Nov 29 11:46:45 worker-2 kubelet[42337]: I1129 11:46:45.387169   42337 kubelet.go:1871] SyncLoop (PLEG): "nginx-56ccc998dd-nnsvj_default(6171e2a7-d4e8-11e7-9c45-000d3a25e3c0)", event: &pleg.PodLifecycleEvent{ID:"6171e2a7-d4e8-11e7-9c45-000d3a25e3c0", Type:"ContainerDied", Data:"d00709dfb00ed5ac99dcd092978e44fc018f44cca5229307c37d11c1a4fe3f07"}
Nov 29 11:46:45 worker-2 kubelet[42337]: I1129 11:46:45.387245   42337 kubelet.go:1871] SyncLoop (PLEG): "nginx-56ccc998dd-nnsvj_default(6171e2a7-d4e8-11e7-9c45-000d3a25e3c0)", event: &pleg.PodLifecycleEvent{ID:"6171e2a7-d4e8-11e7-9c45-000d3a25e3c0", Type:"ContainerDied", Data:"0f539a84b96814651bb199e91f71157bc90c6e0c26340001c3f1c9f7bd9165af"}

cat /etc/systemd/system/kubelet.service

[Unit]
Description=Kubernetes Kubelet
Documentation=https://github.com/GoogleCloudPlatform/kubernetes
After=cri-containerd.service
Requires=cri-containerd.service

[Service]
ExecStart=/usr/local/bin/kubelet \
  --allow-privileged=true \
  --anonymous-auth=false \
  --authorization-mode=Webhook \
  --client-ca-file=/var/lib/kubernetes/ca.pem \
  --cluster-dns=10.32.0.10 \
  --cluster-domain=cluster.local \
  --container-runtime=remote \
  --container-runtime-endpoint=unix:///var/run/cri-containerd.sock \
  --image-pull-progress-deadline=2m \
  --kubeconfig=/var/lib/kubelet/kubeconfig \
  --network-plugin=cni \
  --pod-cidr=10.200.2.0/24 \
  --register-node=true \
  --require-kubeconfig \
  --runtime-request-timeout=15m \
  --tls-cert-file=/var/lib/kubelet/worker-2.pem \
  --tls-private-key-file=/var/lib/kubelet/worker-2-key.pem \
  --v=2
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

Parece que existem vários bugs relacionados com o problema. Temos ambos em nosso cluster 1.8.3.

1. https://github.com/moby/moby/issues/31768 . É bug do docker. Reproduzível no docker-ce = 17.09.0 ~ ce-0 ~ ubuntu.
2. O segundo é mais interessante e talvez esteja relacionado a alguma condição de corrida dentro do kubelet.
   Temos muitos pods que usaram o volume de persistência NFS com subcaminho especificado em montagens de contêiner; de alguma forma, alguns deles estão travando em um estado de encerramento após a exclusão de implantações. E há muitas mensagens no syslog:

 Error: UnmountVolume.TearDown failed for volume "nfs-test" (UniqueName: "kubernetes.io/nfs/39dada78-d9cc-11e7-870d-3c970e298d91-nfs-test") pod "39dada78-d9cc-11e7-870d-3c970e298d91" (UID: "39dada78-d9cc-11e7-870d-3c970e298d91") : remove /var/lib/kubelet/pods/39dada78-d9cc-11e7-870d-3c970e298d91/volumes/kubernetes.io~nfs/nfs-test: directory not empty

E seu diretório verdadeiro não está vazio, ele está desmontado e contém nosso diretório "subcaminho"!
Uma das explicações para esse comportamento:

1. P1: Comece a criar pod ou sincronizar pod
2. P1: Enviar sinal ao gerenciador de volume para fazer montagens / remontagens.
3. P1: está aguardando a conclusão da montagem.
4. P1: Recebe o sinal de montagem com sucesso (na verdade, apenas verifique se todos os volumes estão montados)
5. De alguma forma, o volume foi desmontado. Pode ser outro processo de exclusão desmontá-lo ou algum bug do sistema operacional, ou alguma ação do coletor de lixo.
6. P1: Continue criando container e crie subdiretório no ponto de montagem (já desmontado).
7. Depois de todas as etapas anteriores, o pod não pode ser excluído, porque o diretório de montagem não está vazio.

Mais registros:

Dec  5 15:57:08 ASRock kubelet[2941]: I1205 15:57:08.333877    2941 reconciler.go:212] operationExecutor.VerifyControllerAttachedVolume started for volume "nfs-mtkylje2oc4xlju1ls9rdwjlcmxhyi1ydw" (UniqueName: "kubernetes.io/nfs/005b4bb9-da18-11e7-870d-3c970e298d91-nfs-mtkylje2oc4xlju1ls9rdwjlcmxhyi1ydw") pod "test-df5d868fc-sclj5" (UID: "005b4bb9-da18-11e7-870d-3c970e298d91")
Dec  5 15:57:08 ASRock systemd[1]: Started Kubernetes transient mount for /var/lib/kubelet/pods/005b4bb9-da18-11e7-870d-3c970e298d91/volumes/kubernetes.io~nfs/nfs-mtkylje2oc4xlju1ls9rdwjlcmxhyi1ydw.
Dec  5 15:57:12 ASRock kubelet[2941]: I1205 15:57:12.266404    2941 reconciler.go:186] operationExecutor.UnmountVolume started for volume "nfs-mtkylje2oc4xlju1ls9rdwjlcmxhyi1ydw" (UniqueName: "kubernetes.io/nfs/005b4bb9-da18-11e7-870d-3c970e298d91-nfs-mtkylje2oc4xlju1ls9rdwjlcmxhyi1ydw") pod "005b4bb9-da18-11e7-870d-3c970e298d91" (UID: "005b4bb9-da18-11e7-870d-3c970e298d91")
Dec  5 15:57:12 ASRock kubelet[2941]: E1205 15:57:12.387179    2941 nestedpendingoperations.go:264] Operation for "\"kubernetes.io/nfs/005b4bb9-da18-11e7-870d-3c970e298d91-nfs-mtkylje2oc4xlju1ls9rdwjlcmxhyi1ydw\" (\"005b4bb9-da18-11e7-870d-3c970e298d91\")" failed. No retries permitted until 2017-12-05 15:57:12.887062059 -0800 PST (durationBeforeRetry 500ms). Error: UnmountVolume.TearDown failed for volume "nfs-mtkylje2oc4xlju1ls9rdwjlcmxhyi1ydw" (UniqueName: "kubernetes.io/nfs/005b4bb9-da18-11e7-870d-3c970e298d91-nfs-mtkylje2oc4xlju1ls9rdwjlcmxhyi1ydw") pod "005b4bb9-da18-11e7-870d-3c970e298d91" (UID: "005b4bb9-da18-11e7-870d-3c970e298d91") : remove /var/lib/kubelet/pods/005b4bb9-da18-11e7-870d-3c970e298d91/volumes/kubernetes.io~nfs/nfs-mtkylje2oc4xlju1ls9rdwjlcmxhyi1ydw: directory not empty

De alguma forma, alguns processos de limpeza ((dswp * desejadoStateOfWorldPopulator) findAndRemoveDeletedPods ()) iniciam a desmontagem de volumes enquanto o pod está no estado de inicialização:

Dec  6 14:40:20 ASRock kubelet[15875]: I1206 14:40:20.620655   15875 kubelet_pods.go:886] Pod "test-84cd5ff8dc-kpv7b_4281-kuberlab-test(6e99a8df-dad6-11e7-b35c-3c970e298d91)" is terminated, but some volumes have not been cleaned up
Dec  6 14:40:20 ASRock kubelet[15875]: I1206 14:40:20.686449   15875 kubelet_pods.go:1730] Orphaned pod "6e99a8df-dad6-11e7-b35c-3c970e298d91" found, but volumes not yet removed
Dec  6 14:40:20 ASRock kubelet[15875]: I1206 14:40:20.790719   15875 kuberuntime_container.go:100] Generating ref for container test: &v1.ObjectReference{Kind:"Pod", Namespace:"4281-kuberlab-test", Name:"test-84cd5ff8dc-kpv7b", UID:"6e99a8df-dad6-11e7-b35c-3c970e298d91", APIVersion:"v1", ResourceVersion:"2639758", FieldPath:"spec.containers{test}"}
Dec  6 14:40:20 ASRock kubelet[15875]: I1206 14:40:20.796643   15875 docker_service.go:407] Setting cgroup parent to: "/kubepods/burstable/pod6e99a8df-dad6-11e7-b35c-3c970e298d91"

O pod de inicialização e exclusão está sendo executado ao mesmo tempo.
Para repetir o bug, você deve iniciar e excluir / atualizar imediatamente cerca de 10 implantações (testadas para um único lacaio) e talvez sua operação de montagem não deva ser muito rápida.

Afetado pelo mesmo bug no GKE. Existem soluções alternativas conhecidas para esse problema? Usar --now não funciona.

Eu tenho a correção para esse bug, mas não tenho certeza se ele será mesclado pela equipe do kubernetes.

@dreyk Você poderia fornecer mais detalhes sobre o que descobriu para este bug e qual é a sua correção para que a equipe de armazenamento possa dar uma olhada? Obrigado!

@ gm42 Consegui contornar manualmente esse problema no GKE ao:

1. SSH no nó em que o pod preso foi programado
2. Executando docker ps | grep {pod name} para obter o ID do Docker Container
3. Executando docker rm -f {container id}

No GKE, o upgrade de nós ajudou instantaneamente.

Tenho o mesmo bug em meu cluster local configurado usando kubeadm .

docker ps | grep {pod name} no nó não mostra nada e o pod travou no estado de encerramento. Atualmente, tenho dois pods neste estado.

O que posso fazer para excluir o pod à força? Ou talvez mudar o nome do pod? Não posso girar outro pod com o mesmo nome. Obrigado!

Eu encontrei o motivo no meu cluster 1.7.2,
porque outro programa de monitor monta o caminho raiz /
o caminho raiz contém /var/lib/kubelet/pods/ddc66e10-0711-11e8-b905-6c92bf70b164/volumes/kubernetes.io~secret/default-token-bnttf
então, quando kubelet deleta o pod, mas não consegue liberar o volume, a mensagem é:
Dispositivo ou recurso ocupado

passos:
1) sudo journalctl -u kubelet
este shell me ajuda a encontrar a mensagem de erro,
2) sudo docker inspect
encontre o io.kubernetes.pod.uid ":" ddc66e10-0711-11e8-b905-6c92bf70b164 "
e
HostConfig -> Binds -> "/var/lib/kubelet/pods/ddc66e10-0711-11e8-b905-6c92bf70b164/volumes/kubernetes.io~secret/default-token-bnttf:/var/run/secrets/kubernetes .io / servi ceaccount: ro "

3) grep -l ddc66e10-0711-11e8-b905-6c92bf70b164 / proc / * / mountinfo

/ proc / 90225 / mountinfo
5) ps aux | grep 90225
root 90225 1,3 0,0 2837164 42580? Ssl Fev01 72:40 ./monitor_program

Tenho o mesmo bug no meu 1.7.2

operationExecutor.UnmountVolume iniciado para o volume "default-token-bnttf" (UniqueName: "kubernetes.io/secret/ddc66e10-0711-11e8-b905-6c92bf70b164-default-token-bnttf") pod "ddc66e1090-07115-11e8-b 6c92bf70b164 "kubelet [94382]: E0205 11: 35: 50.509169 94382 nestedpendingoperations.go: 262] Operação para" \ "kubernetes.io/secret/ddc66e10-0711-11e8-b905-6c92bf70b164-default-default-default "ddc66e10-0711-11e8-b905-6c92bf70b164 \") "falhou. Não são permitidas novas tentativas até 05/02/2018 11: 37: 52.509148953 +0800 CST (durationBeforeRetry 2m2s). Erro: UnmountVolume.TearDown falhou para o volume "default-token-bnttf" (UniqueName: "kubernetes.io/secret/ddc66e10-0711-11e8-b905-6c92bf70b164-default-token-bnttf") pod "ddc66e10-0711-11e8-8- b905-6c92bf70b164 "(UID:" ddc66e10-0711-11e8-b905-6c92bf70b164 "): remove /var/lib/kubelet/pods/ddc66e10-0711-11e8-b905-6c92bf70b164/volumes/kubaultio token-bnttf: dispositivo ou recurso ocupado

Reiniciar o serviço docker libera o bloqueio e os pods são removidos em poucos minutos. Este é um bug. Usando docker 17.03

Mesmo problema aqui no Azure, Kube 1.8.7

Também aconteceu conosco há alguns minutos em 1.8.9 - alguém está procurando uma solução para isso? Reiniciar o docker ajuda, mas é um pouco ridículo.

Isso tem acontecido muito comigo na última versão 1.9.4 do GKE. Tenho feito isso por agora:

kubectl delete pod NAME --grace-period=0 --force

O mesmo problema aqui no GKE 1.9.4-gke.1
parece estar relacionado a montagens de volume.
Isso acontece sempre com filebeats configurados conforme descrito aqui:
https://github.com/elastic/beats/tree/master/deploy/kubernetes/filebeat

O log do Kubelet mostra isso:

Mar 23 19:44:16 gke-testing-c2m4-1-97b57429-40jp kubelet[1361]: I0323 19:44:16.380949    1361 reconciler.go:191] operationExecutor.UnmountVolume started for volume "config" (UniqueName: "kubernetes.io/configmap/9a5f1519-2d39-11e8-bec8-42010a8400f3-config") pod "9a5f1519-2d39-11e8-bec8-42010a8400f3" (UID: "9a5f1519-2d39-11e8-bec8-42010a8400f3")
Mar 23 19:44:16 gke-testing-c2m4-1-97b57429-40jp kubelet[1361]: E0323 19:44:16.382032    1361 nestedpendingoperations.go:263] Operation for "\"kubernetes.io/configmap/9a5f1519-2d39-11e8-bec8-42010a8400f3-config\" (\"9a5f1519-2d39-11e8-bec8-42010a8400f3\")" failed. No retries permitted until 2018-03-23 19:44:32.381982706 +0000 UTC m=+176292.263058344 (durationBeforeRetry 16s). Error: "error cleaning subPath mounts for volume \"config\" (UniqueName: \"kubernetes.io/configmap/9a5f1519-2d39-11e8-bec8-42010a8400f3-config\") pod \"9a5f1519-2d39-11e8-bec8-42010a8400f3\" (UID: \"9a5f1519-2d39-11e8-bec8-42010a8400f3\") : error checking /var/lib/kubelet/pods/9a5f1519-2d39-11e8-bec8-42010a8400f3/volume-subpaths/config/filebeat/0 for mount: lstat /var/lib/kubelet/pods/9a5f1519-2d39-11e8-bec8-42010a8400f3/volume-ubpaths/config/filebeat/0/..: not a directory"

kubectl delete pod NAME --grace-period=0 --force
parece funcionar.
também reiniciar o kubelet funciona.

O mesmo problema aqui no GKE 1.9.4-gke.1
Só acontece com um daemonset de filebeat específico, mas recriar todos os nós também não ajuda, simplesmente continua acontecendo.

Também atingindo esse problema no GKE 1.9.4-gke.1 como @Tapppi - os pods foram removidos do docker daemon no nó do host, mas o kubernetes o prendeu em TERMINATING

Events:
  Type    Reason                 Age        From                                                      Message
  ----    ------                 ----       ----                                                      -------
  Normal  SuccessfulMountVolume  43m        kubelet, gke-delivery-platform-custom-pool-c9b9fe86-fgvh  MountVolume.SetUp succeeded for volume "data"
  Normal  SuccessfulMountVolume  43m        kubelet, gke-delivery-platform-custom-pool-c9b9fe86-fgvh  MountVolume.SetUp succeeded for volume "varlibdockercontainers"
  Normal  SuccessfulMountVolume  43m        kubelet, gke-delivery-platform-custom-pool-c9b9fe86-fgvh  MountVolume.SetUp succeeded for volume "prospectors"
  Normal  SuccessfulMountVolume  43m        kubelet, gke-delivery-platform-custom-pool-c9b9fe86-fgvh  MountVolume.SetUp succeeded for volume "config"
  Normal  SuccessfulMountVolume  43m        kubelet, gke-delivery-platform-custom-pool-c9b9fe86-fgvh  MountVolume.SetUp succeeded for volume "filebeat-token-v74k6"
  Normal  Pulled                 43m        kubelet, gke-delivery-platform-custom-pool-c9b9fe86-fgvh  Container image "docker.elastic.co/beats/filebeat:6.1.2" already present on machine
  Normal  Created                43m        kubelet, gke-delivery-platform-custom-pool-c9b9fe86-fgvh  Created container
  Normal  Started                43m        kubelet, gke-delivery-platform-custom-pool-c9b9fe86-fgvh  Started container
  Normal  Killing                <invalid>  kubelet, gke-delivery-platform-custom-pool-c9b9fe86-fgvh  Killing container with id docker://filebeat:Need to kill Pod
/Users/karl.stoney/git/autotrader/terraform-gcp git/master

Para nós, algo novo aconteceu um momento atrás, quando removi à força um pod preso usando kubectl delete pod NAME --grace-period=0 --force , o nó em que esse pod estava entrou em mau estado. Estamos executando o docker 17-12CE, e reiniciar o docker deamon naquela caixa ajudou e desarrolhou o nó.

Para as pessoas que veem esse problema no 1.9.4-gke.1, provavelmente é devido a https://github.com/kubernetes/kubernetes/issues/61178 , que foi corrigido no 1.9.5 e está sendo implementado no GKE esta semana. O problema está relacionado à limpeza de montagens de subcaminhos de um arquivo (não de um diretório). @zackify @ nodefactory-bk @Tapppi @Stono

IIUC, o problema original neste bug está relacionado à configuração do kubelet em contêiner, que é diferente.

A propósito, criar um novo pool de nós com a versão v1.9.3-gke.0 foi nossa solução alternativa para isso, uma vez que v1.9.5 ainda não foi lançado no gke e já é Páscoa.

Alguém pode confirmar que isso foi corrigido na versão 1.9.3+, por favor? Temos alguns problemas sérios por causa desse comportamento e reiniciar o docker cada vez que isso acontecer é soo st00pid.

Fixado em 1.9.6 para mim

Na quarta-feira, 4 de abril de 2018, 11h43 sokoow, [email protected] escreveu:

Alguém pode confirmar que isso foi corrigido na versão 1.9.3+, por favor? Nós temos
alguns problemas sérios por causa desse comportamento, e reiniciar o docker cada
vez que isso acontece é tão st00pid.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/kubernetes/kubernetes/issues/51835#issuecomment-378557636 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/ABaviW5yfj64zVjBYFGUToe2MH3dKwpTks5tlKPNgaJpZM4PKs9r
.

Ok, obrigado @Stono . Mais uma coisa a confirmar aqui. Este é o nosso modelo kubespray para kubelet em contêineres:

#!/bin/bash /usr/bin/docker run \ --net=host \ --pid=host \ --privileged \ --name=kubelet \ --restart=on-failure:5 \ --memory={{ kubelet_memory_limit|regex_replace('Mi', 'M') }} \ --cpu-shares={{ kubelet_cpu_limit|regex_replace('m', '') }} \ -v /dev:/dev:rw \ -v /etc/cni:/etc/cni:ro \ -v /opt/cni:/opt/cni:ro \ -v /etc/ssl:/etc/ssl:ro \ -v /etc/resolv.conf:/etc/resolv.conf \ {% for dir in ssl_ca_dirs -%} -v {{ dir }}:{{ dir }}:ro \ {% endfor -%} -v /:/rootfs:ro,shared \ -v /sys:/sys:ro \ -v /var/lib/docker:/var/lib/docker:rw,shared \ -v /var/log:/var/log:rw,shared \ -v /var/lib/kubelet:/var/lib/kubelet:rw,shared \ -v /var/lib/cni:/var/lib/cni:rw,shared \ -v /var/run:/var/run:rw,shared \ -v /etc/kubernetes:/etc/kubernetes:ro \ -v /etc/os-release:/etc/os-release:ro \ {{ hyperkube_image_repo }}:{{ hyperkube_image_tag}} \ ./hyperkube kubelet --containerized \ "$@"

Isso parece ok? Alguém mais está usando algo semelhante?

Eu falei muito cedo.

  Type    Reason   Age   From                                                      Message                                                                                                             [53/7752]
  ----    ------   ----  ----                                                      -------
  Normal  Killing  4m    kubelet, gke-delivery-platform-custom-pool-560b2b96-gcmb  Killing container with id docker://filebeat:Need to kill Pod

Tive que destruí-lo de forma brutal.

❯ kks delete pod filebeat-x56v8 --force --grace-period 0
warning: Immediate deletion does not wait for confirmation that the running resource has been terminated. The resource may continue to run on the cluster indefinitely.
pod "filebeat-x56v8" deleted

@Stono qual versão do docker você está usando? para nós com docker 17.12CE, fazer a exclusão de pod com --force --grace-period 0 é bastante drástico - quase sempre termina com o nó indisponível devido ao travamento do docker

Ainda estou tendo esse problema no 1.9.6 no cluster gerenciado do Azure AKS.

Usando esta solução alternativa no momento para selecionar todos os pods presos e excluí-los (pois acabo tendo várias faixas de pods de terminação em meu cluster dev / scratch):

kubectl get pods | awk '$3=="Terminating" {print "kubectl delete pod " $1 " --grace-period=0 --force"}' | xargs -0 bash -c

deparei com isso em clusters do Azure e AWS - a solução alternativa foi fornecida por Mike Elliot

https://jira.onap.org/browse/OOM-946

ubuntu @ ip-10-0-0-22 : ~ $ kubectl get pods --all-namespaces
NAMESPACE NOME PRONTO ESTADO REINICIA IDADE
Kube-system heapster-76b8cd7b5-4r88h 1/1 Executando 0 25d
kube-system kube-dns-5d7b4487c9-s4rsg 3/3 Executando 0 25d
kube-system kubernetes-dashboard-f9577fffd-298r6 1/1 Executando 0 25d
kube-system monitoring-grafana-997796fcf-wtz7n 1/1 Executando 0 25d
kube-system monitoring-influxdb-56fdcd96b-2phd2 1/1 Running 0 25d
kube-system tiller-deploy-cc96d4f6b-jzqmz 1/1 Executando 0 25d
onap dev-sms-857f6dbd87-pds58 0/1 Encerrando 0 3h
onap dev-vfc-zte-sdnc-driver-5b6c7cbd6b-5vdvp 0/1 Encerrando 0 3h
ubuntu @ ip-10-0-0-22 : ~ $ kubectl deletar pod dev-vfc-zte-sdnc-driver-5b6c7cbd6b-5vdvp -n onap --grace-period = 0 --force
aviso: a exclusão imediata não espera pela confirmação de que o recurso em execução foi encerrado. O recurso pode continuar em execução no cluster indefinidamente.
pod "dev-vfc-zte-sdnc-driver-5b6c7cbd6b-5vdvp" excluído
ubuntu @ ip-10-0-0-22 : ~ $ kubectl get pods --all-namespaces
NAMESPACE NOME PRONTO STATUS RESTARTS IDADE
Kube-system heapster-76b8cd7b5-4r88h 1/1 Executando 0 25d
kube-system kube-dns-5d7b4487c9-s4rsg 3/3 Executando 0 25d
kube-system kubernetes-dashboard-f9577fffd-298r6 1/1 Executando 0 25d
kube-system monitoring-grafana-997796fcf-wtz7n 1/1 Executando 0 25d
kube-system monitoring-influxdb-56fdcd96b-2phd2 1/1 Running 0 25d
kube-system tiller-deploy-cc96d4f6b-jzqmz 1/1 Executando 0 25d
onap dev-sms-857f6dbd87-pds58 0/1 Encerrando 0 3h
ubuntu @ ip-10-0-0-22 : ~ $ kubectl delete pod dev-sms-857f6dbd87-pds58 -n onap --grace-period = 0 --force
aviso: a exclusão imediata não espera pela confirmação de que o recurso em execução foi encerrado. O recurso pode continuar em execução no cluster indefinidamente.
pod "dev-sms-857f6dbd87-pds58" excluído
ubuntu @ ip-10-0-0-22 : ~ $ kubectl get pods --all-namespaces
NAMESPACE NOME PRONTO STATUS RESTARTS IDADE
Kube-system heapster-76b8cd7b5-4r88h 1/1 Executando 0 25d
kube-system kube-dns-5d7b4487c9-s4rsg 3/3 Executando 0 25d
kube-system kubernetes-dashboard-f9577fffd-298r6 1/1 Executando 0 25d
kube-system monitoring-grafana-997796fcf-wtz7n 1/1 Executando 0 25d
kube-system monitoring-influxdb-56fdcd96b-2phd2 1/1 Running 0 25d
kube-system tiller-deploy-cc96d4f6b-jzqmz 1/1 Executando 0 25d

Não tenho certeza se este é o mesmo problema, mas começamos a notar esse comportamento _desde_ a atualização de 1.9.3 para 10.10.1. Isso nunca aconteceu antes disso. Estamos usando volumes glusterfs, com SubPath. Kubelet registra continuamente coisas como

Apr 23 08:21:11 int-kube-01 kubelet[13018]: I0423 08:21:11.106779   13018 reconciler.go:181] operationExecutor.UnmountVolume started for volume "dev-static" (UniqueName: "kubernetes.io/glusterfs/ad8fabbe-4449-11e8-b21a-a2bfb3c62d0f-dev-static") pod "ad8fabbe-4449-11e8-b21a-a2bfb3c62d0f" (UID: "ad8fabbe-4449-11e8-b21a-a2bfb3c62d0f")
Apr 23 08:21:11 int-kube-01 kubelet[13018]: E0423 08:21:11.122027   13018 nestedpendingoperations.go:267] Operation for "\"kubernetes.io/glusterfs/ad8fabbe-4449-11e8-b21a-a2bfb3c62d0f-dev-static\" (\"ad8fabbe-4449-11e8-b21a-a2bfb3c62d0f\")" failed. No retries permitted until 2018-04-23 08:23:13.121821027 +1000 AEST m=+408681.605939042 (durationBeforeRetry 2m2s). Error: "UnmountVolume.TearDown failed for volume \"dev-static\" (UniqueName: \"kubernetes.io/glusterfs/ad8fabbe-4449-11e8-b21a-a2bfb3c62d0f-dev-static\") pod \"ad8fabbe-4449-11e8-b21a-a2bfb3c62d0f\" (UID: \"ad8fabbe-4449-11e8-b21a-a2bfb3c62d0f\") : Unmount failed: exit status 32\nUnmounting arguments: /var/lib/kubelet/pods/ad8fabbe-4449-11e8-b21a-a2bfb3c62d0f/volumes/kubernetes.io~glusterfs/dev-static\nOutput: umount: /var/lib/kubelet/pods/ad8fabbe-4449-11e8-b21a-a2bfb3c62d0f/volumes/kubernetes.io~glusterfs/dev-static: target is busy.\n        (In some cases useful info about processes that use\n         the device is found by lsof(8) or fuser(1))\n\n"

e lsof mostra de fato que o diretório sob os volumes glusterfs ainda está em uso:

glusterfs  71570                     root   10u      DIR              0,264      4096  9380607748984626555 /var/lib/kubelet/pods/ad8fabbe-4449-11e8-b21a-a2bfb3c62d0f/volumes/kubernetes.io~glusterfs/dev-static/subpathhere
glusterti  71570  71571              root   10u      DIR              0,264      4096  9380607748984626555 /var/lib/kubelet/pods/ad8fabbe-4449-11e8-b21a-a2bfb3c62d0f/volumes/kubernetes.io~glusterfs/dev-static/subpathhere
glustersi  71570  71572              root   10u      DIR              0,264      4096  9380607748984626555 /var/lib/kubelet/pods/ad8fabbe-4449-11e8-b21a-a2bfb3c62d0f/volumes/kubernetes.io~glusterfs/dev-static/subpathhere
glusterme  71570  71573              root   10u      DIR              0,264      4096  9380607748984626555 /var/lib/kubelet/pods/ad8fabbe-4449-11e8-b21a-a2bfb3c62d0f/volumes/kubernetes.io~glusterfs/dev-static/subpathhere
glustersp  71570  71574              root   10u      DIR              0,264      4096  9380607748984626555 /var/lib/kubelet/pods/ad8fabbe-4449-11e8-b21a-a2bfb3c62d0f/volumes/kubernetes.io~glusterfs/dev-static/subpathhere
glustersp  71570  71575              root   10u      DIR              0,264      4096  9380607748984626555 /var/lib/kubelet/pods/ad8fabbe-4449-11e8-b21a-a2bfb3c62d0f/volumes/kubernetes.io~glusterfs/dev-static/subpathhere
glusterep  71570  71579              root   10u      DIR              0,264      4096  9380607748984626555 /var/lib/kubelet/pods/ad8fabbe-4449-11e8-b21a-a2bfb3c62d0f/volumes/kubernetes.io~glusterfs/dev-static/subpathhere
glusterio  71570  71580              root   10u      DIR              0,264      4096  9380607748984626555 /var/lib/kubelet/pods/ad8fabbe-4449-11e8-b21a-a2bfb3c62d0f/volumes/kubernetes.io~glusterfs/dev-static/subpathhere
glusterep  71570  71581              root   10u      DIR              0,264      4096  9380607748984626555 /var/lib/kubelet/pods/ad8fabbe-4449-11e8-b21a-a2bfb3c62d0f/volumes/kubernetes.io~glusterfs/dev-static/subpathhere
glusterep  71570  71582              root   10u      DIR              0,264      4096  9380607748984626555 /var/lib/kubelet/pods/ad8fabbe-4449-11e8-b21a-a2bfb3c62d0f/volumes/kubernetes.io~glusterfs/dev-static/subpathhere
glusterep  71570  71583              root   10u      DIR              0,264      4096  9380607748984626555 /var/lib/kubelet/pods/ad8fabbe-4449-11e8-b21a-a2bfb3c62d0f/volumes/kubernetes.io~glusterfs/dev-static/subpathhere
glusterep  71570  71584              root   10u      DIR              0,264      4096  9380607748984626555 /var/lib/kubelet/pods/ad8fabbe-4449-11e8-b21a-a2bfb3c62d0f/volumes/kubernetes.io~glusterfs/dev-static/subpathhere
glusterep  71570  71585              root   10u      DIR              0,264      4096  9380607748984626555 /var/lib/kubelet/pods/ad8fabbe-4449-11e8-b21a-a2bfb3c62d0f/volumes/kubernetes.io~glusterfs/dev-static/subpathhere
glusterep  71570  71586              root   10u      DIR              0,264      4096  9380607748984626555 /var/lib/kubelet/pods/ad8fabbe-4449-11e8-b21a-a2bfb3c62d0f/volumes/kubernetes.io~glusterfs/dev-static/subpathhere
glusterep  71570  71587              root   10u      DIR              0,264      4096  9380607748984626555 /var/lib/kubelet/pods/ad8fabbe-4449-11e8-b21a-a2bfb3c62d0f/volumes/kubernetes.io~glusterfs/dev-static/subpathhere
glusterfu  71570  71592              root   10u      DIR              0,264      4096  9380607748984626555 /var/lib/kubelet/pods/ad8fabbe-4449-11e8-b21a-a2bfb3c62d0f/volumes/kubernetes.io~glusterfs/dev-static/subpathhere
glusterfu  71570  71593              root   10u      DIR              0,264      4096  9380607748984626555 /var/lib/kubelet/pods/ad8fabbe-4449-11e8-b21a-a2bfb3c62d0f/volumes/kubernetes.io~glusterfs/dev-static/subpathhere

Tudo funcionou bem no 1.9.3, então é como se a correção para esse problema tivesse quebrado nosso caso de uso :(

@ross-w esta assinatura é diferente das outras. Você poderia abrir um novo problema e também incluir as especificações do seu pod?

Alguma atualização sobre esses problemas?
Em nosso caso (Kubernetes 1.9.7, docker 17.03), os pods estão no estado Encerrando, depois que o nó fica sem memória e os pods são reprogramados. Eventualmente, há muitos pods fantasmas no painel do kubernetes e na guia de implantações, podemos ver implantações com pods de 4/1.
Reiniciar o kubelet ou eliminar todos os pods no namespace ajuda, mas é uma solução muito pobre.

@Adiqq Pois era um problema com o próprio Docker.

Dê uma olhada em journalctl -u kubelet -f em um de seus nós. Recebi uma mensagem como 'Não é possível matar o contêinererro gRpc "(não tenho a mensagem real desde que corrigi isso).

Para corrigir isso, reiniciei o docker em cada nota. Durante a inicialização do Docker, limpe os contêineres em um estado quebrado e remova todos os pods obsoletos.

Tive isso ontem em 1.9.7, com um pod preso no estado de encerramento e nos logs ele tinha apenas "precisa matar o pod", tive que --force --grace-period=0 para me livrar.

Também consegui isso com 1.9.7-gke.0.
Não teve problemas com 1.9.6-gke.1.
Mas tinha com 1.9.4 e 1.9.5

O pod que está travando tem um PV anexado.

Reimplantar ou excluir um pod tem o mesmo efeito.
Reiniciar o kubelet no nó incorreto não funcionou. O kubelet não reiniciou e tive que reiniciar todo o nó.

Durante isso, o pod não pôde ser agendado em nenhum outro nó, pois dizia que o PV já estava montado em outro lugar.

@Stono @ nodefactory-bk vocês poderiam dar uma olhada nos logs do kubelet nos nós ofensivos para ver se há algum log detalhado que possa apontar para o problema?

cc @dashpole

Apenas um aplicativo travou no encerramento.
Este é o 1.9.7-gke.1
Aqui está o pod de kubectl describe com segredos redigidos:

Name:                      sharespine-cloud-6b78cbfb8d-xcbh5
Namespace:                 shsp-cloud-dev
Node:                      gke-testing-std4-1-0f83e7c0-qrxg/10.132.0.4
Start Time:                Tue, 22 May 2018 11:14:22 +0200
Labels:                    app=sharespine-cloud
                           pod-template-hash=2634769648
Annotations:               <none>
Status:                    Terminating (expires Wed, 23 May 2018 10:02:01 +0200)
Termination Grace Period:  60s
IP:                        10.40.7.29
Controlled By:             ReplicaSet/sharespine-cloud-6b78cbfb8d
Containers:
  sharespine-cloud:
    Container ID:   docker://4cf402b5dc3ea728fcbff87b57e0ec504093ea3cf7277f6ca83fde726a4bba48
    Image:          ...
    Image ID:       ...
    Ports:          9000/TCP, 9500/TCP
    State:          Running
      Started:      Tue, 22 May 2018 11:16:36 +0200
    Ready:          False
    Restart Count:  0
    Limits:
      memory:  1500M
    Requests:
      cpu:      500m
      memory:   1024M
    Liveness:   http-get http://:9000/ delay=240s timeout=1s period=30s #success=1 #failure=3
    Readiness:  http-get http://:9000/ delay=30s timeout=1s period=10s #success=1 #failure=3
    Environment Variables from:
      sharespine-cloud-secrets  Secret  Optional: false
    Environment:
      APP_NAME:  sharespine-cloud
      APP_ENV:   shsp-cloud-dev (v1:metadata.namespace)
      JAVA_XMS:  128M
      JAVA_XMX:  1024M
    Mounts:
      /home/app/sharespine-cloud-home/ from sharespine-cloud-home (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-x7vzr (ro)
  sharespine-cloud-elker:
    Container ID:   docker://88a5a2bfd6804b5f40534ecdb6953771ac3181cf12df407baa81a34a7215d142
    Image:          ...
    Image ID:       ...
    Port:           <none>
    State:          Running
      Started:      Tue, 22 May 2018 11:16:36 +0200
    Ready:          True
    Restart Count:  0
    Limits:
      memory:  200Mi
    Requests:
      cpu:     10m
      memory:  100Mi
    Environment Variables from:
      sharespine-cloud-secrets  Secret  Optional: false
    Environment:
      APP_NAME:                     sharespine-cloud
      APP_ENV:                      shsp-cloud-dev (v1:metadata.namespace)
      ELASTICSEARCH_LOGBACK_PATH:   /home/app/sharespine-cloud-home/logs/stash/stash.json
      ELASTICSEARCH_LOGBACK_INDEX:  cloud-dev
    Mounts:
      /home/app/sharespine-cloud-home/ from sharespine-cloud-home (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-x7vzr (ro)
Conditions:
  Type           Status
  Initialized    True
  Ready          False
  PodScheduled   True
Volumes:
  sharespine-cloud-home:
    Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
    ClaimName:  sharespine-cloud-home
    ReadOnly:   false
  default-token-x7vzr:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-x7vzr
    Optional:    false
QoS Class:       Burstable
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s
Events:
  Type     Reason         Age                From                                       Message
  ----     ------         ----               ----                                       -------
  Normal   Killing        20m                kubelet, gke-testing-std4-1-0f83e7c0-qrxg  Killing container with id docker://sharespine-cloud-elker:Need to kill Pod
  Normal   Killing        20m                kubelet, gke-testing-std4-1-0f83e7c0-qrxg  Killing container with id docker://sharespine-cloud:Need to kill Pod
  Warning  FailedKillPod  18m                kubelet, gke-testing-std4-1-0f83e7c0-qrxg  error killing pod: failed to "KillPodSandbox" for "83d05e96-5da0-11e8-ba51-42010a840176" with KillPodSandboxError: "rpc error: code = DeadlineExceeded desc = context deadline exceeded"
  Warning  FailedSync     1m (x53 over 16m)  kubelet, gke-testing-std4-1-0f83e7c0-qrxg  error determining status: rpc error: code = DeadlineExceeded desc = context deadline exceeded

Não tenho certeza de onde encontrar kubelet.log nas imagens do gke on googles. Encontrei algo que estou anexando.
kube.log

kubectl -n shsp-cloud-dev delete pod sharespine-cloud-6b78cbfb8d-xcbh5 --force --grace-period 0
matou e removeu.
Tudo começou bem depois, mas demorou um pouco mais do que o normal.

Lembre-se de que isso não acontece TODAS AS vezes para esse aplicativo.
Eu diria aproximadamente 1/4 de vez, provavelmente.

Atingindo isso com o k8s 1.9.6, quando o kubelet não consegue desmontar a montagem do Cephfs, todos os pods no nó permanecem encerrados para sempre. Tive que reiniciar o nó para recuperar, kubelet ou reinicialização do docker não ajudou.

@tuminoid o problema do

Para sua informação, atualizar meus clusters (para k8s v1.10.2) parece ter eliminado esse problema para nós.

O anexo reproduz isso para mim no gke

kubectl version
Client Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.3", GitCommit:"2bba0127d85d5a46ab4b778548be28623b32d0b0", GitTreeState:"clean", BuildDate:"2018-05-21T09:17:39Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"10+", GitVersion:"v1.10.2-gke.1", GitCommit:"75d2af854b1df023c7ce10a8795b85d3dd1f8d37", GitTreeState:"clean", BuildDate:"2018-05-10T17:23:18Z", GoVersion:"go1.9.3b4", Compiler:"gc", Platform:"linux/amd64"}

k8s-nfs-test.yaml.txt

execute-o e exclua-o. Você terá um 'nfs-client' travado na exclusão. O motivo é a montagem rígida no nó e o 'servidor' é excluído primeiro.

@donbowman para o problema de desmontagem do nfs ao excluir o servidor nfs primeiro, você pode definir a opção de montagem "soft" no StorageClass ou PV.

Não vejo como? Posso defini-lo em um PersistentVolumeClaim, mas isso não se aplica aqui.
Não acho que o StorageClass se aplique aqui (seria o under-disk, embaixo do servidor NFS).

O problema está no nfs-client.
estou esquecendo de algo?

Para seu nfs PV, você pode definir o campo mountOptions começando em 1.8 para especificar uma montagem suave. Se você provisionar volumes nfs dinamicamente, também pode configurá-lo em StorageClass.mountOptions

sim, mas não é o PV que está sendo montado com NFS.
É do meu contêiner de servidor NFS.
Não há provisionamento dinâmico.

Isso é usando Google GCP + GKE. O PVC seleciona um PV que é um bloco IO, montado como um ext4 em um contêiner que o reexporta com NFS.

O segundo conjunto de contêineres, que é montado a partir do nfs-server (que é um pod), eles não o veem como um PV. Eles vêem isso como um volume como abaixo.

Não vejo uma maneira de fazer com que este nfs-client veja um 'pvc' para a montagem, então não posso definir as opções de montagem. Nem posso vê-lo como um StorageClass.

Estou esquecendo de algo?

apiVersion: apps/v1beta2
kind: Deployment
metadata:
  name: nfs-client
  labels:
    app: nfs-client
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nfs-client
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: nfs-client
    spec:
      containers:
        - name: nfs-client
          image: busybox:latest
          imagePullPolicy: IfNotPresent
          command: ["sleep", "3600"]
          volumeMounts:
            - name: nfs
              mountPath: /registry
      volumes:
        - name: nfs
          nfs:
            server: nfs-server.default.svc.cluster.local
            path: /

@donbowman para seu segundo conjunto de contêineres, que usa o nfs mount, você pode criar manualmente um PV para esse volume nfs com o conjunto mountOptions e compartilhar o PVC desse nfs PV em todos os seus pods. Nenhum provisionamento dinâmico envolvido.

Algo assim:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-pv
spec:
  storageClassName: ""
  capacity:
    # Capacity doesn't actually matter for nfs
    storage: 500G 
  accessModes:
    - ReadWriteMany
  mountOptions:
    - soft
  nfs:
    server: nfs-server.default.svc.cluster.local
    path: /
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nfs-claim
spec:
  # It's necessary to specify "" as the storageClassName
  # so that the default storage class won't be used
  storageClassName: ""
  volumeName: nfs-pv
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 500G

Obrigado! Então funcionou (no sentido de que agora é uma montagem suave), mas não corrige o problema:

A montagem (conforme observado no Nó) agora é suave:

nfs-server.default.svc.cluster.local:/ on /home/kubernetes/containerized_mounter/rootfs/var/lib/kubelet/pods/cbeda204-638d-11e8-9758-42010aa200b4/volumes/kubernetes.io~nfs/nfs-pv type nfs4 (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,soft,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.162.0.2,local_lock=none,addr=10.19.241.155)

Mas quando excluo tudo, ainda consigo o nfs-client preso para sempre no estado Terminating.

k8s-nfs-test.yaml.txt

em anexo está o yaml que usei. Fiz uma 'criação', esperei que aparecesse, observei que o cliente tinha a montagem, podia ler / escrever arquivos nela, então fiz um 'deletar' nela.

O pod nfs-server é excluído, mas o nfs-client não.

Olhando para o pod, a montagem permaneceu:

# umount -f /home/kubernetes/containerized_mounter/rootfs/var/lib/kubelet/pods/cbeda204-638d-11e8-9758-42010aa200b4/volumes/kubernetes.io~nfs/nfs-pv
umount: /home/kubernetes/containerized_mounter/rootfs/var/lib/kubelet/pods/cbeda204-638d-11e8-9758-42010aa200b4/volumes/kubernetes.io~nfs/nfs-pv: target is busy
        (In some cases useful info about processes that
         use the device is found by lsof(8) or fuser(1).)

@donbowman ah, desculpe, eu estava errado sobre a opção suave. A opção soft apenas evita que as chamadas do sistema de arquivos sejam interrompidas quando o servidor estiver inacessível, mas não ajuda realmente a desmontar o volume nfs. Uma desmontagem forçada precisaria ser feita para isso, que atualmente não temos uma maneira de passar. Por enquanto, você terá que limpar manualmente essas montagens e garantir que exclua seus pods na ordem correta (clientes nfs primeiro, depois servidor nfs).

Tentei adicionar timeo = 30 e intr, mas o mesmo problema.
isso o trava, deve efetuar login no nó e fazer umount -f -l na montagem subjacente e, em seguida, pode fazer um kubectl delete --force --grace-period 0 no pod.

parece que, como isso foi montado em nome do pod, é possível desmontar (ou forçar umount após algum tempo limite) na exclusão automática.

Eu tinha um monte de pods assim, então tive que criar um comando que limparia todos os pods de terminação:

kubectl get pods -o json | jq -c '.items[] | select(.metadata.deletionTimestamp) | .metadata.name' | xargs -I '{}' kubectl delete pod --force --grace-period 0 '{}'

Acho que com o novo arquivo de arquivos do Google teremos o mesmo problema, sem umount.

@donbowman iirc, seu problema é porque você estava encerrando o pod do servidor nfs antes do pod do cliente nfs. Se você usar o filestore, não precisará mais de um pod para hospedar seu servidor nfs, então você não deve ter esse problema, contanto que não exclua todo o isntance do firestore.

não terei o mesmo problema se estiver orquestrando o armazenamento de arquivos? Por exemplo, se eu estou ativando para uma implantação específica do Kubernetes e, em seguida, desativando no final, a ordem não é garantida.

Mas também acho que o problema não é apenas a ordem, o pod do cliente NFS não desmonta, apenas deixa a montagem pendurada no nó. Portanto, independentemente de o armazenamento de arquivos / servidor estar presente ou não, há uma montagem pendente.

Quando um pod é encerrado, desmontamos o volume (supondo que o servidor ainda esteja lá). Se você está vendo montagens penduradas mesmo quando o servidor existe, isso é um bug.

Se você usar provisionamento dinâmico com PVCs e PVs, não permitiremos que o PVC (e o armazenamento subjacente) sejam excluídos até que todos os Pods que fazem referência a ele terminem de usá-lo. Se você quiser orquestrar o provisionamento por conta própria, certifique-se de não excluir o servidor até que todos os pods tenham terminado de usá-lo.

Talvez esta seja uma possível solução alternativa: # 65936

Forçar a exclusão funcionou para kubectl delete po $pod --grace-period=0 --force . A bandeira --now não estava funcionando. Não tenho certeza sobre # 65936, mas gostaria de não matar o nó quando Unknown estados acontecerem.

Tendo o mesmo problema (os pods permanecem sendo encerrados porque um arquivo dentro do pod não pode ser desmontado porque o dispositivo está 'ocupado') em 1.10.5. Para mim, usar --grace-period=0 --force resultará no ponto de montagem para continuar a existir. Eventualmente, acabei com mais de 90000 pontos de montagem, o que tornou o cluster severamente lento. A solução alternativa aqui é localizar a pasta do pod e desmontar recursivamente esses arquivos e, em seguida, excluir recursivamente a pasta do pod.
No meu caso, estou montando um configmap usando subpath em uma pasta existente com arquivos existentes, sobrescrevendo um dos arquivos existentes. Isso costumava funcionar bem para mim no 1.8.6.
O pôster original menciona que os pods ficam "encerrando" por algumas horas, no meu caso são dias. Eu não os vi serem limpos eventualmente, exceto quando eu faço a solução alternativa manual.

Tendo o mesmo problema, causado pelo agregador de log (semelhante ao fluentd), ele monta a pasta /var/lib/docker/containers e o pod tem muitas montagens:

shm                      64.0M         0     64.0M   0% /var/lib/docker/containers/6691cb9460df75579915fd881342931b98b4bfb7a6fbb0733cc6132d7c17710c/shm
shm                      64.0M         0     64.0M   0% /var/lib/docker/containers/4cbbdf53ee5122565c6e118a049c93543dcc93bfd586a3456ff4ca98d59810a3/shm
shm                      64.0M         0     64.0M   0% /var/lib/docker/containers/b2968b63a7a1f673577e5ada5f2cda50e1203934467b7c6573e21b341d80810a/shm
shm                      64.0M         0     64.0M   0% /var/lib/docker/containers/4d54a4eabed68b136b0aa3d385093e4a32424d18a08c7f39f5179440166de95f/shm
shm                      64.0M         0     64.0M   0% /var/lib/docker/containers/0e5487465abc2857446940902d9b9754b3447e587eefc2436b2bb78fd4d5ce4d/shm
shm                      64.0M         0     64.0M   0% /var/lib/docker/containers/c73ed0942d77bf43f9ba016728834c47339793f9f1f31c4e566d73be492cf859/shm
shm                      64.0M         0     64.0M   0% /var/lib/docker/containers/f9ab13f7f145b44beccc40c158287c4cfcc9dc465850f30d691961a2cabcfc14/shm
shm                      64.0M         0     64.0M   0% /var/lib/docker/containers/aa449af555702d04f95fed04d09a3f1d5ae38d677484fc6cc9fc6d4b42182820/shm
shm                      64.0M         0     64.0M   0% /var/lib/docker/containers/f6608e507348b43ade3faa05d0a11b674c29f2038308f138174e8b7b8233633f/shm

No meu caso, alguns pods podem ser bem removidos pelo kubernetes, mas alguns ficam presos no status "encerrando".

Pode estar relacionado a https://github.com/kubernetes/kubernetes/issues/45688 (também estou usando o docker 17)

Eu só tive o problema de que os pods não estavam encerrando porque um segredo estava faltando. Depois que criei aquele segredo naquele namespace, tudo voltou ao normal.

Eu removi meus pods presos assim:

user<strong i="6">@laptop</strong>:~$ kubectl -n storage get pod
NAME                     READY     STATUS        RESTARTS   AGE
minio-65b869c776-47hql   0/1       Terminating   5          1d
minio-65b869c776-bppl6   0/1       Terminating   33         1d
minio-778f4665cd-btnf5   1/1       Running       0          1h
sftp-775b578d9b-pqk5x    1/1       Running       0          28m
user<strong i="7">@laptop</strong>:~$ kubectl -n storage delete pod minio-65b869c776-47hql --grace-period 0 --force
pod "minio-65b869c776-47hql" deleted
user<strong i="8">@laptop</strong>:~$ kubectl -n storage delete pod minio-65b869c776-bppl6 --grace-period 0 --force
pod "minio-65b869c776-bppl6" deleted
user<strong i="9">@laptop</strong>:~$ kubectl -n storage get pod
NAME                     READY     STATUS    RESTARTS   AGE
minio-778f4665cd-btnf5   1/1       Running   0          2h
sftp-775b578d9b-pqk5x    1/1       Running   0          30m
user<strong i="10">@laptop</strong>:~$

Tenho um problema semelhante ao executar no Azure ACS.

10:12 $ kubectl describe pod -n xxx triggerpipeline-3737304981-nx85k 
Name:                      triggerpipeline-3737304981-nx85k
Namespace:                 xxx
Node:                      k8s-agent-d7584a3a-2/10.240.0.6
Start Time:                Wed, 27 Jun 2018 15:33:48 +0200
Labels:                    app=triggerpipeline
                           pod-template-hash=3737304981
Annotations:               kubernetes.io/created-by={"kind":"SerializedReference","apiVersion":"v1","reference":{"kind":"ReplicaSet","namespace":"xxx","name":"triggerpipeline-3737304981","uid":"b91320ff-7a0e-11e8-9e7...
Status:                    Terminating (expires Fri, 27 Jul 2018 09:00:35 +0200)
Termination Grace Period:  0s
IP:                        
Controlled By:             ReplicaSet/triggerpipeline-3737304981
Containers:
  alpine:
    Container ID:  docker://8443c7478dfe1a57a891b455366ca007fe00415178191a54b0199d246ccbd566
    Image:         alpine
    Image ID:      docker-pullable://alpine<strong i="6">@sha256</strong>:e1871801d30885a610511c867de0d6baca7ed4e6a2573d506bbec7fd3b03873f
    Port:          <none>
    Command:
      sh
    Args:
      -c
      apk add --no-cache curl && echo "0 */4 * * * curl -v --trace-time http://myapi:80/api/v1/pipeline/start " | crontab - && crond -f
    State:          Terminated
      Exit Code:    0
      Started:      Mon, 01 Jan 0001 00:00:00 +0000
      Finished:     Mon, 01 Jan 0001 00:00:00 +0000
    Ready:          False
    Restart Count:  0
    Environment:    <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-p9qtw (ro)
Conditions:
  Type           Status
  Initialized    True 
  Ready          False 
  PodScheduled   True 
Volumes:
  default-token-p9qtw:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-p9qtw
    Optional:    false
QoS Class:       BestEffort
Node-Selectors:  <none>
Tolerations:     <none>
Events:          <none>

Tentei usar --now ou definir o período de carência. Por exemplo

09:00 $  kubectl delete pod -n xxx triggerpipeline-3737304981-nx85k --force --grace-period=0
warning: Immediate deletion does not wait for confirmation that the running resource has been terminated. The resource may continue to run on the cluster indefinitely.
pod "triggerpipeline-3737304981-nx85k" deleted

Ainda assim, o pod está travado e isso faz com que a implantação correspondente também seja travada.

Eu também sou assombrado por essas mensagens de “Precisa matar o pod” nos eventos do pod. O que isso significa por falar nisso? Que _Kubernetes_ sente a necessidade de matar o pod, ou que _Eu_ deveria matar o pod?

isso aconteceu comigo alguns dias atrás e desisti de excluir e deixei o pod como estava. Então, hoje, ele desapareceu e parece ser excluído eventualmente.

Aconteceu comigo agora há pouco. A solução --force --now não funcionou para mim. Eu achei a seguinte linha nos logs do kubelet suspeita

6 de agosto 15:25:37 kube-minion-1 kubelet [2778]: W0806 15: 25: 37.986549 2778 docker_sandbox.go: 263] NetworkPlugin cni falhou no gancho de status para pod "backend-foos-227474871-gzhw0_default": Inesperado saída do comando nsenter: não é possível abrir: arquivo ou diretório inexistente

O que me levou a encontrar o seguinte problema:
https://github.com/openshift/origin/issues/15802

Não estou no openshift, mas no Openstack, então pensei que poderia estar relacionado. Eu dei o conselho para reiniciar o docker um tiro.
Reiniciar o docker fez com que os pods presos em "Terminando" fossem embora.

Eu sei que isso é apenas uma solução alternativa, mas às vezes não vou acordar às 3 da manhã para consertar isso.
Não estou dizendo que você deve usar isso, mas pode ajudar algumas pessoas.

O sono é o que eu tenho meus pods terminationGracePeriodSeconds definido para (30 segundos). Se estiver vivo por mais tempo do que isso, este cronjob irá --force --grace-period = 0 e o matará completamente

apiVersion: batch/v1beta1 kind: CronJob metadata: name: stuckpod-restart spec: concurrencyPolicy: Forbid successfulJobsHistoryLimit: 1 failedJobsHistoryLimit: 5 schedule: "*/1 * * * *" jobTemplate: spec: template: spec: containers: - name: stuckpod-restart image: devth/helm:v2.9.1 args: - /bin/sh - -c - echo "$(date) Job stuckpod-restart Starting"; kubectl get pods --all-namespaces=true | awk '$3=="Terminating" {print "sleep 30; echo "$(date) Killing pod $1"; kubectl delete pod " $1 " --grace-period=0 --force"}'; echo "$(date) Job stuckpod-restart Complete"; restartPolicy: OnFailure

Estou vendo o mesmo erro com o Kubernetes v1.10.2. Os pods ficam presos ao encerrar indefinidamente e o kubelet no nó em questão registra repetidamente:

Aug 21 13:25:55 node-09 kubelet[164855]: E0821 13:25:55.149132  
164855 nestedpendingoperations.go:267] 
Operation for "\"kubernetes.io/configmap/b838409a-a49e-11e8-bdf7-000f533063c0-configmap\" 
(\"b838409a-a49e-11e8-bdf7-000f533063c0\")" failed. No retries permitted until 2018-08-21 
13:27:57.149071465 +0000 UTC m=+1276998.311766147 (durationBeforeRetry 2m2s). Error: "error 
cleaning subPath mounts for volume \"configmap\" (UniqueName: 
\"kubernetes.io/configmap/b838409a-a49e-11e8-bdf7-000f533063c0-configmap\") pod 
\"b838409a-a49e-11e8-bdf7-000f533063c0\" (UID: \"b838409a-a49e-11e8-bdf7-000f533063c0\") 
: error deleting /var/lib/kubelet/pods/b838409a-a49e-11e8-bdf7-000f533063c0/volume-
subpaths/configmap/pod-master/2: remove /var/lib/kubelet/pods/b838409a-a49e-11e8-bdf7-
000f533063c0/volume-subpaths/configmap/pod-master/2: device or resource busy"

Posso desmontar manualmente o volume do subcaminho em questão sem reclamar (o Linux não me diz que está ocupado). Isso impede que o kubelet registre a mensagem de erro. No entanto, isso não inspira o Kubernetes a continuar a limpeza, pois o pod ainda é mostrado no estado de encerramento. Reiniciar rotineiramente o Docker para limpar isso não é realmente uma solução aceitável devido à interrupção que causa na execução de contêineres.

Também digno de nota: o próprio contêiner sumiu de docker ps -a sem nenhuma evidência de que ele existiu, então não tenho certeza se isso é realmente um problema do Docker. Estamos usando o Docker versão 17.03.2-ce.

Uma atualização: configuramos nossos nós para redirecionar o diretório raiz do kubelet para um volume não-SO com um link simbólico ( /var/lib/kubelet era um link simbólico apontando para outro diretório em um volume diferente). Quando reconfigurei as coisas para passar --root-dir para o kubelet para que fosse para o diretório desejado diretamente, em vez de através de um link simbólico, e reiniciei o kubelet, ele limpou as montagens de volume e limpou os pods que estavam presos encerrando sem exigir uma reinicialização do Docker.

Eu experimentei esse problema hoje pela primeira vez ao executar alguns pods localmente no minikube.

Eu tinha um monte de pods presos em Terminating devido a um configmap / segredo montado como um volume que estava faltando. Nenhuma das sugestões / soluções alternativas postadas acima funcionou, exceto esta .

Uma coisa que acho que vale a pena notar é o seguinte:

• Quando executei kubectl get pods , obtive a lista de pods com o status Terminating .
• Porém, quando executei docker ps | grep -i {{pod_name}} , nenhum dos pods no status Terminating visto por kubectl get pods estava em execução na VM do minikube.

Eu esperava que docker ps retornasse a lista de pods presos no estado Terminating mas na realidade nenhum deles estava em execução, mas kubectl get pods estava retornando dados sobre eles? Alguém poderia explicar por que isso?

Eu tive esse problema com 4 implantações. Em seguida, mudei de “volume local” para “caminho do host” para todas as montagens e ele se foi para mim.

Eu só tive o problema de que os pods não estavam encerrando porque um segredo estava faltando. Depois que criei aquele segredo naquele namespace, tudo voltou ao normal.

Como você cria um segredo no namespace se o namespace está no estado "Terminando"?

kubectl delete --all pods --namespace = xxxxx --force --grace-period = 0

funciona para mim.

Não se esqueça de "--grace-period = 0". Importa

kubectl me avisou "aviso: a exclusão imediata não espera pela confirmação de que o recurso em execução foi encerrado. O recurso pode continuar a ser executado no cluster indefinidamente." quando eu uso --force --grace-period=0 .
Alguém pode me dizer se isso realmente vai acontecer?

na verdade, quando excluímos algum pod, a exclusão pode demorar por alguns motivos,
e se executarmos "kubectl delete" com a sinalização "--force --grace-period = 0",
o objeto de recurso seria excluído de uma vez.

Você pode ajudar a confirmar se o pod será excluído imediatamente?
Isso significa que a mensagem de aviso é realmente imprecisa?

@windoze , se você --force --grace-period = 0 opção, significa que o objeto pod API será excluído do servidor API imediatamente. O Node kubelet é responsável por limpar as montagens de volume e eliminar os contêineres. Se o kubelet não estiver em execução ou tiver problemas durante a limpeza do pod, o contêiner ainda pode estar em execução. Mas Kubelet deve continuar tentando limpar os pods sempre que possível.

Isso ainda significa que a exclusão pode levar uma eternidade porque o kubelet pode estar com defeito?
Existe alguma maneira de garantir que o pod seja excluído?
Estou fazendo a pergunta porque tenho alguns pods enormes em execução no cluster e não há memória suficiente em cada nó para executar 2 instâncias deles.
Se a exclusão falhar, o nó se tornará inutilizável e, se esse problema ocorrer várias vezes, o serviço ficará completamente inativo porque, eventualmente, nenhum nó poderá executar este pod.

No ambiente docker normal, posso forçar a eliminação de um pod com kill -9 ou algo parecido, mas parece que o k8s não tem essa função.

@windoze , você sabe por que a exclusão do pod com frequência falhou? É porque o kubelet não está em execução ou o kubelet estava tentando encerrar o contêiner, mas falhou com alguns erros?

Tal situação aconteceu várias vezes no meu cluster há vários meses, o kubelet estava em execução, mas o daemon do docker parecia ter alguns problemas e travou sem nenhum log de erro.
Minha solução foi fazer login no nó e forçar o encerramento do processo do contêiner e reiniciar o daemon do docker.
Depois de algumas atualizações, o problema desapareceu e nunca mais o tive.

kubectl delete pods <podname> --force --grace-period=0 funcionou para mim!

@ shinebayar-g, o problema com --force é que isso pode significar que seu contêiner continuará funcionando. Ele apenas diz ao Kubernetes para esquecer os contêineres deste pod. Uma solução melhor é usar SSH na VM que está executando o pod e investigar o que está acontecendo com o Docker. Tente matar manualmente os contêineres com docker kill e, se for bem-sucedido, tente excluir o pod normalmente novamente.

@agolomoodysaada Ah, isso faz sentido. Obrigada pelo esclarecimento. Então, eu realmente não saberia se o contêiner real foi realmente excluído ou não está certo?

então, é o final de 2018, o kube 1.12 foi lançado e ... vocês ainda têm problemas com os pods presos?

Eu tenho o mesmo problema, ou --force --grace-period = 0 ou --force --now não funciona, o que se segue são os logs:

root @ r15-c70-b03-master01 : ~ # kubectl -n infra-lmat get pod node-exporter-zbfpx
NOME PRONTO STATUS REINICIA IDADE
node-exporter-zbfpx 0/1 Terminando 0 4d

root @ r15-c70-b03-master01 : ~ # kubectl -n infra-lmat deletar pod node-exporter-zbfpx --grace-period = 0 --force
aviso: a exclusão imediata não espera pela confirmação de que o recurso em execução foi encerrado. O recurso pode continuar em execução no cluster indefinidamente.
pod "node-exporter-zbfpx" excluído

root @ r15-c70-b03-master01 : ~ # kubectl -n infra-lmat get pod node-exporter-zbfpx
NOME PRONTO STATUS REINICIA IDADE
node-exporter-zbfpx 0/1 Terminando 0 4d

root @ r15-c70-b03-master01 : ~ # kubectl -n infra-lmat deletar pod node-exporter-zbfpx --now --force
pod "node-exporter-zbfpx" excluído

root @ r15-c70-b03-master01 : ~ # kubectl -n infra-lmat get pod node-exporter-zbfpx
NOME PRONTO STATUS REINICIA IDADE
node-exporter-zbfpx 0/1 Terminando 0 4d

root @ r15-c70-b03-master01 : ~ #

Tentei editar o pod e excluir a seção de finalizadores nos metadados, mas também falhou.

Ainda estou vendo isso de forma 100% reproduzível (mesmas definições de recursos) com o kubectl 1.13 alpha e o Docker para Desktop no macOS. Por reproduzível, quero dizer que a única maneira de consertar parece ser redefinir os padrões de fábrica do Docker para Mac e, quando configuro meu cluster novamente usando os mesmos recursos (script de implantação), o mesmo script de limpeza falha.

Não sei por que seria relevante, mas meu script de limpeza se parece com:

#!/usr/bin/env bash
set -e

function usage() {
    echo "Usage: $0 <containers|envs|volumes|all>"
}

if [ "$1" = "--help" ] || [ "$1" = "-h" ] || [ "$1" = "help" ]; then
    echo "$(usage)"
    exit 0
fi

if [ $# -lt 1 ] || [ $# -gt 1 ]; then
    >&2 echo "$(usage)"
    exit 1
fi

MODE=$1

function join_with {
    local IFS="$1"
    shift
    echo "$*"
}

resources=()

if [ "$MODE" = "containers" ] || [ "$MODE" = "all" ]; then
    resources+=(daemonsets replicasets statefulsets services deployments pods rc)
fi

if [ "$MODE" = "envs" ] || [ "$MODE" = "all" ]; then
    resources+=(configmaps secrets)
fi

if [ "$MODE" = "volumes" ] || [ "$MODE" = "all" ]; then
    resources+=(persistentvolumeclaims persistentvolumes)
fi

kubectl delete $(join_with , "${resources[@]}") --all

Como o cluster é executado localmente, posso verificar se não há contêineres em execução no Docker, é apenas o kubectl que está travando nos pods de encerramento. Quando eu describe os pods, o status é listado como Status: Terminating (lasts <invalid>)

Aconteceu comigo mais uma vez. Eu estava tentando instalar o percona pmm-server com compartilhamento NFS e o software nem apareceu, então eu removi e isso aconteceu. (A reivindicação persistente não estava funcionando para este software). Acho que estou chamando o bom e velho kubectl delete pods <podname> --force --grace-period=0 mais uma vez. Mas a questão é como eu sei onde esse casulo está morando?

@ shinebayar-g, SSH na VM em que estava e execute docker ps .

Bem, não estava lá .. Eu tenho poucas VMs, então perguntei como descobrir qual é a certa. :)

@ shinebayar-g isso pode funcionar:
kubectl describe pod/some-pod-name | grep '^Node:'

o mesmo problema.

docker ps constatou que o contêiner está no status "Morto" e não saiu (0) como esperado

A exclusão manual do contêiner leva à seguinte entrada de registro do docker:

level=warning msg="container kill failed because of 'container not found' or 'no such process': Cannot kill container 

Infelizmente a linha está cortada, mas acho que me lembro, o problema era que o processo não estava mais lá.

Ainda estou travando esse problema com o k8s v1.11.0. Aqui está uma lista de verificação do que eu faço para limpar meus pods:

• Certifique-se de que todos os recursos anexados ao pod foram recuperados. Nem todos eles estão visíveis em kubectl get ; alguns deles são conhecidos apenas pelo Kubelet em que o pod está sendo executado, então você terá que seguir seu fluxo de registro localmente
  
  
  
  • Em particular, diretórios umount quais Kubelet reclama com device or resource busy mensagens
  
  
• Quando tudo mais falhar, kubectl edit o pod com falha e remova finalizers: → - foregroundDeletion

Mais duas dicas:

• No estado estacionário, um Kubelet não confuso não deve registrar nenhuma mensagem periódica. Qualquer tipo de falha repetida em liberar algo é o sintoma de um pod preso.
• você pode manter um comando kubectl delete bloqueado em outra janela para monitorar seu progresso (mesmo em um pod que você já "excluiu" muitas vezes). kubectl delete será encerrado assim que o último recurso bloqueado for liberado.

Confrontado com isso hoje.
O que foi feito:

1. ssh para o nó e remover o contêiner manualmente
2. Depois disso kubectl get pods me mostra o que meu contêiner preso 0/1 terminating (era 1/1 terminating )
3. Remova a seção finalizers do pod, meu era foregroundDeletion ($ kubectl editar pod / nome) -> recipiente removido da lista de pods
4. Excluir implantação -> todas as coisas relacionadas à implantação removidas.

kubectl version
Client Version: version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.0", GitCommit:"91e7b4fd31fcd3d5f436da26c980becec37ceefe", GitTreeState:"clean", BuildDate:"2018-06-27T20:17:28Z", GoVersion:"go1.10.2", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.3", GitCommit:"2bba0127d85d5a46ab4b778548be28623b32d0b0", GitTreeState:"clean", BuildDate:"2018-05-21T09:05:37Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}

estamos enfrentando o mesmo problema quando começamos a montar os segredos (compartilhados com muitos pods). O pod entra no estado terminating e fica lá para sempre. Nossa versão é v1.10.0. O contêiner do docker anexado se foi, mas a referência no servidor de API permanece, a menos que eu exclua o pod à força com a opção --grace-period=0 --force .

Procurando uma solução permanente.

Bem, recentemente testei o exploit runc CVE-2019-5736 em meu cluster de teste, como você já sabe, o exploit reescreve o binário runc na máquina host. Sua exploração destrutiva. Depois disso, vi um comportamento estranho no cluster. Todos os pods travaram no estado de terminação. A solução alternativa foi drenar o docker de eliminação de nós afetados e reinstalá-lo. Depois disso, todos os pods e cluster K8s estão funcionando normalmente como antes. Talvez seja um problema do docker e reinstalá-lo resolva seu problema também !. obrigado

V1.13.3 fresco instale aqui. Isso acontece comigo também. Acontece desde que montei os mesmos volumes NFS em alguns pods, o que parece ter algo a ver com isso.

Vejo esse problema ao criar uma implantação que tenta criar um volume usando um segredo que não existe, a exclusão dessa implantação / serviço deixa em torno de Terminating pod.

enfrentando o mesmo problema com v.1.12.3, e --grace-period = 0 --force ou --now ambos inválidos, exclua o conjunto de estados que também pertence

Mesmo problema com uma montagem SMB (eu acho?) (Arquivos do Azure compartilham de acordo com https://docs.microsoft.com/en-us/azure/aks/azure-files-volume).

mesmo problema com 13.3

Eu tenho o mesmo problema que o pod está no estado "Terminando" por quase 2 dias.
Estou usando o Minikube em uma máquina Linux (Debian).

Versão Kubectl:
Server Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.3", GitCommit:"721bfa751924da8d1680787490c54b9179b1fed0", GitTreeState:"clean", BuildDate:"2019-02-01T20:00:57Z", GoVersion:"go1.11.5", Compiler:"gc", Platform:"linux/amd64"}
Versão do Minikube:
minikube version: v0.34.1

@ardalanrazavi por que está encerrando por dois dias? Apenas force a exclusão se não excluir após 5 minutos

@nmors

por que está encerrando por dois dias?

Esta é uma boa pergunta. Todos nós gostaríamos de saber disso.

Apenas force a exclusão se não excluir após 5 minutos

Excluí-lo à força deixa o cluster em estado inconsistente. (Com o minikube, esse não é o seu cluster real, é reconhecidamente muito menos preocupante)

@AndrewSav

Não vejo outras soluções aqui para ser franco.

Claro, o cluster ficará em um "estado inconsistente". Eu gostaria de entender o que você quer dizer exatamente com isso. O fechamento forçado é ruim. Eu também não gosto disso, mas no meu caso, sinto-me confortável destruindo e redistribuindo todos os recursos conforme necessário.

No meu caso, parece que só fica preso terminando nos pods que têm uma montagem NFS. E só acontece quando o servidor NFS é desativado antes de o cliente tentar.

Corrigi o problema, consegui isolar que todos os pods presos na finalização estavam todos em um nó, o nó foi reiniciado e o problema desapareceu.

@nmors @AndrewSav Eu também

Excluir seu servidor NFS antes de excluir seus pods pode causar o travamento permanente da desmontagem. É melhor ordenar suas exclusões nesse caso, de modo que seu servidor NFS seja sempre excluído por último.

@ msau42 Meu servidor NFS não faz parte do cluster k8s - é um aparelho e uma máquina separados, todos juntos

Não importa se faz parte do cluster k8s ou não. Se o servidor nfs estiver inacessível, a desmontagem irá travar até que se torne acessível novamente.

@ msau42 isso é estranho, porque tenho quase certeza de que mesmo quando voltou a ficar online, os pods ainda estavam travados no encerramento. novos pods são iniciados e montados perfeitamente.

Eu uso o servidor NFS no kubernetes seguido por este exemplo e isso acontece com bastante frequência, infelizmente.

@ shinebayar-g Eu também segui esse guia, mas agora me livrei dos PVs e PVCs e defini meu volume diretamente na implantação, assim:

        volumeMounts:
        - mountPath: /my-pod-mountpoint
          name: my-vol
      volumes:
        - name: my-vol
          nfs:
            server: "10.x.x.x"
            path: "/path/on/server"
            readOnly: false

Não tive nenhum problema desde então, mudei isso apenas cerca de uma semana na esperança de que a configuração mais simples fosse mais confiável ... vamos ver ... Talvez isso resolva o problema?

Como solução alternativa, escrevi um script que pega algumas últimas linhas de /var/log/syslog e procura erros como "Operação para ... remover / var / lib / kubelet / pods ... diretório não vazio" ou "nfs. ..device is busy ... unmount.nfs "ou" identificador de arquivo NFS obsoleto ".
Em seguida, ele extrai o pod_id ou o diretório completo do pod e vê quais montagens ele possui (como mount | grep $pod_id ), depois desmonta todos e remove os diretórios correspondentes. Eventualmente, o kubelet faz o resto e desliga e exclui os pods sem problemas. Não há mais pods no estado de terminação.

Eu coloquei esse script no cron para ser executado a cada minuto. Como resultado - nenhum problema por enquanto, mesmo 3-4 meses depois.
Observação : eu sei, essa abordagem não é confiável e requer verificação em cada atualização do cluster, mas funciona!

Estou usando a versão 1.10 e tive esse problema hoje e acho que meu problema está relacionado ao problema de montagem do volume secreto, que pode ter deixado alguma tarefa pendente e deixado o pod com status de encerramento para sempre.

Tive que usar a opção --grace-period = 0 --force para encerrar os pods.

root@ip-10-31-16-222:/var/log# journalctl -u kubelet | grep dp-tag-change-ingestion-com-depl-5bd59f74c4-589ds Mar 20 15:50:31 ip-10-31-16-222.eu-west-2.compute.internal kubelet[528]: I0320 15:50:31.179901 528 reconciler.go:207] operationExecutor.VerifyControllerAttachedVolume started for volume "config-volume" (UniqueName: "kubernetes.io/configmap/e3d7c57a-4b27-11e9-9aaa-0203c98ff31e-config-volume") pod "dp-tag-change-ingestion-com-depl-5bd59f74c4-589ds" (UID: "e3d7c57a-4b27-11e9-9aaa-0203c98ff31e") Mar 20 15:50:31 ip-10-31-16-222.eu-west-2.compute.internal kubelet[528]: I0320 15:50:31.179935 528 reconciler.go:207] operationExecutor.VerifyControllerAttachedVolume started for volume "default-token-xjlgc" (UniqueName: "kubernetes.io/secret/e3d7c57a-4b27-11e9-9aaa-0203c98ff31e-default-token-xjlgc") pod "dp-tag-change-ingestion-com-depl-5bd59f74c4-589ds" (UID: "e3d7c57a-4b27-11e9-9aaa-0203c98ff31e") Mar 20 15:50:31 ip-10-31-16-222.eu-west-2.compute.internal kubelet[528]: I0320 15:50:31.179953 528 reconciler.go:207] operationExecutor.VerifyControllerAttachedVolume started for volume "secret-volume" (UniqueName: "kubernetes.io/secret/e3d7c57a-4b27-11e9-9aaa-0203c98ff31e-secret-volume") pod "dp-tag-change-ingestion-com-depl-5bd59f74c4-589ds" (UID: "e3d7c57a-4b27-11e9-9aaa-0203c98ff31e") Mar 20 15:50:31 ip-10-31-16-222.eu-west-2.compute.internal kubelet[528]: E0320 15:50:31.310200 528 nestedpendingoperations.go:267] Operation for "\"kubernetes.io/secret/e3d7c57a-4b27-11e9-9aaa-0203c98ff31e-secret-volume\" (\"e3d7c57a-4b27-11e9-9aaa-0203c98ff31e\")" failed. No retries permitted until 2019-03-20 15:50:31.810156118 +0000 UTC m=+966792.065305175 (durationBeforeRetry 500ms). Error: "MountVolume.SetUp failed for volume \"secret-volume\" (UniqueName: \"kubernetes.io/secret/e3d7c57a-4b27-11e9-9aaa-0203c98ff31e-secret-volume\") pod \"dp-tag-change-ingestion-com-depl-5bd59f74c4-589ds\" (UID: \"e3d7c57a-4b27-11e9-9aaa-0203c98ff31e\") : secrets \"data-platform.xxx-com\" not found" Mar 20 15:50:31 ip-10-31-16-222.eu-west-2.compute.internal kubelet[528]: E0320 15:50:31.885807 528 nestedpendingoperations.go:267] Operation for "\"kubernetes.io/secret/e3d7c57a-4b27-11e9-9aaa-0203c98ff31e-secret-volume\" (\"e3d7c57a-4b27-11e9-9aaa-0203c98ff31e\")" failed. No retries permitted until 2019-03-20 15:50:32.885784622 +0000 UTC m=+966793.140933656 (durationBeforeRetry 1s). Error: "MountVolume.SetUp failed for volume \"secret-volume\" (UniqueName: \"kubernetes.io/secret/e3d7c57a-4b27-11e9-9aaa-0203c98ff31e-secret-volume\") pod \"dp-tag-change-ingestion-com-depl-5bd59f74c4-589ds\" (UID: \"e3d7c57a-4b27-11e9-9aaa-0203c98ff31e\") : secrets \"data-platform.xxxxx-com\" not found" Mar 20 15:50:32 ip-10-31-16-222.eu-west-2.compute.internal kubelet[528]: E0320 15:50:32.987385 528 nestedpendingoperations.go:267] Operation for "\"kubernetes.io/secret/e3d7c57a-4b27-11e9-9aaa-0203c98ff31e-secret-volume\" (\"e3d7c57a-4b27-11e9-9aaa-0203c98ff31e\")" failed. No retries permitted until 2019-03-20 15:50:34.987362044 +0000 UTC m=+966795.242511077 (durationBeforeRetry 2s). Error: "MountVolume.SetUp failed for volume \"secret-volume\" (UniqueName: \"kubernetes.io/secret/e3d7c57a-4b27-11e9-9aaa-0203c98ff31e-secret-volume\") pod \"dp-tag-change-ingestion-com-depl-5bd59f74c4-589ds\" (UID: \"e3d7c57a-4b27-11e9-9aaa-0203c98ff31e\") : secrets \"data-platform.xxx-com\" not found" Mar 20 15:50:35 ip-10-31-16-222.eu-west-2.compute.internal kubelet[528]: E0320 15:50:35.090836 528 nestedpendingoperations.go:267] Operation for "\"kubernetes.io/secret/e3d7c57a-4b27-11e9-9aaa-0203c98ff31e-secret-volume\" (\"e3d7c57a-4b27-11e9-9aaa-0203c98ff31e\")" failed. No retries permitted until 2019-03-20 15:50:39.090813114 +0000 UTC m=+966799.345962147 (durationBeforeRetry 4s). Error: "MountVolume.SetUp failed for volume \"secret-volume\" (UniqueName: \"kubernetes.io/secret/e3d7c57a-4b27-11e9-9aaa-0203c98ff31e-secret-volume\") pod \"dp-tag-change-ingestion-com-depl-5bd59f74c4-589ds\" (UID: \"e3d7c57a-4b27-11e9-9aaa-0203c98ff31e\") : secrets \"data-platform.xxx-com\" not found" Mar 20 15:50:39 ip-10-31-16-222.eu-west-2.compute.internal kubelet[528]: E0320 15:50:39.096621 528 nestedpendingoperations.go:267] Operation for "\"kubernetes.io/secret/e3d7c57a-4b27-11e9-9aaa-0203c98ff31e-secret-volume\" (\"e3d7c57a-4b27-11e9-9aaa-0203c98ff31e\")" failed. No retries permitted until 2019-03-20 15:50:47.096593013 +0000 UTC m=+966807.351742557 (durationBeforeRetry 8s). Error: "MountVolume.SetUp failed for volume \"secret-volume\" (UniqueName: \"kubernetes.io/secret/e3d7c57a-4b27-11e9-9aaa-0203c98ff31e-secret-volume\") pod \"dp-tag-change-ingestion-com-depl-5bd59f74c4-589ds\" (UID: \"e3d7c57a-4b27-11e9-9aaa-0203c98ff31e\") : secrets \"data-platform.xxx-com\" not found" Mar 20 15:50:47 ip-10-31-16-222.eu-west-2.compute.internal kubelet[528]: E0320 15:50:47.108644 528 nestedpendingoperations.go:267] Operation for "\"kubernetes.io/secret/e3d7c57a-4b27-11e9-9aaa-0203c98ff31e-secret-volume\" (\"e3d7c57a-4b27-11e9-9aaa-0203c98ff31e\")" failed. No retries permitted until 2019-03-20 15:51:03.10862005 +0000 UTC m=+966823.363769094 (durationBeforeRetry 16s). Error: "MountVolume.SetUp failed for volume \"secret-volume\" (UniqueName: \"kubernetes.io/secret/e3d7c57a-4b27-11e9-9aaa-0203c98ff31e-secret-volume\") pod \"dp-tag-change-ingestion-com-depl-5bd59f74c4-589ds\" (UID: \"e3d7c57a-4b27-11e9-9aaa-0203c98ff31e\") : secrets \"data-platform.xxx-com\" not found" Mar 20 15:51:03 ip-10-31-16-222.eu-west-2.compute.internal kubelet[528]: E0320 15:51:03.133029 528 nestedpendingoperations.go:267] Operation for "\"kubernetes.io/secret/e3d7c57a-4b27-11e9-9aaa-0203c98ff31e-secret-volume\" (\"e3d7c57a-4b27-11e9-9aaa-0203c98ff31e\")" failed. No retries permitted until 2019-03-20 15:51:35.133006645 +0000 UTC m=+966855.388155677 (durationBeforeRetry 32s). Error: "MountVolume.SetUp failed for volume \"secret-volume\" (UniqueName: \"kubernetes.io/secret/e3d7c57a-4b27-11e9-9aaa-0203c98ff31e-secret-volume\") pod \"dp-tag-change-ingestion-com-depl-5bd59f74c4-589ds\" (UID: \"e3d7c57a-4b27-11e9-9aaa-0203c98ff31e\") : secrets \"data-platform.xxxx-com\" not found" Mar 20 15:51:35 ip-10-31-16-222.eu-west-2.compute.internal kubelet[528]: E0320 15:51:35.184310 528 nestedpendingoperations.go:267] Operation for "\"kubernetes.io/secret/e3d7c57a-4b27-11e9-9aaa-0203c98ff31e-secret-volume\" (\"e3d7c57a-4b27-11e9-9aaa-0203c98ff31e\")" failed. No retries permitted until 2019-03-20 15:52:39.184281161 +0000 UTC m=+966919.439430217 (durationBeforeRetry 1m4s). Error: "MountVolume.SetUp failed for volume \"secret-volume\" (UniqueName: \"kubernetes.io/secret/e3d7c57a-4b27-11e9-9aaa-0203c98ff31e-secret-volume\") pod \"dp-tag-change-ingestion-com-depl-5bd59f74c4-589ds\" (UID: \"e3d7c57a-4b27-11e9-9aaa-0203c98ff31e\") : secrets \"data-platform.xxx-com\" not found" Mar 20 15:52:34 ip-10-31-16-222.eu-west-2.compute.internal kubelet[528]: E0320 15:52:34.005027 528 kubelet.go:1640] Unable to mount volumes for pod "dp-tag-change-ingestion-com-depl-5bd59f74c4-589ds_default(e3d7c57a-4b27-11e9-9aaa-0203c98ff31e)": timeout expired waiting for volumes to attach or mount for pod "default"/"dp-tag-change-ingestion-com-depl-5bd59f74c4-589ds". list of unmounted volumes=[secret-volume]. list of unattached volumes=[secret-volume config-volume default-token-xjlgc]; skipping pod Mar 20 15:52:34 ip-10-31-16-222.eu-west-2.compute.internal kubelet[528]: E0320 15:52:34.005085 528 pod_workers.go:186] Error syncing pod e3d7c57a-4b27-11e9-9aaa-0203c98ff31e ("dp-tag-change-ingestion-com-depl-5bd59f74c4-589ds_default(e3d7c57a-4b27-11e9-9aaa-0203c98ff31e)"), skipping: timeout expired waiting for volumes to attach or mount for pod "default"/"dp-tag-change-ingestion-com-depl-5bd59f74c4-589ds". list of unmounted volumes=[secret-volume]. list of unattached volumes=[secret-volume config-volume default-token-xjlgc] Mar 20 15:52:39 ip-10-31-16-222.eu-west-2.compute.internal kubelet[528]: E0320 15:52:39.196332 528 nestedpendingoperations.go:267] Operation for "\"kubernetes.io/secret/e3d7c57a-4b27-11e9-9aaa-0203c98ff31e-secret-volume\" (\"e3d7c57a-4b27-11e9-9aaa-0203c98ff31e\")" failed. No retries permitted until 2019-03-20 15:54:41.196308703 +0000 UTC m=+967041.451457738 (durationBeforeRetry 2m2s). Error: "MountVolume.SetUp failed for volume \"secret-volume\" (UniqueName: \"kubernetes.io/secret/e3d7c57a-4b27-11e9-9aaa-0203c98ff31e-secret-volume\") pod \"dp-tag-change-ingestion-com-depl-5bd59f74c4-589ds\" (UID: \"e3d7c57a-4b27-11e9-9aaa-0203c98ff31e\") : secrets \"data-platform.xxxx-com\" not found" Mar 20 15:54:41 ip-10-31-16-222.eu-west-2.compute.internal kubelet[528]: E0320 15:54:41.296252 528 nestedpendingoperations.go:267] Operation for "\"kubernetes.io/secret/e3d7c57a-4b27-11e9-9aaa-0203c98ff31e-secret-volume\" (\"e3d7c57a-4b27-11e9-9aaa-0203c98ff31e\")" failed. No retries permitted until 2019-03-20 15:56:43.296229192 +0000 UTC m=+967163.551378231 (durationBeforeRetry 2m2s). Error: "MountVolume.SetUp failed for volume \"secret-volume\" (UniqueName: \"kubernetes.io/secret/e3d7c57a-4b27-11e9-9aaa-0203c98ff31e-secret-volume\") pod \"dp-tag-change-ingestion-com-depl-5bd59f74c4-589ds\" (UID: \"e3d7c57a-4b27-11e9-9aaa-0203c98ff31e\") : secrets \"data-platform.xxxx-com\" not found" Mar 20 15:54:48 ip-10-31-16-222.eu-west-2.compute.internal kubelet[528]: E0320 15:54:48.118620 528 kubelet.go:1640] Unable to mount volumes for pod "dp-tag-change-ingestion-com-depl-5bd59f74c4-589ds_default(e3d7c57a-4b27-11e9-9aaa-0203c98ff31e)": timeout expired waiting for volumes to attach or mount for pod "default"/"dp-tag-change-ingestion-com-depl-5bd59f74c4-589ds". list of unmounted volumes=[secret-volume]. list of unattached volumes=[secret-volume config-volume default-token-xjlgc]; skipping pod Mar 20 15:54:48 ip-10-31-16-222.eu-west-2.compute.internal kubelet[528]: E0320 15:54:48.118681 528 pod_workers.go:186] Error syncing pod e3d7c57a-4b27-11e9-9aaa-0203c98ff31e ("dp-tag-change-ingestion-com-depl-5bd59f74c4-589ds_default(e3d7c57a-4b27-11e9-9aaa-0203c98ff31e)"), skipping: timeout expired waiting for volumes to attach or mount for pod "default"/"dp-tag-change-ingestion-com-depl-5bd59f74c4-589ds". list of unmounted volumes=[secret-volume]. list of unattached volumes=[secret-volume config-volume default-token-xjlgc] Mar 20 15:56:43 ip-10-31-16-222.eu-west-2.compute.internal kubelet[528]: E0320 15:56:43.398396 528 nestedpendingoperations.go:267] Operation for "\"kubernetes.io/secret/e3d7c57a-4b27-11e9-9aaa-0203c98ff31e-secret-volume\" (\"e3d7c57a-4b27-11e9-9aaa-0203c98ff31e\")" failed. No retries permitted until 2019-03-20 15:58:45.398368668 +0000 UTC m=+967285.653517703 (durationBeforeRetry 2m2s). Error: "MountVolume.SetUp failed for volume \"secret-volume\" (UniqueName: \"kubernetes.io/secret/e3d7c57a-4b27-11e9-9aaa-0203c98ff31e-secret-volume\") pod \"dp-tag-change-ingestion-com-depl-5bd59f74c4-589ds\" (UID: \"e3d7c57a-4b27-11e9-9aaa-0203c98ff31e\") : secrets \"data-platform.xxxx-com\" not found" Mar 20 15:57:05 ip-10-31-16-222.eu-west-2.compute.internal kubelet[528]: E0320 15:57:05.118566 528 kubelet.go:1640] Unable to mount volumes for pod "dp-tag-change-ingestion-com-depl-5bd59f74c4-589ds_default(e3d7c57a-4b27-11e9-9aaa-0203c98ff31e)": timeout expired waiting for volumes to attach or mount for pod "default"/"dp-tag-change-ingestion-com-depl-5bd59f74c4-589ds". list of unmounted volumes=[secret-volume]. list of unattached volumes=[secret-volume config-volume default-token-xjlgc]; skipping pod Mar 20 15:57:05 ip-10-31-16-222.eu-west-2.compute.internal kubelet[528]: E0320 15:57:05.118937 528 pod_workers.go:186] Error syncing pod e3d7c57a-4b27-11e9-9aaa-0203c98ff31e ("dp-tag-change-ingestion-com-depl-5bd59f74c4-589ds_default(e3d7c57a-4b27-11e9-9aaa-0203c98ff31e)"), skipping: timeout expired waiting for volumes to attach or mount for pod "default"/"dp-tag-change-ingestion-com-depl-5bd59f74c4-589ds". list of unmounted volumes=[secret-volume]. list of unattached volumes=[secret-volume config-volume default-token-xjlgc] Mar 20 15:59:22 ip-10-31-16-222.eu-west-2.compute.internal kubelet[528]: E0320 15:59:22.118593 528 kubelet.go:1640] Unable to mount volumes for pod "dp-tag-change-ingestion-com-depl-5bd59f74c4-589ds_default(e3d7c57a-4b27-11e9-9aaa-0203c98ff31e)": timeout expired waiting for volumes to attach or mount for pod "default"/"dp-tag-change-ingestion-com-depl-5bd59f74c4-589ds". list of unmounted volumes=[secret-volume config-volume default-token-xjlgc]. list of unattached volumes=[secret-volume config-volume default-token-xjlgc]; skipping pod Mar 20 15:59:22 ip-10-31-16-222.eu-west-2.compute.internal kubelet[528]: E0320 15:59:22.118624 528 pod_workers.go:186] Error syncing pod e3d7c57a-4b27-11e9-9aaa-0203c98ff31e ("dp-tag-change-ingestion-com-depl-5bd59f74c4-589ds_default(e3d7c57a-4b27-11e9-9aaa-0203c98ff31e)"), skipping: timeout expired waiting for volumes to attach or mount for pod "default"/"dp-tag-change-ingestion-com-depl-5bd59f74c4-589ds". list of unmounted volumes=[secret-volume config-volume default-token-xjlgc]. list of unattached volumes=[secret-volume config-volume default-token-xjlgc]

Descobri que se você usar --force --grace-period=0 tudo o que ele faz é remover a referência ... se você executar ssh no nó, ainda verá os contêineres do docker em execução.

No meu caso, houve Memória insuficiente no nó.
E o kernel matou o agente cílio, o que parece perturbar o término do pod.
Acabei de reiniciar o nó e ele foi limpo.

Na minha experiência, sudo systemctl restart docker no nó ajuda (mas obviamente há tempo de inatividade).

E isso ainda está acontecendo periodicamente em nós aleatórios que estão A) perto dos limites de memória ou B) CPU com fome (seja bc de algum problema kswapd0 que pode ainda estar relacionado com mem, ou carga real)

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

Problemas obsoletos apodrecem após 30 dias de inatividade.
Marque o problema como novo com /remove-lifecycle rotten .
Problemas podres são encerrados após 30 dias adicionais de inatividade.

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

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

Problemas podres são encerrados após 30 dias de inatividade.
Reabra o problema com /reopen .
Marque o problema como novo com /remove-lifecycle rotten .

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

@ fejta-bot: Fechando este problema.

Este é um problema muito ativo ainda, k8s 1.15.4 e RHEL Docker 1.13.1. O tempo todo os pods permanecem em Terminating mas o contêiner já se foi e o k8s não consegue se descobrir sozinho, mas requer interação humana. Torna o script de teste um PITA real.

/reabrir
/ remove-lifecycle podre

@tuminoid : Você não pode reabrir uma edição / RP a menos que seja o autor ou um colaborador.

/reabrir
/ remove-lifecycle podre

@mikesplain : Reabriu este problema.

O mesmo aqui: o pod travou na fase de terminação por mais de 19 minutos. O contêiner foi encerrado com sucesso, mas o Kubernetes ainda acredita que precisa esperar por algo.

Name:                      worker-anton-nginx-695d8bd9c6-7q4l9
Namespace:                 anton
Priority:                  0
Status:                    Terminating (lasts 19m)
Termination Grace Period:  30s
IP:                        10.220.3.36
IPs:                       <none>
Controlled By:             ReplicaSet/worker-anton-nginx-695d8bd9c6
Containers:
  worker:
    Container ID:   docker://12c169c8ed915bc290c14c854a6ab678fcacea9bb7b1aab5512b533df4683dd6
    Port:           8080/TCP
    Host Port:      0/TCP
    State:          Terminated
      Exit Code:    0
      Started:      Mon, 01 Jan 0001 00:00:00 +0000
      Finished:     Mon, 01 Jan 0001 00:00:00 +0000
    Ready:          False
    Restart Count:  0
Conditions:
  Type              Status
  Initialized       True 
  Ready             False 
  ContainersReady   False 
  PodScheduled      True 
Events:          <none>

Sem eventos, não logs ...

Client Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.2", GitCommit:"c97fe5036ef3df2967d086711e6c0c405941e14b", GitTreeState:"clean", BuildDate:"2019-10-17T17:16:09Z", GoVersion:"go1.12.10", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"14+", GitVersion:"v1.14.8-gke.2", GitCommit:"188432a69210ca32cafded81b4dd1c063720cac0", GitTreeState:"clean", BuildDate:"2019-10-21T20:01:24Z", GoVersion:"go1.12.11b4", Compiler:"gc", Platform:"linux/amd64"}
a

Você pode verificar os registros do kubelet e ver se há alguma mensagem sobre falha na desmontagem do volume ou pods órfãos?

Eu também vi isso
E1206 03: 05: 40.247161 25653 kubelet_volumes.go: 154] Pod órfão "0406c4bf-17e3-4613-a526-34e8a6cee208" encontrado, mas os caminhos de volume ainda estão presentes no disco: Houve um total de 8 erros semelhantes a este. Aumente a verbosidade para vê-los.

Eu também vi. Não é possível verificar os registros porque o kubectl reclama que não pode se conectar ao docker container e não pode criar um novo pod devido à existência atual de um pod de encerramento. Bastante irritante.

Também é irritante ter que confirmar se o Kubernetes limpou corretamente os pods antigos ou não.
Esperançosamente, isso será corrigido em breve.

E quanto a esse problema? Resolveu? Eu tenho um mesmo, mas isso não começa a acontecer de imediato, mas algum tempo depois do início do nó, se você zerar o nó, então por algum tempo está tudo bem

Você poderia verificar se há finalizadores no pod impedindo que ele seja excluído?

Não há finalizadores no pod emitido

Para sua informação, resolvi isso com uma exclusão forçada usando:

kubectl delete pods <pod> --grace-period=0 --force

E eu acredito que isso conseguiu encerrar o pod. Desde então, não tive o problema novamente. Possivelmente atualizei desde então, então pode ser um problema de versão, mas não 100%, já que faz tanto tempo que não vejo o problema.

Isso acontece quando um pod está ficando sem memória. Ele não termina até que o uso da memória diminua novamente.

Para sua informação, resolvi isso com uma exclusão forçada usando:

kubectl delete pods <pod> --grace-period=0 --force

E eu acredito que isso conseguiu encerrar o pod. Desde então, não tive o problema novamente. Possivelmente atualizei desde então, então pode ser um problema de versão, mas não 100%, já que faz tanto tempo que não vejo o problema.

Isso funcionou para mim

kubectl delete pods <pod> --grace-period=0 --force é uma correção temporária, não quero executar uma correção manual sempre que houver failover para um dos pods afetados. Meus pods do zookeeper não estão terminando no minikube e no Azure AKS.

Atualização em 9 de março de 2020
Usei um gancho de ciclo de vida preStop para encerrar manualmente meus pods. Meus pods do zookeeper estavam travados em um status de encerramento e não respondiam a um sinal de termo de dentro do contêiner. Eu tinha basicamente o mesmo manifesto em execução em outro lugar e tudo termina corretamente, sem ideia de qual é a causa raiz.

mesmo problema, super chato

mesmo problema :( os pods travaram no encerramento, desde 3 dias

Para sua informação, resolvi isso com uma exclusão forçada usando:

kubectl delete pods <pod> --grace-period=0 --force

E eu acredito que isso conseguiu encerrar o pod. Desde então, não tive o problema novamente. Possivelmente atualizei desde então, então pode ser um problema de versão, mas não 100%, já que faz tanto tempo que não vejo o problema.

Além disso, o sinalizador --force não significa necessariamente que o pod seja removido, apenas não espera pela confirmação (e elimina a referência, no meu entendimento). Conforme indicado pelo aviso The resource may continue to run on the cluster indefinetely .

Edit: eu estava mal informado. Veja o comentário do elrok123s abaixo para mais motivação.

Para sua informação, resolvi isso com uma exclusão forçada usando:

kubectl delete pods <pod> --grace-period=0 --force

E eu acredito que isso conseguiu encerrar o pod. Desde então, não tive o problema novamente. Possivelmente atualizei desde então, então pode ser um problema de versão, mas não 100%, já que faz tanto tempo que não vejo o problema.

Além disso, o sinalizador --force não significa necessariamente que o pod seja removido, apenas não espera pela confirmação (e elimina a referência, no meu entendimento). Conforme indicado pelo aviso The resource may continue to run on the cluster indefinetely .

Correto, mas o ponto é que --grace-period=0 força a exclusão acontecer :) não tenho certeza de por que seu comentário é relevante: /

Acho que seu comentário é relevante porque o contêiner subjacente
(docker ou qualquer outro) ainda pode estar em execução e não foi totalmente excluído .., O
ilusão de que "removido" é um pouco enganador às vezes

Na quinta, 4 de junho de 2020 às 9h16, Conner Stephen McCabe <
notificaçõ[email protected]> escreveu:

Para sua informação, resolvi isso com uma exclusão forçada usando:

kubectl delete pods--grace-period = 0 --force

E eu acredito que isso conseguiu encerrar o pod. Desde então eu
não tive o problema novamente. Possivelmente atualizei desde então,
pode ser um problema de versão, mas não 100%, já que faz tanto tempo
Eu vi o problema.

Além disso, a sinalização --force não significa necessariamente que o pod seja removido,
apenas não espera pela confirmação (e descarta a referência, para o meu
compreensão). Conforme declarado pelo aviso, o recurso pode continuar em execução
no cluster indefinidamente.

Correto, mas o ponto é que --grace-period = 0 força a exclusão para
acontecer :) não tenho certeza por que seu comentário é relevante: /

-
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/kubernetes/kubernetes/issues/51835#issuecomment-638840136 ,
ou cancelar
https://github.com/notifications/unsubscribe-auth/AAH34CDZF7EJRLAQD7OSH2DRU6NCRANCNFSM4DZKZ5VQ
.

Esse é realmente o meu ponto; usando isso, o método --force corre o risco de deixar a carga subjacente pesando em seus nós e não necessariamente corrige o problema original. No pior caso, é uma correção "Se eu não consigo ver, não existe", que pode ser ainda mais difícil de detectar.

Ou você está dizendo que --grace-period=0 certamente forçará a remoção do contêiner subjacente, @ elrok123?
Se for esse o caso, meu comentário é baseado em conhecimento defeituoso e é irrelevante, mas se o risco de deixar contêineres em execução permanecer ao usar --grace-period=0 mesmo ocorre com meu argumento.

@oscarlofwenhamn Pelo que eu sei, isso está efetivamente executando sigkill em todos os processos naquele pod, garantindo a exclusão de processos zumbis (fonte: Ponto 6 em 'Termination of Pods' - https://kubernetes.io/docs/concepts / workloads / pods / pod / # : ~: text = Quando% 20the% 20grace% 20period% 20 expira, período% 200% 20 (exclusão% 20 imediata).) e remoção do pod com sucesso (pode não acontecer imediatamente, mas acontecerá acontecer.)

O guia menciona que remove a referência, mas não exclui o pod em si (fonte: 'Forçar exclusão' - https://kubernetes.io/docs/tasks/run-application/force-delete-stateful-set-pod/ ), no entanto, o período de graça = 0 deve efetivamente destruir seu pod, embora não imediatamente.

Estou apenas lendo a documentação e as maneiras recomendadas para lidar com o cenário que encontrei. O problema que encontrei especificamente não era recorrente e era algo que aconteceu uma vez; Eu acredito que a REAL correção para isso é corrigir sua implantação, mas até você chegar lá, este método deve ajudar.

@ elrok123 Brilhante - eu estava mesmo mal informado. Atualizei minha resposta acima, fazendo referência a esta explicação. Obrigado pela resposta detalhada e mais um método motivado para lidar com os pods problemáticos. Felicidades!

atualmente, os pods estão presos por mais de 2 dias no estado de encerramento.

Para mim, o namespace está preso em Terminating . Nenhum pod é listado. Sem serviços ... nada. O namespace está vazio. Ainda assim ... preso no Encerramento.

@JoseFMP use kubectl para solicitar o yaml do namespace, pode haver finalizadores que estão atrasando o processo.

@JordyBottelier Obrigado.

Sem finalizadores. Ainda preso Terminating

@JoseFMP aqui está um script para :
`` `

! / bin / bash

set -eo pipefail

die () {echo "$ *" 1> & 2; saída 1; }

necessidade() {
qual "$ 1" &> / dev / null || die "Binário '$ 1' está faltando, mas é obrigatório"
}

verificando os pré-requisitos

precisa de "jq"
precisa de "curl"
precisa de "kubectl"

PROJETO = "$ 1"
mudança

teste -n "$ PROJECT" || die "Argumentos ausentes: kill-ns"

proxy kubectl &> / dev / null &
PROXY_PID = $!
killproxy () {
matar $ PROXY_PID
}
armadilha killproxy EXIT

sleep 1 # dê ao proxy um segundo

kubectl get namespace "$ PROJECT" -o json | jq 'del (.spec.finalizers [] | select ("kubernetes"))' | curl -s -k -H "Content-Type: application / json" -X PUT -o / dev / null --data-binary @ - http: // localhost : 8001 / api / v1 / namespaces / $ PROJECT / finalize && echo "Espaço de nomes eliminado: $ PROJECT" `` `

Aparentemente, também me deparei com isso, com vários pods presos no encerramento, incluindo um pod que não é mais visível em qualquer lugar da minha infraestrutura, mas ainda funciona como um fantasma (ele atende a solicitações e posso ver as solicitações atendidas mesmo com uma escala de implantação de zero).

Não tenho visibilidade nem controle sobre este pod e pergunto como posso solucionar uma situação como essa sem desligar todos os nós à força.

Aparentemente, também me deparei com isso, com vários pods presos no encerramento, incluindo um pod que não é mais visível em qualquer lugar da minha infraestrutura, mas ainda funciona como um fantasma (ele atende a solicitações e posso ver as solicitações atendidas mesmo com uma escala de implantação de zero).

Não tenho visibilidade nem controle sobre este pod e pergunto como posso solucionar uma situação como essa sem desligar todos os nós à força.

você terá que acessar o docker no nó.
Você pode usar meu dink (https://github.com/Agilicus/dink) que abrirá um pod com um shell com acesso ao docker ou ssh para o pod.
docker ps -a
docker stop ####

boa sorte.

Obrigado pela direção.

Acabei conseguindo resolver isso, mas ainda estou um pouco intrigado como isso poderia acontecer (para mim, o pod era completamente invisível). Como estava na produção, as coisas estavam um pouco agitadas e não consegui fazer o diagnóstico, mas se acontecer de novo, espero que eu possa fazer um relatório de bug melhor.

Vendo um sintoma semelhante, os pods travaram na finalização (curiosamente, todos eles têm um teste do tipo exec para prontidão / vivacidade). Olhando os registros, posso ver: kubelet [1445]: I1022 10: 26: 32.203865 1445 prober.go: 124] Sonda de prontidão para "test-service-74c4664d8d-58c96_default (822c3c3d-082a-4dc9-943c-19f04544713e): test -service "falhou (falha): OCI runtime exec falhou: exec falhou: não é possível executar um contêiner que parou: desconhecido. Essa mensagem se repete para sempre e a alteração do probe exec para tcpSocket parece permitir que o pod seja encerrado (com base em um teste, fará o acompanhamento). O pod parece ter um dos contêineres "Executando", mas não "Pronto". Os registros do contêiner "Em execução" são exibidos como se o serviço tivesse sido interrompido.

Isso acontece no containerd 1.4.0 quando a carga do nó é alta e vm.max_map_count é definido com um valor mais alto do que o padrão, o containerd-shim não drena o fifo stdout e bloqueia esperando que ele seja drenado, enquanto o dockerd não consegue evento / reconhecimento do containerd de que os processos se foram.

@discanto obrigado por compartilhar esta informação. O problema está sendo corrigido ou rastreado?

@ Random-Liu

O bug foi aberto há mais de 3 anos. Os pods travados ao encerrar podem ser causados ​​por vários motivos. Ao relatar seu caso, seria muito útil postar alguns dos registros do kubelet para ver se os pods travaram.