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

Le nettoyage du volume et du réseau prend généralement plus de temps lors de la terminaison. Pouvez-vous trouver dans quelle phase votre pod est bloqué? Nettoyage de volume par exemple?

Le nettoyage du volume et du réseau prend généralement plus de temps lors de la terminaison.

Correct. Ils sont toujours suspects.

@igorleao Vous pouvez également essayer kubectl delete pod xxx --now .

Salut @resouer et @dixudx
Je ne suis pas sûr. En regardant les journaux kubelet pour un pod différent avec le même problème, j'ai trouvé:

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.

Comme vous pouvez le voir, ce cluster a Calico pour CNI.
Les lignes suivantes attirent mon attention:

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-t-il un meilleur moyen de savoir à quelle phase un pod est bloqué?

kubectl delete pod xxx --now semble fonctionner plutôt bien, mais je souhaite vraiment découvrir sa cause profonde et éviter les interactions humaines.

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

Il semble que kubelet/mount n'a pas réussi à monter configmap en tant que volume en raison d'un changement de nom de fichier.

@igorleao Est-ce reproductible? Ou ce n'est tout simplement pas si stable, cela se produit parfois. J'ai déjà rencontré de telles erreurs, juste pour m'en assurer.

@dixudx cela se produit plusieurs fois par jour pour un certain cluster. D'autres clusters créés avec la même version de kops et kubernetes, dans la même semaine, fonctionnent très bien.

@igorleao Comme le journal montre que le gestionnaire de volumes n'a pas réussi à supprimer le répertoire secret car le périphérique est occupé.
Pouvez-vous s'il vous plaît vérifier si le répertoire /var/lib/kubelet/pods/GUID/volumes/kubernetes.io~secret/token-key est toujours monté ou non? Merci!

@igorleao comment

Nous constatons un comportement similaire. Nous exécutons kubelet en tant que conteneur et le problème a été partiellement atténué en montant /var/lib/kubelet comme partagé (par défaut, docker monte le volume en tant que rslave). Mais nous voyons toujours des problèmes similaires, mais moins fréquents. Actuellement, je soupçonne que d'autres montages devraient être faits de manière différente (par exemple /var/lib/docker ou /rootfs )

@stormltf Pouvez-vous s'il vous plaît publier la configuration de votre conteneur kubelet?

@stormltf vous exécutez kubelet dans un conteneur et n'utilisez pas le drapeau --containerized (qui fait quelques astuces avec les montages ). Ce qui signifie essentiellement que tous les montages effectués par kubelet seront effectués dans l'espace de noms de montage du conteneur. Heureusement qu'ils seront proposés à nouveau dans l'espace de noms de la machine hôte (comme vous avez / var / lib / kubelet comme partagé), mais je ne suis pas sûr de ce qui se passe si l'espace de noms est supprimé (lorsque le conteneur kubelet est supprimé).

Pouvez-vous s'il vous plaît pour les pods bloqués faire ce qui suit:

sur le nœud sur lequel le pod s'exécute

• docker exec -ti /kubelet /bin/bash -c "mount | grep STUCK_POD_UUID"
• et même sur le nœud lui-même mount | grep STUCK_POD_UUID .

Veuillez également faire de même pour le pod fraîchement créé. Je m'attends à voir des montages /var/lib/kubelet (par exemple, default-secret)

@stormltf avez-vous redémarré kubelet après la création des deux premiers pods?

@stormltf Vous pouvez essayer de faire en sorte que /var/lib/docker et /rootfs soient partagés (ce que je ne vois pas dans votre docker inspect, mais voir à l'intérieur du conteneur) mountpoint.

/ sig stockage

Pour certains, cela pourrait aider. Nous exécutons kubelet dans un conteneur docker avec l'indicateur --containerized et avons pu résoudre ce problème en montant /rootfs , /var/lib/docker et /var/lib/kubelet tant que montages partagés. Les montures finales ressemblent à ceci

      -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/ \

Pour plus de détails. Cela ne résout pas correctement le problème car pour chaque montage lié, vous obtiendrez 3 montures à l'intérieur du conteneur kubelet (2 parasites). Mais au moins une monture partagée permet de les démonter facilement d'un seul coup.

CoreOS n'a pas ce problème. Parce que l'utilisation de rkt et non de docker pour le conteneur kubelet. Dans le cas où notre cas kubelet fonctionnerait dans Docker et que chaque montage à l'intérieur de kubelet continer serait proposé dans /var/lib/docker/overlay/... et /rootfs c'est pourquoi nous avons deux montages parasites pour chaque volume de montage bind:

• un de /rootfs en /rootfs/var/lib/kubelet/<mount>
• un de /var/lib/docker en /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

J'ai le même problème avec Kubernetes 1.8.1 sur Azure - une fois le déploiement modifié et les nouveaux pods démarrés, les anciens pods sont bloqués à la fin.

J'ai le même problème sur Kubernetes 1.8.2 sur IBM Cloud. Une fois les nouveaux pods démarrés, les anciens pods sont bloqués en se terminant.

version 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"}

J'ai utilisé kubectl delete pod xxx --now ainsi que kubectl delete pod foo --grace-period=0 --force en vain.

Si la cause principale est toujours la même (montages mal proposés), il s'agit d'un bogue spécifique à la distribution imo.

Veuillez décrire comment vous exécutez kubelet dans le cloud IBM? unité systemd? a-t-il --containerized drapeau

il est exécuté avec l'option --containerized définie sur false.

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

- drapeau conteneurisé: Non

ok, j'ai besoin de plus d'informations, veuillez consulter mon commentaire ci-dessus https://github.com/kubernetes/kubernetes/issues/51835#issuecomment -333090349

et s'il vous plaît également montrer le contenu de /lib/systemd/system/kubelet.service et s'il y a quelque chose à propos de kubelet dans /etc/systemd/system veuillez partager aussi.

En particulier, si kubelet fonctionne dans le docker, je veux voir tous les montages de liaison -v .

Aujourd'hui, j'ai rencontré un problème qui peut être le même que celui décrit, où nous avons eu des pods sur l'un de nos systèmes clients bloqués dans l'état de terminaison pendant plusieurs jours. Nous voyions également les erreurs "Erreur: UnmountVolume.TearDown a échoué pour le volume" avec "périphérique ou ressource occupé" répété pour chacun des pods bloqués.

Dans notre cas, il semble y avoir un problème avec docker sur les systèmes basés sur RHEL / Centos 7.4 couvert dans ce problème moby: https://github.com/moby/moby/issues/22260 et ce moby PR: https: // github .com / moby / moby / pull / 34886 / fichiers

Pour nous, une fois que nous avons défini l'option sysctl fs.may_detach_mounts = 1 en quelques minutes, tous nos pods de terminaison ont été nettoyés.

Je suis également confronté à ce problème: les pods sont restés bloqués dans l'état de terminaison sur 1.8.3.

Journaux kubelet pertinents du nœud:

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"

Kubelet s'exécute en tant qu'unité systemd (pas dans le conteneur) sur Ubuntu 16.04.
Comme vous pouvez le voir, il y a eu un montage sur le serveur NFS et kubelet a tenté de supprimer le répertoire de montage car il considère ce répertoire comme non monté.

Spécifications des volumes du pod:

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

UPD : J'ai déjà rencontré ce problème avant aussi sur 1.6.6

Vivre la même chose sur 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

version 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"}

décrire le 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

Il semble qu'il existe différents bogues liés à un problème. Nous avons les deux sur notre cluster 1.8.3.

1. https://github.com/moby/moby/issues/31768 .C'est le bogue du docker. Reproductible sur le docker-ce = 17.09.0 ~ ce-0 ~ ubuntu.
2. La seconde est plus intéressante et peut-être liée à une condition de race à l'intérieur de kubelet.
   Nous avons beaucoup de pods qui utilisaient un volume de persistance NFS avec un sous-chemin spécifié dans les montages de conteneurs, certains d'entre eux se bloquant dans un état de fin après la suppression des déploiements. Et il y a beaucoup de messages dans le 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

Et c'est vrai que le répertoire n'est pas vide, il est démonté et contient notre répertoire "sous-chemin"!
L'une des explications d'un tel comportement:

1. P1: Commencez à créer un pod ou à synchroniser un pod
2. P1: Envoyer un signal au gestionnaire de volume pour effectuer des montages / remontages.
3. P1: Attend que le montage soit terminé.
4. P1: réception du signal de montage de succès (en fait, vérifiez simplement que tous les volumes sont montés)
5. D'une manière ou d'une autre, le volume n'est plus monté. Peut-être un autre processus de suppression le démonter ou un bogue du système d'exploitation, ou une action de ramasse-miettes.
6. P1: Continuez à créer le conteneur et créez un sous-répertoire dans le point de montage (déjà démonté).
7. Après toutes les étapes précédentes, le pod ne peut pas être supprimé, car le répertoire de montage n'est pas vide.

Plus de journaux:

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

En quelque sorte, un processus de nettoyage ((dswp * desireStateOfWorldPopulator) findAndRemoveDeletedPods ()) démarre le démontage des volumes alors que le pod est dans l'état d'initialisation:

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"

L'initialisation et la suppression du pod s'exécutent en même temps.
Pour répéter avec bogue, vous devez démarrer et supprimer / mettre à jour immédiatement environ 10 déploiements (testés pour un seul minion) et peut-être que votre opération de montage ne doit pas être très rapide.

Affecté par le même bug sur GKE. Existe-t-il des solutions de contournement connues pour ce problème? L'utilisation de --now ne fonctionne pas.

J'ai un correctif pour ce bogue, mais je ne suis pas sûr qu'il sera fusionné par l'équipe kubernetes.

@dreyk Pourriez-vous s'il vous plaît fournir plus de détails sur ce que vous avez découvert pour ce bogue et quel est votre correctif afin que l'équipe de stockage puisse y jeter un œil? Merci!

@ gm42 J'ai pu contourner manuellement ce problème sur GKE en:

1. SSH dans le nœud sur lequel le pod bloqué a été planifié
2. Lancer docker ps | grep {pod name} pour obtenir l'ID du conteneur Docker
3. Courant docker rm -f {container id}

Sur GKE, la mise à niveau des nœuds a aidé instantanément.

J'ai le même bogue sur mon cluster local configuré en utilisant kubeadm .

docker ps | grep {pod name} sur le nœud ne montre rien et le pod est bloqué dans l'état de fin. J'ai actuellement deux pods dans cet état.

Que puis-je faire pour supprimer de force le pod? Ou peut-être changer le nom du pod? Je ne peux pas faire tourner un autre pod sous le même nom. Merci!

J'ai trouvé la raison dans mon cluster 1.7.2,
car un autre programme de surveillance monte le chemin racine /
le chemin racine contient /var/lib/kubelet/pods/ddc66e10-0711-11e8-b905-6c92bf70b164/volumes/kubernetes.io~secret/default-token-bnttf
Ainsi, lorsque kubelet supprime le pod, mais qu'il ne peut pas libérer le volume, le message est:
Périphérique ou ressource occupé

pas:
1) sudo journalctl -u kubelet
ce shell m'aide à trouver le message d'erreur,
2) sudo docker inspecter
recherchez le io.kubernetes.pod.uid ":" ddc66e10-0711-11e8-b905-6c92bf70b164 "
et
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
racine 90225 1,3 0,0 2837164 42580? Ssl Feb01 72:40 ./monitor_program

