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

일반적으로 볼륨 및 네트워크 정리는 종료에 더 많은 시간을 소비합니다. 포드가 어느 단계에서 멈췄는지 찾을 수 있습니까? 예를 들어 볼륨 정리?

일반적으로 볼륨 및 네트워크 정리는 종료에 더 많은 시간을 소비합니다.

옳은. 그들은 항상 의심합니다.

@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.

보시다시피이 클러스터에는 CNI 용 Calico가 있습니다.
다음 줄은 내 관심을 끕니다.

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 특정 클러스터에 대해 하루에 여러 번 발생합니다. 같은 주에 동일한 버전의 kops 및 kubernetes로 생성 된 다른 클러스터는 정상적으로 작동합니다.

@igorleao 로그는 장치가 사용 중이기 때문에 볼륨 관리자가 secrete 디렉토리를 제거하지 못했음을 보여줍니다.
/var/lib/kubelet/pods/GUID/volumes/kubernetes.io~secret/token-key 디렉토리가 아직 마운트되었는지 여부를 확인해 주시겠습니까? 감사!

@igorleao kubelet을 어떻게 실행합니까? 용기에? 그렇다면 kubelet에 대한 systemd 단위 또는 도커 구성을 게시 할 수 있습니까?

비슷한 행동이 보입니다. kubelet을 컨테이너로 실행하고 /var/lib/kubelet 을 공유로 마운트하여 문제를 부분적으로 완화했습니다 (기본적으로 docker는 볼륨을 rslave로 마운트 함). 그러나 여전히 유사한 문제가 발생하지만 빈도는 낮습니다. 현재 다른 마운트는 다른 방식으로 수행해야한다고 생각합니다 (예 : /var/lib/docker 또는 /rootfs )

@stormltf kubelet 컨테이너 구성을 게시 해 주시겠습니까?

@stormltf 컨테이너에서 kubelet을 실행하고 있으며 --containerized 플래그를 사용하지 마십시오 ( 마운트로 몇 가지 트릭을

막힌 포드에 대해 다음을 수행하십시오.

포드가 실행중인 노드

• docker exec -ti /kubelet /bin/bash -c "mount | grep STUCK_POD_UUID"
• 노드 자체에서 동일 mount | grep STUCK_POD_UUID .

새로 만든 포드에 대해서도 동일하게 수행하십시오. /var/lib/kubelet 마운트 (예 : default-secret)를 볼 것으로 예상됩니다.

@stormltf 처음 두 개의 포드가 생성 된 후 kubelet을 다시 시작 했습니까?

@stormltf /var/lib/docker 및 /rootfs 를 공유 (도커 검사에서는 볼 수 없지만 컨테이너 내부에서 볼 수 있음) 마운트 지점으로 만들 수 있습니다.

/ 시그 스토리지

일부에게는 도움이 될 수 있습니다. --containerized 플래그를 사용하여 docker 컨테이너에서 kubelet을 실행 중이며 /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/ \

자세한 내용은. 이것은 모든 bind 마운트에 대해 kubelet 컨테이너 내부에 3 개의 마운트 (2 개의 기생충)를 얻게되므로 문제를 제대로 해결하지 못합니다. 그러나 적어도 공유 마운트를 사용하면 한 번의 샷으로 쉽게 마운트 해제 할 수 있습니다.

CoreOS에는이 문제가 없습니다. kubelet 컨테이너에 대해도 커가 아닌 rkt를 사용하기 때문입니다. 우리의 경우 kubelet이 Docker에서 실행되고 kubelet continer 내부의 모든 마운트가 /var/lib/docker/overlay/... 및 /rootfs 제안되는 경우, 이것이 모든 bind 마운트 볼륨에 대해 두 개의 기생충 마운트가있는 이유입니다.

• /rootfs/var/lib/kubelet/<mount> 에서 /rootfs 에서 /rootfs/var/lib/kubelet/<mount>
• /var/lib/docker/overlay/.../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

Azure의 Kubernetes 1.8.1과 동일한 문제가 있습니다. 배포가 변경되고 새 포드가 시작된 후 이전 포드가 종료시 멈 춥니 다.

IBM Cloud의 Kubernetes 1.8.2에서 동일한 문제가 있습니다. 새 포드가 시작된 후 이전 포드가 종료되는 동안 멈 춥니 다.

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 을 (를) 사용하지 않았습니다.

근본 원인이 여전히 동일하다면 (부적절하게 제안 된 마운트) 이것은 배포 관련 버그 imo입니다.

IBM Cloud에서 kubelet run을 실행하는 방법을 설명해주세요. 시스템 단위? --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 깃발 : 아니오

좋아, 더 많은 정보가 필요합니다. 위의 댓글을 참조하십시오. https://github.com/kubernetes/kubernetes/issues/51835#issuecomment -333090349

/lib/systemd/system/kubelet.service 콘텐츠도 보여 주시고 /etc/systemd/system 에 kubelet에 대한 내용이 있으면 공유 해주세요.

특히 kubelet이 도커에서 실행되면 모든 바인드 마운트 -v 를보고 싶습니다.

오늘 저는 고객 시스템 중 하나의 포드가 며칠 동안 종료 상태로 멈춰있는 설명과 동일한 문제가 발생했습니다. 또한 "오류 : 볼륨에 대해 UnmountVolume.TearDown 실패"에 대한 오류가 발생했으며, 멈춘 각 포드에 대해 "장치 또는 리소스 사용 중"이 반복되었습니다.

우리의 경우이 moby 문제에서 다루는 RHEL / Centos 7.4 기반 시스템의 docker 문제인 것으로 보입니다 : https://github.com/moby/moby/issues/22260 및이 moby PR : https : // github .com / moby / moby / pull / 34886 / files

우리에게는 몇 분 안에 sysctl 옵션 fs.may_detach_mounts = 1을 설정하면 모든 Terminating pod가 정리되었습니다.

나는 또한이 문제에 직면하고 있습니다 : 포드가 1.8.3에서 Terminating 상태로 멈췄습니다.

노드의 관련 kubelet 로그 :

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은 Ubuntu 16.04에서 컨테이너가 아닌 systemd 단위로 실행됩니다.
보시다시피 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 지속성 볼륨을 사용하는 포드가 많이 있습니다. 일부 포드는 배포를 삭제 한 후 종료 상태에 있습니다. 그리고 syslog에는 많은 메시지가 있습니다.

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

그리고 그것은 사실 디렉토리가 비어 있지 않고 마운트 해제되고 "하위 경로"디렉토리를 포함하고 있다는 것입니다!
이러한 동작에 대한 설명 중 하나 :

1. P1 : 포드 생성 또는 포드 동기화 시작
2. P1 : 볼륨 관리자에게 신호를 보내 마운트 / 재 마운트합니다.
3. P1 : 마운트가 완료되기를 기다리고 있습니다.
4. P1 : 성공 마운트 신호 수신 (실제로 모든 볼륨이 마운트되었는지 확인)
5. 어떻게 든 볼륨이 마운트 해제됩니다. 다른 삭제 프로세스가 마운트 해제 또는 일부 OS 버그 또는 일부 가비지 수집기 작업 일 수 있습니다.
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 * desiredStateOfWorldPopulator) 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 컨테이너 ID 얻기
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 delete pod이지만 볼륨을 해제 할 수없는 경우 메시지는 다음과 같습니다.
장치 또는 리소스 사용 중

