@ kubernetes / sig-aws @ kubernetes / sig-планирование

Обычно очистка тома и сети требует больше времени на завершение. Сможете ли вы найти, в какой фазе застряла ваша капсула? Например, очистка тома?

Обычно очистка тома и сети требует больше времени на завершение.

Верный. Они всегда подозрительны.

@igorleao Вы также можете попробовать kubectl delete pod xxx --now .

Привет, @resouer и @dixudx
Я не уверен. Просматривая журналы kubelet для другого модуля с той же проблемой, я обнаружил:

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.

Как видите, в этом кластере есть Calico для CNI.
Мое внимание привлекают следующие строки:

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 

Есть ли лучший способ узнать, в какой фазе застрял контейнер?

kubectl delete pod xxx --now кажется, работает очень хорошо, но я действительно хочу выяснить его первопричину и избежать человеческого взаимодействия.

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

Похоже, kubelet/mount не удалось смонтировать configmap как том из-за такого переименования файла.

@igorleao Это воспроизводимо? Или это просто не так стабильно, случается время от времени. Я и раньше встречал подобные ошибки, на всякий случай.

@dixudx это происходит несколько раз в день для определенного кластера. Другие кластеры, созданные с той же версией копсов и кубернетов на той же неделе, работают нормально.

@igorleao Как видно из журнала, диспетчеру томов не удалось удалить секретный каталог, потому что устройство занято.
Не могли бы вы проверить, смонтирован ли каталог /var/lib/kubelet/pods/GUID/volumes/kubernetes.io~secret/token-key или нет? Благодаря!

@igorleao как запустить кубелет? в контейнере? если да, не могли бы вы опубликовать конфигурацию вашего модуля systemd или докера для kubelet?

Мы видим подобное поведение. Мы запускаем kubelet как контейнер, и проблема была частично решена путем монтирования /var/lib/kubelet как общего (по умолчанию докер монтирует том как rslave). Но все же мы видим похожие проблемы, но реже. В настоящее время я подозреваю, что некоторые другие крепления должны выполняться другим способом (например, /var/lib/docker или /rootfs )

@stormltf Не могли бы вы опубликовать конфигурацию контейнера kubelet?

@stormltf вы запускаете kubelet в контейнере и не используете флаг --containerized (который делает некоторые трюки с монтировками ). Это в основном означает, что все монтирования, которые выполняет kubelet, будут выполняться в пространстве имен монтирования контейнера. Хорошо, что они будут предложены обратно в пространство имен хост-машины (поскольку у вас есть / var / lib / kubelet как общий), но я не уверен, что происходит, когда пространство имен удаляется (когда контейнер kubelet удален).

Не могли бы вы сделать следующее:

на узле, где работает под

• docker exec -ti /kubelet /bin/bash -c "mount | grep STUCK_POD_UUID"
• и то же самое на самом узле mount | grep STUCK_POD_UUID .

Сделайте то же самое для только что созданного модуля. Я ожидаю увидеть несколько /var/lib/kubelet mounts (например, default-secret)

@stormltf , вы перезапускали kubelet после создания первых двух подов?

@stormltf Вы можете попробовать сделать точки /var/lib/docker и /rootfs общими (чего я не вижу в вашем docker inspect, но вижу внутри контейнера).

/ sig хранилище

Кому-то это может помочь. Мы запускаем kubelet в контейнере докеров с флагом --containerized и смогли решить эту проблему, установив /rootfs , /var/lib/docker и /var/lib/kubelet как общие средства монтирования. Окончательные крепления выглядят так

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

Для более подробной информации. Это не решает проблему должным образом, так как за каждое крепление привязки вы получите 3 крепления внутри контейнера кубелета (2 паразита). Но, по крайней мере, общее крепление позволяет легко их демонтировать одним выстрелом.

В CoreOS такой проблемы нет. Потому что использование rkt, а не docker для контейнера kubelet. В случае, если в нашем случае kubelet работает в Docker и каждое монтирование внутри kubelet continer предлагается в /var/lib/docker/overlay/... и /rootfs , поэтому у нас есть два монтирования паразитов для каждого тома монтирования привязки:

• один из /rootfs в /rootfs/var/lib/kubelet/<mount>
• один из /var/lib/docker в /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

У меня такая же проблема с Kubernetes 1.8.1 в Azure - после изменения развертывания и запуска новых модулей старые модули застревают при завершении.

У меня такая же проблема с Kubernetes 1.8.2 в IBM Cloud. После запуска новых модулей старые модули останавливаются при завершении работы.

версия 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"}

Я использовал kubectl delete pod xxx --now а также kubectl delete pod foo --grace-period=0 --force безрезультатно.

Если основная причина все та же (неправильно предложенные крепления), то это ошибка, специфичная для дистрибутива.

Опишите, пожалуйста, как вы запускаете kubelet run в облаке IBM? системный блок? есть ли у него флаг --containerized ?

он запускается с флагом --containerized, установленным в значение 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

--containerized flag: Нет

хорошо, мне нужна дополнительная информация, см. мой комментарий выше https://github.com/kubernetes/kubernetes/issues/51835#issuecomment -333090349

а также, пожалуйста, покажите содержимое /lib/systemd/system/kubelet.service и, если есть что-нибудь о kubelet в /etc/systemd/system поделитесь тоже.

В частности, если kubelet работает в докере, я хочу увидеть все привязки -v .

Сегодня я столкнулся с проблемой, которая может быть такой же, как описанная, когда у нас были модули в одной из наших клиентских систем, которые зависали в состоянии завершения на несколько дней. Мы также наблюдали ошибки типа «Ошибка: сбой UnmountVolume.TearDown для тома», когда «устройство или ресурс занят» повторялись для каждого из застрявших модулей.

В нашем случае, похоже, проблема с докером в системах на базе RHEL / Centos 7.4, охваченных этой проблемой moby: https://github.com/moby/moby/issues/22260 и этим PR moby: https: // github .com / moby / moby / pull / 34886 / файлы

Для нас, как только мы установим параметр sysctl fs.may_detach_mounts = 1, в течение пары минут все наши конечные модули будут очищены.

Я также сталкиваюсь с этой проблемой: модули застряли в состоянии завершения на 1.8.3.

Соответствующие логи кублета с узла:

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 работает как модуль systemd (не в контейнере) в Ubuntu 16.04.
Как видите, произошло монтирование к серверу NFS, и каким-то образом kubelet попытался удалить каталог монтирования, потому что он считает этот каталог несмонтированным.

Объемы спецификации из капсулы:

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

UPD : Я сталкивался с этой проблемой и раньше на 1.6.6

То же самое в 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

версия 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"}

описать под 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"}

кот /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

Похоже, есть другая ошибка, связанная с проблемой. У нас есть оба в нашем кластере 1.8.3.

1. https://github.com/moby/moby/issues/31768 . Это ошибка докера. Воспроизводится на docker-ce = 17.09.0 ~ ce-0 ~ ubuntu.
2. Второе более интересно и, возможно, связано с каким-то состоянием гонки внутри kubelet.
   У нас есть много модулей, которые использовали постоянный том NFS с указанным подпутьем при монтировании контейнеров, так или иначе некоторые из них застревают в состоянии завершения после удаления развертываний. И в системном журнале много сообщений:

 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

И это правда, что каталог не пустой, он размонтирован и содержит наш каталог "subpath"!
Одно из объяснений такого поведения:

