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

Kubernetes zhoudaiyu • at 2021-03-19 14:08:29 • 47 Views

我們的場景就是想通過刪除 Pod 解決一些容器內部署的應用本身的問題,比如 JVM 的 OOM 等問題,但是重啟 Pod 後自動重建是比較慢的,因為要排程到其他機器再拉映象 balabala 。重啟 container 的速度是比重啟 Pod 快不少的,但是 K8S 好像沒有現成的能重啟 container 的 API 。stack 上說有比較不優雅的方式就是 kubectl exec -it xxx kill 1,這樣貌似確實可以重啟 container,但是不知道有沒有風險。不知道是確實沒有 API 還是我沒找到。如果沒有 API 的話,大家有啥穩定的方式重啟 container ?

Total: 33
  • TomatoAres 2021-03-18 16:34:57
    docker restart [container_id]
  • eric96 2021-03-18 18:31:10
    kill 1
  • eric96 2021-03-18 18:31:10
    優雅關閉,需要鉤子。據我所知,只有關閉 pod 才支援鉤子。想要重啟容器,除非程式本身退出就是優雅的,不然得自己想辦法去保證
  • wxsm 2021-03-18 18:32:10
    在 container 內定義殺程序鉤子,可以通過 http 請求呼叫。內網通過 pod ip 訪問即可
  • zhoudaiyu 2021-03-18 18:33:10
    @TomatoAres 最好是 k8s 的 api,這樣平臺好對接。。。

    @eric96 kill 1 不算優雅嗎? kill -9 1 算不優雅吧

    @wxsm 程式自殺的鉤子?
  • wxsm 2021-03-18 18:33:10
  • corvofeng 2021-03-18 18:30:10
    我們自己叢集沒有給使用者重啟這個功能, 只允許刪除重建。 如果 docker 分層比較好, 而且是內網 dockerhub, pull 也不太慢吧
  • Usaki 2021-03-18 19:30:10
    crictl rmp [pod name]
  • dandankele 2021-03-18 20:32:10
    配置 livenessprobe 檢測到不健康不就重啟了嗎?
  • ETiV 2021-03-18 20:32:10
    有個命令可以滾動重啟的( rollout 後面接個什麼引數,忘了),

    你要的應該是服務穩定,而不是重啟得快
  • vzard 2021-03-18 20:32:10
    內網倉庫拉映象應該很快的
  • kennylam777 2021-03-18 20:32:10
    livenessprobe 做檢測, 然後配合 readinessprobe , 等新的 pod 上來後才停掉舊的
  • bwangel 2021-03-18 22:29:55
    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:23:55
    @kennylam777
    @bwangel 我們比較粗暴 存活就緒都監控埠 只要應用啟動 埠就有了 所以只能殺應用讓埠不佔用 然後探針重啟
  • kennylam777 2021-03-18 22:32:55
    @zhoudaiyu 但是直接重啟 process 也會殺掉現有連線, 如果用 readyness 的話, 配合好 service IP 的設計, 舊 pod 在 termination 十幾秒的時間內新的請求會被導引到新 pod, 而舊的連線在 termination grace period 下仍能生存一會
  • zhoudaiyu 2021-03-18 23:27:55
    @kennylam777 我感覺主要還是現在探針不好使 如果確實能反應應用可用性 就不需要過多的人為操作了
  • 12101111 2021-03-18 23:28:55
    容器裡放一個守護程序,OOM 了自己重啟,重啟不了就自殺讓 Pod 重建
  • tiedan 2021-03-18 23:28:55
    kill -HUP
  • kennylam777 2021-03-18 23:28:55
    @zhoudaiyu 探針可以是最簡單的 TCP, 然後是 HTTP, 最後殺著是 exec 直接跑 command, 只要你要求的可用性都能用一個固定及可以迴圈的方法返回 exit code 就可以

    還是有要求的話 exec 這種玩法可以讓 Pod 去呼叫外部的檢測結果去讓 k8s 做判斷
  • bwangel 2021-03-19 00:31:55
    @zhoudaiyu

    是想通過刪除 Pod 解決一些容器內部署的應用本身的問題,比如 JVM 的 OOM 等問題,
    ----
    這一點可以再詳細說一下嗎?

    JVM OOM 發生後應用就退出了嗎?
  • lifanxi 2021-03-19 00:30:55
    鏡象如果太大應該儘可能優化大小,實在不能再小的情況下,可以在所有機器上預先把鏡象 pull 好,這樣 Pod 可以隨便 Failover 都可以秒啟。
  • zhoudaiyu 2021-03-19 01:23:06
    @bwangel 不會退出,會 hang,除非到達了 Pod 的 limit 配置的記憶體限制容器才會被重啟
  • zhoudaiyu 2021-03-19 01:25:06
    @lifanxi 映象普遍接近 1G 左右,已經做過映象瘦身了,我說映象可能只是一方面,還有別的耗時的地方,主要是在 container creating 這個階段
  • zhoudaiyu 2021-03-19 01:28:06
    @kennylam777 是的,其實我們我在讓別的組做 HTTP 探針,就像 SpringBoot Actuator 這種
  • RedrumSherlock 2021-03-19 07:26:46
    只說映象的話,如果 imagePullPolicy 設成 ifNotPresent 的話是不會重新拉的,這也是預設和推薦的設定
  • zhoudaiyu 2021-03-19 08:28:46
    @RedrumSherlock 現在就麼配置的
  • cassyfar 2021-03-19 08:28:46
    @zhoudaiyu

    k8s liveness and readiness 的檢測肯定得反應你服務真是健康情況啊。你這樣只檢測埠,毫無意義。你的服務肯定得有個 endpoint 去返回 health status 。
    講道理 container creating 多長時間是沒關係的。
  • lifanxi 2021-03-19 08:30:46
    @zhoudaiyu 奇怪,為啥這麼慢。我這一個映象 20G,也是秒啟動的。
  • Lee2019 2021-03-19 10:28:44
    @lifanxi 你應該是這臺 node 上面已經有這個 20G 的映象而不需要重新 pull 映象了
    如果你 pod 排程到沒有這個映象的 node 上,那麼肯定會耗一定的時間在拉映象上
  • Lee2019 2021-03-19 10:29:44
    @zhoudaiyu
    你的映象可以試試拆分一下呢?
    initContainers 放你的基礎映象,比如 java 服務的基礎 java 映象這類
    然後把程式單獨打一個映象,大小就會小很多
Add a reply
For Commenting you need to Login. If you dont have a Account you need to Register.