mirror of
https://github.com/fluxcd/flagger.git
synced 2026-09-05 02:47:17 +00:00
Pujitha Paladugu
cf6cb64421
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>