1. P1: начать создание модуля или модуля синхронизации
2. P1: послать сигнал диспетчеру томов для выполнения монтирования / повторного монтирования.
3. P1: Ожидает завершения монтирования.
4. P1: получить сигнал успешного монтирования (на самом деле просто проверьте, что все тома смонтированы)
5. Как-то громкость размонтирована. Это может быть другой процесс удаления, размонтировать его, или какая-то ошибка ОС, или какое-то действие сборщика мусора.
6. P1: Продолжить создание контейнера и создать подкаталог в точке монтирования (уже отключен).
7. В конце концов, предыдущий шаговый модуль нельзя удалить, потому что каталог монтирования не пуст.

Еще журналы:

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

Каким-то образом какой-то процесс очистки ((dswp * desireStateOfWorldPopulator) findAndRemoveDeletedPods ()) запускает размонтирование томов, пока модуль находится в состоянии инициализации:

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"

Инициализация и удаление модуля выполняются одновременно.
Чтобы повторить с ошибкой, вы должны запустить и немедленно удалить / обновить около 10 развертываний (проверено для одного миньона) и, возможно, ваша операция монтирования должна быть не очень быстрой.

Затронуто той же ошибкой на GKE. Есть ли какие-либо известные обходные пути для этой проблемы? Использование --now не работает.

У меня есть исправление для этой ошибки, но я не уверен, что она будет объединена командой kubernetes.

@dreyk Не могли бы вы предоставить более подробную информацию о том, что вы обнаружили для этой ошибки, и что вы исправили, чтобы команда хранилища могла посмотреть? Благодаря!

@ gm42 Мне удалось вручную обойти эту проблему в GKE:

1. SSH в узел, на котором был запланирован застрявший модуль
2. Запуск docker ps | grep {pod name} для получения идентификатора контейнера Docker
3. Запуск docker rm -f {container id}

На GKE обновление узлов помогло мгновенно.

У меня такая же ошибка в моем локальном кластере, настроенном с использованием kubeadm .

docker ps | grep {pod name} на узле ничего не показывает, и модуль застрял в состоянии завершения. Сейчас у меня в этом состоянии две капсулы.

Что я могу сделать, чтобы удалить пакет принудительно? А может, поменять название пода? Я не могу запустить еще одну капсулу с тем же именем. Благодаря!

Я нашел причину в своем кластере 1.7.2,
потому что другая программа монитора монтирует корневой путь /
корневой путь содержит /var/lib/kubelet/pods/ddc66e10-0711-11e8-b905-6c92bf70b164/volumes/kubernetes.io~secret/default-token-bnttf
поэтому, когда kubelet удаляет pod, но он не может освободить том, сообщение:
устройство или ресурс занят

шаги:
1) sudo journalctl -u kubelet
эта оболочка помогает мне найти сообщение об ошибке,
2) sudo docker inspect
найдите io.kubernetes.pod.uid ":" ddc66e10-0711-11e8-b905-6c92bf70b164 "
и
HostConfig -> Привязки -> "/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
корень 90225 1,3 0,0 2837164 42580? SSL 01 фев 72:40 ./monitor_program

У меня такая же ошибка на 1.7.2

operationExecutor.UnmountVolume запущен для тома «default-token-bnttf» (Уникальное имя: «kubernetes.io/secret/ddc66e10-0711-11e8-b905-6c92bf70b164-default-token-bnttf») pod «ddc66e10-079011-e8 6c92bf70b164 "kubelet [94382]: E0205 11: 35: 50.509169 94382 nestedpendingoperations.go: 262] Операция для" \ "kubernetes.io/secret/ddc66e10-0711-11e8-b905-6c92bf70b164-default-ftoken-bnt (\t "ddc66e10-0711-11e8-b905-6c92bf70b164 \") "не удалось. Повторные попытки не допускаются до 2018-02-05 11:37: 52.509148953 +0800 CST (durationBeforeRetry 2m2s). Ошибка: сбой UnmountVolume.TearDown для тома «default-token-bnttf» (Уникальное имя: «kubernetes.io/secret/ddc66e10-0711-11e8-b905-6c92bf70b164-default-token-bnttf») pod «ddc66e10-0711-11e8 b905-6c92bf70b164 "(UID:" ddc66e10-0711-11e8-b905-6c92bf70b164 "): удалить /var/lib/kubelet/pods/ddc66e10-0711-11e8-b905-6c92bf70b164/volumes/kubbernetes.io~~ token-bnttf: устройство или ресурс занят

Перезапуск службы докеров снимает блокировку, и модули удаляются в течение нескольких минут. Это ошибка. Использование докера 17.03

Та же проблема здесь, в Azure, Kube 1.8.7

Это случилось с нами несколько минут назад на 1.8.9 - кто-нибудь ищет решение этой проблемы? Перезапуск докера помогает, но немного смешно.

Это часто происходило со мной в последней версии 1.9.4 на GKE. Сделал это сейчас:

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

Такая же проблема здесь на GKE 1.9.4-gke.1
похоже, связано с креплением тома.
Это происходит каждый раз, когда filebeats настроен, как описано здесь:
https://github.com/elastic/beats/tree/master/deploy/kubernetes/filebeat

Журнал Kubelet показывает это:

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
вроде работает.
также перезапуск кубелет работает.

Такая же проблема здесь на GKE 1.9.4-gke.1
Это происходит только с определенным демоном filebeat, но воссоздание всех узлов тоже не помогает, это просто продолжается.

Также эта проблема возникает в GKE 1.9.4-gke.1, например @Tapppi - 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

Для нас только что произошло что-то новое, когда я принудительно удалил застрявший модуль с помощью kubectl delete pod NAME --grace-period=0 --force , узел, на котором находился этот модуль, просто перешел в неработоспособное состояние. Мы запускаем docker 17-12CE, и перезапуск docker deamon на этом ящике помог и откупорил узел.

Для людей, которые видят эту проблему в 1.9.4-gke.1, скорее всего, это связано с https://github.com/kubernetes/kubernetes/issues/61178 , который исправлен в версии 1.9.5 и развертывается в GKE. эта неделя. Проблема связана с очисткой подключений подкаталога файла (не каталога). @zackify @ nodefactory-bk @Tapppi @Stono

IIUC, исходная проблема в этой ошибке связана с конфигурацией контейнерного кублета, который отличается.

Кстати, создание нового пула узлов с версией v1.9.3-gke.0 было нашим обходным путем для этого, поскольку v1.9.5 все еще не развернут на gke, и уже наступила пасха.

Может кто-нибудь подтвердить, что это исправлено в версии 1.9.3+, пожалуйста? У нас есть серьезные проблемы из-за этого поведения, и перезапуск докера каждый раз, когда это происходит, soo st00pid.

Исправлено на 1.9.6 для меня

В среду, 4 апреля 2018 г., 11:43, sokoow, [email protected] написал:

Может кто-нибудь подтвердить, что это исправлено в версии 1.9.3+, пожалуйста? У нас есть
некоторые серьезные проблемы из-за этого поведения и перезапуск докера каждый
время, когда это происходит, так просто.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/kubernetes/kubernetes/issues/51835#issuecomment-378557636 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/ABaviW5yfj64zVjBYFGUToe2MH3dKwpTks5tlKPNgaJpZM4PKs9r
.

Хорошо, спасибо @Stono . Еще одна вещь, которую нужно подтвердить здесь. Вот наш шаблон kubespray для контейнерного кублета:

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

Выглядит нормально? Кто-нибудь еще использует подобное?

