Context
Say we have d.yaml
in which a deployment, whose strategy is RollingUpdate
, is defined.
We first create a deployment:
kubectl apply -f d.yaml
After some time, we modify d.yaml
and re-apply it to update the deployment.
vi d.yaml
kubectl apply -f d.yaml
This starts rolling out a new replicaset R_new
.
Normally, the old (previous) replicaset R_old
is killed only after R_new
has successfully been rolled out.
Question (tl;dr)
Is it possible to kill R_old
without waiting for rolling out R_new
to complete?
By "kill", I mean completely stopping a replicaset; it should never restart. (So kubectl delete replicaset
didn't help.)
Question (long)
In my specific situation, my containers connect to an external database. This single database is also connected from many containers managed by other teams.
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...