K8S 有没有能直接重新 Pod 中的 container 的 API？

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 1380 天前的主题，其中的信息可能已经有所发展或是发生改变。

我们的场景就是想通过删除 Pod 解决一些容器内部署的应用本身的问题，比如 JVM 的 OOM 等问题，但是重启 Pod 后自动重建是比较慢的，因为要调度到其他机器再拉镜像 balabala 。重启 container 的速度是比重启 Pod 快不少的，但是 K8S 好像没有现成的能重启 container 的 API 。stack 上说有比较不优雅的方式就是 kubectl exec -it xxx kill 1，这样貌似确实可以重启 container，但是不知道有没有风险。不知道是确实没有 API 还是我没找到。如果没有 API 的话，大家有啥稳定的方式重启 container ？

33 条回复 • 2021-03-19 20:15:48 +08:00

TomatoAres

2021-03-18 16:10:45 +08:00

docker restart [container_id]

eric96

2021-03-18 17:56:52 +08:00

kill 1

eric96

2021-03-18 17:58:42 +08:00

优雅关闭，需要钩子。据我所知，只有关闭 pod 才支持钩子。想要重启容器，除非程序本身退出就是优雅的，不然得自己想办法去保证

wxsm

2021-03-18 18:10:48 +08:00 via iPhone

在 container 内定义杀进程钩子，可以通过 http 请求调用。内网通过 pod ip 访问即可

zhoudaiyu

2021-03-18 18:15:47 +08:00

@TomatoAres 最好是 k8s 的 api，这样平台好对接。。。

@eric96 kill 1 不算优雅吗？ kill -9 1 算不优雅吧

@wxsm 程序自杀的钩子？

wxsm

2021-03-18 18:16:46 +08:00 via iPhone

@zhoudaiyu 对

corvofeng

2021-03-18 18:28:58 +08:00 via Android

我们自己集群没有给用户重启这个功能，只允许删除重建。如果 docker 分层比较好，而且是内网 dockerhub， pull 也不太慢吧

Usaki

2021-03-18 19:28:25 +08:00 via Android

crictl rmp [pod name]

dandankele

2021-03-18 20:06:20 +08:00

配置 livenessprobe 检测到不健康不就重启了吗？

ETiV

2021-03-18 20:09:58 +08:00 via iPhone

有个命令可以滚动重启的（ rollout 后面接个什么参数，忘了），

你要的应该是服务稳定，而不是重启得快

vzard

2021-03-18 20:11:25 +08:00

内网仓库拉镜像应该很快的

kennylam777

2021-03-18 20:12:21 +08:00

livenessprobe 做檢測, 然後配合 readinessprobe , 等新的 pod 上來後才停掉舊的

bwangel

2021-03-18 22:01:14 +08:00

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 中的容器。

zhoudaiyu

2021-03-18 22:21:50 +08:00 via iPhone

@kennylam777
@bwangel 我们比较粗暴存活就绪都监控端口只要应用启动端口就有了所以只能杀应用让端口不占用然后探针重启

kennylam777

2021-03-18 22:30:19 +08:00

@zhoudaiyu 但是直接重啟 process 也會殺掉現有連線, 如果用 readyness 的話, 配合好 service IP 的設計, 舊 pod 在 termination 十幾秒的時間內新的請求會被導引到新 pod, 而舊的連線在 termination grace period 下仍能生存一會

zhoudaiyu

2021-03-18 22:32:59 +08:00 via iPhone

@kennylam777 我感觉主要还是现在探针不好使如果确实能反应应用可用性就不需要过多的人为操作了

12101111

2021-03-18 22:41:42 +08:00

容器里放一个守护进程，OOM 了自己重启，重启不了就自杀让 Pod 重建

tiedan

2021-03-18 22:45:58 +08:00

kill -HUP

kennylam777

2021-03-18 22:50:20 +08:00

@zhoudaiyu 探針可以是最簡單的 TCP, 然後是 HTTP, 最後殺著是 exec 直接跑 command, 只要你要求的可用性都能用一個固定及可以循環的方法返回 exit code 就可以

還是有要求的話 exec 這種玩法可以讓 Pod 去調用外部的檢測結果去讓 k8s 做判斷

bwangel

2021-03-19 00:12:28 +08:00

@zhoudaiyu

是想通过删除 Pod 解决一些容器内部署的应用本身的问题，比如 JVM 的 OOM 等问题，
----
这一点可以再详细说一下吗？

JVM OOM 发生后应用就退出了吗？

lifanxi

2021-03-19 00:28:27 +08:00

镜象如果太大应该尽可能优化大小，实在不能再小的情况下，可以在所有机器上预先把镜象 pull 好，这样 Pod 可以随便 Failover 都可以秒启。

zhoudaiyu

2021-03-19 01:23:01 +08:00 via iPhone

@bwangel 不会退出，会 hang，除非到达了 Pod 的 limit 配置的内存限制容器才会被重启

zhoudaiyu

2021-03-19 01:24:52 +08:00 via iPhone

@lifanxi 镜像普遍接近 1G 左右，已经做过镜像瘦身了，我说镜像可能只是一方面，还有别的耗时的地方，主要是在 container creating 这个阶段

zhoudaiyu

2021-03-19 01:28:00 +08:00 via iPhone

@kennylam777 是的，其实我们我在让别的组做 HTTP 探针，就像 SpringBoot Actuator 这种

RedrumSherlock

2021-03-19 06:32:12 +08:00 via Android

只说镜像的话，如果 imagePullPolicy 设成 ifNotPresent 的话是不会重新拉的，这也是默认和推荐的设置

zhoudaiyu

2021-03-19 07:58:47 +08:00 via iPhone

@RedrumSherlock 现在就么配置的

cassyfar

2021-03-19 08:00:17 +08:00

@zhoudaiyu

k8s liveness and readiness 的检测肯定得反应你服务真是健康情况啊。你这样只检测端口，毫无意义。你的服务肯定得有个 endpoint 去返回 health status 。
讲道理 container creating 多长时间是没关系的。

lifanxi

2021-03-19 08:13:10 +08:00 via Android

@zhoudaiyu 奇怪，为啥这么慢。我这一个镜像 20G，也是秒启动的。

Lee2019

2021-03-19 10:00:29 +08:00

@lifanxi 你应该是这台 node 上面已经有这个 20G 的镜像而不需要重新 pull 镜像了
如果你 pod 调度到没有这个镜像的 node 上，那么肯定会耗一定的时间在拉镜像上

Lee2019

2021-03-19 10:02:20 +08:00

@zhoudaiyu
你的镜像可以试试拆分一下呢？
initContainers 放你的基础镜像，比如 java 服务的基础 java 镜像这类
然后把程序单独打一个镜像，大小就会小很多

zhoudaiyu

2021-03-19 10:05:34 +08:00

@cassyfar 确实，因为当时推广容器的时候，还没有这种健康检查接口，现在好像快弄出来了
@Lee2019 emmmmm，其实我提问的描述有点问题，我的意思是 container creating 的过程是比较长的，拉镜像算是其中的一步吧，还有启动容器什么的，我也看不到这个过程。。。所以就简略描述为拉镜像

zorui

2021-03-19 10:29:20 +08:00

java 跑在 K8S 的问题，spring 应用更恼火启动时会初始化一堆东西。 GraalVM 成熟了重建快很多

panzhc

2021-03-19 20:15:48 +08:00

@ETiV kubectl rollout restart deployment/nginx