Я заговорил слишком рано.

  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

Пришлось уничтожить его самым жестоким образом.

❯ 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, какую версию докера вы используете? для нас с docker 17.12CE удаление пода с помощью --force --grace-period 0 довольно радикально - это почти всегда заканчивается тем, что узел недоступен из-за зависания докера

У меня все еще возникает эта проблема в 1.9.6 в управляемом кластере Azure AKS.

Используя этот обходной путь в настоящий момент, чтобы выбрать все застрявшие модули и удалить их (так как у меня в моем кластере разработки / царапин появляются образцы завершающих модулей):

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

столкнулся с этим на майских кластерах Azure и AWS - обходное решение было предоставлено Майком Эллиотом.

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

ubuntu @ ip-10-0-0-22 : ~ $ kubectl получить pods --all-namespaces
NAMESPACE ИМЯ СОСТОЯНИЕ ГОТОВНОСТЬ ВОЗВРАЩАЕТСЯ ВОЗРАСТ
kube-system heapster-76b8cd7b5-4r88h 1/1 Выполняется 0 25d
kube-system kube-dns-5d7b4487c9-s4rsg 3/3 Запуск 0 25d
kube-system kubernetes-dashboard-f9577fffd-298r6 1/1 работает 0 25d
kube-system monitoring-grafana-997796fcf-wtz7n 1/1 Выполняется 0 25d
kube-system monitoring-infxdb-56fdcd96b-2phd2 1/1 Выполняется 0 25d
kube-system tiller-deploy-cc96d4f6b-jzqmz 1/1 Запуск 0 25d
onap dev-sms-857f6dbd87-pds58 0/1 Завершение 0 3 часа
onap dev-vfc-zte-sdnc-driver-5b6c7cbd6b-5vdvp 0/1 Завершение 0 3h
ubuntu @ ip-10-0-0-22 : ~ $ kubectl delete pod dev-vfc-zte-sdnc-driver-5b6c7cbd6b-5vdvp -n onap --grace-period = 0 --force
предупреждение: немедленное удаление не дожидается подтверждения того, что работающий ресурс был прекращен. Ресурс может продолжать работать в кластере бесконечно.
Под "dev-vfc-zte-sdnc-driver-5b6c7cbd6b-5vdvp" удален
ubuntu @ ip-10-0-0-22 : ~ $ kubectl получить pods --all-namespaces
NAMESPACE ИМЯ ГОТОВНОСТЬ СТАТУС ВОЗРАСТ
kube-system heapster-76b8cd7b5-4r88h 1/1 Выполняется 0 25d
kube-system kube-dns-5d7b4487c9-s4rsg 3/3 Запуск 0 25d
kube-system kubernetes-dashboard-f9577fffd-298r6 1/1 работает 0 25d
kube-system monitoring-grafana-997796fcf-wtz7n 1/1 Выполняется 0 25d
kube-system monitoring-infxdb-56fdcd96b-2phd2 1/1 Выполняется 0 25d
kube-system tiller-deploy-cc96d4f6b-jzqmz 1/1 Запуск 0 25d
onap dev-sms-857f6dbd87-pds58 0/1 Завершение 0 3 часа
ubuntu @ ip-10-0-0-22 : ~ $ kubectl удалить pod dev-sms-857f6dbd87-pds58 -n onap --grace-period = 0 --force
предупреждение: немедленное удаление не дожидается подтверждения того, что работающий ресурс был прекращен. Ресурс может продолжать работать в кластере бесконечно.
Под "dev-sms-857f6dbd87-pds58" удален
ubuntu @ ip-10-0-0-22 : ~ $ kubectl получить pods --all-namespaces
NAMESPACE ИМЯ ГОТОВНОСТЬ СТАТУС ВОЗРАСТ
kube-system heapster-76b8cd7b5-4r88h 1/1 Выполняется 0 25d
kube-system kube-dns-5d7b4487c9-s4rsg 3/3 Запуск 0 25d
kube-system kubernetes-dashboard-f9577fffd-298r6 1/1 работает 0 25d
kube-system monitoring-grafana-997796fcf-wtz7n 1/1 Выполняется 0 25d
kube-system monitoring-infxdb-56fdcd96b-2phd2 1/1 Выполняется 0 25d
kube-system tiller-deploy-cc96d4f6b-jzqmz 1/1 Запуск 0 25d

Я не уверен, что это та же проблема, но мы начали замечать такое поведение _ с тех пор, как обновлялись с 1.9.3 до 10.10.1. Раньше этого не было. Мы используем тома glusterfs с SubPath. Kubelet постоянно регистрирует такие вещи, как

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"

а lsof действительно показывает, что каталог под томами glusterfs все еще используется:

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

В 1.9.3 все было хорошо, так что исправление этой проблемы как будто нарушило наш вариант использования :(

@ ross-w эта подпись отличается от других. Не могли бы вы открыть новый выпуск, а также указать свою спецификацию модуля?

Есть новости по этим вопросам?
В нашем случае (Kubernetes 1.9.7, docker 17.03) поды находятся в состоянии Завершение после того, как узел выходит из памяти и поды переносятся. В конце концов, на панели инструментов kubernetes и на вкладке развертывания мы можем увидеть развертывания с модулями 4/1.
Перезапуск kubelet или уничтожение всех подов в пространстве имен помогает, но это очень плохое решение.

@Adiqq Потому что проблема была в

Посмотрите на journalctl -u kubelet -f на одном из ваших узлов. У меня было сообщение типа «Невозможно убить контейнер.gRpc error »(с тех пор, как я исправил это, настоящего сообщения у меня нет).

Чтобы исправить это, я перезапускал докер для каждой заметки. Во время загрузки Docker очистите контейнеры в сломанном состоянии и удалите все эти устаревшие поды.

У меня было это вчера в 1.9.7, с модулем, застрявшим в состоянии завершения, и в журналах было просто «нужно убить модуль», мне пришлось --force --grace-period=0 чтобы избавиться.

Только что получил это с 1.9.7-gke.0.
Проблем с 1.9.6-гке.1 не было.
Но было это с 1.9.4 и 1.9.5

К застрявшему стручку прикреплен PV.

Повторное развертывание или удаление модуля имеет тот же эффект.
Не удалось перезапустить kubelet на проблемном узле. kubelet не запускался снова, и мне пришлось перезапустить весь узел.

При этом модуль нельзя было запланировать ни на каком другом узле, поскольку он сказал, что PV уже смонтирован где-то еще.

@Stono @ nodefactory-bk, ребята, не могли бы вы взглянуть на свои журналы kubelet на проблемных узлах, чтобы узнать, есть ли какие-либо подробные журналы, которые могут указывать на проблему?

cc @dashpole

Просто одно приложение зависло при завершении работы.
Это на 1.9.7-гке.1
Вот kubectl description pod с отредактированными секретами:

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

Не знаю, где найти kubelet.log в gke on googles images. Нашел то, что прикрепляю.
kube.log

kubectl -n shsp-cloud-dev delete pod sharespine-cloud-6b78cbfb8d-xcbh5 --force --grace-period 0
убил его и удалил.
Потом все началось нормально, но заняло немного больше времени, чем обычно.

Имейте в виду, что с этим приложением это случается не КАЖДЫЙ раз.
Я бы сказал примерно в 1/4 раза, наверное.

В случае с k8s 1.9.6, когда kubelet не может размонтировать монтирование Cephfs, все поды на узле остаются закрытыми навсегда. Пришлось перезапустить узел для восстановления, перезапуск кубелета или докера не помог.

@tuminoid проблема ceph звучит иначе. Не могли бы вы открыть новый выпуск, а также предоставить события модуля и журналы кубелета для этого модуля?

К вашему сведению, обновление моих кластеров (до k8s v1.10.2), похоже, устранило эту проблему для нас.

Прилагаемый воспроизводит это для меня на 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

запустите его, затем удалите. Вы получите "nfs-client" при удалении. Причина в жестком монтировании узла и удалении «сервера» в первую очередь.

@donbowman для проблемы размонтирования nfs, когда вы сначала удаляете сервер nfs, вы можете установить опцию «мягкого» монтирования в StorageClass или PV.

Я не понимаю как? Я могу установить его на PersistentVolumeClaim, но здесь это не применяется.
Я не думаю, что здесь применяется StorageClass (это будет нижний диск под сервером nfs).

Проблема связана с nfs-клиентом.
я что-то упускаю?

Для вашего nfs PV вы можете установить поле mountOptions, начиная с версии 1.8, чтобы указать мягкое монтирование. Если вы динамически подготавливаете тома nfs, вы также можете установить его в своем StorageClass.mountOptions

да, но это не PV, который монтируется с NFS.
Это из моего контейнера NFS-сервера.
Нет динамической подготовки.

Это использует Google GCP + GKE. PVC выбирает PV, который является блочным вводом-выводом, установленным как ext4 в контейнер, который реэкспортирует его с помощью NFS.

Второй набор контейнеров, который монтируется с nfs-сервера (который сам по себе является подом), они не видят в нем как PV. Они видят в нем объем, как показано ниже.

Я не вижу способа заставить этот nfs-клиент видеть «pvc» для монтирования, поэтому я не могу установить параметры монтирования. Я также не могу рассматривать его как StorageClass.

Я что-то упускаю?

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 для вашего 2-го набора контейнеров, который использует монтирование nfs, вы можете вручную создать PV для этого тома nfs с установленным mountOptions и совместно использовать PVC для этого PV nfs во всех ваших подах. Никакой динамической подготовки.

Что-то вроде этого:

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

Благодаря! Итак, это сработало (в том смысле, что теперь это мягкое крепление), но не решило проблему:

Крепление (как видно на узле) теперь мягкое:

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)

