Po usunięciu pod Kubernetes zostanie odtworzony

Zacząłem kapsuły na polecenie

$ kubectl run busybox --image=busybox --restart=Never --tty -i --generator=run-pod/v1

Coś poszło nie tak i teraz nie mogę tego usunąć Pod.

Próbowałem użyć metod opisanych poniżej, ale Podwciąż są odtwarzane.

$ kubectl delete pods  busybox-na3tm
pod "busybox-na3tm" deleted
$ kubectl get pods
NAME                                     READY     STATUS              RESTARTS   AGE
busybox-vlzh3                            0/1       ContainerCreating   0          14s

$ kubectl delete pod busybox-vlzh3 --grace-period=0


$ kubectl delete pods --all
pod "busybox-131cq" deleted
pod "busybox-136x9" deleted
pod "busybox-13f8a" deleted
pod "busybox-13svg" deleted
pod "busybox-1465m" deleted
pod "busybox-14uz1" deleted
pod "busybox-15raj" deleted
pod "busybox-160to" deleted
pod "busybox-16191" deleted


$ kubectl get pods --all-namespaces
NAMESPACE   NAME            READY     STATUS              RESTARTS   AGE
default     busybox-c9rnx   0/1       RunContainerError   0          23s

Musisz usunąć wdrożenie, co z kolei powinno usunąć pody i zestawy replik https://github.com/kubernetes/kubernetes/issues/24137

Aby wyświetlić listę wszystkich wdrożeń:

kubectl get deployments --all-namespaces

Następnie, aby usunąć wdrożenie:

kubectl delete -n NAMESPACE deployment DEPLOYMENT

Gdzie NAMESPACE to przestrzeń nazw, w której się znajduje, a DEPLOYMENT to namewdrożenie.

W niektórych przypadkach może również działać z powodu zadania lub zestawu demonów. Sprawdź poniższe i uruchom odpowiednie polecenie usuwania.

kubectl get jobs

kubectl get daemonsets.app --all-namespaces

kubectl get daemonsets.extensions --all-namespaces

Zamiast próbować dowiedzieć się, czy jest to wdrożenie, deamonset, statefulset ... czy co (w moim przypadku był to kontroler replikacji, który ciągle obejmował nowe pody :) Aby ustalić, co to było, co obejmowało obraz, ja otrzymałem wszystkie zasoby za pomocą tego polecenia:

kubectl get all

Oczywiście możesz także pobrać wszystkie zasoby ze wszystkich przestrzeni nazw:

kubectl get all --all-namespaces

lub zdefiniuj przestrzeń nazw, którą chcesz sprawdzić:

kubectl get all -n NAMESPACE_NAME

Kiedy zobaczyłem, że kontroler replikacji jest odpowiedzialny za mój problem, usunąłem go:

kubectl delete replicationcontroller/CONTROLLER_NAME

jeśli twój pod ma nazwę taką jak name-xxx-yyy, może być kontrolowany przez replicasets.apps o nazwie name-xxx, powinieneś najpierw usunąć ten zestaw replik przed usunięciem poda

kubectl delete replicasets.apps name-xxx

Zwróć także uwagę na zestawy stanowe

kubectl get sts --all-namespaces

aby usunąć wszystkie stanowe zestawy w przestrzeni nazw

kubectl --namespace <yournamespace> delete sts --all

aby usunąć je jeden po drugim

kubectl --namespace ag1 delete sts mssql1 
kubectl --namespace ag1 delete sts mssql2
kubectl --namespace ag1 delete sts mssql3

W niektórych przypadkach kapsuły nadal nie znikną, nawet po usunięciu rozmieszczenia. W takim przypadku, aby wymusić ich usunięcie, możesz uruchomić poniższe polecenie.

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

Zapewni to informacje o wszystkich zasobnikach, wdrożeniach, usługach i zadaniach w przestrzeni nazw.

kubectl get pods,services, deployments, jobs

pody mogą być tworzone przez wdrożenia lub zadania

