github/flagger
1
0
Fork 0
mirror of https://github.com/fluxcd/flagger.git synced 2026-04-15 06:57:34 +00:00
Code Issues Packages Projects Releases Wiki Activity

Support per-config configTracker disable via ConfigMap/Secret annotation

Browse Source 
This allows a user to annotate a specific ConfigMap or Secret to be disabled/ignored via the
configTracking logic that tracks config changes makes configuration copies for the primary Deploy

Closes #435
This commit is contained in:
leigh capili
2020-08-17 16:24:56 -06:00
parent 34f0273c34
commit dad70a6876
5 changed files with 523 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/gitbook/usage/how-it-works.md
+11 -7
View File
@@ -75,16 +75,11 @@ Based on the above configuration, Flagger generates the following Kubernetes obj
* `deployment/<targetRef.name>-primary`
* `hpa/<autoscalerRef.name>-primary`
The primary deployment is considered the stable release of your app, by default all traffic is routed to this version
The primary deployment is considered the stable release of your app, by default all traffic is routed to this version
and the target deployment is scaled to zero.
Flagger will detect changes to the target deployment (including secrets and configmaps) and will perform a
canary analysis before promoting the new version as primary.
If the target deployment uses secrets and/or configmaps, Flagger will create a copy of each object using the `-primary`
prefix and will reference these objects in the primary deployment. You can disable the secrets/configmaps tracking
with the `-enable-config-tracking=false` command flag in the Flagger deployment manifest under containers args
or by setting `--set configTracking.enabled=false` when installing Flagger with Helm.
**Note** that the target deployment must have a single label selector in the format `app: <DEPLOYMENT-NAME>`:
```yaml
@@ -102,11 +97,20 @@ spec:
app: podinfo
```
Besides `app` Flagger supports `name` and `app.kubernetes.io/name` selectors.
In addition to `app`, Flagger supports `name` and `app.kubernetes.io/name` selectors.
If you use a different convention you can specify your label with
the `-selector-labels=my-app-label` command flag in the Flagger deployment manifest under containers args
or by setting `--set selectorLabels=my-app-label` when installing Flagger with Helm.
If the target deployment uses secrets and/or configmaps, Flagger will create a copy of each object using the `-primary`
suffix and will reference these objects in the primary deployment. If you annotate your ConfigMap or Secret with
`flagger.app/config-tracking: disabled`, Flagger will use the same object for the primary deployment instead of making
a primary copy.
You can disable the secrets/configmaps tracking globally with the `-enable-config-tracking=false` command flag in
the Flagger deployment manifest under containers args or by setting `--set configTracking.enabled=false` when
installing Flagger with Helm, but disabling config-tracking using the the per Secret/ConfigMap annotation may fit your
use-case better.
The autoscaler reference is optional, when specified, Flagger will pause the traffic increase while the
target and primary deployments are scaled up or down. HPA can help reduce the resource usage during the canary analysis.