J'ai le même bug sur ma 1.7.2

operationExecutor.UnmountVolume a démarré pour le volume "default-token-bnttf" (UniqueName: "kubernetes.io/secret/ddc66e10-0711-11e8-b905-6c92bf70b164-default-token-bnttf") pod "ddc66e10-0711-11e8-b90 6c92bf70b164 "kubelet [94382]: E0205 11: 35: 50.509169 94382 nestedpendingoperations.go: 262] Opération pour" \ "kubernetes.io/secret/ddc66e10-0711-11e8-b905-6c92en-bf70b164-deftt-tf (\" "ddc66e10-0711-11e8-b905-6c92bf70b164 \") "a échoué. Aucune nouvelle tentative n'est autorisée jusqu'au 05/02/2018 11: 37: 52.509148953 +0800 CST (durationBeforeRetry 2m2s). Erreur: UnmountVolume.TearDown a échoué pour le volume "default-token-bnttf" (UniqueName: "kubernetes.io/secret/ddc66e10-0711-11e8-b905-6c92bf70b164-default-token-bnttf") pod "ddc66e10-0711-11e8- b905-6c92bf70b164 "(UID:" ddc66e10-0711-11e8-b905-6c92bf70b164 "): remove /var/lib/kubelet/pods/ddc66e10-0711-11e8-b905-6c92bf70b164/volumes/subernetes/subernetes token-bnttf: périphérique ou ressource occupé

Le redémarrage du service Docker libère le verrou et les pods sont supprimés en quelques minutes. C'est un bug. Utilisation de docker 17.03

Même problème ici sur Azure, Kube 1.8.7

Cela nous est arrivé il y a quelques minutes aussi sur 1.8.9 - quelqu'un cherche à résoudre ce problème? Le redémarrage de docker aide, mais c'est un peu ridicule.

Cela m'est souvent arrivé avec la dernière version 1.9.4 sur GKE. Je fais ça pour le moment:

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

Même problème ici sur GKE 1.9.4-gke.1
semble être lié aux montages de volume.
Cela se produit à chaque fois que filebeats est configuré comme décrit ici:
https://github.com/elastic/beats/tree/master/deploy/kubernetes/filebeat

Le journal Kubelet montre ceci:

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
semble fonctionner.
également le redémarrage de kubelet fonctionne.

Même problème ici sur GKE 1.9.4-gke.1
Cela n'arrive qu'avec un ensemble de démons filebeat spécifique, mais recréer tous les nœuds n'aide pas non plus, cela continue de se produire.

Ce problème a également été rencontré sur GKE 1.9.4-gke.1 comme @Tapppi - les pods ont été supprimés du démon docker sur le nœud hôte, mais kubernetes l'avait bloqué dans 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

Pour nous, quelque chose de nouveau s'est produit il y a un instant, lorsque j'ai supprimé de force un pod bloqué en utilisant kubectl delete pod NAME --grace-period=0 --force , le nœud sur lequel se trouvait ce pod est juste devenu malsain. Nous exécutons docker 17-12CE et le redémarrage de docker deamon sur cette boîte a aidé et débouché le nœud.

Pour les gens qui voient ce problème sur 1.9.4-gke.1, il est probablement dû à https://github.com/kubernetes/kubernetes/issues/61178 , qui est corrigé dans 1.9.5 et est en cours de déploiement dans GKE cette semaine. Le problème est lié au nettoyage des montages de sous-chemins d'un fichier (pas d'un répertoire). @zackify @ nodefactory-bk @Tapppi @Stono

IIUC, le problème original de ce bogue est lié à la configuration du kubelet conteneurisé, qui est différent.

BTW, créer un nouveau pool de nœuds avec la version v1.9.3-gke.0 était notre solution de contournement pour cela, car v1.9.5 n'est toujours pas déployé sur gke et que c'est déjà Pâques.

Quelqu'un peut-il confirmer que cela est corrigé dans la version 1.9.3+ s'il vous plaît? Nous avons de sérieux problèmes à cause de ce comportement, et le redémarrage de docker chaque fois que cela se produit est tellement st00pid.

Fixé sur 1.9.6 pour moi

Le mercredi 4 avril 2018, 11 h 43 sokoow, [email protected] a écrit:

Quelqu'un peut-il confirmer que cela est corrigé dans la version 1.9.3+ s'il vous plaît? Nous avons
certains problèmes graves à cause de ce comportement et le redémarrage de docker chacun
le moment où cela se produit est soo st00pid.

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/kubernetes/kubernetes/issues/51835#issuecomment-378557636 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ABaviW5yfj64zVjBYFGUToe2MH3dKwpTks5tlKPNgaJpZM4PKs9r
.

D'accord, merci @Stono . Encore une chose à confirmer ici. Voici notre modèle kubespray pour kubelet conteneurisé:

#!/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 \ "$@"

Cela semble-t-il correct? Est-ce que quelqu'un d'autre utilise similaire?

J'ai parlé trop tôt.

  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

J'ai dû le détruire de manière brutale.

❯ 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 quelle version de docker utilisez-vous? pour nous avec docker 17.12CE, faire la suppression de pod avec --force --grace-period 0 est assez drastique - cela finit presque toujours par un nœud indisponible en raison du blocage du docker

J'ai toujours ce problème sur la version 1.9.6 sur le cluster géré Azure AKS.

En utilisant cette solution de contournement pour le moment pour sélectionner tous les pods bloqués et les supprimer (car je finis par avoir des pans de pods de terminaison dans mon cluster dev / scratch):

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

rencontré ce problème sur les clusters Azure et AWS de mai - la solution de contournement a été fournie par Mike Elliot

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

ubuntu @ ip-10-0-0-22 : ~ $ kubectl récupère les pods --all-namespaces
NAMESPACE NOM READY STATUS RESTARTS AGE
kube-system heapster-76b8cd7b5-4r88h 1/1 Fonctionnement 0 25d
kube-system kube-dns-5d7b4487c9-s4rsg 3/3 Fonctionnement 0 25d
kube-system kubernetes-dashboard-f9577fffd-298r6 1/1 Exécution 0 25d
kube-system monitoring-grafana-997796fcf-wtz7n 1/1 Fonctionnement 0 25d
kube-system monitoring-influxdb-56fdcd96b-2phd2 1/1 Exécution 0 25d
kube-system tiller-deploy-cc96d4f6b-jzqmz 1/1 Exécution 0 25d
onap dev-sms-857f6dbd87-pds58 0/1 Terminaison 0 3h
onap dev-vfc-zte-sdnc-driver-5b6c7cbd6b-5vdvp 0/1 Terminaison 0 3h
ubuntu @ ip-10-0-0-22 : ~ $ kubectl supprimer le pod dev-vfc-zte-sdnc-driver-5b6c7cbd6b-5vdvp -n onap --grace-period = 0 --force
avertissement: la suppression immédiate n'attend pas la confirmation de l'arrêt de la ressource en cours d'exécution. La ressource peut continuer à s'exécuter sur le cluster indéfiniment.
pod "dev-vfc-zte-sdnc-driver-5b6c7cbd6b-5vdvp" supprimé
ubuntu @ ip-10-0-0-22 : ~ $ kubectl récupère les pods --all-namespaces
NAMESPACE NOM READY STATUS RESTARTS AGE
kube-system heapster-76b8cd7b5-4r88h 1/1 Fonctionnement 0 25d
kube-system kube-dns-5d7b4487c9-s4rsg 3/3 Fonctionnement 0 25d
kube-system kubernetes-dashboard-f9577fffd-298r6 1/1 Exécution 0 25d
kube-system monitoring-grafana-997796fcf-wtz7n 1/1 Fonctionnement 0 25d
kube-system monitoring-influxdb-56fdcd96b-2phd2 1/1 Exécution 0 25d
kube-system tiller-deploy-cc96d4f6b-jzqmz 1/1 Exécution 0 25d
onap dev-sms-857f6dbd87-pds58 0/1 Terminaison 0 3h
ubuntu @ ip-10-0-0-22 : ~ $ kubectl supprimer le pod dev-sms-857f6dbd87-pds58 -n onap --grace-period = 0 --force
avertissement: la suppression immédiate n'attend pas la confirmation de l'arrêt de la ressource en cours d'exécution. La ressource peut continuer à s'exécuter sur le cluster indéfiniment.
pod "dev-sms-857f6dbd87-pds58" supprimé
ubuntu @ ip-10-0-0-22 : ~ $ kubectl récupère les pods --all-namespaces
NAMESPACE NOM READY STATUS RESTARTS AGE
kube-system heapster-76b8cd7b5-4r88h 1/1 Fonctionnement 0 25d
kube-system kube-dns-5d7b4487c9-s4rsg 3/3 Fonctionnement 0 25d
kube-system kubernetes-dashboard-f9577fffd-298r6 1/1 Exécution 0 25d
kube-system monitoring-grafana-997796fcf-wtz7n 1/1 Fonctionnement 0 25d
kube-system monitoring-influxdb-56fdcd96b-2phd2 1/1 Exécution 0 25d
kube-system tiller-deploy-cc96d4f6b-jzqmz 1/1 Exécution 0 25d

Je ne suis pas sûr que ce soit le même problème, mais nous avons commencé à remarquer ce comportement _depuis_ la mise à niveau de 1.9.3 à 10.10.1. Cela ne s'est jamais produit auparavant. Nous utilisons des volumes glusterfs, avec SubPath. Kubelet enregistre en continu des choses comme

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"

et lsof montre en effet que le répertoire sous les volumes glusterfs est toujours utilisé:

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

Tout allait bien sur la version 1.9.3, c'est donc comme si le correctif de ce problème avait cassé notre cas d'utilisation :(

@ ross-w cette signature est différente des autres. Pourriez-vous ouvrir un nouveau problème et inclure également les spécifications de votre pod?

Des mises à jour sur ces problèmes?
Dans notre cas (Kubernetes 1.9.7, docker 17.03), les pods sont dans l'état Terminating, une fois que le nœud est sorti de mémoire et que les pods sont replanifiés. Finalement, il y a beaucoup de pods fantômes dans le tableau de bord Kubernetes et dans l'onglet Déploiements, nous pouvons voir les déploiements avec des pods 4/1.
Redémarrer kubelet ou tuer tous les pods dans l'espace de noms aide, mais c'est une très mauvaise solution.

@Adiqq Car c'était un problème avec Docker lui-même.

Jetez un œil à journalctl -u kubelet -f sur l'un de vos nœuds. J'ai eu un message du type `` Impossible de tuer le conteneurErreur gRpc "(je n'ai pas le vrai message depuis que j'ai corrigé ce problème).

Pour résoudre ce problème, j'ai redémarré le docker sur chaque note. Lors du démarrage, nettoyez les conteneurs Docker dans un état cassé et supprimez tous ces pods périmés.

J'ai eu ça hier en 1.9.7, avec un pod bloqué en état de terminaison et dans les journaux il avait juste "besoin de tuer le pod", j'ai dû --force --grace-period=0 pour me débarrasser.

Je viens de l'obtenir avec 1.9.7-gke.0.
N'a pas eu de problèmes avec 1.9.6-gke.1.
Mais je l'ai eu avec 1.9.4 et 1.9.5

Le pod coincé a un PV attaché.

Le redéploiement ou la suppression d'un pod a le même effet.
Le redémarrage de kubelet sur le nœud incriminé n'a pas fonctionné. kubelet n'a pas redémarré et j'ai dû redémarrer le nœud entier.

Pendant ce temps, le pod ne pouvait être programmé sur aucun autre nœud car il indiquait que le PV était déjà monté ailleurs.

@Stono @ nodefactory-bk pourriez-vous jeter un coup d'œil à vos journaux kubelet sur les nœuds incriminés pour voir s'il existe des journaux détaillés qui pourraient indiquer le problème?

cc @dashpole

Juste une application bloquée à la fin.
Ceci est sur 1.9.7-gke.1
Voici kubectl décrire le pod avec des secrets rédigés:

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

Je ne sais pas où trouver kubelet.log dans gke sur les images Google. J'ai trouvé quelque chose que j'attache.
kube.log

kubectl -n shsp-cloud-dev delete pod sharespine-cloud-6b78cbfb8d-xcbh5 --force --grace-period 0
tué et enlevé.
Cela a bien commencé après mais a pris un peu plus de temps que d'habitude.

Remarquez que cela ne se produit pas CHAQUE fois pour cette application.
Je dirais probablement environ 1/4 fois.

En frappant cela avec k8s 1.9.6, lorsque kubelet est incapable de démonter le montage Cephfs, tous les pods sur le nœud restent terminés pour toujours. J'ai dû redémarrer le nœud pour récupérer, le redémarrage de kubelet ou de docker n'a pas aidé.

@tuminoid le problème de ceph sonne différemment. Pourriez-vous ouvrir un nouveau problème et fournir également des événements de pod et des journaux de kubelet pour ce pod?

Pour info, la mise à jour de mes clusters (vers k8s v1.10.2) semble avoir éliminé ce problème pour nous.

La pièce jointe me le reproduit sur 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

exécutez-le, puis supprimez-le. Vous obtiendrez un «client nfs» bloqué lors de la suppression. La raison en est le montage en dur sur le nœud, et le «serveur» est supprimé en premier.

@donbowman pour le problème de

Je ne vois pas comment? Je peux le définir sur un PersistentVolumeClaim, mais cela ne s'applique pas ici.
Je ne pense pas que StorageClass s'applique ici (ce serait le sous-disque, sous le serveur nfs).

Le problème concerne le client nfs.
est-ce que je manque quelque chose?

Pour votre PV nfs, vous pouvez définir le champ mountOptions à partir de la version 1.8 pour spécifier un montage logiciel. Si vous provisionnez dynamiquement des volumes nfs, vous pouvez également le définir dans votre StorageClass.mountOptions

oui, mais ce n'est pas le PV qui est monté avec NFS.
C'est de mon conteneur de serveur NFS.
Il n'y a pas de provisioning dynamique.

Cela utilise Google GCP + GKE. Le PVC sélectionne un PV qui est un bloc IO, monté en ext4 dans un conteneur qui le réexporte avec NFS.

Le 2ème ensemble de conteneurs, qui se monte à partir du serveur nfs (qui est lui-même un pod), ils ne le voient pas comme un PV. Ils le voient comme un volume comme ci-dessous.

Je ne vois pas de moyen de faire en sorte que ce client nfs voie un 'pvc' pour le montage, donc je ne peux pas définir les options de montage. Je ne peux pas non plus le voir comme une StorageClass.

Est-ce que je manque quelque chose?

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 pour votre deuxième ensemble de conteneurs, qui utilise le montage nfs, vous pouvez créer manuellement un PV pour ce volume nfs avec l'ensemble mountOptions, et partager le PVC pour ce PV nfs dans tous vos pods. Aucun provisionnement dynamique impliqué.

Quelque chose comme ça:

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

Merci! Cela a donc fonctionné (dans le sens où il s'agit maintenant d'un montage logiciel) mais ne résout pas le problème:

Le montage (comme observé sur le nœud) est maintenant souple:

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)

Mais quand je supprime le tout, le client nfs reste bloqué pour toujours dans l'état de terminaison.

k8s-nfs-test.yaml.txt

ci-joint est le yaml que j'ai utilisé. J'ai fait un 'créer', j'ai attendu qu'il apparaisse, observé que le client avait le montage, pouvait lire / écrire des fichiers dedans, puis j'ai fait une 'suppression' dessus.

Le pod nfs-server est supprimé, mais le nfs-client ne l'est pas.

En regardant sur le pod, la monture est restée:

# 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 tellement désolé, je me suis trompé sur l'option douce. L'option logicielle empêche uniquement les appels de système de fichiers de se bloquer lorsque le serveur est inaccessible, mais n'aide pas réellement à démonter le volume nfs. Un démontage de force devrait être fait pour cela, que nous n'avons actuellement pas de moyen de traverser. Pour l'instant, vous devrez nettoyer manuellement ces montages et vous assurer de supprimer vos pods dans le bon ordre (clients nfs d'abord, puis serveur nfs).

J'ai essayé d'ajouter timeo = 30 et intr, mais même problème.
cela le verrouille, doit se connecter au nœud et faire un umount -f -l sur le montage sous-jacent, puis peut faire un kubectl delete --force --grace-period 0 sur le pod.

il semble que puisque cela a été monté pour le compte du pod, il pourrait être possible de démonter (ou de forcer le démontage après un certain délai) lors de la suppression automatique.

J'avais un tas de pods comme ça, donc j'ai dû proposer une commande qui nettoierait tous les pods de terminaison:

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

Je pense qu'avec le nouveau magasin de fichiers de Google, nous aurons le même problème, pas de montage.

@donbowman iirc, votre problème est dû au fait que vous mettiez fin au pod serveur nfs avant le pod client nfs. Si vous utilisez filestore, vous n'avez plus besoin d'un pod pour héberger votre serveur nfs, vous ne devriez donc pas avoir ce problème tant que vous ne supprimez pas l'intégralité de l'instance de Firestore.

N'aurai-je pas le même problème si j'organise le magasin de fichiers? Par exemple, si j'en parle pour un déploiement Kubernetes spécifique, puis en bas à la fin, l'ordre n'est pas garanti.

Mais je pense aussi que le problème n'est pas seulement l'ordre, la suppression du pod client nfs ne se démonte pas du tout, elle laisse simplement le support suspendu sur le nœud. Donc, que le fichier / serveur soit présent ou non, il y a un montage suspendu.

Lorsqu'un pod est terminé, nous démontons le volume (en supposant que le serveur est toujours là). Si vous voyez des montures pendantes même lorsque le serveur existe, c'est un bogue.

Si vous utilisez l'approvisionnement dynamique avec des PVC et des PV, nous n'autorisons pas la suppression du PVC (et du stockage sous-jacent) tant que tous les pods qui le référencent ne l'utilisent pas. Si vous souhaitez orchestrer l'approvisionnement vous-même, vous devez vous assurer de ne pas supprimer le serveur tant que tous les pods n'ont pas fini de l'utiliser.

C'est peut-être une solution de contournement possible: # 65936

Forcer la suppression a fonctionné pour kubectl delete po $pod --grace-period=0 --force . L'indicateur --now ne fonctionnait pas. Je ne suis pas sûr de # 65936 mais je voudrais ne pas tuer le nœud lorsque des états Unknown se produisent.

Ayant le même problème (les pods restent en terminaison car un fichier dans le pod ne peut pas être démonté car le périphérique est `` occupé '') sur 1.10.5. Pour moi, l'utilisation de --grace-period=0 --force permettra au point de montage de continuer à exister. Finalement, je me suis retrouvé avec plus de 90000 points de montage, ce qui a considérablement ralenti le cluster. La solution de contournement consiste à effectuer une recherche dans le dossier du pod et à démonter ces fichiers de manière récursive, puis à supprimer de manière récursive le dossier du pod.
Dans mon cas, je monte un configmap en utilisant un sous-chemin dans un dossier existant avec des fichiers existants, en écrasant l'un des fichiers existants. Cela fonctionnait bien pour moi sur 1.8.6.
L'affiche originale mentionne que les gousses restent en «terminaison» pendant quelques heures, dans mon cas, ce sont des jours. Je ne les ai pas vus être nettoyés finalement, sauf lorsque je fais la solution de contournement manuelle.

Ayant le même problème, causé par l'agrégateur de journaux (similaire à fluentd), il monte le dossier /var/lib/docker/containers et le pod a beaucoup de montages:

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

Dans mon cas, certains pods peuvent être bien supprimés par kubernetes, mais certains sont bloqués en état de "fin".

Cela pourrait être lié à https://github.com/kubernetes/kubernetes/issues/45688 (j'utilise également docker 17)

J'ai juste eu le problème que les pods ne se terminaient pas car un secret manquait. Après avoir créé ce secret dans cet espace de noms, tout était revenu à la normale.

J'ai retiré mes pods bloqués comme ceci:

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>:~$

Vous avez un problème similaire en cours d'exécution sur 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>

J'ai essayé d'utiliser --now ou de définir la période de grâce. Par exemple

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

Le pod est toujours suspendu et cela entraîne également le blocage du déploiement correspondant.

Je suis également hanté par ces messages «Need to kill Pod» dans les événements du pod. Qu'est-ce que cela signifie d'ailleurs? Que _Kubernetes_ ressent le besoin de tuer le pod, ou que _Je_ devrais tuer le pod?

cela m'est arrivé il y a quelques jours et j'ai abandonné la suppression et laissé le pod tel quel. Puis aujourd'hui, il a disparu et semble être finalement supprimé.

Cela m'est arrivé tout à l'heure. La solution --force --now n'a pas fonctionné pour moi. J'ai trouvé la ligne suivante dans les journaux de kubelet suspecte

6 août 15:25:37 kube-minion-1 kubelet [2778]: W0806 15: 25: 37.986549 2778 docker_sandbox.go: 263] NetworkPlugin cni a échoué sur le hook d'état du pod "backend-foos-227474871-gzhw0_default": inattendu sortie de la commande nsenter: impossible d'ouvrir: aucun fichier ou répertoire de ce type

