Skip to content

Exclude linkerd-proxy sidecar ports from port discovery - #1955

Open
pujitha24 wants to merge 1 commit into
fluxcd:mainfrom
pujitha24:auto/issue-1345
Open

Exclude linkerd-proxy sidecar ports from port discovery#1955
pujitha24 wants to merge 1 commit into
fluxcd:mainfrom
pujitha24:auto/issue-1345

Conversation

@pujitha24

Copy link
Copy Markdown

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

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 fluxcd#1345: "portDiscovery
does not work for linkerd" (using portDiscovery on a linkerd-meshed
deployment).

Note this does not address the original report in fluxcd#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 fluxcd#1345

Signed-off-by: Pujitha Paladugu <10557236+pujitha24@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

canary activation removes unspecified ports from the pre-existing service

1 participant