語境
假設我們d.yaml在其中定義了一個部署，其策略是RollingUpdate。
我們首先創建一個部署：
kubectl apply -f d.yaml
一段時間后，我們修改d.yaml并重新應用它來更新部署。
vi d.yaml
kubectl apply -f d.yaml
這開始推出一個新的副本集R_new。
通常，舊的（以前的）副本集只有在成功推出后才會R_old被殺死。R_new
問題（tl;博士）
是否有可能在R_old不等待推出R_new完成的情況下殺死？
通過“殺死”，我的意思是完全停止復制集；它永遠不應該重新啟動。（所以kubectl delete replicaset沒有幫助。）
問題（長）
在我的具體情況下，我的容器連接到外部資料庫。這個單一的資料庫也與其他團隊管理的許多容器相連。
If the maximum number of connections allowed is already reached, new containers associated with R_new fail to start (i.e. CrashLoopBackOff).
If I could forcefully kill R_old, the number of connections would be lowered by N where N is the number of replicas, and thus R_new's containers would successfully start.
FAQ:
Q. Why not temporarily stop using RollingUpdate strategy?
A. Actually I have no permission to edit d.yaml. It is edited by CI/CD.
Q. Why not just make the maximum number of connections larger?
A. I have no permission for the database either...
uj5u.com熱心網友回復：
是否可以在不等待推出 R_new 完成的情況下殺死 R_old？“殺死”是指完全停止復制集；它永遠不應該重新啟動。（所以 kubectl delete replicaset 沒有幫助。）
- 對部署進行更改
- 縮減部署
replicas=0，使其與停止舊副本集一樣好 - 將部署擴展到所需的數量
replicas，replicasets將在部署中使用新的配置更改創建新的。
步驟 1 和 2 可以根據需要互換
uj5u.com熱心網友回復：
從技術上講，您可以通過運行洗掉舊的副本集kubectl delete replicaset R_old，這將終止舊的 pod。我剛剛在我的集群中驗證了它（kubernetes 版本 1.21.8）。
然而，終止一個 pod 并不一定意味著它會立即被殺死。pod 的實際終止取決于是否定義了preStop 生命周期鉤子，以及terminationGracePeriodSeconds 的值（參見鍵入說明kubectl explain pod.spec.terminationGracePeriodSeconds）。
默認情況下，kubelet 僅在其容器中的所有行程都停止或寬限期結束后才會洗掉 pod。
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/452921.html
標籤：kubernetes