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>
On a failed promotion the canary keeps serving, but the traffic may
already have been shifted to the primary by runPromotionTrafficShift
before it started failing. Route all traffic back to the canary and
report the matching canary weight instead of zeroing it.
Addresses review feedback on #1931.
Signed-off-by: Pedram Pourmohammad <eragon.pedy@gmail.com>
When the canary analysis succeeds, Flagger copies the canary pod spec
to the primary and waits for the primary rollout to finish. If the
primary fails to become ready, the non-retriable readiness error
triggered the standard analysis rollback, which routes all traffic to
the primary and scales the canary to zero.
During promotion the primary already runs the new (failing) spec while
the canary is the only healthy copy of the new revision still serving
traffic. Rolling back therefore sends all traffic to the broken primary
and deletes the working canary, taking the application down.
Halt the promotion instead: when the primary is not ready and the canary
is in the Promoting or Finalising phase, mark the rollout as failed and
alert, but keep the canary running and leave routing untouched until the
primary recovers or a corrected revision is applied.
Fixes#1898
Signed-off-by: Pedram Pourmohammad <eragon.pedy@gmail.com>
When skipAnalysis is enabled and the canary is promoted, the
post-rollout webhooks were not being executed. This fix ensures
that runPostRolloutHooks is called in shouldSkipAnalysis, matching
the behavior of the normal promotion path.
Fixesfluxcd/flagger#1195
Signed-off-by: Vishal Kumar Singh <vishal.kr.singh2021@gmail.com>
Since version 1.18 (released in July 2021), Contour supports field
HTTPProxy.spec.ingressClassName as a way to specify ingress class for HTTPProxy.
Using this field allows to avoid problems emerging from improper
annotation cleanup, diffing and copying (see issue #1848).
Signed-off-by: Sergey Ptashnik <nnz1024@gmail.com>
Datadog provider is often meeting API rate limits on bigger
implementations. Datadog Cluster Agent can batch metric queries
and expose them through an endpoint compatible with Kubernetes External
Metrics API.
This implementations allows to use this endpoint and any other server
implementing Kubernetes External Metrics API. Including k8s API server
itself.
Co-authored-by: Johan Lore <johan.lore@decathlon.com>
Co-authored-by: Maxime Véroone <maxime.veroone@decathlon.com>
Signed-off-by: Johan Lore <johan.lore@decathlon.com>
Signed-off-by: Maxime Véroone <maxime.veroone@decathlon.com>
Signed-off-by: Johan Lore <johan.lore@decathlon.com>
When Prometheus returns an HTTP error (4xx/5xx), the error message now
includes the status code and reason phrase. Previously, only the response
body was shown, which made it difficult to diagnose issues like HTTP 403
errors caused by missing authorization policies.
Fixesfluxcd/flagger#1434
Signed-off-by: rohansood10 <rohansood10@users.noreply.github.com>
currently the log line exposes the error, however that's always going to be nil
based on the check just above it. This provides better visibility into the failure reason
Signed-off-by: Erik Miller <erik.miller@gusto.com>
It can take some time for changes to propagate for cloud load balancers,
so flagger should ensure the route changes are current before proceeding
with any more.
Signed-off-by: Steven Davidovitz <sdavidovitz@groq.com>
immanuwell
Pujitha Paladugu
Sanskar Jaiswal
Chiman Jain
Pedram Pourmohammad
Niklas Ott
Danny Kulchinsky
Vishal Kumar Singh
kei-gnu
Sergey Ptashnik
Mara Furland
Johan LoreandMaxime Véroone
Yap Sok Ann
rohansood10
Stefan Prodan
Renato Vassão
Erik Miller
Steven Davidovitz