[feature request] Support SidecarSet update strategy when pod recreate or inject
What would you like to be added:
Support SidecarSet update strategy when pod recreate or inject
Why is this needed:
There are two teams under one organizational structure. Team A maintain SidecarSet. Team B maintain Application which can use Deployment.
Team A inject SidecarSet to Pod which may controlled by Team B. Now, Team A want to update SidecarSet to new version. They use a partition update strategy.
At the same time, Team B want to release a new application version which may fix an emergency bug. Unfortunately, SidecarSet is all new version now.
So, I want to apply update strategy when pod inject.
Here is an example:
first,
# sidecarset.yaml
apiVersion: apps.kruise.io/v1alpha1
kind: SidecarSet
metadata:
name: test-sidecarset
spec:
selector:
matchLabels:
sidecarset: test-sidecarset
updateStrategy:
type: RollingUpdate
# type: NotUpdate
maxUnavailable: 1
partition: 2
containers:
- name: sidecar1
image: centos:6.7
command: ["sleep", "999d"] # do nothing at all
volumeMounts:
- name: log-volume
mountPath: /var/log
volumes: # this field will be merged into pod.spec.volumes
- name: log-volume
emptyDir: {}
apiVersion: apps/v1
kind: Deployment
metadata:
name: test-nginx
spec:
replicas: 5
selector:
matchLabels:
app: test-nginx
template:
metadata:
labels:
app: test-nginx
sidecarset: test-sidecarset
spec:
containers:
- name: test-nginx
image: nginx:1.15.1
resources:
limits:
memory: "256Mi"
cpu: "500m"
ports:
- containerPort: 10000
now, result is
kubectl get po
NAME READY STATUS RESTARTS AGE
test-nginx-778d5db47b-95mwt 2/2 Running 0 7m59s
test-nginx-778d5db47b-9nvvk 2/2 Running 1 7m59s
test-nginx-778d5db47b-vvknk 2/2 Running 0 7m59s
test-nginx-778d5db47b-wk567 2/2 Running 0 7m59s
test-nginx-778d5db47b-x6k8d 2/2 Running 1 7m59s
then, Team A update SidecarSet.
# sidecarset.yaml
apiVersion: apps.kruise.io/v1alpha1
kind: SidecarSet
metadata:
name: test-sidecarset
spec:
selector:
matchLabels:
sidecarset: test-sidecarset
updateStrategy:
type: RollingUpdate
# type: NotUpdate
maxUnavailable: 1
partition: 2
containers:
- name: sidecar1
image: centos:7
command: ["sleep", "999d"] # do nothing at all
volumeMounts:
- name: log-volume
mountPath: /var/log
volumes: # this field will be merged into pod.spec.volumes
- name: log-volume
emptyDir: {}
result
kubectl get po -o yaml | grep 'image: centos'
image: centos:6.7
image: centos:7
image: centos:6.7
image: centos:7
image: centos:7
at the same time, Team B update Deployment.
apiVersion: apps/v1
kind: Deployment
metadata:
name: test-nginx
spec:
replicas: 5
selector:
matchLabels:
app: test-nginx
template:
metadata:
labels:
app: test-nginx
sidecarset: test-sidecarset
spec:
containers:
- name: test-nginx
image: nginx:1.15.1
resources:
limits:
memory: "128Mi"
cpu: "500m"
ports:
- containerPort: 10000
result
kubectl get po -o yaml | grep 'image: centos'
image: centos:7
image: centos:7
image: centos:7
image: centos:7
image: centos:7
expect two centos: 6.7 and three centos: 7
Very Good Issue!
In fact, we have noticed this problem and are solving it. The current progress about the solution is as follows:
-
#715 has been ready to support the storage of historical revisions of SidecarSet.
-
The next plan is to enable users to inject the specified historical version of SidecarSet. (very soon)
Oh, I notice this #715.
- I want is keep SidecarSet's update strategy even if Pod recreate. They are related but different.
- There are any PR now, otherwise I can contribute one.
Another issue is the update strategy equal NotUpdate.
I want to apply a new version SidecarSet only if Team B update their application (risk considerations). Of course, new version SidecarSet have some update strategy.
Oh, I notice this #715.
- I want is keep SidecarSet's update strategy even if Pod recreate. They are related but different.
- There are any PR now, otherwise I can contribute one.
-
Can you further describe your desired upgrade behavior of SidecarSet?
-
We would MOSTLY WELCOME you to contribute your solutions/codes for kruise! Maybe, you can first submit a proposal to describe your solution if you have time.
https://github.com/openkruise/kruise/pull/1021