我们的场景就是想通过删除 Pod 解决一些容器内部署的应用本身的问题，比如 JVM 的 OOM 等问题，但是重启 Pod 后自动重建是比较慢的，因为要调度到其他机器再拉镜像 balabala 。重启 container 的速度是比重启 Pod 快不少的，但是 K8S 好像没有现成的能重启 container 的 API 。stack 上说有比较不优雅的方式就是 kubectl exec -it xxx kill 1，这样貌似确实可以重启 container，但是不知道有没有风险。不知道是确实没有 API 还是我没找到。如果没有 API 的话，大家有啥稳定的方式重启 container ？
This topic created in 1880 days ago, the information mentioned may be changed or developed.
 | 1 TomatoAres Mar 18, 2021 docker restart [container_id] |
 | 2 eric96 Mar 18, 2021 kill 1 |
| 3 eric96 Mar 18, 2021 优雅关闭，需要钩子。据我所知，只有关闭 pod 才支持钩子。想要重启容器，除非程序本身退出就是优雅的，不然得自己想办法去保证 |
 | 4 wxsm Mar 18, 2021 via iPhone 在 container 内定义杀进程钩子，可以通过 http 请求调用。内网通过 pod ip 访问即可 |
 | 5 zhoudaiyu OP PRO |
 | 7 corvofeng Mar 18, 2021 via Android 我们自己集群没有给用户重启这个功能， 只允许删除重建。 如果 docker 分层比较好， 而且是内网 dockerhub， pull 也不太慢吧 |
 | 8 Usaki Mar 18, 2021 via Android crictl rmp [pod name] |
 | 9 dandankele Mar 18, 2021  1 配置 livenessprobe 检测到不健康不就重启了吗？ |
 | 10 ETiV Mar 18, 2021 via iPhone 1 有个命令可以滚动重启的（ rollout 后面接个什么参数，忘了）， 你要的应该是服务稳定，而不是重启得快 |
 | 11 vzard Mar 18, 2021 内网仓库拉镜像应该很快的 |
 | 12 kennylam777 Mar 18, 2021 2 livenessprobe 做, 然後配合 readinessprobe , 等新的 pod 上後才停掉的 |
 | 13 bwangel Mar 18, 2021 12 楼正解，存活探针。 https://kubernetes.io/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-liveness-HTTP-request 应用提供一个接口，k8s 会每过 N 秒就请求一次，如果这个接口返回了 500，那么 k8s 就会重启 pod 中的容器。 |
| 14 zhoudaiyu OP PRO |
| 15 kennylam777 Mar 18, 2021 1 @zhoudaiyu 但是直接重 process 也掉有, 如果用 readyness 的, 配合好 service IP 的, pod 在 termination 十秒的新的求被引到新 pod, 而的在 termination grace period 下仍能生存一 |
| 16 zhoudaiyu OP PRO @kennylam777 我感觉主要还是现在探针不好使 如果确实能反应应用可用性 就不需要过多的人为操作了 |
 | 17 12101111 Mar 18, 2021 容器里放一个守护进程，OOM 了自己重启，重启不了就自杀让 Pod 重建 |
 | 18 tiedan Mar 18, 2021 kill -HUP |
| 19 kennylam777 Mar 18, 2021 @zhoudaiyu 探可以是最的 TCP, 然後是 HTTP, 最後著是 exec 直接跑 command, 只要你要求的可用性都能用一固定及可以循的方法返回 exit code 就可以 是有要求的 exec 玩法可以 Pod 去用外部的果去 k8s 做判 |
| 20 bwangel Mar 19, 2021 |
 | 21 lifanxi Mar 19, 2021 镜象如果太大应该尽可能优化大小，实在不能再小的情况下，可以在所有机器上预先把镜象 pull 好，这样 Pod 可以随便 Failover 都可以秒启。 |
| 23 zhoudaiyu OP PRO @lifanxi 镜像普遍接近 1G 左右，已经做过镜像瘦身了，我说镜像可能只是一方面，还有别的耗时的地方，主要是在 container creating 这个阶段 |
| 24 zhoudaiyu OP PRO @kennylam777 是的，其实我们我在让别的组做 HTTP 探针，就像 SpringBoot Actuator 这种 |
 | 25 RedrumSherlock Mar 19, 2021 via Android 只说镜像的话，如果 imagePullPolicy 设成 ifNotPresent 的话是不会重新拉的，这也是默认和推荐的设置 |
| OP PRO @RedrumSherlock 现在就么配置的 |
 | 27 cassyfar Mar 19, 2021 @zhoudaiyu k8s liveness and readiness 的检测肯定得反应你服务真是健康情况啊。你这样只检测端口，毫无意义。你的服务肯定得有个 endpoint 去返回 health status 。 讲道理 container creating 多长时间是没关系的。 |
 | 29 Lee2019 Mar 19, 2021 @lifanxi 你应该是这台 node 上面已经有这个 20G 的镜像而不需要重新 pull 镜像了 如果你 pod 调度到没有这个镜像的 node 上，那么肯定会耗一定的时间在拉镜像上 |
| 30 Lee2019 Mar 19, 2021 |
| 31 zhoudaiyu OP PRO |
 | 32 zorui Mar 19, 2021 java 跑在 K8S 的问题，spring 应用更恼火启动时会初始化一堆东西。 GraalVM 成熟了重建快很多 |
Select Language