V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
zhoudaiyu
V2EX  ›  Kubernetes

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

  •  
  •   zhoudaiyu · 258 天前 · 1933 次点击
    这是一个创建于 258 天前的主题,其中的信息可能已经有所发展或是发生改变。

    我们的场景就是想通过删除 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
        1
    TomatoAres  
       258 天前
    docker restart [container_id]
    eric96
        2
    eric96  
       258 天前
    kill 1
    eric96
        3
    eric96  
       258 天前
    优雅关闭,需要钩子。据我所知,只有关闭 pod 才支持钩子。想要重启容器,除非程序本身退出就是优雅的,不然得自己想办法去保证
    wxsm
        4
    wxsm  
       258 天前 via iPhone
    在 container 内定义杀进程钩子,可以通过 http 请求调用。内网通过 pod ip 访问即可
    zhoudaiyu
        5
    zhoudaiyu  
    OP
       258 天前
    @TomatoAres 最好是 k8s 的 api,这样平台好对接。。。

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

    @wxsm 程序自杀的钩子?
    wxsm
        6
    wxsm  
       258 天前 via iPhone
    corvofeng
        7
    corvofeng  
       258 天前 via Android
    我们自己集群没有给用户重启这个功能, 只允许删除重建。 如果 docker 分层比较好, 而且是内网 dockerhub, pull 也不太慢吧
    Usaki
        8
    Usaki  
       258 天前 via Android
    crictl rmp [pod name]
    dandankele
        9
    dandankele  
       258 天前   ❤️ 1
    配置 livenessprobe 检测到不健康不就重启了吗?
    ETiV
        10
    ETiV  
       258 天前 via iPhone   ❤️ 1
    有个命令可以滚动重启的( rollout 后面接个什么参数,忘了),

    你要的应该是服务稳定,而不是重启得快
    vzard
        11
    vzard  
       258 天前
    内网仓库拉镜像应该很快的
    kennylam777
        12
    kennylam777  
       258 天前   ❤️ 2
    livenessprobe 做檢測, 然後配合 readinessprobe , 等新的 pod 上來後才停掉舊的
    bwangel
        13
    bwangel  
       258 天前
    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
        14
    zhoudaiyu  
    OP
       258 天前 via iPhone
    @kennylam777
    @bwangel 我们比较粗暴 存活就绪都监控端口 只要应用启动 端口就有了 所以只能杀应用让端口不占用 然后探针重启
    kennylam777
        15
    kennylam777  
       258 天前   ❤️ 1
    @zhoudaiyu 但是直接重啟 process 也會殺掉現有連線, 如果用 readyness 的話, 配合好 service IP 的設計, 舊 pod 在 termination 十幾秒的時間內新的請求會被導引到新 pod, 而舊的連線在 termination grace period 下仍能生存一會
    zhoudaiyu
        16
    zhoudaiyu  
    OP
       258 天前 via iPhone
    @kennylam777 我感觉主要还是现在探针不好使 如果确实能反应应用可用性 就不需要过多的人为操作了
    12101111
        17
    12101111  
       258 天前
    容器里放一个守护进程,OOM 了自己重启,重启不了就自杀让 Pod 重建
    tiedan
        18
    tiedan  
       258 天前
    kill -HUP
    kennylam777
        19
    kennylam777  
       258 天前
    @zhoudaiyu 探針可以是最簡單的 TCP, 然後是 HTTP, 最後殺著是 exec 直接跑 command, 只要你要求的可用性都能用一個固定及可以循環的方法返回 exit code 就可以

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

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

    JVM OOM 发生后应用就退出了吗?
    lifanxi
        21
    lifanxi  
       258 天前
    镜象如果太大应该尽可能优化大小,实在不能再小的情况下,可以在所有机器上预先把镜象 pull 好,这样 Pod 可以随便 Failover 都可以秒启。
    zhoudaiyu
        22
    zhoudaiyu  
    OP
       258 天前 via iPhone
    @bwangel 不会退出,会 hang,除非到达了 Pod 的 limit 配置的内存限制容器才会被重启
    zhoudaiyu
        23
    zhoudaiyu  
    OP
       258 天前 via iPhone
    @lifanxi 镜像普遍接近 1G 左右,已经做过镜像瘦身了,我说镜像可能只是一方面,还有别的耗时的地方,主要是在 container creating 这个阶段
    zhoudaiyu
        24
    zhoudaiyu  
    OP
       258 天前 via iPhone
    @kennylam777 是的,其实我们我在让别的组做 HTTP 探针,就像 SpringBoot Actuator 这种
    RedrumSherlock
        25
    RedrumSherlock  
       258 天前 via Android
    只说镜像的话,如果 imagePullPolicy 设成 ifNotPresent 的话是不会重新拉的,这也是默认和推荐的设置
    zhoudaiyu
        26
    zhoudaiyu  
    OP
       258 天前 via iPhone
    @RedrumSherlock 现在就么配置的
    cassyfar
        27
    cassyfar  
       258 天前
    @zhoudaiyu

    k8s liveness and readiness 的检测肯定得反应你服务真是健康情况啊。你这样只检测端口,毫无意义。你的服务肯定得有个 endpoint 去返回 health status 。
    讲道理 container creating 多长时间是没关系的。
    lifanxi
        28
    lifanxi  
       258 天前 via Android
    @zhoudaiyu 奇怪,为啥这么慢。我这一个镜像 20G,也是秒启动的。
    Lee2019
        29
    Lee2019  
       258 天前
    @lifanxi 你应该是这台 node 上面已经有这个 20G 的镜像而不需要重新 pull 镜像了
    如果你 pod 调度到没有这个镜像的 node 上,那么肯定会耗一定的时间在拉镜像上
    Lee2019
        30
    Lee2019  
       258 天前
    @zhoudaiyu
    你的镜像可以试试拆分一下呢?
    initContainers 放你的基础镜像,比如 java 服务的基础 java 镜像这类
    然后把程序单独打一个镜像,大小就会小很多
    zhoudaiyu
        31
    zhoudaiyu  
    OP
       258 天前
    @cassyfar 确实,因为当时推广容器的时候,还没有这种健康检查接口,现在好像快弄出来了
    @Lee2019 emmmmm,其实我提问的描述有点问题,我的意思是 container creating 的过程是比较长的,拉镜像算是其中的一步吧,还有启动容器什么的,我也看不到这个过程。。。所以就简略描述为拉镜像
    zorui
        32
    zorui  
       258 天前
    java 跑在 K8S 的问题,spring 应用更恼火启动时会初始化一堆东西。 GraalVM 成熟了重建快很多
    panzhc
        33
    panzhc  
       257 天前
    @ETiV kubectl rollout restart deployment/nginx
    关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   3966 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 20ms · UTC 06:02 · PVG 14:02 · LAX 22:02 · JFK 01:02
    ♥ Do have faith in what you're doing.