我已经用命令启动了豆荚

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

出了点问题,现在我没法删除这个Pod了。

我尝试使用下面描述的方法,但Pod不断被重新创建。

$ 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

当前回答

在我的例子中,我通过像kubectl apply -f deployment这样的YAML文件进行部署。解决方案似乎是通过kubectl delete -f deployment.yaml删除

其他回答

在我的例子中,我通过像kubectl apply -f deployment这样的YAML文件进行部署。解决方案似乎是通过kubectl delete -f deployment.yaml删除

您需要删除部署,然后再删除pod和副本集https://github.com/kubernetes/kubernetes/issues/24137

列出所有部署:

kubectl get deployments --all-namespaces

然后删除部署:

kubectl delete -n NAMESPACE deployment DEPLOYMENT

其中NAMESPACE是它所在的名称空间,DEPLOYMENT是部署的名称。如果NAMESPACE是默认值,则完全取消-n选项。

在某些情况下,它也可能由于作业或守护进程启动而运行。 检查以下内容并运行相应的删除命令。

kubectl get jobs

kubectl get daemonsets.app --all-namespaces

kubectl get daemonsets.extensions --all-namespaces

在某些情况下,即使删除部署,pod仍然不会消失。在这种情况下,要强制删除它们,可以运行以下命令。

Kubectl删除pods podname——grace-period=0——force

这里的许多答案都告诉我们删除一个特定的k8s对象,但你可以一次删除多个对象,而不是一个一个地删除:

Kubectl删除部署、作业、服务、pods——所有-n <命名空间>

在我的例子中,我使用OLM -操作员生命周期管理器运行OpenShift集群。OLM是控制部署的人,所以当我删除部署时,它不足以阻止pods重新启动。

只有当我删除OLM及其订阅时,部署、服务和pod才消失了。

首先列出命名空间中的所有k8s对象:

$ 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没有与get all一起列出,所以我专门搜索了它:

$ 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 

现在删除所有对象,包括olm、订阅、部署、副本集等:

$ 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

再次列出对象-全部消失:

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

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

这个问题的根本原因是deployment/job/replicasets spec属性策略->类型,它定义了pod将被销毁(隐式或显式)时应该发生什么。对我来说,是“再造”。

根据@nomad的回答,删除部署/作业/复制集是一个简单的修复方法,以避免在新手用户搞砸集群之前尝试致命的组合。

在开始调试之前,尝试以下命令来理解幕后操作:

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