단계 :
1) sudo journalctl -u kubelet
이 쉘은 오류 메시지를 찾는 데 도움이됩니다.
2) sudo 도커 검사
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 | 그렙 90225
루트 90225 1.3 0.0 2837164 42580? SSL Feb01 72:40 ./monitor_program

내 1.7.2에 동일한 버그가 있습니다.

"default-token-bnttf"볼륨에 대해 operationExecutor.UnmountVolume 시작됨 (UniqueName : "kubernetes.io/secret/ddc66e10-0711-11e8-b905-6c92bf70b164-default-token-bnttf") 포드 "ddc66e10-0711-11e8-b905- 6c92bf70b164 "kubelet [94382] : E0205 11 : 35 : 50.509169 94382 nestedpendingoperations.go : 262]" "kubernetes.io/secret/ddc66e10-0711-11e8-b905-6c92bf70b164-default-token-bnttf"("ddc66e10- 0711-11e8-b905-6c92bf70b164 ")"가 실패했습니다. 2018-02-05 11 : 37 : 52.509148953 +0800 CST (durationBeforeRetry 2m2s)까지는 재 시도가 허용되지 않습니다. 오류 : "default-token-bnttf"볼륨에 대해 UnmountVolume.TearDown이 실패했습니다 (UniqueName : "kubernetes.io/secret/ddc66e10-0711-11e8-b905-6c92bf70b164-default-token-bnttf") 포드 "ddc66e10-0711-11e8- b905-6c92bf70b164 "(UID :"ddc66e10-0711-11e8-b905-6c92bf70b164 ") : /var/lib/kubelet/pods/ddc66e10-0711-11e8-b905-6c92bf70b164/volumes/kubernetes.io~secret/default- 제거 token-bnttf : 장치 또는 리소스 사용 중

Docker 서비스를 다시 시작하면 잠금이 해제되고 몇 분 내에 포드가 제거됩니다. 이것은 버그입니다. Docker 17.03 사용

Azure, Kube 1.8.7의 동일한 문제

1.8.9에서도 몇 분 전에 우리에게 일어났습니다. 누구든지이 문제를 해결하기 위해 찾고 있습니까? 도커를 다시 시작하면 도움이되지만 약간 우스꽝 스럽습니다.

이것은 GKE의 최신 1.9.4 릴리스에서 많이 발생했습니다. 지금이 작업을 수행했습니다.

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
작동하는 것 같습니다.
kubelet을 다시 시작해도 작동합니다.

GKE 1.9.4-gke.1에서 동일한 문제
특정 파일 비트 데몬 셋에서만 발생하지만 모든 노드를 다시 만드는 것도 도움이되지 않고 계속 발생합니다.

또한 GKE에 @Tapppi 같은 1.9.4-gke.1이 문제를 타격 - 포드가 호스트 노드에서 고정 표시기 데몬에서 제거하지만는 Kubernetes 그것이 붙어 있었다 된 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,이 버그의 원래 문제는 컨테이너화 된 kubelet의 구성과 관련이 있습니다.

BTW, v1.9.3-gke.0 버전으로 새 노드 풀을 만드는 것은 v1.9.5 이 여전히 gke에서 출시되지 않고 이미 부활절이기 때문에이 문제를 해결하는 방법이었습니다.

누군가이 문제가 버전 1.9.3 이상에서 수정되었음을 확인할 수 있습니까? 이 동작으로 인해 심각한 문제가 있으며, 이런 일이 발생할 때마다 docker를 다시 시작하는 것은 soo st00pid입니다.

나를 위해 1.9.6에서 수정되었습니다.

2018 년 4 월 4 일 수요일 오전 11:43 sokoow, [email protected] 작성 :

누군가이 문제가 버전 1.9.3 이상에서 수정되었음을 확인할 수 있습니까? 우리는
이 동작으로 인해 심각한 문제가 발생하고 각각 도커를 다시 시작합니다.
이런 일이 일어나는 시간은 soo st00pid입니다.

