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

[zhoudaiyu]

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

[lifanxi]

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

[zhoudaiyu]

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

[zhoudaiyu]

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

[zhoudaiyu]

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

[RedrumSherlock]

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

[zhoudaiyu]

@RedrumSherlock 现在就么配置的

[cassyfar]

@zhoudaiyu

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

[lifanxi]

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

[Lee2019]

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

[Lee2019]

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

[zhoudaiyu]

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

[zorui]

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

[panzhc]

@ETiV kubectl rollout restart deployment/nginx