Но когда я удаляю все это, nfs-клиент все равно навсегда застревает в состоянии завершения.

k8s-nfs-test.yaml.txt

прилагается ямл, который я использовал. Я сделал «создание», дождался его появления, заметил, что у клиента есть монтирование, он может читать / записывать в нем файлы, а затем произвел «удаление».

Модуль nfs-server удален, а nfs-client - нет.

Если посмотреть на капсулу, то крепление осталось:

# 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 ах, извини, я ошибся насчет мягкого варианта. Программный параметр предотвращает зависание вызовов файловой системы только тогда, когда сервер недоступен, но на самом деле не помогает размонтировать том nfs. Для этого потребуется принудительное размонтирование, через которое у нас в настоящее время нет возможности пройти. На данный момент вам придется вручную очистить эти крепления и убедиться, что вы удаляете свои модули в правильном порядке (сначала клиенты nfs, затем сервер nfs).

Я попытался добавить timeo = 30 и intr, но та же проблема.
это блокирует его, необходимо войти в узел и выполнить команду umount -f -l для основного монтирования, а затем выполнить команду kubectl delete --force --grace-period 0 для модуля.

похоже, что, поскольку это было смонтировано от имени модуля, его можно было отключить (или принудительно отключить по истечении некоторого времени ожидания) при автоматическом удалении.

У меня была куча таких подов, поэтому мне пришлось придумать команду, которая очистила бы все завершающие поды:

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

Я думаю, что с новым файловым хранилищем Google у нас будет такая же проблема, без umount.

@donbowman iirc, ваша проблема в том, что вы завершали работу модуля сервера nfs до модуля клиента nfs. Если вы используете файловое хранилище, вам больше не нужен модуль для размещения вашего сервера nfs, поэтому у вас не должно возникнуть этой проблемы, пока вы не удалите весь isntance firestore.

Разве у меня не будет такой же проблемы, если я буду организовывать хранилище файлов? например, если я поднимаю его для конкретного развертывания кубернетов, а затем в конце, порядок не гарантируется.

Но также я думаю, что проблема не только в порядке, удаление клиентского модуля nfs не размонтируется вообще, оно просто оставляет монтирование висящим на узле. Итак, независимо от того, присутствует ли файловое хранилище / сервер или нет, есть болтающееся монтирование.

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

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

Возможно, это обходной путь: # 65936

Принудительное удаление сработало для kubectl delete po $pod --grace-period=0 --force . Флаг --now не работал. Я не уверен насчет # 65936, но я бы не хотел убивать узел при возникновении состояний Unknown .

Возникла та же проблема (модули продолжают завершать работу, потому что файл внутри модуля не может быть отключен, потому что устройство «занято») 1.10.5. Для меня использование --grace-period=0 --force приведет к тому, что точка монтирования продолжит существовать. В конце концов у меня было более 90000 точек монтирования, что сильно замедлило работу кластера. Обходной путь здесь - найти в папке модуля и рекурсивно отключить эти файлы, а затем рекурсивно удалить папку модуля.
В моем случае я монтирую конфигурационную карту, используя подпуть, в существующую папку с существующими файлами, перезаписывая один из существующих файлов. Раньше у меня это нормально работало на 1.8.6.
В исходном плакате упоминается, что капсулы остаются в «прекращении» в течение нескольких часов, в моем случае это дни. Я не видел, чтобы их убирали в конечном итоге, за исключением тех случаев, когда я выполнял обходной путь вручную.

Имея ту же проблему, вызванную агрегатором журналов (похожим на fluentd), он монтирует папку /var/lib/docker/containers а pod имеет много монтирований:

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

В моем случае некоторые поды могут быть хорошо удалены кубернетами, но некоторые застряли в статусе "завершение".

Это может быть связано с https://github.com/kubernetes/kubernetes/issues/45688 (я также использую docker 17)

У меня просто была проблема, что стручки не завершались из-за отсутствия секрета. После того, как я создал этот секрет в этом пространстве имен, все вернулось к норме.

Я удалил застрявшие стручки вот так:

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

Возникла аналогичная проблема в 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>

Я пробовал использовать --now или установить льготный период. Например

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

Модуль по-прежнему зависает, и это приводит к зависанию и соответствующего развертывания.

Меня также преследуют эти сообщения «Нужно убить под» в событиях с подом. Кстати, что это значит? Что _Kubernetes_ чувствует необходимость убить капсулу, или что _I_ должен убить капсулу?

это случилось со мной пару дней назад, и я отказался от удаления и оставил модуль как есть. А сегодня он исчез и, кажется, в конечном итоге будет удален.

Это случилось со мной только что. Решение --force --now не сработало для меня. Я нашел следующую строку в журналах kubelet подозрительной

6 августа 15:25:37 kube-minion-1 kubelet [2778]: W0806 15: 25: 37.986549 2778 docker_sandbox.go: 263] NetworkPlugin cni не удалось обработать обработчик состояния для модуля «backend-foos-227474871-gzhw0_default»: неожиданно вывод команды nsenter: невозможно открыть: нет такого файла или каталога

Это привело меня к обнаружению следующей проблемы:
https://github.com/openshift/origin/issues/15802

