Strąki utknęły w stanie Zakończenia

Próbowałem usunąć plik ReplicationControllerz 12 zasobnikami i mogłem zobaczyć, że niektóre zasobniki utknęły w Terminatingstanie.

Mój klaster Kubernetes składa się z jednego węzła płaszczyzny sterowania i trzech węzłów roboczych zainstalowanych na maszynach wirtualnych Ubuntu.

Co może być przyczyną tego problemu?

NAME        READY     STATUS        RESTARTS   AGE
pod-186o2   1/1       Terminating   0          2h
pod-4b6qc   1/1       Terminating   0          2h
pod-8xl86   1/1       Terminating   0          1h
pod-d6htc   1/1       Terminating   0          1h
pod-vlzov   1/1       Terminating   0          1h

Możesz użyć następującego polecenia, aby wymusić usunięcie POD.

kubectl delete pod <PODNAME> --grace-period=0 --force --namespace <NAMESPACE>

Wymuś usunięcie zasobnika:

kubectl delete pod --grace-period=0 --force --namespace <NAMESPACE> <PODNAME>

--forceFlaga jest obowiązkowe.

Usuń blok finalizatorów z zasobu (pod, wdrożenie, ds itp.) Yaml:

"finalizers": [
  "foregroundDeletion"
]

Praktyczna odpowiedź - zawsze możesz usunąć zamykający moduł, uruchamiając:

kubectl delete pod NAME --grace-period=0

Odpowiedź historyczna - w wersji 1.1 występował problem polegający na tym, że czasami strąki pozostawały w stanie Zakończenia, jeśli ich węzły zostały nieczysto usunięte z klastra.

Znalazłem to polecenie bardziej proste:

for p in $(kubectl get pods | grep Terminating | awk '{print $1}'); do kubectl delete pod $p --grace-period=0 --force;done

Usunie wszystkie zasobniki w stanie Zakończenia w domyślnej przestrzeni nazw.

W moim przypadku --forceopcja nie do końca działała. Nadal widziałem kapsułę! Utknął w trybie kończącym / nieznanym. Więc po uruchomieniu

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

Pobiegłem

kubectl patch pod <pod> -p '{"metadata":{"finalizers":null}}'

Jeśli --grace-period=0nie działa, możesz:

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

Natknąłem się na to niedawno podczas usuwania przestrzeni nazw gawronu - utknął w stanie Zakończenia.

Jedyną rzeczą, która pomogła, było usunięcie finalizatora kubernetes poprzez bezpośrednie wywołanie interfejsu API k8s z curl, jak sugerowano tutaj .

• kubectl get namespace rook-ceph -o json > tmp.json
• usuń finerner kubernetes w tmp.json(zostaw pustą tablicę "finalizers": [])
• uruchom kubectl proxyw innym terminalu do celów uwierzytelniania i uruchom następujące żądanie curl do zwróconego portu
• curl -k -H "Content-Type: application/json" -X PUT --data-binary @tmp.json 127.0.0.1:8001/k8s/clusters/c-mzplp/api/v1/namespaces/rook-ceph/finalize
• Przestrzeń nazw zniknęła

Szczegółowy porzucenie wieży Ceph tutaj .

Pierwotne pytanie brzmi „ Co może być przyczyną tego problemu? ”, A odpowiedź została omówiona na stronie https://github.com/kubernetes/kubernetes/issues/51835 & https://github.com/kubernetes/kubernetes/issues / 65569 i patrz https://www.bountysource.com/issues/33241128-unable-to-remove-a-stopped-container-device-or-resource-busy

Jest to spowodowane wyciekaniem montażu dokującego do innej przestrzeni nazw.

Możesz zalogować się do hosta pod w celu sprawdzenia.

minikube ssh
docker container ps | grep <id>
docker container stop <id> 

Natknąłem się na to niedawno, aby uwolnić zasoby w moim klastrze. oto polecenie ich usunięcia.

kubectl get pods --all-namespaces | grep Terminating | while read line; do 
pod_name=$(echo $line | awk '{print $2}' ) name_space=$(echo $line | awk 
'{print $1}' ); kubectl delete pods $pod_name -n $name_space --grace-period=0 --force; 
done

mam nadzieję, że pomoże to komuś, kto to przeczyta