kubectl delete job [job_name]
kubectl delete deployment [deployment_name]

Jeśli usuniesz wdrożenie lub zadanie, ponowne uruchomienie podów może zostać zatrzymane.

Wiele odpowiedzi tutaj mówi, aby usunąć określony obiekt k8s, ale możesz usunąć wiele obiektów naraz, zamiast jednego po drugim:

kubectl delete deployments,jobs,services,pods --all -n <namespace>

W moim przypadku używam klastra OpenShift z OLM - Operator Lifecycle Manager . OLM kontroluje wdrożenie, więc kiedy usunąłem wdrożenie, nie wystarczyło, aby zatrzymać ponowne uruchamianie strąków.

Dopiero gdy usunąłem OLM i jego subskrypcję , wdrożenie, usługi i pody zniknęły.

Najpierw wypisz wszystkie obiekty k8s w twojej przestrzeni nazw:

$ kubectl get all -n openshift-submariner

NAME                                       READY   STATUS    RESTARTS   AGE
pod/submariner-operator-847f545595-jwv27   1/1     Running   0          8d  
NAME                                  TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
service/submariner-operator-metrics   ClusterIP   101.34.190.249   <none>        8383/TCP   8d
NAME                                  READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/submariner-operator   1/1     1            1           8d
NAME                                             DESIRED   CURRENT   READY   AGE
replicaset.apps/submariner-operator-847f545595   1         1         1       8d

OLM nie ma na liście get all, więc szukam go konkretnie:

$ kubectl get olm -n openshift-submariner

NAME                                                      AGE
operatorgroup.operators.coreos.com/openshift-submariner   8d
NAME                                                             DISPLAY      VERSION
clusterserviceversion.operators.coreos.com/submariner-operator   Submariner   0.0.1 

Teraz usuń wszystkie obiekty, w tym OLM, subskrypcje, wdrożenia, zestawy replik itp .:

$ kubectl delete olm,svc,rs,rc,subs,deploy,jobs,pods --all -n openshift-submariner

operatorgroup.operators.coreos.com "openshift-submariner" deleted
clusterserviceversion.operators.coreos.com "submariner-operator" deleted
deployment.extensions "submariner-operator" deleted
subscription.operators.coreos.com "submariner" deleted
service "submariner-operator-metrics" deleted
replicaset.extensions "submariner-operator-847f545595" deleted
pod "submariner-operator-847f545595-jwv27" deleted

Wyświetl ponownie obiekty - wszystkie zniknęły:

$ kubectl get all -n openshift-submariner
No resources found.

$ kubectl get olm -n openshift-submariner
No resources found.

Gdy kapsuła jest odtwarzana automatycznie, nawet po ręcznym usunięciu kapsuły, wówczas te kapsuły zostały utworzone przy użyciu wdrożenia. Podczas tworzenia stanowiska automatycznie tworzy ReplicaSet i Pods. W zależności od liczby replik kapsuły wymienionej w skrypcie wdrażania początkowo utworzy tę liczbę zasobników. Gdy spróbujesz ręcznie usunąć dowolny pod, automatycznie utworzy on ponownie ten pod.

Tak, czasami trzeba siłą usunąć strąki. Ale w tym przypadku polecenie siły nie działa.

Zamiast usuwać NS możesz spróbować usunąć replicaSet

kubectl get rs --all-namespaces

Następnie usuń replicaSet

kubectl delete rs your_app_name

Po skorzystaniu z interaktywnego samouczka otrzymałem kilka podów, usług i wdrożeń:

me@pooh ~ > kubectl get pods,services
NAME                                       READY   STATUS    RESTARTS   AGE
pod/kubernetes-bootcamp-5c69669756-lzft5   1/1     Running   0          43s
pod/kubernetes-bootcamp-5c69669756-n947m   1/1     Running   0          43s
pod/kubernetes-bootcamp-5c69669756-s2jhl   1/1     Running   0          43s
pod/kubernetes-bootcamp-5c69669756-v8vd4   1/1     Running   0          43s