Ce qui m'a amené à trouver le problème suivant:
https://github.com/openshift/origin/issues/15802

Je ne suis pas sur openstack mais sur Openstack, donc j'ai pensé que cela pourrait être lié. J'ai donné le conseil de redémarrer docker un coup.
Le redémarrage de docker a fait disparaître les pods bloqués dans "Terminer".

Je sais que ce n'est qu'une solution de rechange, mais je ne me réveille plus parfois à 3 heures du matin pour résoudre ce problème.
Je ne dis pas que vous devriez l'utiliser, mais cela pourrait aider certaines personnes.

Le sommeil est ce que j'ai mes pods, la terminaisonGracePeriodSeconds est définie sur (30 secondes). S'il est en vie plus longtemps que cela, ce cronjob forcera --grace-period = 0 et le tuera complètement

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

Je vois la même erreur avec Kubernetes v1.10.2. Les pods se bloquent indéfiniment et le kubelet sur le nœud en question enregistre à plusieurs reprises:

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"

Je peux démonter manuellement le volume du sous-chemin en question sans me plaindre (Linux ne me dit pas qu'il est occupé). Cela empêche le kubelet d'enregistrer le message d'erreur. Cependant, cela n'incite pas Kubernetes à poursuivre le nettoyage, car le pod est toujours affiché dans l'état de fin. Le redémarrage régulier de Docker pour nettoyer cela n'est pas vraiment une solution acceptable en raison de la perturbation qu'il provoque dans l'exécution des conteneurs.

A noter également: le conteneur lui-même est passé de docker ps -a sans aucune preuve qu'il ait jamais existé, donc je ne suis pas sûr qu'il s'agisse en fait d'un problème Docker. Nous utilisons la version 17.03.2-ce de Docker.

Une mise à jour: nous avions configuré nos nœuds pour rediriger le répertoire racine de kubelet vers un volume non-OS avec un lien symbolique ( /var/lib/kubelet était un lien symbolique pointant vers un autre répertoire sur un volume différent). Lorsque j'ai reconfiguré les choses pour passer --root-dir au kubelet afin qu'il aille directement dans le répertoire souhaité, plutôt que via un lien symbolique, et redémarré le kubelet, il a nettoyé les montages de volume et effacé les pods qui étaient bloqués terminer sans nécessiter un redémarrage de Docker.

J'ai rencontré ce problème aujourd'hui pour la première fois en exécutant des pods localement sur minikube.

J'avais un tas de pods coincés dans Terminating raison d'un configmap / secret monté en tant que volume manquant. Aucune des suggestions / solutions de contournement / solutions publiées ci-dessus n'a fonctionné à l'exception de celle-ci .

Une chose qui, à mon avis, mérite d'être signalée est la suivante:

• Quand j'ai lancé kubectl get pods , j'ai obtenu la liste des pods avec le statut Terminating .
• Quand j'ai exécuté docker ps | grep -i {{pod_name}} cependant, aucun des pods dans le statut Terminating vu par kubectl get pods n'était en cours d'exécution dans la VM minikube.

Je m'attendais docker ps ce que Terminating mais en réalité aucun d'entre eux n'était en cours d'exécution, pourtant kubectl get pods renvoyait des données à leur sujet? Quelqu'un pourrait-il expliquer pourquoi?

J'ai rencontré ce problème avec 4 déploiements. Ensuite, je suis passé du «volume local» au «chemin de l'hôte» pour tous les montages, et c'est parti pour moi.

J'ai juste eu le problème que les pods ne se terminaient pas car un secret manquait. Après avoir créé ce secret dans cet espace de noms, tout était revenu à la normale.

Comment créer un secret dans l'espace de noms si l'espace de noms est à l'état «Terminating»?

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

travaille pour moi.

N'oubliez pas "--grace-period = 0". Cela compte

kubectl m'a averti "avertissement: la suppression immédiate n'attend pas la confirmation que la ressource en cours d'exécution a été arrêtée. La ressource peut continuer à s'exécuter sur le cluster indéfiniment." quand j'utilise --force --grace-period=0 .
Quelqu'un peut-il me dire si ça va vraiment arriver?

en fait, lorsque nous supprimons un pod, cela peut retarder la suppression pour certaines raisons,
et si nous exécutons "kubectl delete" avec le drapeau "--force --grace-period = 0",
l'objet ressource serait supprimé immédiatement.

Pouvez-vous aider à confirmer si le pod sera supprimé immédiatement?
Cela signifie-t-il que le message d'avertissement est en fait inexact?

@windoze , si vous choisissez l'option --force --grace-period = 0, cela signifie que l'objet API du pod sera immédiatement supprimé du serveur API. Node kubelet est chargé de nettoyer les montages de volume et de tuer les conteneurs. Si kubelet n'est pas en cours d'exécution ou rencontre des problèmes lors du nettoyage du pod, le conteneur est peut-être toujours en cours d'exécution. Mais Kubelet devrait continuer d'essayer de nettoyer les gousses chaque fois que possible.

Cela signifie donc toujours que la suppression pourrait prendre une éternité parce que kubelet pourrait ne pas fonctionner correctement?
Existe-t-il un moyen de s'assurer que le pod est supprimé?
Je pose la question parce que j'ai d'énormes pods en cours d'exécution dans le cluster et qu'il n'y a pas assez de mémoire sur chaque nœud pour en exécuter 2 instances.
Si la suppression échoue, le nœud devient inutilisable et si ce problème se produit plusieurs fois, le service sera complètement arrêté car il n'y aura finalement aucun nœud qui pourra exécuter ce pod.

Dans un environnement docker simple, je peux forcer la destruction d'un pod avec kill -9 ou quelque chose comme ça, mais il semble que k8s n'ait pas une telle fonction.

@windoze savez-vous pourquoi la suppression de votre pod a souvent échoué? C'est parce que kubelet n'est pas en cours d'exécution ou que kubelet essayait de tuer le conteneur mais a échoué avec quelques erreurs?

Une telle situation s'est produite plusieurs fois sur mon cluster il y a plusieurs mois, kubelet était en cours d'exécution mais le démon docker semblait avoir des problèmes et s'est bloqué sans journal d'erreurs.
Ma solution était de me connecter au nœud et de forcer la suppression du processus de conteneur et de redémarrer le démon docker.
Après quelques mises à niveau, le problème avait disparu et je ne l'ai plus jamais eu.

kubectl delete pods <podname> --force --grace-period=0 fonctionné pour moi!

@ shinebayar-g, le problème avec --force est que cela pourrait signifier que votre conteneur continuera à fonctionner. Il dit simplement à Kubernetes d'oublier les conteneurs de ce pod. Une meilleure solution consiste à SSH dans la VM exécutant le pod et à enquêter sur ce qui se passe avec Docker. Essayez de tuer manuellement les conteneurs avec docker kill et en cas de succès, essayez à nouveau de supprimer le pod normalement.

@agolomoodysaada Ah, c'est logique. Merci pour l'explication. Donc, je ne saurais pas vraiment que le conteneur réel est vraiment supprimé ou non?

alors, c'est la fin de 2018, le kube 1.12 est sorti et ... vous avez tous encore des problèmes avec les pods bloqués?

J'ai le même problème, soit --force --grace-period = 0 ou --force --now ne fonctionne pas, voici les journaux:

root @ r15-c70-b03-master01 : ~ # kubectl -n infra-lmat obtenir le pod node-exporter-zbfpx
NOM READY STATUS REDEMARRE L'ÂGE
node-exporter-zbfpx 0/1 Terminaison 0 4d

root @ r15-c70-b03-master01 : ~ # kubectl -n infra-lmat supprimer le pod node-exporter-zbfpx --grace-period = 0 --force
avertissement: la suppression immédiate n'attend pas la confirmation de l'arrêt de la ressource en cours d'exécution. La ressource peut continuer à s'exécuter sur le cluster indéfiniment.
pod "node-exporter-zbfpx" supprimé

root @ r15-c70-b03-master01 : ~ # kubectl -n infra-lmat obtenir le pod node-exporter-zbfpx
NOM READY STATUS REDEMARRE L'ÂGE
node-exporter-zbfpx 0/1 Terminaison 0 4d

root @ r15-c70-b03-master01 : ~ # kubectl -n infra-lmat supprimer le pod node-exporter-zbfpx --now --force
pod "node-exporter-zbfpx" supprimé

root @ r15-c70-b03-master01 : ~ # kubectl -n infra-lmat obtenir le pod node-exporter-zbfpx
NOM READY STATUS REDEMARRE L'ÂGE
node-exporter-zbfpx 0/1 Terminaison 0 4d

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

J'ai essayé de modifier le pod et de supprimer la section des finaliseurs dans les métadonnées, mais cela a également échoué.

Je vois toujours cela de manière reproductible à 100% (mêmes définitions de ressources) avec kubectl 1.13 alpha et Docker for Desktop sur macOS. Par reproductible, je veux dire que la seule façon de résoudre ce problème semble être de réinitialiser Docker pour Mac, et lorsque je configure à nouveau mon cluster en utilisant les mêmes ressources (script de déploiement), le même script de nettoyage échoue.

Je ne sais pas pourquoi cela serait pertinent, mais mon script de nettoyage ressemble à:

#!/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

Étant donné que le cluster est exécuté localement, je peux vérifier qu'aucun conteneur describe les pods, le statut est indiqué comme Status: Terminating (lasts <invalid>)

Cela m'est arrivé une fois de plus. J'essayais d'installer percona pmm-server avec le partage NFS et le logiciel n'est même pas venu, alors j'ai supprimé et cela s'est produit. (La revendication persistante ne fonctionnait pas pour ce logiciel). Je suppose que j'appelle à nouveau le bon vieux kubectl delete pods <podname> --force --grace-period=0 . Mais la question est de savoir comment puis-je savoir où vit ce pod?

@ shinebayar-g, SSH dans la VM sur laquelle il se trouvait et exécutez docker ps .

Eh bien, ce n'était pas là ... J'ai peu de VM, alors j'ai demandé comment savoir laquelle est la bonne. :)

@ shinebayar-g cela peut fonctionner:
kubectl describe pod/some-pod-name | grep '^Node:'

même problème.

docker ps trouvé que le conteneur est à l'état "Mort" non Quitté (0) comme prévu

En supprimant manuellement le conteneur, accédez à l'entrée de journal Docker suivante:

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

Malheureusement, la ligne est coupée, mais je pense que je m'en souviens, le problème était que le processus n'était plus là.

Je suis toujours coincé avec ce problème avec k8s v1.11.0. Voici une liste de contrôle de ce que je fais pour nettoyer mes dosettes:

• Assurez-vous que toutes les ressources associées au pod ont été récupérées. Tous ne sont pas visibles dans kubectl get ; certains d'entre eux ne sont connus que du Kubelet sur lequel le pod fonctionne, vous devrez donc suivre son flux de journal localement
  
  
  
  • En particulier, les répertoires umount dont Kubelet se plaint avec des messages device or resource busy
  
  
• Quand tout le reste échoue, kubectl edit le pod échoué et supprimez finalizers: → - foregroundDeletion

Deux autres conseils:

• En régime permanent, un Kubelet non confus ne doit enregistrer aucun message périodique. Tout type d'échec répété pour libérer quelque chose est le symptôme d'un pod coincé.
• vous pouvez garder une commande kubectl delete bloquée dans une autre fenêtre pour suivre votre progression (même sur un pod que vous avez déjà "supprimé" plusieurs fois). kubectl delete se terminera dès que la dernière ressource bloquée sera libérée.

Face à cela aujourd'hui.
Ce qui a été fait:

1. ssh au nœud et supprimer le conteneur manuellement
2. Après cela kubectl get pods me montre ce que mon conteneur coincé 0/1 terminating (était 1/1 terminating )
3. Supprimer la section finalizers du pod, mon was foregroundDeletion ($ kubectl edit pod / name) -> conteneur supprimé de la liste des pods
4. Supprimer le déploiement -> tous les éléments liés au déploiement supprimés.

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

nous sommes confrontés au même problème lorsque nous avons commencé à monter des secrets (partagés avec de nombreux pods). Le pod entre dans l'état terminating et y reste pour toujours. Notre version est v1.10.0. Le conteneur docker attaché a disparu, mais la référence dans le serveur API reste à moins que je ne supprime de force le pod avec l'option --grace-period=0 --force .

À la recherche d'une solution permanente.

Eh bien, récemment, j'ai testé l'exploit runc CVE-2019-5736 sur mon cluster de préparation, comme vous le savez déjà, l'exploit réécrit le binaire runc sur la machine hôte. Son exploit destructeur. Après cela, j'ai vu un comportement étrange sur le cluster. Tous les pods sont bloqués sur l'état de fin. La solution de contournement consistait à vidanger le docker de purge de nœud affecté et à le réinstaller. Après cela, tous les pods et clusters k8 fonctionnent normalement comme avant. Peut-être que c'est un problème de docker et le réinstaller résout votre problème aussi !. Merci

La nouvelle version v1.13.3 est installée ici. Cela m'arrive aussi. Cela se produit depuis que j'ai monté les mêmes volumes NFS sur quelques pods, ce qui semble avoir quelque chose à voir avec cela.

Je vois ce problème lors de la création d'un déploiement qui tente de créer un volume en utilisant un secret qui n'existe pas, la suppression de ce déploiement / service laisse autour d'un pod Terminating .

face au même problème avec v.1.12.3, et --grace-period = 0 --force ou --now les deux invalides, supprimez le statefulset qui appartient également invalide

Même problème avec un montage SMB (je pense?) (Partage Azure Files selon https://docs.microsoft.com/en-us/azure/aks/azure-files-volume).

même problème avec 13.3

J'ai le même problème que le pod est dans l'état «Terminé» depuis près de 2 jours.
J'utilise Minikube sur une machine Linux (Debian).

Version 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"}
Version Minikube:
minikube version: v0.34.1

@ardalanrazavi pourquoi se termine-t-il pendant deux jours? Il suffit de forcer la suppression si elle ne supprime pas après 5 minutes

@nmors

pourquoi se termine-t-il pendant deux jours?

C'est une bonne question. Nous aimerions tous savoir cela.

Il suffit de forcer la suppression si elle ne supprime pas après 5 minutes

Le supprimer de force laisse le cluster dans un état incohérent. (Avec minikube, ce n'est pas votre vrai cluster, c'est certes beaucoup moins préoccupant)

@AndrewSav

Je ne vois aucune autre solution ici pour être franc.

Bien sûr, le cluster sera laissé dans un "état incohérent". J'aimerais comprendre ce que vous entendez exactement par là. La fermeture forcée est mauvaise. Je n'aime pas non plus cela, mais dans mon cas, je suis à l'aise pour détruire et redéployer toutes les ressources au besoin.

Dans mon cas, il semble ne rester bloqué qu'en se terminant sur les pods qui ont un montage NFS. Et cela ne se produit que lorsque le serveur NFS tombe en panne avant que le client essaie de tomber en panne.

J'ai résolu le problème, j'ai pu isoler que tous les pods bloqués se terminaient tous sur un nœud, le nœud a été redémarré et le problème a disparu.

@nmors @AndrewSav J'ai également forcé la suppression.

La suppression de votre serveur nfs avant de supprimer vos pods est connue pour entraîner un blocage définitif du démontage. Dans ce cas, il est préférable d'ordonner vos suppressions afin que votre serveur nfs soit toujours supprimé en dernier.

@ msau42 Mon serveur NFS ne fait pas partie du cluster k8s - c'est un appareil et une machine séparés tous ensemble

Peu importe qu'il fasse partie du cluster k8s ou non. Si le serveur nfs est inaccessible, le démontage se bloque jusqu'à ce qu'il redevienne accessible.

@ msau42 c'est étrange, car je suis à peu près sûr que même quand il est revenu en ligne, les pods étaient toujours bloqués. les nouveaux pods démarrent et se montent bien.

J'utilise le serveur NFS sur kubernetes suivi de cet exemple et cela arrive assez souvent malheureusement ..

@ shinebayar-g J'ai également suivi ce guide, mais maintenant je me suis débarrassé des PV et des PVC et j'ai défini mon volume directement dans le déploiement, comme ceci:

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

Je n'ai eu aucun problème depuis, j'ai changé cela seulement environ une semaine en espérant que la configuration plus simple serait plus fiable .. voyons voir ... Peut-être que cela résoudra le problème?

Pour contourner le problème, j'ai écrit un script qui saisit quelques dernières lignes de /var/log/syslog et recherche des erreurs comme "Opération pour ... supprimer / var / lib / kubelet / pods ... répertoire non vide" ou "nfs. ..le périphérique est occupé ... unmount.nfs "ou" descripteur de fichier NFS périmé ".
Ensuite, il extrait le répertoire complet du pod_id ou du pod et voit ses montages (comme mount | grep $pod_id ), puis tout démonte et supprime les répertoires correspondants. Finalement, kubelet fait le reste et arrête et supprime les pods en douceur. Plus de pods à l'état de terminaison.

J'ai mis ce script dans cron pour qu'il s'exécute toutes les minutes. En conséquence - aucun problème pour l'instant, même 3-4 mois plus tard.
Remarque : je sais que cette approche n'est pas fiable et qu'elle nécessite une vérification à chaque mise à niveau du cluster, mais cela fonctionne!

J'utilise la version 1.10 et j'ai rencontré ce problème aujourd'hui et je pense que mon problème est lié au problème du montage d'un volume secret qui aurait pu laisser une tâche en suspens et laisser le pod en état de terminaison pour toujours.

J'ai dû utiliser l'option --grace-period = 0 --force pour terminer les 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]

J'ai trouvé que si vous utilisez --force --grace-period=0 tout ce qu'il fait est de supprimer la référence ... si vous ssh dans le nœud, vous verrez toujours les conteneurs docker en cours d'exécution.

Dans mon cas, il y avait Out of memory sur le nœud.
Et le noyau a tué l'agent de cil, ce qui semble perturber la terminaison des gousses.
Je viens de redémarrer le nœud et il s'est effacé.

D'après mon expérience, sudo systemctl restart docker sur le nœud aide (mais il y a évidemment des temps d'arrêt).

