Motivation:
When canary.spec.service.portDiscovery is enabled, Flagger scans the
target Deployment/DaemonSet containers and adds any extra container
ports to the generated canary/primary/apex Services, so multi-port
apps stay reachable. The exclusion list used to skip mesh sidecars
only knew about Istio's container names ("istio-proxy", "envoy").
Linkerd's proxy injector uses the container name "linkerd-proxy", so
its internal ports (e.g. 4143 inbound, 4191 admin) were treated as
application ports and added to the generated Services instead of
being skipped. This was reported as a comment on #1345: "portDiscovery
does not work for linkerd" (using portDiscovery on a linkerd-meshed
deployment).
Note this does not address the original report in #1345, which does
not enable portDiscovery at all — dropping ports that only exist on a
pre-existing Service (and are not declared as container ports) is a
separate, broader problem that needs its own design discussion.
Approach:
Add "linkerd-proxy" to the sidecars exclusion map in
pkg/canary/util.go, matching how "istio-proxy" and "envoy" are
already excluded from getPorts().
Validation:
Added TestGetPortsExcludesSidecars to pkg/canary/util_test.go,
asserting that getPorts() drops linkerd-proxy and istio-proxy
container ports while keeping a regular app container's extra port.
go build ./...
go test ./pkg/canary/... -run TestGetPortsExcludesSidecars -v
Both passed. Also ran the full pkg/canary test suite (go test
./pkg/canary/...) with no regressions.
Fixes#1345
Signed-off-by: Pujitha Paladugu <10557236+pujitha24@users.noreply.github.com>
This should avoid frequent "Operation cannot be fulfilled" errors from
polluting Canary resource events and logs.
Signed-off-by: Aurel Canciu <aurel.canciu@nexhealth.com>
Modify `canary.IsPrimaryReady()` and `canary.Initialize()` to return a
boolean indicating if the error is retriable. Modify the scheduler to
rollback the analysis and mark the Canary object as failed if the above
two functions or `canary.IsCanaryRead()` returns false along with an
error.
Signed-off-by: Sanskar Jaiswal <jaiswalsanskar078@gmail.com>
This adds a new Checksum field to the canary webhook body, which is a
hash of the LastAppliedSpec and TrackedConfigs.
This can be used to identify the rollout of a specific configuration,
and differentiate between webhooks being sent for different
configuration and deployment versions.
Signed-off-by: Kevin McDermott <kevin@weave.works>
Adding support for overriding the primary scaler replica count via
.spec.autoscalerRef.primaryScalerReplicas, a feature which would enable
users to define a different scaling configurations for the primary.
This can be useful in the situation where the user does not want to
scale the canary workload to the exact same size as the primary,
especially when opting for a canary deployment pattern where only a
small portion of traffic is routed to the canary workload pods.
Signed-off-by: Aurel Canciu <aurelcanciu@gmail.com>
Without this, the canary replicas are updated twice:
to 1 replica then after a few seconds to the value of HPA minReplicas.
In some cases, when updated to 1 replica (before updated by HPA
controller to the minReplicas), it's considered ready: 1 of 1 (readyThreshold 100%),
and the canary weight is advanced to receive traffic with less capacity
than expected.
Co-Authored-By: Joshua Gibeon <joshuagibeon7719@gmail.com>
Co-authored-by: Sanskar Jaiswal <hey@aryan.lol>
Signed-off-by: Andy Librian <andylibrian@gmail.com>
Prevents the canary from getting triggered, when a canary deploy is
updated to match the primary deploy after an analysis fails.
Signed-off-by: Sanskar Jaiswal <sanskar.jaiswal@weave.works>
Signed-off-by: Karl Heins <karlheins@northwesternmutual.com>
Support updating primary Deployment/DaemonSet/HPA/Service labels and annotations after first-time rollout
If a "primary" ConfigMap or Secret already exists, keep the list of
ownerReferences and append the updating Canary as ownerReference if it's
not already in the list. This will prevent the GC from deleting primary
ConfigMaps and Secrets used by multiple primary deployments when one is
deleted.
Signed-off-by: Zacharias Taubert <zacharias.taubert@gmail.com>