—
당신이 언급 되었기 때문에 이것을 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/kubernetes/kubernetes/issues/51835#issuecomment-378557636 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/ABaviW5yfj64zVjBYFGUToe2MH3dKwpTks5tlKPNgaJpZM4PKs9r
.

좋아요, 감사합니다 @Stono . 여기서 확인해야 할 사항이 하나 더 있습니다. 다음은 컨테이너화 된 kubelet 용 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을 사용하여 포드를 삭제하는 것은 상당히 과감합니다. 거의 항상 docker hang으로 인해 노드를 사용할 수 없게됩니다.

Azure AKS 관리 클러스터의 1.9.6에서 여전히이 문제가 발생합니다.

현재이 해결 방법을 사용하여 멈춰있는 모든 포드를 선택하고 삭제합니다 (개발 / 스크래치 클러스터에 종료 포드가 늘어남에 따라).

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

May Azure 및 AWS 클러스터 모두에서이 문제가 발생했습니다. 해결 방법은 Mike Elliot에서 제공했습니다.

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

ubuntu @ ip-10-0-0-22 : ~ $ kubectl get pods --all-namespaces
네임 스페이스 이름 준비 상태 다시 시작 나이
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 Running 0 25d
kube-system monitoring-grafana-997796fcf-wtz7n 1/1 Running 0 25d
kube-system monitoring-influxdb-56fdcd96b-2phd2 1/1 Running 0 25d
kube-system tiller-deploy-cc96d4f6b-jzqmz 1/1 Running 0 25d
onap dev-sms-857f6dbd87-pds58 0/1 종료 0 3h
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 get pods --all-namespaces
네임 스페이스 이름 준비 상태 다시 시작 나이
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 Running 0 25d
kube-system monitoring-grafana-997796fcf-wtz7n 1/1 Running 0 25d
kube-system monitoring-influxdb-56fdcd96b-2phd2 1/1 Running 0 25d
kube-system tiller-deploy-cc96d4f6b-jzqmz 1/1 Running 0 25d
onap dev-sms-857f6dbd87-pds58 0/1 종료 0 3h
ubuntu @ ip-10-0-0-22 : ~ $ kubectl delete pod dev-sms-857f6dbd87-pds58 -n onap --grace-period = 0 --force
경고 : 즉시 삭제는 실행중인 리소스가 종료되었다는 확인을 기다리지 않습니다. 리소스는 클러스터에서 무기한 계속 실행될 수 있습니다.
포드 "dev-sms-857f6dbd87-pds58"삭제됨
ubuntu @ ip-10-0-0-22 : ~ $ kubectl get pods --all-namespaces
네임 스페이스 이름 준비 상태 다시 시작 나이
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 Running 0 25d
kube-system monitoring-influxdb-56fdcd96b-2phd2 1/1 실행 중 0 25d
kube-system tiller-deploy-cc96d4f6b-jzqmz 1/1 Running 0 25d

이것이 동일한 문제인지 확실하지 않지만 1.9.3에서 10.10.1로 업그레이드 한 이후로이 동작을 인식 하기 시작했습니다 . 그 전에는 그런 일이 없었습니다. SubPath와 함께 glusterfs 볼륨을 사용하고 있습니다. 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), 노드가 메모리를 벗어나고 포드가 다시 예약 된 후 포드는 Terminating 상태입니다. 결국 kubernetes 대시 보드에 많은 고스트 포드가 있으며 배포 탭에서 4/1 포드가있는 배포를 볼 수 있습니다.
kubelet을 다시 시작하거나 네임 스페이스의 모든 pod를 종료하면 도움이되지만 매우 열악한 솔루션입니다.

@Adiqq Docker 자체 문제였습니다.

노드 중 하나에서 journalctl -u kubelet -f 를 살펴보십시오. '컨테이너를 죽일 수 없습니다.gRpc 오류 "(이 문제를 해결 한 이후 실제 메시지가 없습니다).

수정하기 위해 각 메모에서 도커를 다시 시작했습니다. Docker를 부팅하는 동안 손상된 상태의 컨테이너를 정리하고이 부실한 포드를 모두 제거합니다.

어제 1.9.7에서 포드가 종료 상태로 멈 췄고 로그에 "포드를 죽일 필요가 있음"이 있었기 때문에 제거하려면 --force --grace-period=0 했습니다.

1.9.7-gke.0으로이 문제를 해결했습니다.
1.9.6-gke.1에 문제가 없었습니다.
하지만 1.9.4와 1.9.5에서는

고정 된 포드에 PV가 연결되어 있습니다.

포드를 재배포하거나 삭제해도 동일한 효과가 있습니다.
문제가되는 노드에서 kubelet을 다시 시작해도 작동하지 않았습니다. kubelet이 다시 시작되지 않았고 전체 노드를 다시 시작해야했습니다.

이 동안 pod는 PV가 이미 다른 곳에 마운트되었다고 말했기 때문에 다른 노드에서 예약 할 수 없습니다.

@Stono @ nodefactory-bk 문제를 지적 할 수있는 자세한 로그가 있는지 확인하기 위해 문제가되는 노드의 kubelet 로그를 살펴볼 수 있습니까?

cc @dashpole

하나의 앱이 종료되는 동안 중단되었습니다.
이것은 1.9.7-gke.1에 있습니다.
다음은 비밀이 수정 된 kubectl describe 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

Google 이미지의 gke에서 kubelet.log를 어디서 찾을 수 있는지 확실하지 않습니다. 내가 첨부하는 것을 찾았습니다.
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 마운트를 해제 할 수 없을 때 노드의 모든 포드가 영원히 종료 된 상태로 유지됩니다. 복구를 위해 노드를 다시 시작해야했는데 kubelet 또는 docker restart가 도움이되지 않았습니다.