Я не на openshift, а на Openstack, поэтому подумал, что это может быть связано. Я посоветовал перезапустить докер.
Перезапуск докера заставил модули, застрявшие в "Завершении", исчезнуть.

Я знаю, что это всего лишь обходной путь, но я больше не просыпаюсь в 3 часа ночи, чтобы это исправить.
Не говорю, что вам следует использовать это, но это может помочь некоторым людям.

Сон - это то, что у меня для стручков terminationGracePeriodSeconds установлено на (30 секунд). Если он живет дольше, этот cronjob --force --grace-period = 0 и полностью его убьет

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

Я вижу ту же ошибку с Kubernetes v1.10.2. Поды застревают при завершении работы на неопределенный срок, и кубелет на соответствующем узле неоднократно регистрируется:

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"

Я могу вручную отключить указанный том подпути без жалоб (Linux не сообщает мне, что он занят). Это не позволяет кубелету регистрировать сообщение об ошибке. Однако это не вдохновляет Kubernetes на продолжение очистки, поскольку модуль все еще отображается в состоянии завершения. Регулярный перезапуск Docker для очистки этого решения не является приемлемым решением из-за нарушения работы контейнеров.

Также обратите внимание: сам контейнер ушел из docker ps -a без каких-либо доказательств того, что он когда-либо существовал, поэтому я не уверен, что это действительно проблема Docker. Мы используем Docker версии 17.03.2-ce.

Обновление: мы настроили наши узлы для перенаправления корневого каталога kubelet на том, не связанный с ОС, с помощью символической ссылки ( /var/lib/kubelet была символической ссылкой, указывающей на другой каталог на другом томе). Когда я перенастроил вещи, чтобы передать --root-dir в kubelet, чтобы он шел в нужный каталог напрямую, а не через символическую ссылку, и перезапустил kubelet, он очистил монтирования тома и очистил застрявшие поды завершение без перезапуска Docker.

Я впервые столкнулся с этой проблемой сегодня, когда запускал несколько модулей локально на minikube.

У меня была куча модулей, застрявших в Terminating из-за того, что configmap / secret смонтирован как том, который отсутствовал. Ни одно из предложений / обходных путей / решений, опубликованных выше, не сработало, кроме этого .

Я думаю, что стоит обратить внимание на следующее:

• Когда я запустил kubectl get pods , я получил список модулей со статусом Terminating .
• Однако, когда я запустил docker ps | grep -i {{pod_name}} , ни один из модулей в статусе Terminating который видел kubectl get pods не работал в виртуальной машине minikube.

Я ожидал, что docker ps вернет список модулей, застрявших в состоянии Terminating но на самом деле ни один из них не работал, но kubectl get pods возвращал данные о них? Кто-нибудь сможет объяснить, почему это так?

У меня возникла эта проблема с 4 развертываниями. Затем я переключился с «локального тома» на «путь к хосту» для всех монтировок, и он исчез для меня.

У меня просто была проблема, что стручки не завершались из-за отсутствия секрета. После того, как я создал этот секрет в этом пространстве имен, все вернулось к норме.

Как создать секрет в пространстве имен, если пространство имен находится в состоянии «Завершение»?

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

работает на меня.

Не забывайте про "--grace-period = 0". Это имеет значение

kubectl предупредил меня: «предупреждение: немедленное удаление не дожидается подтверждения того, что работающий ресурс был прекращен. Ресурс может продолжать работать в кластере бесконечно». когда я использую --force --grace-period=0 .
Может ли кто-нибудь сказать мне, действительно ли это произойдет?

на самом деле, когда мы удаляем какой-то под, удаление может задерживаться по некоторым причинам,
и если мы выполним «kubectl delete» с флагом «--force --grace-period = 0»,
объект ресурса будет немедленно удален.

Можете ли вы помочь подтвердить, будет ли модуль немедленно удален?
Означает ли это, что предупреждающее сообщение действительно неточно?

@windoze , если вы установите параметр --force --grace-period = 0, это означает, что объект API модуля будет немедленно удален с сервера API. Node kubelet отвечает за очистку монтированных томов и уничтожение контейнеров. Если kubelet не запущен или возникают проблемы при очистке модуля, возможно, контейнер все еще работает. Но Кубелет должен стараться убирать стручки, когда это возможно.

Значит, это по-прежнему означает, что удаление может длиться вечно, потому что kubelet может работать неправильно?
Есть ли способ убедиться, что модуль удален?
Я задаю этот вопрос, потому что у меня в кластере работает несколько огромных модулей, и на каждом узле не хватает памяти для запуска двух их экземпляров.
Если удаление завершилось неудачно, узел становится непригодным для использования, и если эта проблема возникает несколько раз, служба будет полностью отключена, потому что в конечном итоге не будет узла, который может запустить этот модуль.

В обычной среде докеров я могу принудительно убить модуль с помощью kill -9 или чего-то подобного, но, похоже, у k8s такой функции нет.

@windoze знаете, почему удаление вашего модуля часто не удавалось? Это потому, что kubelet не запущен, или kubelet пытался убить контейнер, но не удалось с некоторыми ошибками?

Такая ситуация случилась несколько раз на моем кластере несколько месяцев назад, kubelet работал, но демон docker, похоже, имел проблемы и зависал без журнала ошибок.
Мое решение заключалось в том, чтобы войти в систему и принудительно убить процесс контейнера и перезапустить демон докера.
После некоторых обновлений проблема исчезла, и у меня ее больше не было.

kubectl delete pods <podname> --force --grace-period=0 у меня сработало!

@ shinebayar-g, проблема с --force том, что это может означать, что ваш контейнер будет продолжать работать. Он просто говорит Kubernetes забыть о контейнерах этого пода. Лучшее решение - подключиться по SSH к виртуальной машине, на которой запущен модуль, и изучить, что происходит с Docker. Попробуйте вручную убить контейнеры с помощью docker kill и в случае успеха попробуйте снова удалить контейнер в обычном режиме.

@agolomoodysaada Ах, в этом есть смысл. Спасибо за объяснение. Так что я бы не знал, действительно ли контейнер удален или нет?

Итак, конец 2018 года, kube 1.12 отсутствует и ... у вас все еще есть проблемы с застрявшими подами?

У меня такая же проблема, либо --force --grace-period = 0, либо --force --now не работает, следующие журналы:

root @ r15-c70-b03-master01 : ~ # kubectl -n Infra-lmat получить pod node-exporter-zbfpx
ИМЯ ГОТОВ СОСТОЯНИЕ ВОЗРАСТ ВОЗРАСТ
node-exporter-zbfpx 0/1 Завершение 0 4d

root @ r15-c70-b03-master01 : ~ # kubectl -n infra-lmat delete pod node-exporter-zbfpx --grace-period = 0 --force
предупреждение: немедленное удаление не дожидается подтверждения того, что работающий ресурс был прекращен. Ресурс может продолжать работать в кластере бесконечно.
модуль "node-exporter-zbfpx" удален

root @ r15-c70-b03-master01 : ~ # kubectl -n Infra-lmat получить pod node-exporter-zbfpx
ИМЯ ГОТОВ СОСТОЯНИЕ ВОЗРАСТ ВОЗРАСТ
node-exporter-zbfpx 0/1 Завершение 0 4d

root @ r15-c70-b03-master01 : ~ # kubectl -n infra-lmat delete pod node-exporter-zbfpx --now --force
модуль "node-exporter-zbfpx" удален

