精华内容
下载资源
问答
  • k8s删除pod

    千次阅读 2019-05-07 12:06:47
    1、先删除pod 2、再删除对应的deployment 否则只是删除pod是不管用的,还会看到pod,因为deployment.yaml文件中定义了副本数量 实例如下: 删除pod [root@test2 ~]# kubectl get pod -n jenkins NAME READY ...

    1、先删除pod

    2、再删除对应的deployment

    否则只是删除pod是不管用的,还会看到pod,因为deployment.yaml文件中定义了副本数量


    实例如下:

    删除pod

    [root@test2 ~]# kubectl get pod -n jenkins
    NAME                        READY     STATUS    RESTARTS   AGE
    jenkins2-8698b5449c-grbdm   1/1       Running   0          8s
    [root@test2 ~]# kubectl delete pod jenkins2-8698b5449c-grbdm -n jenkins
    pod "jenkins2-8698b5449c-grbdm" deleted

    查看pod仍然存储

    [root@test2 ~]# kubectl get pod -n jenkins
    NAME                        READY     STATUS    RESTARTS   AGE
    jenkins2-8698b5449c-dbqqb   1/1       Running   0          8s
    [root@test2 ~]# 

    删除deployment

    [root@test2 ~]# kubectl get deployment -n jenkins
    NAME       DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
    jenkins2   1         1         1            1           17h
    [root@test2 ~]# kubectl delete deployment jenkins2 -n jenkins

    再次查看pod消失

    deployment.extensions "jenkins2" deleted
    [root@test2 ~]# kubectl get deployment -n jenkins
    No resources found.
    [root@test2 ~]# 
    [root@test2 ~]# kubectl get pod -n jenkins
    No resources found.

    展开全文
  • K8s删除pod

    2020-08-22 18:11:20
    1.先删除deployment : kubectl delete deployment hello-world-1 2.再删除pod:kubectl delete pod hello-world-1-848d769b64-5g9nm

    1.先删除deployment : kubectl delete deployment hello-world-1
    2.再删除pod:kubectl delete pod hello-world-1-848d769b64-5g9nm

    展开全文
  • k8s 删除pod

    2019-07-05 16:32:42
    删除pod删除对应的deployment 否则只是删除pod是不管用的,还会看到pod,因为deployment.yaml文件中定义了副本数量 实例如下: 删除pod [root@test2 ~]# kubectl get pod -n jenkins NAME READY STATUS ...

    先删除pod

    再删除对应的deployment

    否则只是删除pod是不管用的,还会看到pod,因为deployment.yaml文件中定义了副本数量


    实例如下:

    删除pod

    [root@test2 ~]# kubectl get pod -n jenkins
    NAME                        READY     STATUS    RESTARTS   AGE
    jenkins2-8698b5449c-grbdm   1/1       Running   0          8s
    [root@test2 ~]# kubectl delete pod jenkins2-8698b5449c-grbdm -n jenkins
    pod "jenkins2-8698b5449c-grbdm" deleted

    查看pod仍然存储

    [root@test2 ~]# kubectl get pod -n jenkins
    NAME                        READY     STATUS    RESTARTS   AGE
    jenkins2-8698b5449c-dbqqb   1/1       Running   0          8s
    [root@test2 ~]# 

    删除deployment

    [root@test2 ~]# kubectl get deployment -n jenkins
    NAME       DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
    jenkins2   1         1         1            1           17h
    [root@test2 ~]# kubectl delete deployment jenkins2 -n jenkins

    再次查看pod消失

    deployment.extensions "jenkins2" deleted
    [root@test2 ~]# kubectl get deployment -n jenkins
    No resources found.
    [root@test2 ~]# 
    [root@test2 ~]# kubectl get pod -n jenkins
    No resources found.

     

    原文 https://www.cnblogs.com/effortsing/p/10496547.html

    展开全文
  • 需求k8s集群中的node节点要升级内存,以应对服务迁入、pod扩缩容导致的资源短缺;亦或是node节点宕机,此时都需要对node节点进行停机维护,那么node节点上的pod应该如何处理呢?默认迁移当node节点关机后,k8s集群并...
    5e29e7f3bf7b14c214e90b2bde8aeff5.png

    需求

    k8s集群中的node节点要升级内存,以应对服务迁入、pod扩缩容导致的资源短缺;亦或是node节点宕机,此时都需要对node节点进行停机维护,那么node节点上的pod应该如何处理呢?

    默认迁移

    当node节点关机后,k8s集群并没有立刻发生任何自动迁移动作,如果该node节点上的副本数为1,则会出现服务中断的情况。其实事实并非如此,k8s在等待5分钟后,会自动将停机node节点上的pod自动迁移到其他node节点上

    具体过程如下:

    # 1.模拟node节点停机,停止kubeletsystemctl stop kubelet# 2.集群状态# 此时停机的node点处于NotReady状态# kubectl get nodeNAME                STATUS     ROLES     AGE   VERSIONk8s-3-217   Ready        master     88d   v1.18.2k8s-3-218   NotReady      88d   v1.18.2k8s-3-219   Ready           88d   v1.18.2# 3.监控pod状态,大约等待5分钟左右,集群开始有动作# kubectl get pod -n test -o wide -n test -wNAME                                   READY   STATUS    RESTARTS   AGE   IP             NODE           NOMINATED NODE   READINESS GATEShelloworld-79956d95b4-q7jjg            1/1     Running   0          19h   10.244.1.154   k8s-3-218   helloworld-79956d95b4-q7jjg            1/1     Running   0          19h   10.244.1.154   k8s-3-218   # 5分钟后,pod终止并进行重建helloworld-79956d95b4-q7jjg            1/1     Terminating   0          19h   10.244.1.154   k8s-3-218   helloworld-79956d95b4-nnlrq            0/1     Pending       0          0s    helloworld-79956d95b4-nnlrq            0/1     Pending       0          0s             k8s-3-219   helloworld-79956d95b4-nnlrq            0/1     ContainerCreating   0          1s             k8s-3-219   helloworld-79956d95b4-nnlrq            0/1     Running             0          3s    10.244.2.215   k8s-3-219   helloworld-79956d95b4-nnlrq            1/1     Running             0          66s   10.244.2.215   k8s-3-219   # 4.访问测试:在pod重新迁移到其他node节点时,服务是不可用的。# curl -x 192.168.3.219:80 hello.test.cn503 Service Temporarily Unavailable

    503 Service Temporarily Unavailable

    nginx/1.17.8
    # 5.迁移完毕:服务正常访问# curl -x 192.168.3.219:80 hello.test.cnHello,world!

    从以上过程看出,停机node节点上的pod在5分钟后先终止再重建,直到pod在新节点启动并由readiness探针检测正常后并处于11 Running状态才可以正式对外提供服务。因此服务中断时间=停机等待5分钟时间+重建时间+服务启动时间+readiness探针检测正常时间

    在此大家可能有一个疑问:为什么pod在5分钟后开始迁移呢?
    此时需要涉及到k8s中的Taint(污点)和 Toleration(容忍),这是从Kubernetes 1.6开始提供的高级调度功能。Taint和Toleration相互配合,可以避免pod被分配到不合适的节点上。每个节点上都可以应用一个或多个Taint,这表示对于那些不能容忍Taint的pod,是不会被该节点接受的。如果将Toleration应用于pod上,则表示这些pod可以(但不要求)被调度到具有匹配Taint的节点上。

    具体来分析下:

    # 1.查看停止服务节点的状态# kubelet停止后,node节点自动添加了Taints;# kubectl describe node k8s-3-218Name:               k8s-3-218Roles:              CreationTimestamp:  Fri, 22 May 2020 11:36:16 +0800Taints:             node.kubernetes.io/unreachable:NoExecute                    node.kubernetes.io/unreachable:NoScheduleUnschedulable:      falseLease:  HolderIdentity:  k8s-3-218  AcquireTime:       RenewTime:       Wed, 19 Aug 2020 09:31:22 +0800Conditions:  Type                 Status    LastHeartbeatTime                 LastTransitionTime                Reason              Message  ----                 ------    -----------------                 ------------------                ------              -------  NetworkUnavailable   False     Tue, 18 Aug 2020 09:07:59 +0800   Tue, 18 Aug 2020 09:07:59 +0800   FlannelIsUp         Flannel is running on this node  MemoryPressure       Unknown   Wed, 19 Aug 2020 09:29:56 +0800   Wed, 19 Aug 2020 09:32:07 +0800   NodeStatusUnknown   Kubelet stopped posting node status.  DiskPressure         Unknown   Wed, 19 Aug 2020 09:29:56 +0800   Wed, 19 Aug 2020 09:32:07 +0800   NodeStatusUnknown   Kubelet stopped posting node status.  PIDPressure          Unknown   Wed, 19 Aug 2020 09:29:56 +0800   Wed, 19 Aug 2020 09:32:07 +0800   NodeStatusUnknown   Kubelet stopped posting node status.  Ready                Unknown   Wed, 19 Aug 2020 09:29:56 +0800   Wed, 19 Aug 2020 09:32:07 +0800   NodeStatusUnknown   Kubelet stopped posting node status....省略...Events:              # 2.查看pod状态# kubectl describe pod helloworld-8565c4687b-rrfmj -n testName:                      helloworld-8565c4687b-rrfmjNamespace:                 testPriority:                  0......Node-Selectors:  Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s                 node.kubernetes.io/unreachable:NoExecute for 300sEvents:          

    此时pod的Tolerations 默认对于具有相应Taint的node节点容忍时间为300s,超过此时间pod将会被驱逐到其他可用node节点上。因此5分钟后node节点上所有的pod重新被调度,在此期间服务是中断的。

    既然默认的pod迁移无法避免服务中断,那么我们在node节点停机前,我们手动迁移是否可以?

    efedc0200af08fd95a61a5bf30cd0b0e.png

    手动迁移

    为避免等待默认的5分钟,我们还可以使用cordon、drain、uncordor三个命令实现节点的主动维护。此时需要用到以下三个命令:

    • cordon:标记节点不可调度,后续新的pod不会被调度到此节点,但是该节点上的pod可以正常对外服务;
    • drain:驱逐节点上的pod至其他可调度节点;
    • uncordon:标记节点可调度;

    具体操作过程如下:

    # 1.标记节点不可调度# kubectl cordon k8s-3-219node/k8s-3-219 cordoned# 查看节点状态,此时219被标记为不可调度# kubectl get nodeNAME           STATUS                     ROLES    AGE   VERSIONk8s-3-217   Ready                      master   89d   v1.18.2k8s-3-218   Ready                         88d   v1.18.2k8s-3-219   Ready,SchedulingDisabled      88d   v1.18.2# 2.驱逐pod# kubectl drain k8s-3-219 --delete-local-data --ignore-daemonsets --forcenode/k8s-3-219 already cordonedWARNING: ignoring DaemonSet-managed Pods: ingress-nginx/nginx-ingress-controller-gmzq6, kube-system/kube-flannel-ds-amd64-5gfwh, kube-system/kube-proxy-vdckkevicting pod kube-system/tiller-deploy-6c65968d87-75pfmevicting pod kube-system/metrics-server-7f96bbcc66-bgt7jevicting pod test/helloworld-79956d95b4-nnlrq# 参数如下:--delete-local-data  删除本地数据,即使emptyDir也将删除;--ignore-daemonsets  忽略DeamonSet,否则DeamonSet被删除后,仍会自动重建;--force  不加force参数只会删除该node节点上的ReplicationController, ReplicaSet, DaemonSet,StatefulSet or Job,加上后所有pod都将删除;# 3. 查看驱逐,219上的pod迁移到218上了。# kubectl get pod -n test -o wideNAME                                   READY   STATUS        RESTARTS   AGE   IP             NODE           NOMINATED NODE   READINESS GATEShelloworld-79956d95b4-gg58c            0/1     Running       0          20s   10.244.1.165   k8s-3-218   helloworld-79956d95b4-nnlrq            1/1     Terminating   0          77m   10.244.2.215   k8s-3-219   

    此时与默认迁移不同的是,pod会先重建再终止,此时的服务中断时间=重建时间+服务启动时间+readiness探针检测正常时间,必须等到1/1 Running服务才会正常。因此在单副本时迁移时,服务终端是不可避免的

    如何能够做到平滑迁移呢?我们继续往下看。

    平滑迁移

    要做到平滑迁移就需要用的pdb(PodDisruptionBudget),即主动驱逐保护。无论是默认迁移和手动迁移,都会导致服务中断,而pdb能可以实现节点维护期间不低于一定数量的pod正常运行,从而保证服务的可用性。

    在仍以helloworld为例,由于只有一个副本,因此需要保证维护期间这个副本在迁移完成后,才会终止。

    # 从218 驱逐到 219# 1.标记节点不可调度# kubectl cordon k8s-3-218node/k8s-3-218 cordoned# 2.新建pdbvim pdb-test.yamlapiVersion: policy/v1beta1kind: PodDisruptionBudgetmetadata:  name: pdb-test  namespace: testspec:  minAvailable: 1  selector:    matchLabels:      app: helloworld# 2.应用并查看状态# kubectl apply -f pdb-test.yaml# kubectl get pdb -n testNAME       MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGEpdb-test   1                         N/A                          0                                       7s# 3.驱逐# kubectl drain k8s-3-218 --delete-local-data --ignore-daemonsets --forcenode/k8s-3-218 already cordonedWARNING: ignoring DaemonSet-managed Pods: ingress-nginx/nginx-ingress-controller-hhb6h, kube-system/kube-flannel-ds-amd64-pb4d7, kube-system/kube-proxy-rzdcjevicting pod kube-system/tiller-deploy-6c65968d87-ktqmmevicting pod kube-system/metrics-server-7f96bbcc66-6p6wmevicting pod test/helloworld-79956d95b4-gg58cerror when evicting pod "helloworld-79956d95b4-gg58c" (will retry after 5s): Cannot evict pod as it would violate the pod's disruption budget.evicting pod test/helloworld-79956d95b4-gg58cerror when evicting pod "helloworld-79956d95b4-gg58c" (will retry after 5s): Cannot evict pod as it would violate the pod's disruption budget.pod/tiller-deploy-6c65968d87-ktqmm evicted#此时由于只有一个副本,最小可用为1,则ALLOWED就为0,因此在一个副本通过pdb是不会发生驱逐的。我们需要先扩容,将副本数调整为大于1。# 3.手动调整副本数,将replicas为2kubectl edit deploy helloworld -n test# 再次查看pdb# kubectl get pdb -n testNAME       MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGEpdb-test   1               N/A               1                     13m#此时最小可用为1 ,ALLOWED为1,此时是数量会自动计算。# 4.驱逐# kubectl drain k8s-3-218 --delete-local-data --ignore-daemonsets --force# 5.维护完毕,将node调整为可调度# kubectl uncordon k8s-3-218

    本次驱逐,由于helloworld始终保持有一个pod在提供服务,因此服务是不中断的
    最后将副本数可以调节为1并将node节点调整为可调度,维护完毕。

    993ff1ecb6b344551f3d62dcb13ab48f.png

    总结

    通过简单了解了Taint(污点)和 Toleration(容忍)作用,我们既可以通过设置tolerationSeconds来缩短等待时间,也可以自行定义匹配规则实现符合实际情况的调度规则。


    另外还要注意先重建再终止先终止再重建,在此过程中服务启动时间和探针检测时间决定你的服务中断时间。

    展开全文
  • 1、引言由谷歌开源推出的k8s,作为现在容器编排领域的事实标准,已经被各大云计算厂商及互联网公司广泛推崇使用。熟悉k8s的小伙伴们可能都知道k8s中有一个很重要的DNS组件,叫CoreDNS,作为一个专注于DNS领域干货...
  • k8s 删除 pod 及 service

    2020-12-20 22:56:21
    2、删除deployment(先删除deployment,删除后replicaset.apps 和 pod 自动就被删除了) kubectl deletedeployment.apps/nginx-1596365264-controller -n kube-system kubectl deletedeployment....
  • k8s删除pod一直处于terminating状态

    千次阅读 2021-02-25 23:31:26
    用的nfs挂载卷,当删除pv后再删除pod时,pod一直处于terminating状态。 解决办法: 强制删除 # 删除POD kubectl delete pod [pod name] --force --grace-period=0 -n [namespace] # 删除NAMESPACE kubectl ...
  • 删除pod kubectl delete pod <podname> 然后再查看所有pod,发现又新建了一个pod. 这是因为deployment.yaml文件中定义了副本数量,所以还需要删除副本。 查看deployment kubectl get deployment <name>...
  • 这种情况下可以使用强制删除命令: kubectl delete pod [pod name] --force --grace-period=0 -n [namespace] 注意:必须加-n参数指明namespace,否则可能报错pod not found。
  • k8s删除pod、node前的注意事项

    千次阅读 2019-01-30 15:58:00
    删除pod,或者node之前,需要注意容器是否正在运行,不然后续会报错,导致容器停止后自动重启等问题 docker报错rpc error: code = 14 desc = grpc: the connection is unavailable 下面是首先需要操作的(顺序不能...
  • k8s更新版本后,老的POD一直出现Terminating,多久都不能删除。 然后,进入具体的节点机器之后,查看日志输出如下类似: ERROR: driver "overlay" failed to remove root filesystem for 738f492a57f80951b279c3bd...
  • https://blog.csdn.net/weixin_41988331/article/details/100886789
  • k8sPod重启方法

    万次阅读 2019-10-29 21:07:35
    在使用 docker 的过程中,我们可以使用docker restart {container_id}来重启容器,但是在 kubernetes 中并没有重启命令(没有 kubectl restart {podname}),有时候我们的 Pod 出现 Bug意外终止,导致我们需要重启 ...
  • k8s 创建pod删除pod

    千次阅读 2020-04-28 14:38:10
    1、查看所有pod [root@k8s1 ~]# kubectl get pods --all-namespaces 2、下载nginx镜像 https://hub.docker.com/_/nginx?tab=tags ##浏览器打开 3、pull到docker仓库 [root@k8s1 ~]#docker pull nginx:stable...
  • k8s-pod

    2020-09-01 01:04:36
    podk8s集群最小调度单位 pod控制器类型 RC(ReplicationController) 可以保证容器应用副本数始终保持在用户自定义的副本数,少则创建,多则回收 RS(ReplicaSet)和RC没有本质区别,支持集合式selector ...
  • 强制删除k8spod

    千次阅读 2019-02-19 22:57:04
    序言 好久不摸k8s,快忘记怎么玩了,离技术的距离越来越远了。 如果每天都是一个故障,每天都复盘一下,你就知道你的时间都浪费在哪儿了。强制删除pod 故事背...
  • k8s查看pod的命令

    万次阅读 2019-11-13 09:19:41
    kubectl get pod 参数解析 NAME pod名 READY 准备好的副本数 STATUS 状态 RESTARTS 重启 AGE 已经运行的时间 查看pod资源(较详细) kubectl get pod -o wide 参数解析 IP ip地址 NODE 运行节点 NOMINATED NODE 指定...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 16,914
精华内容 6,765
关键字:

k8s删除pod