Closed adel121 closed 1 year ago
Merging #166 (69fa8d9) into main (20c7885) will decrease coverage by
0.05%
. The diff coverage is45.83%
.
@@ Coverage Diff @@
## main #166 +/- ##
==========================================
- Coverage 63.22% 63.18% -0.05%
==========================================
Files 41 41
Lines 3073 3094 +21
==========================================
+ Hits 1943 1955 +12
- Misses 1014 1020 +6
- Partials 116 119 +3
Flag | Coverage Δ | |
---|---|---|
unittests | 63.18% <45.83%> (-0.05%) |
:arrow_down: |
Flags with carried forward coverage won't be shown. Click here to find out more.
Files Changed | Coverage Δ | |
---|---|---|
...endeddaemonsetreplicaset/strategy/limits/limits.go | 57.14% <40.00%> (-7.57%) |
:arrow_down: |
...endeddaemonsetreplicaset/strategy/rollingupdate.go | 78.07% <41.66%> (-2.50%) |
:arrow_down: |
controllers/extendeddaemonset/controller.go | 75.53% <57.14%> (-0.44%) |
:arrow_down: |
... and 1 file with indirect coverage changes
Continue to review full report in Codecov by Sentry.
Legend - Click here to learn more
Δ = absolute <relative> (impact)
,ø = not affected
,? = missing data
Powered by Codecov. Last update 20c7885...69fa8d9. Read the comment docs.
What does this PR do?
This PR enhances the extended daemon set to keep track of pods that were already unhealthy before deployment.
Jira Card
Motivation
The EDS controller like the Daemonset controller is configured to limit the number of daemonset pod un-ready during a rollout. For example the rollout strategy can be not more than 5% of pod unready. But if before a rollout start 4% of the existing pods are not ready, it means that the controller can also update 1% at the same time (5%-4%= 1%) which slow down the deployment. and even in some case block the deployment (if more than 5% of the pods are unready before the rollout).
If the EDS could keep track of the number of pods that were initially unhealthy before deployment, it would be able to keep the rollout strategy unaffected (and thus not blocked or slowed-down) by the pods that were previously unhealthy.
Changes Made
unready-pods
.limits.go
, the number of initially unhealthy pods (which is stored in the annotations of the ERS) is used to compensate for this difference in the calculation.Additional Notes
k8s.gcr.io/pause:latest
was used in the integration tests. However this image doesn't work on arm architecture, this is why I changed it tok8s.gcr.io/pause:3.0
.Describe your test plan
CalculatePodToCreateAndDelete
inlimits.go
was unit-tested inlimits_test.go
to ensure that the pods that were already unhealthy are taken into consideration.make test
make e2e
k8s.gcr.io/pause:3.0
)kubectl create configmap example-configmap
make install
to install the CRDsmake run
, attention you should addLeaderElectionNamespace: "kube-system"
to the created manager inmain.go
for this to work)kubectl delete configmap example-configmap
envFrom
property from the pod templatekubectl get ers --watch
. You should see 1 canary and the active replicaset