root @ r15-c70-b03-master01 : ~ # kubectl -n Infra-lmat получить pod node-exporter-zbfpx
ИМЯ ГОТОВ СОСТОЯНИЕ ВОЗРАСТ ВОЗРАСТ
node-exporter-zbfpx 0/1 Завершение 0 4d

корень @ r15-c70-b03-master01 : ~ #

Я попытался отредактировать модуль и удалить раздел финализаторов в метаданных, но это тоже не удалось.

Я все еще вижу это на 100% воспроизводимым образом (те же определения ресурсов) с альфа-версией kubectl 1.13 и Docker для рабочего стола на macOS. Под воспроизводимым я подразумеваю, что единственный способ исправить это, похоже, - это сбросить настройки Docker для Mac, и когда я снова настраиваю свой кластер, используя те же ресурсы (сценарий развертывания), тот же сценарий очистки не работает.

Я не уверен, почему это может быть актуально, но мой сценарий очистки выглядит так:

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

Поскольку кластер запускается локально, я могу проверить, что в Docker нет запущенных контейнеров, это просто kubectl, который зависает на завершающих модулях. Когда я describe стручки, статус отображается как Status: Terminating (lasts <invalid>)

Просто случилось со мной еще раз. Я пытался установить percona pmm-server с общим ресурсом NFS, но программное обеспечение даже не подошло, поэтому я удалил, и это произошло. (Постоянная претензия не работает для этого программного обеспечения). Думаю, я снова звоню старому доброму kubectl delete pods <podname> --force --grace-period=0 . Но вопрос в том, как мне узнать, где живет эта капсула?

@ shinebayar-g, подключитесь по SSH к виртуальной машине и запустите docker ps .

Ну, этого не было ... У меня мало виртуальных машин, поэтому я спросил, как определить, какая из них правильная. :)

@ shinebayar-g это может сработать:
kubectl describe pod/some-pod-name | grep '^Node:'

та же проблема.

docker ps обнаружил, что контейнер находится в состоянии "мертвый", не завершен (0), как ожидалось

При удалении контейнера вручную появится следующая запись в журнале докеров:

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

К сожалению, линия прервана, но я помню, что проблема заключалась в том, что процесса больше не было.

Я все еще сталкиваюсь с этой проблемой с k8s v1.11.0. Вот контрольный список того, что я делаю для очистки своих контейнеров:

• Убедитесь, что все ресурсы, прикрепленные к модулю, возвращены. Не все они видны в kubectl get ; некоторые из них известны только Kubelet, на котором запущен модуль, поэтому вам придется отслеживать его поток журнала локально
  
  
  
  • В частности, umount каталоги, на которые Kubelet жалуется с device or resource busy сообщениями.
  
  
• Когда все остальное не помогает, kubectl edit сбойный модуль и удалите finalizers: → - foregroundDeletion

Еще два совета:

• В установившемся состоянии Kubelet, не сбитый с толку, не должен регистрировать никаких периодических сообщений. Любая повторяющаяся неспособность что-то освободить - это симптом застрявшей капсулы.
• вы можете заблокировать команду kubectl delete в другом окне, чтобы отслеживать свой прогресс (даже в пакете, который вы уже «удаляли» много раз). kubectl delete прекратит работу, как только будет освобожден последний застрявший ресурс.

Столкнулся с этим сегодня.
Что было сделано:

1. ssh на узел и удалить контейнер вручную
2. После этого kubectl get pods показывает мне, что мой застрявший контейнер 0/1 terminating (был 1/1 terminating )
3. Удалить раздел finalizers из модуля, мой был foregroundDeletion ($ kubectl edit pod / name) -> контейнер удален из списка модулей
4. Удалить развертывание -> все связанные с развертыванием материалы удалены.

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

мы столкнулись с той же проблемой, когда начали монтировать секреты (общие для многих модулей). Модуль переходит в состояние terminating и остается там навсегда. Наша версия - v1.10.0. Прикрепленный контейнер докеров исчез, но ссылка на сервере API останется, если я не удаляю модуль принудительно с опцией --grace-period=0 --force .

Ищем постоянное решение.

Что ж, недавно я протестировал эксплойт runc CVE-2019-5736 на моем промежуточном кластере. Как вы уже знаете, эксплойт перезаписывает двоичный файл runc на хост-машине. Его разрушительный подвиг. После этого я увидел странное поведение в кластере. Все поды застряли в состоянии завершения. Обходным путем было слить докер очистки затронутого узла и переустановить его. После этого все поды и кластер k8s работают в обычном режиме. Возможно, это проблема с докером, и повторная установка тоже решит вашу проблему! благодаря

Свежую v1.13.3 устанавливаем здесь. Со мной такое тоже бывает. Произошло с тех пор, как я смонтировал одни и те же тома NFS на нескольких модулях, что, кажется, как-то связано с этим.

Я вижу эту проблему при создании развертывания, которое пытается создать том с использованием несуществующего секрета, удаление этого развертывания / службы оставляет около Terminating pod.

столкнулся с той же проблемой с v.1.12.3, и --grace-period = 0 --force или --now оба недопустимы, удалите набор состояний, который также является недействительным

Та же проблема с подключением SMB (я думаю?) (Общий доступ к файлам Azure в соответствии с https://docs.microsoft.com/en-us/azure/aks/azure-files-volume).

та же проблема с 13.3

У меня такая же проблема, что модуль находится в состоянии «Завершение» почти 2 дня.
Я использую Minikube на машине с Linux (Debian).

Версия 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"}
Версия Minikube:
minikube version: v0.34.1

@ardalanrazavi, почему он прекращается на два дня? Просто принудительно удалите, если он не удаляется через 5 минут

@nmors

почему он прекращается на два дня?

Это хороший вопрос. Мы все хотели бы это знать.

Просто принудительно удалите, если он не удаляется через 5 минут

При его принудительном удалении кластер остается в несогласованном состоянии. (С minikube это не ваш настоящий кластер, по общему признанию, это гораздо менее беспокоит)

@AndrewSav

Честно говоря, я не вижу здесь других решений.

Конечно, кластер останется в «несогласованном состоянии». Я хотел бы понять, что вы имеете в виду именно под этим. Принудительное закрытие - это плохо. Мне это тоже не нравится, но в моем случае мне удобно уничтожать и повторно развертывать любые ресурсы по мере необходимости.

В моем случае, похоже, что он застревает только на модулях, у которых есть монтирование NFS. И происходит только тогда, когда сервер NFS выходит из строя до того, как клиент пытается его отключить.

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

@nmors @AndrewSav Я тоже сделал принудительное удаление.

Известно, что удаление вашего nfs-сервера перед удалением модулей приводит к тому, что размонтирование зависает навсегда. В этом случае лучше всего упорядочить удаление, чтобы ваш nfs-сервер всегда удалялся последним.

@ msau42 Мой сервер NFS не является частью кластера k8s - это отдельное устройство и машина вместе

Неважно, входит он в кластер k8s или нет. Если сервер nfs недоступен, размонтирование зависнет, пока он снова не станет доступным.

@ msau42 , это странно, потому что я почти уверен, что даже когда он вернулся в онлайн, поды все еще зависали, завершая работу. новые стручки заводятся и монтируются нормально.

Я использую сервер NFS на кубернетах, следуя этому примеру, и, к сожалению, это случается довольно часто ..

@ shinebayar-g Я тоже следовал этому руководству, но теперь я избавился от PV и PVC и определил свой том непосредственно в развертывании, например:

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

С тех пор у меня не было никаких проблем, я изменил это примерно через неделю в надежде, что более простая конфигурация будет более надежной ... посмотрим ... Может быть, это решит проблему?

В качестве обходного пути я написал сценарий, который захватывает последние строки из /var/log/syslog и ищет ошибки, такие как «Операция для ... удалить / var / lib / kubelet / pods ... каталог не пуст» или «nfs. ..устройство занято ... unmount.nfs "или" устаревший дескриптор файла NFS ".
Затем он извлекает полный каталог pod_id или pod и смотрит, какие у него монтирования (например, mount | grep $pod_id ), затем размонтирует все и удаляет соответствующие каталоги. В конце концов, kubelet сделает все остальное, корректно завершит работу и удалит поды. В состоянии завершения нет модулей.

Я поместил этот скрипт в cron, чтобы он запускался каждую минуту. В результате - пока никаких проблем, даже через 3-4 месяца.
Примечание : я знаю, что этот подход ненадежен и требует проверки при каждом обновлении кластера, но он работает!

Я использую версию 1.10, и сегодня у меня возникла эта проблема, и я думаю, что моя проблема связана с проблемой установки секретного тома, которая могла оставить некоторую задачу отложенной и навсегда оставить модуль в состоянии завершения.

Мне пришлось использовать параметр --grace-period = 0 --force для завершения работы модулей.

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]