@tuminoid ceph 문제는 다르게 들립니다. 새 문제를 열고 해당 포드에 대한 포드 이벤트 및 kubelet 로그를 제공 할 수 있습니까?

참고로 클러스터를 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'가 멈 춥니 다. 그 이유는 노드의 하드 마운트이며 '서버'가 먼저 삭제됩니다.

nfs 서버를 먼저 삭제할 때 nfs 마운트 해제 문제에 대한 @donbowman , StorageClass 또는 PV에서 "소프트"마운트 옵션을 설정할 수 있습니다.

어떻게 모르겠어요? PersistentVolumeClaim에서 설정할 수 있지만 여기에는 적용되지 않습니다.
여기에 StorageClass가 적용되지 않는다고 생각합니다 (NFS 서버 아래의 디스크 아래).

이 문제는 nfs-client에 있습니다.
내가 뭘 놓치고 있니?

nfs PV의 경우 1.8에서 시작하는 mountOptions 필드를 설정하여 소프트 마운트를 지정할 수 있습니다. nfs 볼륨을 동적으로 프로비저닝하는 경우 StorageClass.mountOptions에서 설정할 수도 있습니다.

예, 그러나 NFS로 마운트되는 PV는 아닙니다.
내 NFS 서버 컨테이너에서 가져온 것입니다.
동적 프로비저닝이 없습니다.

Google GCP + GKE를 사용하고 있습니다. PVC는 NFS로 다시 내보내는 컨테이너에 ext4로 마운트 된 블록 IO 인 PV를 선택합니다.

nfs-server (자체 포드)에서 마운트되는 두 번째 컨테이너 세트는 PV로 인식하지 않습니다. 그들은 그것을 아래와 같은 볼륨으로 봅니다.

이 nfs-client가 마운트에 대해 '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: /

nfs 마운트를 사용하는 두 번째 컨테이너 세트의 @donbowman 을 사용하면 mountOptions 세트로 해당 nfs 볼륨에 대한 PV를 수동으로 생성하고 모든 포드에서 해당 nfs PV에 대한 PVC를 공유 할 수 있습니다. 동적 프로비저닝이 필요하지 않습니다.

이 같은:

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-client가 Terminating 상태에서 영원히 멈춰 있습니다.

k8s-nfs-test.yaml.txt

첨부는 내가 사용한 yaml입니다. 나는 '만들기'를했고, 그것이 올 때까지 기다렸다가 클라이언트가 마운트를 가지고 있음을 관찰하고, 파일을 읽고 쓸 수 있다는 것을 관찰 한 다음, '삭제'를했습니다.

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 서버를 호스팅하는 데 더 이상 포드가 필요하지 않으므로 전체 Firestore isntance를 삭제하지 않는 한이 문제가 발생하지 않아야합니다.

파일 저장소를 오케스트레이션하는 경우 동일한 문제가 발생하지 않습니까? 예를 들어 특정 kubernetes 배포를 위해 가져온 다음 마지막에 다운하면 순서가 보장되지 않습니다.

그러나 또한 문제는 순서가 아니라 nfs 클라이언트 포드 삭제가 전혀 마운트 해제되지 않고 마운트가 노드에 매달려 있다고 생각합니다. 따라서 파일 저장소 / 서버가 있는지 여부에 관계없이 매달린 마운트가 있습니다.

포드가 종료되면 볼륨을 마운트 해제합니다 (서버가 아직 있다고 가정). 서버가 존재하더라도 매달린 마운트가 보인다면 그것은 버그입니다.

PVC 및 PV와 함께 동적 프로비저닝을 사용하는 경우이를 참조하는 모든 Pod가이를 사용하여 완료 될 때까지 PVC (및 기본 스토리지)를 삭제할 수 없습니다. 프로비저닝을 직접 오케스트레이션하려면 모든 포드에서 서버 사용을 완료 할 때까지 서버를 삭제하지 않도록해야합니다.

가능한 해결 방법 일 수 있습니다. # 65936

강제 삭제는 kubectl delete po $pod --grace-period=0 --force . --now 플래그가 작동하지 않았습니다. # 65936에 대해 잘 모르겠지만 Unknown 상태가 발생할 때 노드를 죽이지 않고 싶습니다.

1.10.5에서 동일한 문제가 발생합니다 (장치가 '사용 중'이기 때문에 포드 내의 파일을 마운트 해제 할 수 없기 때문에 포드가 종료 상태로 남아 있음). 나를 위해 --grace-period=0 --force 를 사용하면 마운트 지점이 계속 존재하게됩니다. 결국 나는 90000 개가 넘는 마운트 포인트로 끝났고, 이로 인해 클러스터가 심각하게 느려졌습니다. 여기서 해결 방법은 pod의 폴더에서 찾기를 수행하고 해당 파일을 재귀 적으로 마운트 해제 한 다음 pod 폴더를 재귀 적으로 삭제하는 것입니다.
제 경우에는 하위 경로를 사용하여 기존 파일이있는 기존 폴더에 configmap을 마운트하고 기존 파일 중 하나를 덮어 씁니다. 이것은 1.8.6에서 나를 위해 잘 작동했습니다.
원래 포스터에는 포드가 몇 시간 동안 '종료'상태에 있다고 언급되어 있습니다. 제 경우에는 며칠입니다. 수동 해결 방법을 수행하는 경우를 제외하고는 결국 정리되는 것을 보지 못했습니다.

동일한 문제가 발생하여 log aggregator (fluentd와 유사)로 인해 /var/lib/docker/containers 폴더를 마운트하고 포드에는 많은 마운트가 있습니다.

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