Et cela se produit encore périodiquement sur des nœuds aléatoires qui sont soit A) proches des limites de mémoire, soit B) en manque de processeur (soit en raison d'un problème kswapd0 qui pourrait encore être lié à la mémoire, soit en charge réelle)

Les problèmes disparaissent après 90 jours d'inactivité.
Marquez le problème comme récent avec /remove-lifecycle stale .
Les problèmes périmés pourrissent après 30 jours d'inactivité supplémentaires et finissent par se fermer.

Si ce problème peut être résolu en toute sécurité maintenant, veuillez le faire avec /close .

Envoyez vos commentaires à sig-testing, kubernetes / test-infra et / ou fejta .
/ cycle de vie périmé

Les problèmes périmés pourrissent après 30 jours d'inactivité.
Marquez le problème comme récent avec /remove-lifecycle rotten .
Les problèmes pourris se ferment après 30 jours supplémentaires d'inactivité.

Si ce problème peut être résolu en toute sécurité maintenant, veuillez le faire avec /close .

Envoyez vos commentaires à sig-testing, kubernetes / test-infra et / ou fejta .
/ cycle de vie pourri

Les problèmes pourris se ferment après 30 jours d'inactivité.
Rouvrez le problème avec /reopen .
Marquez le problème comme récent avec /remove-lifecycle rotten .

Envoyez vos commentaires à sig-testing, kubernetes / test-infra et / ou fejta .
/Fermer

@ fejta-bot: Clôture de ce numéro.

C'est encore un problème très actif, k8s 1.15.4 et RHEL Docker 1.13.1. Tout le temps les pods restent dans Terminating mais le conteneur est déjà parti, et k8s ne peut pas se comprendre, mais nécessite une interaction humaine. Rend le script de test réel PITA.

/rouvrir
/ remove-lifecycle pourri

@tuminoid : Vous ne pouvez pas rouvrir un problème / PR à moins que vous ne l'ayez créé ou que vous ne soyez un collaborateur.

/rouvrir
/ remove-lifecycle pourri

@mikesplain : a

Idem ici: le pod est bloqué en phase de fin pendant plus de 19 minutes. Le conteneur est terminé avec succès, mais Kubernetes pense toujours qu'il doit attendre quelque chose.

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>

Pas d'événements, pas de journaux ...

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

Pouvez-vous vérifier vos journaux kubelet et voir s'il y a des messages concernant l'échec du démontage du volume ou des pods orphelins?

J'ai vu ça aussi
E1206 03: 05: 40.247161 25653 kubelet_volumes.go: 154] Pod orphelin "0406c4bf-17e3-4613-a526-34e8a6cee208" trouvé, mais les chemins de volume sont toujours présents sur le disque: il y a eu un total de 8 erreurs similaires à celle-ci. Augmentez la verbosité pour les voir.