Я обнаружил, что если вы используете --force --grace-period=0 все, что он делает, - это удаляет ссылку ... если вы подключитесь к узлу по ssh, вы все равно увидите, что контейнеры докеров работают.

В моем случае на узле была нехватка памяти.
И ядро ​​убило ресничный агент, что, кажется, мешает уничтожению стручка.
Я только что перезапустил узел, и он очистился.

По моему опыту, помогает sudo systemctl restart docker на узле (но очевидно, что время простоя).

И это все еще происходит периодически на случайных узлах, которые либо A) близки к пределам памяти, либо B) CPU не хватает (либо bc из некоторой проблемы kswapd0, которая все еще может быть связана с памятью, либо фактической загрузкой)

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

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

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

Старые выпуски гниют после 30 дней бездействия.
Отметьте проблему как новую с помощью /remove-lifecycle rotten .
Гнилые проблемы закрываются после дополнительных 30 дней бездействия.

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

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

Гнилые проблемы закрываются после 30 дней бездействия.
Повторно откройте проблему с помощью /reopen .
Отметьте проблему как новую с помощью /remove-lifecycle rotten .

Отправьте отзыв в sig-testing, kubernetes / test-infra и / или fejta .
/Закрыть

@ fejta-bot: Закрытие этого вопроса.

Это очень активная проблема, k8s 1.15.4 и RHEL Docker 1.13.1. Все время стручки остаются в Terminating но контейнера уже нет, и k8s не может определить себя, но требует взаимодействия с человеком. Делает тестовые скрипты настоящим PITA.

/ повторно открыть
/ remove-lifecycle гнилой

@tuminoid : Вы не можете повторно открыть проблему / PR, если не являетесь автором или соавтором.

/ повторно открыть
/ remove-lifecycle гнилой

@mikesplain : Повторно

То же самое и здесь: капсула застряла в фазе завершения более 19 минут. Контейнер успешно завершен, но Kubernetes все еще считает, что ему нужно чего-то ждать.

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>

Ни событий, ни логов ...

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

Можете ли вы проверить свои журналы kubelet и увидеть, есть ли сообщения о сбое размонтирования тома или о потерянных модулях?

Я тоже это видел
E1206 03: 05: 40.247161 25653 kubelet_volumes.go: 154] Обнаружен потерянный под "0406c4bf-17e3-4613-a526-34e8a6cee208", но пути к томам все еще присутствуют на диске: Всего было 8 похожих ошибок. Включите многословие, чтобы увидеть их.

Я тоже это видел. Невозможно проверить журналы, потому что kubectl жалуется, что не может подключиться к контейнеру докера и не может создать новый модуль из-за текущего существования завершающего модуля. Скорее раздражает.

Я тоже испытываю это, и довольно неприятно подтверждать, правильно ли Kubernetes очистил старые поды или нет.
Надеюсь, это скоро будет исправлено.

А как насчет этого вопроса? Это разрешилось? У меня такой же, но это начинает происходить не сразу, а через какое-то время после старта ноды, если сбросить ноду то какое-то время все хорошо

Не могли бы вы проверить, есть ли в модуле финализаторы, препятствующие его удалению?

В выданном пакете нет финализаторов

К вашему сведению, я решил это с помощью принудительного удаления, используя:

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

И я считаю, что этому удалось успешно уничтожить капсулу. С тех пор я больше не сталкивался с этой проблемой. Возможно, с тех пор я обновился, так что это может быть проблема с версией, но не на 100%, так как я так давно не видел проблему.

У меня такое случается, когда у модуля заканчивается память. Он не прекращается, пока использование памяти снова не снизится.

К вашему сведению, я решил это с помощью принудительного удаления, используя:

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

И я считаю, что этому удалось успешно уничтожить капсулу. С тех пор я больше не сталкивался с этой проблемой. Возможно, с тех пор я обновился, так что это может быть проблема с версией, но не на 100%, так как я так давно не видел проблему.

Это сработало для меня

kubectl delete pods <pod> --grace-period=0 --force - это временное исправление, я не хочу запускать исправление вручную каждый раз, когда происходит переключение на один из затронутых модулей. Мои стручки zookeeper не заканчиваются в minikube и Azure AKS.

Обновление 9 марта 2020 г.
Я использовал ловушку жизненного цикла preStop, чтобы вручную завершить работу своих модулей. Мои стручки zookeeper застряли в состоянии завершения и не отвечали на сигнал термина из контейнера. У меня был в основном тот же манифест, работающий в другом месте, и все завершается правильно, не знаю, в чем основная причина.

та же проблема, супер раздражает

та же проблема :( стручки застряли в прекращении работы с 3 дней

К вашему сведению, я решил это с помощью принудительного удаления, используя:

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

И я считаю, что этому удалось успешно уничтожить капсулу. С тех пор я больше не сталкивался с этой проблемой. Возможно, с тех пор я обновился, так что это может быть проблема с версией, но не на 100%, так как я так давно не видел проблему.

Кроме того, флаг --force не обязательно означает, что модуль удален, он просто не ждет подтверждения (и удаляет ссылку, насколько я понимаю). Как сказано в предупреждении The resource may continue to run on the cluster indefinetely .

Изменить: я был плохо информирован. См. Комментарий elrok123s ниже для дальнейшей мотивации.

К вашему сведению, я решил это с помощью принудительного удаления, используя:

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

И я считаю, что этому удалось успешно уничтожить капсулу. С тех пор я больше не сталкивался с этой проблемой. Возможно, с тех пор я обновился, так что это может быть проблема с версией, но не на 100%, так как я так давно не видел проблему.

Кроме того, флаг --force не обязательно означает, что модуль удален, он просто не ждет подтверждения (и удаляет ссылку, насколько я понимаю). Как сказано в предупреждении The resource may continue to run on the cluster indefinetely .

Правильно, но дело в том, что --grace-period=0 заставляет удаление произойти :) не уверен, почему ваш комментарий актуален: /

Я считаю, что его комментарий уместен, потому что основной контейнер
(докер или что-то еще) может все еще работать и не удален полностью ..,
иллюзия того, что он «удален», временами немного вводит в заблуждение