필자의 경우 일부 포드는 kubernetes에 의해 잘 제거 될 수 있지만 일부 포드는 "종료 중"상태로 멈 춥니 다.

https://github.com/kubernetes/kubernetes/issues/45688 과 관련이있을 수 있습니다 (도커 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_가 포드를 죽일 필요가 있다고 느끼는가, 아니면 포드를 죽여야한다고?

이것은 며칠 전에 나에게 일어 났고 삭제를 포기하고 포드를 그대로 두었습니다. 그리고 오늘은 사라져 결국 삭제 된 것 같습니다.

방금 나에게 일어났다. --force --now 솔루션이 작동하지 않았습니다. kubelet 로그에서 의심스러운 다음 줄을 발견했습니다.

8 월 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에 있기 때문에 관련이 있다고 생각했습니다. 나는 도커를 다시 시작하라는 조언을 주었다.
Docker를 다시 시작하면 "종료 중"에 갇힌 포드가 사라졌습니다.

나는 이것이 해결 방법 일 뿐이라는 것을 알고 있지만 더 이상이 문제를 해결하기 위해 새벽 3시에 깨어나지 않습니다.
이것을 사용해야한다는 말은 아니지만 일부 사람들에게 도움이 될 수 있습니다.

수면은 내 포드 종료 GracePeriodSeconds가 (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에서 동일한 오류가 표시됩니다. 포드가 무기한 종료되는 동안 멈추고 해당 노드의 kubelet이 반복적으로 기록합니다.

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"

불만없이 문제의 하위 경로 볼륨을 수동으로 마운트 해제 할 수 있습니다 (리눅스는 사용 중이라고 표시하지 않습니다). 이렇게하면 kubelet이 오류 메시지를 기록하는 것을 중지합니다. 그러나 포드가 여전히 종료 상태로 표시되기 때문에 Kubernetes가 정리를 계속하도록 유도하지는 않습니다. 이를 정리하기 위해 Docker를 정기적으로 다시 시작하는 것은 컨테이너 실행 중단으로 인해 실제로 허용되는 솔루션이 아닙니다.

또한 참고 : 컨테이너 자체가 docker ps -a 에서 사라 졌다는 증거가 없기 때문에 이것이 실제로 Docker 문제인지 확실하지 않습니다. Docker 버전 17.03.2-ce를 사용하고 있습니다.

업데이트 : 심볼릭 링크를 사용하여 kubelet 루트 디렉터리를 OS가 아닌 볼륨으로 리디렉션하도록 노드를 구성했습니다 ( /var/lib/kubelet 는 다른 볼륨의 다른 디렉터리를 가리키는 심볼릭 링크 임). --root-dir 를 kubelet에 전달하도록 재구성하여 심볼릭 링크를 통하지 않고 원하는 디렉토리로 직접 이동하고 kubelet을 다시 시작하면 볼륨 마운트를 정리하고 멈춰있는 포드를 지 웠습니다. Docker를 다시 시작할 필요없이 종료됩니다.

오늘 minikube에서 일부 포드를 로컬로 실행하면서이 문제를 처음으로 경험했습니다.

누락 된 볼륨으로 마운트 된 configmap / secret으로 인해 Terminating 에 여러 개의 포드가 붙어있었습니다. 제안 / 해결 방법 / 솔루션 없음 위를 제외하고 일하지 게시 된 이 하나 .

주목할 가치가 있다고 생각하는 한 가지는 다음과 같습니다.

• kubectl get pods 실행했을 때 Terminating 상태의 포드 목록이 표시됩니다.
• 내가 달릴 때 docker ps | grep -i {{pod_name}} 불구을에서 포드의 어느 Terminating 의해 본 상태 kubectl get pods minikube VM에서 실행되지 않았다.

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 사용할 때.
정말로 일어날 지 아무도 말해 줄 수 있습니까?

실제로 일부 포드를 삭제하면 몇 가지 이유로 삭제가 지연 될 수 있습니다.
"--force --grace-period = 0"플래그와 함께 "kubectl delete"를 실행하면
자원 객체는 즉시 삭제됩니다.

포드가 즉시 삭제되는지 확인하는 데 도움을 줄 수 있습니까?
경고 메시지가 실제로 부정확하다는 의미입니까?

@windoze , --force --grace-period = 0 옵션이면 pod API 객체가 API 서버에서 즉시 삭제됨을 의미합니다. 노드 kubelet은 볼륨 마운트를 정리하고 컨테이너를 종료합니다. kubelet이 실행되고 있지 않거나 포드를 정리하는 동안 문제가있는 경우 컨테이너가 계속 실행 중일 수 있습니다. 그러나 Kubelet은 가능할 때마다 계속해서 포드를 정리해야합니다.

그래도 kubelet이 오작동 할 수 있기 때문에 삭제가 영원히 걸릴 수 있음을 의미합니까?
포드가 삭제되었는지 확인하는 방법이 있습니까?
클러스터에서 몇 개의 거대한 포드가 실행 중이고 모든 노드에 2 개의 인스턴스를 실행하기에 충분한 메모리가 없기 때문에 질문하는 것입니다.
삭제에 실패하면 노드를 사용할 수 없게되고이 문제가 여러 번 발생하면 결국이 포드를 실행할 수있는 노드가 없으므로 서비스가 완전히 중단됩니다.

평범한 도커 환경에서 kill -9 또는 이와 유사한 것으로 포드를 강제 종료 할 수 있지만 k8s에는 이러한 기능이없는 것 같습니다.

@windoze 포드 삭제가 자주 실패한 이유를 알고 있습니까? 그것은 kubelet이 실행 중이 아니거나 kubelet이 컨테이너를 죽이려고했지만 몇 가지 오류로 실패했기 때문입니까?

이러한 상황은 몇 달 전에 내 클러스터에서 여러 번 발생했으며 kubelet이 실행 중이었지만 docker 데몬은 문제가있는 것 같고 오류 로그없이 멈췄습니다.
내 해결책은 노드에 로그인하고 컨테이너 프로세스를 강제 종료하고 도커 데몬을 다시 시작하는 것입니다.
일부 업그레이드 후 문제가 사라지고 다시는 발생하지 않았습니다.

kubectl delete pods <podname> --force --grace-period=0 가) 저에게 효과적이었습니다!