Je l'ai vu aussi. Impossible de vérifier les journaux car kubectl se plaint qu'il ne peut pas se connecter au conteneur Docker et ne peut pas créer de nouveau pod en raison de l'existence actuelle du pod de terminaison. Plutôt ennuyeux.

Le vivre aussi et c'est plutôt ennuyeux d'avoir à confirmer si Kubernetes a correctement nettoyé les anciens pods ou non.
Espérons que cela sera bientôt résolu.

Et qu'en est-il de ce problème? At-il résolu? J'ai la même chose, mais cela ne commence pas à se produire immédiatement, mais quelque temps après le début du nœud, si vous réinitialisez le nœud, alors pendant un certain temps, tout va bien

Pourriez-vous vérifier s'il y a des finaliseurs sur le pod qui l'empêchent d'être supprimé?

Il n'y a pas de finaliseurs dans le pod émis

Pour info, j'ai résolu ce problème avec une suppression forcée en utilisant:

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

Et je pense que cela a réussi à terminer le pod. Depuis, je n'ai plus ressenti le problème. J'ai peut-être mis à jour depuis lors, il pourrait donc s'agir d'un problème de version, mais pas à 100% depuis que je n'ai pas vu le problème depuis si longtemps.

Cela m'arrive lorsqu'un pod manque de mémoire. Il ne se termine que lorsque l'utilisation de la mémoire diminue à nouveau.