NAME                 TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
service/kubernetes   ClusterIP   10.96.0.1    <none>        443/TCP   37s
me@pooh ~ > kubectl get deployments --all-namespaces
NAMESPACE     NAME                  DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
default       kubernetes-bootcamp   4         4         4            4           1h
docker        compose               1         1         1            1           1d
docker        compose-api           1         1         1            1           1d
kube-system   kube-dns              1         1         1            1           1d

Aby wszystko wyczyścić, delete --alldziałało dobrze:

me@pooh ~ > kubectl delete pods,services,deployments --all
pod "kubernetes-bootcamp-5c69669756-lzft5" deleted
pod "kubernetes-bootcamp-5c69669756-n947m" deleted
pod "kubernetes-bootcamp-5c69669756-s2jhl" deleted
pod "kubernetes-bootcamp-5c69669756-v8vd4" deleted
service "kubernetes" deleted
deployment.extensions "kubernetes-bootcamp" deleted

To pozostawiło mi (wydaje mi się) pusty klaster Kubernetes:

me@pooh ~ > kubectl get pods,services,deployments
NAME                 TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
service/kubernetes   ClusterIP   10.96.0.1    <none>        443/TCP   8m

Jeśli masz zadanie, które nadal działa, musisz je przeszukać i usunąć:

kubectl get job --all-namespaces | grep <name>

i

kubectl delete job <job-name>

Możesz kubectl get replicasetssprawdzić stare wdrożenie na podstawie wieku lub czasu

Usuń stare wdrożenie na podstawie czasu, jeśli chcesz usunąć ten sam aktualnie działający moduł aplikacji

kubectl delete replicasets <Name of replicaset>

Napotkałem również problem, użyłem poniższego polecenia, aby usunąć wdrożenie.

kubectl delete deployments DEPLOYMENT_NAME

ale strąki wciąż się odtwarzały, więc przekroczyłem sprawdzenie zestawu replik za pomocą poniższego polecenia

kubectl get rs

następnie edytuj zestaw replik na 1 do 0

kubectl edit rs REPICASET_NAME

Główną przyczyną zadanego pytania był atrybut specyfikacji deployment / job / replicasets, strategy->typektóry definiuje, co powinno się zdarzyć, gdy pod zostanie zniszczony (niejawnie lub jawnie). W moim przypadku tak było Recreate.

Zgodnie z odpowiedzią @ nomad , usunięcie zestawów wdrożeniowych / zadań / replik jest prostym rozwiązaniem pozwalającym uniknąć eksperymentowania ze śmiercionośnymi kombinacjami przed zepsuciem klastra jako początkujący użytkownik.

Wypróbuj następujące polecenia, aby zrozumieć działania za kulisami, zanim przejdziesz do debugowania:

kubectl get all -A -o name
kubectl get events -A | grep <pod-name>

W moim przypadku wdrożyłem za pomocą pliku YAML, takiego jak kubectl apply -f deployment.yamli wydaje się, że rozwiązaniem jest usunięcie za pośrednictwemkubectl delete -f deployment.yaml

Doświadczyłem podobnego problemu: po usunięciu wdrożenia ( kubectl delete deploy <name>) pody nadal działały i były automatycznie tworzone ponownie po usunięciu (kubectl delete po <name> ).

Okazało się, że skojarzony zestaw replik nie został z jakiegoś powodu usunięty automatycznie, a po usunięciu tego ( kubectl delete rs <name>) można było usunąć pody.

W przypadku wdrożeń, które mają zestawy stanowe (lub usługi, zadania itp.), Możesz użyć tego polecenia:

To polecenie kończy wszystko, co działa w określonym <NAMESPACE>

kubectl -n <NAMESPACE> delete replicasets,deployments,jobs,service,pods,statefulsets --all

I mocny

kubectl -n <NAMESPACE> delete replicasets,deployments,jobs,service,pods,statefulsets --all --cascade=true --grace-period=0 --force