@ shinebayar-g, --force 의 문제는 컨테이너가 계속 실행된다는 것을 의미 할 수 있다는 것입니다. Kubernetes에게이 포드의 컨테이너를 잊어 버리라고 지시합니다. 더 나은 솔루션은 포드를 실행하는 VM에 SSH를 사용하여 Docker에서 진행되는 작업을 조사하는 것입니다. docker kill 하여 컨테이너를 수동으로 종료하고 성공하면 포드를 정상적으로 다시 삭제합니다.

@agolomoodysaada 아, 말이 되네요. 설명해 주셔서 감사합니다. 그래서 실제 컨테이너가 정말로 삭제되었는지 아닌지 정말 알 수 없습니까?

그래서, 2018 년 말에 kube 1.12가 나왔고 ... 여러분 모두 여전히 멈춤 포드에 문제가 있습니까?

--force --grace-period = 0 또는 --force --now 작동하지 않는 동일한 문제가 있습니다. 다음은 로그입니다.

root @ r15-c70-b03-master01 : ~ # kubectl -n infra-lmat get 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 get 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 get pod node-exporter-zbfpx
이름 준비 상태 다시 시작 나이
node-exporter-zbfpx 0/1 종료 0 4d

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

포드를 편집하고 메타 데이터에서 종료 자 섹션을 삭제하려고했지만 실패했습니다.

macOS에서 kubectl 1.13 alpha 및 Docker for Desktop을 사용하면 여전히 100 % 재현 가능한 방식 (동일한 리소스 정의)으로 표시됩니다. 재현성이란 문제를 해결하는 유일한 방법은 Mac 용 Docker를 공장 초기화하는 것으로 보이며 동일한 리소스 (배포 스크립트)를 사용하여 클러스터를 다시 설정하면 동일한 정리 스크립트가 실패합니다.

왜 관련이 있는지 잘 모르겠지만 내 정리 스크립트는 다음과 같습니다.

#!/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>) 로 나열됩니다.

다시 한 번 나에게 일어났다. NFS 공유를 사용하여 percona pmm-server를 설치하려고했는데 소프트웨어가 나오지 않았기 때문에 제거했습니다. (이 소프트웨어에는 영구적 인 주장이 적용되지 않았습니다). 다시 한번 좋은 오래된 kubectl delete pods <podname> --force --grace-period=0 라고 부르는 것 같아요. 그러나 질문은이 포드가 어디에 살고 있는지 어떻게 알 수 있습니까?

@ shinebayar-g, SSH가있는 VM에 SSH를 사용하고 docker ps 합니다.

글쎄요 .. 저는 VM이 ​​거의 없어서 어떤 VM이 적합한 지 알아내는 방법을 물었습니다. :)

@ shinebayar-g 이것은 작동 할 수 있습니다.
kubectl describe pod/some-pod-name | grep '^Node:'

같은 문제.

docker ps 컨테이너가 예상대로 종료되지 않은 "Dead"상태에 있음을 발견했습니다 (0).

컨테이너를 수동으로 삭제하면 다음과 같은 Docker 로그 항목이 생성됩니다.

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에만 알려져 있으므로 로컬에서 로그 스트림을 따라야합니다.
  
  
  
  • 특히, Kubelet이 device or resource busy 메시지로 불평하는 umount 디렉토리
  
  
• 다른 모든 방법이 실패하면 kubectl edit 실패한 포드를 제거하고 finalizers: → - foregroundDeletion

두 가지 추가 팁 :

• 정상 상태에서 혼란스럽지 않은 Kubelet은주기적인 메시지를 기록하지 않아야합니다. 어떤 종류의 반복적으로 무언가를 놓지 않는 것은 꼬투리가 고착 된 증상입니다.
• kubectl delete 명령을 다른 창에서 차단하여 진행 상황을 모니터링 할 수 있습니다 (이미 여러 번 "삭제"한 포드에서도). kubectl delete 는 마지막 중단 된 리소스가 해제되는 즉시 종료됩니다.

오늘 이것에 직면했습니다.
수행 된 작업 :

1. ssh를 노드로 이동하고 컨테이너를 수동으로 제거
2. 그 후 kubectl get pods 은 (는) 내 stucked 컨테이너 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입니다. 연결된 Docker 컨테이너는 사라지지만 --grace-period=0 --force 옵션을 사용하여 포드를 강제로 삭제하지 않는 한 API 서버의 참조는 유지됩니다.

영구적 인 해결책을 찾고 있습니다.

음, 최근에 스테이징 클러스터에서 runc exploit CVE-2019-5736을 테스트했습니다. 이미 알고 있듯이 익스플로잇은 호스트 컴퓨터에서 runc 바이너리를 다시 작성합니다. 파괴적인 악용. 그 후 나는 클러스터에서 이상한 행동을 보았습니다. 모든 포드가 종료 상태에 있습니다. 해결 방법은 영향을받는 노드 제거 도커를 비우고 다시 설치하는 것입니다. 그 후 모든 포드와 k8s 클러스터가 이전과 같이 정상적으로 작동합니다. 아마도 도커 문제이고 다시 설치하면 문제도 해결됩니다!. 감사