Pour info, j'ai résolu ce problème avec une suppression forcée en utilisant:

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

Et je pense que cela a réussi à terminer le pod. Depuis, je n'ai plus ressenti le problème. J'ai peut-être mis à jour depuis lors, il pourrait donc s'agir d'un problème de version, mais pas à 100% depuis que je n'ai pas vu le problème depuis si longtemps.

Cela a fonctionné pour moi

kubectl delete pods <pod> --grace-period=0 --force est un correctif temporaire, je ne veux pas exécuter un correctif manuel à chaque fois qu'il y a un basculement pour l'un des pods affectés. Mes pods de gardien de zoo ne se terminent pas dans minikube et sur Azure AKS.

Mise à jour du 9 mars 2020
J'ai utilisé un hook de cycle de vie preStop pour terminer manuellement mes pods. Mes pods de gardien de zoo étaient bloqués dans un état de terminaison et ne répondaient pas à un signal de terme provenant du conteneur. J'avais essentiellement le même manifeste en cours d'exécution ailleurs et tout se termine correctement, aucune idée de la cause première.

même problème, super ennuyeux

même problème: (pods bloqués à la fin, depuis 3 jours

Pour info, j'ai résolu ce problème avec une suppression forcée en utilisant:

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

Et je pense que cela a réussi à terminer le pod. Depuis, je n'ai plus ressenti le problème. J'ai peut-être mis à jour depuis lors, il pourrait donc s'agir d'un problème de version, mais pas à 100% depuis que je n'ai pas vu le problème depuis si longtemps.

De plus, l'indicateur --force ne signifie pas nécessairement que le pod est supprimé, il n'attend tout simplement pas la confirmation (et laisse tomber la référence, à ma connaissance). Comme indiqué par l'avertissement The resource may continue to run on the cluster indefinetely .

Edit: j'étais mal informé. Voir le commentaire d'elrok123s ci-dessous pour plus de motivation.

Pour info, j'ai résolu ce problème avec une suppression forcée en utilisant:

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

Et je pense que cela a réussi à terminer le pod. Depuis, je n'ai plus ressenti le problème. J'ai peut-être mis à jour depuis lors, il pourrait donc s'agir d'un problème de version, mais pas à 100% depuis que je n'ai pas vu le problème depuis si longtemps.

De plus, l'indicateur --force ne signifie pas nécessairement que le pod est supprimé, il n'attend tout simplement pas la confirmation (et laisse tomber la référence, à ma connaissance). Comme indiqué par l'avertissement The resource may continue to run on the cluster indefinetely .

Correct, mais le fait est que --grace-period=0 force la suppression :) je ne sais pas pourquoi votre commentaire est pertinent: /