В четверг, 4 июня 2020 г., в 9:16, Коннер Стивен МакКейб <
[email protected]> написал:

К вашему сведению, я решил это с помощью принудительного удаления, используя:

kubectl удалить поды--grace-period = 0 --force

И я считаю, что этому удалось успешно уничтожить капсулу. С тех пор я
больше не сталкивались с этой проблемой. Я, возможно, обновил с тех пор,
так что может быть проблема с версией, но не на 100%, так как это было так давно
Я видел проблему.

Кроме того, флаг --force не обязательно означает, что модуль удален, он
просто не ждет подтверждения (и отбрасывает ссылку на мой
понимание). Как указано в предупреждении, ресурс может продолжать работать
на кластере неопределенно.

Верно, но дело в том, что --grace-period = 0 заставляет удаление
бывает :) не уверен, почему ваш комментарий актуален: /

-
Вы получили это, потому что оставили комментарий.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/kubernetes/kubernetes/issues/51835#issuecomment-638840136 ,
или отписаться
https://github.com/notifications/unsubscribe-auth/AAH34CDZF7EJRLAQD7OSH2DRU6NCRANCNFSM4DZKZ5VQ
.

Это действительно моя точка зрения; использование этого метода --force рискует оставить базовую нагрузку, утяжеляющую ваши узлы, и не обязательно решит исходную проблему. В худшем случае это исправление «Если я не вижу, значит, его не существует», которое может оказаться еще сложнее обнаружить.

Или вы говорите, что --grace-period=0 гарантированно принудительно удалит базовый контейнер, @ elrok123?
Если это так, мой комментарий основан на неверных знаниях и не имеет отношения к делу, но если сохраняется риск выхода из запущенных контейнеров при использовании --grace-period=0 же самое и с моей точкой зрения.

@oscarlofwenhamn Насколько мне известно, это эффективно запускает sigkill для всех процессов в этом модуле, обеспечивая удаление процессов зомби (источник: пункт 6 в разделе «Завершение работы модулей» - https://kubernetes.io/docs/concepts / workloads / pods / pod / # : ~: text = Когда истекает% 20the% 20grace% 20period% 20, период% 200% 20 (немедленное удаление% 20).) и успешное удаление модуля (может произойти не сразу, но это произойдет. случиться.)

В руководстве упоминается, что он удаляет ссылку, но не удаляет сам модуль (источник: «Принудительное удаление» - https://kubernetes.io/docs/tasks/run-application/force-delete-stateful-set-pod/ ), однако grace-period = 0 должен эффективно убивать ваш модуль, хотя и не сразу.

Я просто читаю документы и рекомендую способы справиться со сценарием, с которым я столкнулся. Проблема, с которой я столкнулся, не была повторяющейся проблемой, а произошла однажды; Я действительно считаю, что РЕАЛЬНОЕ исправление для этого исправляет ваше развертывание, но пока вы не доберетесь до него, этот метод должен помочь.

@ elrok123 Великолепно - я действительно был плохо информирован. Я обновил свой ответ выше, сославшись на это объяснение. Спасибо за подробный ответ и за дополнительный мотивированный метод решения проблемных стручков. Ура!

в настоящее время контейнеры застревают на 2+ дня в состоянии завершения.

Для меня пространство имен застряло в Terminating . В списке нет стручков. Никаких услуг ... ничего. Пространство имен пусто. Тем не менее ... застрял в прекращении.

@JoseFMP использует kubectl для запроса yaml из пространства имен, у него могут быть финализаторы, которые задерживают процесс.

@JordyBottelier Спасибо.

Никаких финализаторов. Все еще застрял Terminating

@JoseFMP - это сценарий, который полностью его уничтожает (фактически уничтожает его), просто сохраните его и запустите ./script_name:
``

! / bin / bash

установить -eo pipefail

die () {echo "$ *" 1> & 2; выход 1; }

нужно() {
который "$ 1" &> / dev / null || die "Двоичный" $ 1 "отсутствует, но необходим"
}

проверка предварительных требований

нужно "jq"
нужен "завиток"
нужен "kubectl"

ПРОЕКТ = "$ 1"
сдвиг

test -n "$ PROJECT" || die "Отсутствующие аргументы: kill-ns"

kubectl прокси &> / dev / null &
PROXY_PID = $!
killproxy () {
убить $ PROXY_PID
}
ловушка killproxy ВЫХОД

sleep 1 # дайте прокси секунду

kubectl получить пространство имен "$ 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 "Убитое пространство имен: $ PROJECT" ``

Я также, похоже, столкнулся с этим, когда несколько модулей застряли в завершении, в том числе один модуль, который больше не виден нигде в моей инфраструктуре, но все еще работает как призрак (он обслуживает запросы, и я вижу, что запросы обслуживаются даже с масштабом развертывания нуля).

У меня нет ни видимости, ни контроля над этим модулем, и я спрашиваю, как я должен устранять подобную ситуацию, не выключая все узлы принудительно?

Я также, похоже, столкнулся с этим, когда несколько модулей застряли в завершении, в том числе один модуль, который больше не виден нигде в моей инфраструктуре, но все еще работает как призрак (он обслуживает запросы, и я вижу, что запросы обслуживаются даже с масштабом развертывания нуля).

У меня нет ни видимости, ни контроля над этим модулем, и я спрашиваю, как я должен устранять подобную ситуацию, не выключая все узлы принудительно?

вам нужно будет получить доступ к докеру на узле.
Вы можете использовать мой dink (https://github.com/Agilicus/dink), который вызовет модуль с оболочкой с доступом к докеру или ssh для модуля.
docker ps -a
docker stop ####

удачи.

Спасибо за направление.

В конце концов я смог решить эту проблему, но все еще был немного озадачен, как это могло случиться (для меня капсула была полностью невидимой). Поскольку это было в производстве, все было немного беспокойно, и я не мог выполнить диагностику, но если это произойдет снова, надеюсь, я смогу составить лучший отчет об ошибке.

Увидев подобный симптом, поды застряли в завершении (что интересно, все они имеют зонд типа exec для готовности / активности). Просматривая логи, я вижу: kubelet [1445]: I1022 10: 26: 32.203865 1445 prober.go: 124] Зонд готовности для "test-service-74c4664d8d-58c96_default (822c3c3d-082a-4dc9-943c-19f04544713e): test -service "не удалось (сбой): Ошибка выполнения OCI: сбой выполнения: невозможно выполнить остановленный контейнер: неизвестно. Это сообщение повторяется бесконечно, и изменение зондирования exec на tcpSocket, похоже, позволяет модулю завершиться (на основе теста, последует за ним). Кажется, что у модуля есть один из контейнеров «Выполняется», но не «Готов», журналы для контейнера «Выполняется» отображаются так, как будто служба остановлена.

Это происходит в containerd 1.4.0, когда загрузка узла высока и vm.max_map_count установлено на более высокое значение, чем значение по умолчанию, containerd-shim не сливает stdout fifo и блокирует, ожидая его слива, в то время как dockerd не может событие / подтверждение от containerd, что процессы ушли.

@discanto благодарит за то, что

@ Рэндом-Лю

Ошибка открылась более 3-х лет. Стручки, застрявшие при завершении работы, могут быть вызваны множеством причин. Сообщая о своем случае, было бы очень полезно опубликовать некоторые журналы kubelet, чтобы узнать, застряли ли поды.