여기에 새로운 v1.13.3을 설치하십시오. 이것은 나에게도 일어난다. 나는 그것과 관련이있는 것처럼 보이는 몇 개의 포드에 동일한 NFS 볼륨을 마운트했기 때문에 발생합니다.

존재하지 않는 암호를 사용하여 볼륨을 생성하려는 배포를 생성 할 때이 문제가 발생합니다. 해당 배포 / 서비스를 삭제하면 Terminating 포드가 남습니다.

v.1.12.3과 동일한 문제에 직면하고 --grace-period = 0 --force 또는 --now 둘 다 유효하지 않음, 또한 유효하지 않은 statefulset을 삭제하십시오.

SMB (내 생각에?) 마운트 (https://docs.microsoft.com/en-us/azure/aks/azure-files-volume에 따라 Azure Files 공유)와 동일한 문제입니다.

13.3과 동일한 문제

포드가 거의 2 일 동안 "종료 중"상태라는 것과 동일한 문제가 있습니다.
Linux 컴퓨터 (Debian)에서 Minikube를 사용하고 있습니다.

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를 사용하면 실제 클러스터가 아니므로 걱정할 필요가 없습니다.)

뿡 빵뀨

솔직히 여기에 다른 해결책이 없습니다.

물론 클러스터는 "일관되지 않은 상태"로 남아 있습니다. 이게 정확히 무슨 뜻인지 이해하고 싶습니다. 강제 종료가 나쁩니다. 나는 또한 그것을 좋아하지 않지만, 제 경우에는 필요에 따라 자원을 파괴하고 재배치하는 것이 편합니다.

제 경우에는 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

그 이후로 문제가 없었습니다. 간단한 구성이 더 신뢰할 수 있기를 바라며 약 1 주일 정도만 변경했습니다. 보겠습니다.이 문제가 해결 될까요?

해결 방법으로 /var/log/syslog 에서 마지막 줄을 가져와 "Operation for ... remove / var / lib / kubelet / pods ... directory not empty"또는 "nfs. ..device is busy ... unmount.nfs "또는"stale NFS file handle ".
그런 다음 pod_id 또는 pod 전체 디렉토리를 추출하고 마운트가 무엇인지 (예 mount | grep $pod_id ) 확인한 다음 모든 마운트를 해제하고 해당 디렉토리를 제거합니다. 결국 kubelet이 나머지 작업을 수행하고 pod를 정상적으로 종료하고 삭제합니다. Terminating 상태의 포드가 더 이상 없습니다.

이 스크립트를 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가 부족한 임의 노드에서 주기적으로 발생합니다 (아직 메모리와 관련이있을 수있는 일부 kswapd0 문제의 bc 또는 실제로드).

90 일 동안 활동이 없으면 문제가 부실해집니다.
/remove-lifecycle stale 하여 최신 문제로 표시합니다.
비활성 문제는 추가로 30 일 동안 사용하지 않으면 썩고 결국 종료됩니다.

이 문제를 지금 종료해도 안전하다면 /close 하여 종료하세요.

sig-testing, kubernetes / test-infra 및 / 또는 fejta에 피드백을
/ lifecycle stale

비활성 문제는 30 일 동안 활동이 없으면 부패합니다.
/remove-lifecycle rotten 하여 최신 문제로 표시합니다.
썩은 문제는 추가로 30 일 동안 사용하지 않으면 닫힙니다.

이 문제를 지금 종료해도 안전하다면 /close 하여 종료하세요.

sig-testing, kubernetes / test-infra 및 / 또는 fejta에 피드백을
/ lifecycle rotten

썩은 문제는 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 rotten

@tuminoid : 본인이 저작하거나 공동 작업자가 아닌 이상 이슈 / PR을 다시 열 수 없습니다.

/다시 열다
/ remove-lifecycle rotten

@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이 Docker 컨테이너에 연결할 수없고 현재 종료 포드가 존재하여 새 포드를 만들 수 없다고 불평하기 때문에 로그를 확인할 수 없습니다. 오히려 짜증나.

이를 경험하고 Kubernetes가 이전 포드를 적절하게 정리했는지 확인해야하는 것은 다소 성가신 일입니다.
이 문제가 곧 해결되기를 바랍니다.

이 문제는 어떻습니까? 해결 되었습니까? 나는 동일하지만 이것은 즉시 발생하지 않지만 노드가 시작된 후 얼마 동안 노드를 재설정하면 얼마 동안 모든 것이 좋습니다

팟 (Pod)에 파이널 라이저 (Finalizers)가 삭제되지 않도록하고 있는지 확인할 수 있습니까?

발급 된 포드에 종료자가 없습니다.

참고로 다음을 사용하여 강제 삭제로이 문제를 해결했습니다.

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 은 (는) 일시적인 수정입니다. 영향을받는 포드 중 하나에 대한 장애 조치가 발생할 때마다 수동 수정을 실행하고 싶지 않습니다. 내 사육사 포드가 minikube 및 Azure AKS에서 종료되지 않습니다.

2020 년 3 월 9 일 업데이트
preStop 수명주기 후크를 사용하여 포드를 수동으로 종료했습니다. 내 사육사 포드가 종료 상태에 갇혀 컨테이너 내부의 기간 신호에 응답하지 않습니다. 나는 기본적으로 다른 곳에서 동일한 매니페스트를 실행했으며 모든 것이 올바르게 종료되며 근본 원인이 무엇인지 알 수 없습니다.

같은 문제, 매우 짜증나

같은 문제 :( 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 강제로 삭제가 발생한다는 것입니다. :) 귀하의 댓글이 왜 관련이 있는지 확실하지 않습니다.