Je pense que son commentaire est pertinent car le conteneur sous-jacent
(docker ou autre) est peut-être toujours en cours d'exécution et n'est pas entièrement supprimé .., Le
l'illusion de "supprimé" est parfois un peu trompeuse

Le jeu.4 juin 2020 à 09:16, Conner Stephen McCabe <
[email protected]> a écrit:

Pour info, j'ai résolu ce problème avec une suppression forcée en utilisant:

kubectl supprimer des pods--grace-period = 0 --force

Et je pense que cela a réussi à terminer le pod. Depuis, je
n'ont pas rencontré à nouveau le problème. J'ai peut-être mis à jour depuis,
cela pourrait donc être un problème de version, mais pas à 100% car il y a si longtemps
J'ai vu le problème.

De plus, l'indicateur --force ne signifie pas nécessairement que le pod est supprimé, il
n'attend tout simplement pas la confirmation (et laisse tomber la référence, à mon
compréhension). Comme indiqué par l'avertissement La ressource peut continuer à s'exécuter
sur le cluster indéfiniment.

Correct, mais le fait est que --grace-period = 0 force la suppression à
arriver :) je ne sais pas pourquoi votre commentaire est pertinent: /

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/kubernetes/kubernetes/issues/51835#issuecomment-638840136 ,
ou se désinscrire
https://github.com/notifications/unsubscribe-auth/AAH34CDZF7EJRLAQD7OSH2DRU6NCRANCNFSM4DZKZ5VQ
.