그의 의견은 관련성이 있다고 생각합니다.
(도커 또는 기타) 아직 실행 중일 수 있으며 완전히 삭제되지 않았습니다 ..,
"제거 된"환상은 때때로 약간 오해의 소지가 있습니다.

2020 년 6 월 4 일 목요일 오전 9:16, Conner Stephen McCabe <
[email protected]> 작성 :

참고로 다음을 사용하여 강제 삭제로이 문제를 해결했습니다.

kubectl delete pods--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

가이드는 참조를 제거하지만 포드 자체는 삭제하지 않는다고 언급합니다 (출처 : '강제 삭제'-https://kubernetes.io/docs/tasks/run-application/force-delete-stateful-set-pod/ ) 그러나 grace-period = 0은 즉시가 아니라 효과적으로 포드를 시그 킬해야합니다.

나는 문서와 내가 만난 시나리오를 처리하는 권장 방법을 읽고 있습니다. 내가 특별히 만난 문제는 되풀이되는 문제가 아니며 한 번 발생한 문제였습니다. 이 문제에 대한 REAL 수정은 배포를 수정하는 것이라고 생각하지만 여기에 도달 할 때까지이 방법이 도움이 될 것입니다.

@ elrok123 Brilliant-나는 실제로 정보가 좋지 않았습니다. 이 설명을 참조하여 위의 응답을 업데이트했습니다. 자세한 응답과 문제가있는 포드를 처리하는 동기 부여 방법에 감사드립니다. 건배!

현재 포드가 종료 상태에서 2 일 이상 멈춰 있습니다.

나를 위해 네임 스페이스는 Terminating 있습니다. 목록에 포드가 없습니다. 서비스 없음 ... 아무것도. 네임 스페이스가 비어 있습니다. 여전히 ... 종료 중입니다.

@JoseFMP 는 kubectl을 사용하여 네임 스페이스에서 yaml을 요청합니다. 프로세스를 유지하는 종료자가있을 수 있습니다.

@JordyBottelier 감사합니다.

종료자가 없습니다. 여전히 Terminating

@JoseFMP는 여기에서 완전히 제거하고 (효과적으로 핵을 제거하는) 스크립트로 저장하고 ./script_name을 실행합니다.:
```

! / bin / bash

-eo pipefail 설정

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

need () {
어느 "$ 1"&> / dev / null || die "바이너리 '$ 1'이 누락되었지만 필수입니다."
}

사전 요구 사항 확인

"jq"필요
"컬"필요
"kubectl"필요

PROJECT = "$ 1"
시프트

테스트 -n "$ PROJECT"|| die "누락 된 인수 : kill-ns"

kubectl 프록시 &> / dev / null &
PROXY_PID = $!
killproxy () {
$ PROXY_PID 죽이기
}
killproxy EXIT 트랩

sleep 1 # 프록시에 1 초주기

kubectl get namespace "$ PROJECT"-o json | jq 'del (.spec.finalizers [] | select ( "kubernetes"))'| curl -s -k -H "Content-Type : application / json"-X PUT -o / dev / null --data-binary @ -http : // localhost : 8001 / api / v1 / namespaces / $ PROJECT / finalize && echo "사멸 된 네임 스페이스 : $ PROJECT"```

또한 인프라에서 더 이상 표시되지 않지만 여전히 고스트로 실행되는 하나의 포드를 포함하여 여러 포드가 종료되는 동안 멈춰있는 것처럼 보였습니다 (요청을 처리하고 배포 규모에서도 요청이 제공되는 것을 볼 수 있습니다. 0의).

이 포드에 대한 가시성 또는 제어 권한이 없으며 모든 노드를 강제로 종료하지 않고 이와 같은 상황을 해결하는 방법을 묻습니다.

또한 인프라에서 더 이상 표시되지 않지만 여전히 고스트로 실행되는 하나의 포드를 포함하여 여러 포드가 종료되는 동안 멈춰있는 것처럼 보였습니다 (요청을 처리하고 배포 규모에서도 요청이 제공되는 것을 볼 수 있습니다. 0의).

이 포드에 대한 가시성 또는 제어 권한이 없으며 모든 노드를 강제로 종료하지 않고 이와 같은 상황을 해결하는 방법을 묻습니다.

노드의 도커에 액세스해야합니다.
내 dink (https://github.com/Agilicus/dink)를 사용하면 Docker 액세스가있는 셸이있는 포드를 가져 오거나 포드에 대한 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 실패 : exec 실패 : 중지 된 컨테이너를 실행할 수 없음 : 알 수 없음. 이 메시지는 영원히 반복되며 exec 프로브를 tcpSocket으로 변경하면 pod가 종료되는 것처럼 보입니다 (테스트에 따라 후속 조치가 수행됩니다). 포드에 "실행 중"컨테이너 중 하나가 있지만 "준비"가 아닌 것 같습니다. "실행 중"컨테이너에 대한 로그는 서비스가 중지 된 것처럼 표시됩니다.

이는 node로드가 높고 vm.max_map_count가 기본값보다 높은 값으로 설정된 containerd 1.4.0에서 발생합니다. containerd-shim은 stdout fifo를 드레 이닝하지 않고 드레 이닝되기를 기다리는 블록을 차단하지만 dockerd는 프로세스가 사라 졌다는 containerd의 이벤트 / 승인.

@discanto 이 정보를 공유해 주셔서 감사합니다. 문제가 수정되거나 추적되고 있습니까?

@ Random-Liu

버그가 3 년 이상 열렸습니다. 종료시 포드가 멈춘 이유는 여러 가지가 있습니다. 사례를보고 할 때 일부 kubelet 로그를 게시하여 포드가 멈췄는지 확인하는 것이 매우 유용합니다.