C'est en effet mon point; l'utilisation de cette méthode --force risque de laisser la charge sous-jacente alourdir vos nœuds et ne résout pas nécessairement le problème d'origine. Dans le pire des cas, c'est un "Si je ne peux pas le voir, il n'existe pas" -fixe qui peut finir par être encore plus difficile à détecter.

Ou dites-vous que --grace-period=0 est garanti pour forcer la suppression du conteneur sous-jacent, @ elrok123?
Si tel est le cas, mon commentaire est basé sur des connaissances erronées et n'est pas pertinent, mais si le risque de laisser des conteneurs en cours d'exécution persiste lors de l'utilisation de --grace-period=0 , mon point de vue l'est également.

@oscarlofwenhamn Autant que je sache, cela exécute efficacement sigkill sur tous les processus de ce pod, garantissant la suppression des processus zombie (source: Point 6 sous `` Termination of Pods '' - https://kubernetes.io/docs/concepts / workloads / pods / pod / # : ~: text = Lorsque% 20the% 20grace% 20period% 20 expire, période% 200% 20 (suppression immédiate de% 20).), et suppression réussie du pod (peut ne pas se produire immédiatement, mais cela se produira se produire.)

Le guide mentionne qu'il supprime la référence, mais ne supprime pas le pod lui-même (source: 'Forcer la suppression' - https://kubernetes.io/docs/tasks/run-application/force-delete-stateful-set-pod/ ), mais la période de grâce = 0 devrait effectivement tuer votre pod, mais pas immédiatement.

Je lis juste la documentation et les méthodes recommandées pour gérer le scénario que j'ai rencontré. Le problème que j'ai spécifiquement rencontré n'était pas un problème récurrent, et quelque chose qui s'est produit une fois; Je pense que le VRAI correctif pour cela est de corriger votre déploiement, mais jusqu'à ce que vous y arriviez, cette méthode devrait vous aider.

@ elrok123 Brillant - J'étais en effet mal informé. J'ai mis à jour ma réponse ci-dessus, en faisant référence à cette explication. Merci pour la réponse détaillée et une autre méthode motivée pour traiter les pods gênants. À votre santé!

ont actuellement des pods bloqués pendant plus de 2 jours dans l'état de terminaison.

Pour moi, l'espace de noms est bloqué dans Terminating . Aucun pod n'est répertorié. Pas de services ... rien. L'espace de noms est vide. Toujours ... coincé dans Terminating.

@JoseFMP utilise kubectl pour demander le yaml à partir de l'espace de noms, il peut avoir des finaliseurs qui retardent le processus.

@JordyBottelier Merci.

Aucun finaliseur. Toujours bloqué Terminating

@JoseFMP voici un script pour le tuer complètement (efficacement le nucléaire), enregistrez-le simplement et exécutez ./script_name:
''

! / bin / bash

set -eo pipefail

die () {echo "$ *" 1> & 2; sortie 1; }

avoir besoin() {
dont "$ 1" &> / dev / null || die "Le binaire '$ 1' est manquant mais obligatoire"
}

vérification des pré-demandes

besoin de "jq"
besoin de "curl"
besoin de "kubectl"

PROJET = "1 $"
décalage

test -n "$ PROJET" || die "Arguments manquants: kill-ns"

proxy kubectl &> / dev / null &
PROXY_PID = $!
killproxy () {
tuer $ PROXY_PID
}
piège killproxy EXIT

sleep 1 # donne au proxy une seconde

kubectl récupère l'espace de noms "$ 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 "Espace de noms tué: $ PROJECT" `` `

J'ai aussi apparemment rencontré cela, avec plusieurs pods bloqués dans la terminaison, y compris un pod qui n'est plus visible nulle part dans mon infrastructure mais qui fonctionne toujours comme un fantôme (il sert les demandes et je peux voir les demandes traitées même avec une échelle de déploiement de zéro).

Je n'ai aucune visibilité ni contrôle sur ce pod et me demande comment je suis censé résoudre une situation comme celle-ci sans fermer tous les nœuds de force?

J'ai aussi apparemment rencontré cela, avec plusieurs pods bloqués dans la terminaison, y compris un pod qui n'est plus visible nulle part dans mon infrastructure mais qui fonctionne toujours comme un fantôme (il sert les demandes et je peux voir les demandes traitées même avec une échelle de déploiement de zéro).

Je n'ai aucune visibilité ni contrôle sur ce pod et me demande comment je suis censé résoudre une situation comme celle-ci sans fermer tous les nœuds de force?

vous devrez accéder au docker sur le nœud.
Vous pouvez utiliser mon dink (https://github.com/Agilicus/dink) qui affichera un pod avec un shell avec un accès docker, ou ssh vers le pod.
docker ps -a
docker stop ####

bonne chance.

Merci pour la direction.

J'ai finalement réussi à résoudre ce problème, mais je suis toujours un peu perplexe sur la façon dont cela pourrait arriver (pour moi, le pod était complètement invisible). Comme c'était en production, les choses étaient un peu mouvementées et je n'ai pas pu effectuer de diagnostics, mais si cela se reproduit, j'espère que je pourrai faire un meilleur rapport de bogue.

Voyant un symptôme similaire, les pods sont bloqués en fin (il est intéressant de noter qu'ils ont tous une sonde de type exec pour la préparation / la vivacité). En regardant les journaux, je peux voir: kubelet [1445]: I1022 10: 26: 32.203865 1445 prober.go: 124] Sonde de préparation pour "test-service-74c4664d8d-58c96_default (822c3c3d-082a-4dc9-943c-19f04544713e): test -service "a échoué (échec): l'exécution de l'exécution OCI a échoué: échec de l'exécution: impossible d'exécuter un conteneur qui s'est arrêté: inconnu. Ce message se répète pour toujours et changer la sonde exec en tcpSocket semble permettre au pod de se terminer (basé sur un test, suivra). Le pod semble avoir l'un des conteneurs "Running" mais pas "Ready", les journaux du conteneur "Running" s'affichent comme si le service s'était arrêté.

Cela se produit sur containerd 1.4.0 lorsque la charge du nœud est élevée et que vm.max_map_count est défini sur une valeur plus élevée que la valeur par défaut, le containerd-shim ne vide pas le fifo stdout et bloque en attendant qu'il soit drainé, tandis que dockerd ne parvient pas à atteindre le événement / acquitter de containerd que les processus ont disparu

@discanto merci d'avoir partagé cette information. Le problème est-il résolu ou suivi?

@ Random-Liu

Le bug a ouvert plus de 3 ans. Les pods bloqués à la fin peuvent être causés par diverses raisons. Lorsque vous signalez votre cas, il serait très utile de publier certains des journaux de kubelet pour voir si les pods sont bloqués.