Skip to content

Fix #6724: Allow setting enableServiceLinks on the Integration pod template#6725

Open
lsergio wants to merge 1 commit into
apache:mainfrom
lsergio:feat/6724-enableServiceLinks
Open

Fix #6724: Allow setting enableServiceLinks on the Integration pod template#6725
lsergio wants to merge 1 commit into
apache:mainfrom
lsergio:feat/6724-enableServiceLinks

Conversation

@lsergio

@lsergio lsergio commented Jul 23, 2026

Copy link
Copy Markdown
Contributor

Motivation

Fixes #6724

Users need to control the Kubernetes pod-level enableServiceLinks flag on an
Integration. When many Services exist in a namespace, Kubernetes injects a
{SVC}_SERVICE_HOST / {SVC}_SERVICE_PORT env var per Service into every
container (the Docker-links compatibility feature). This bloats the environment
and can slow pod startup, so operators commonly want to set
enableServiceLinks: false. There was previously no way to express this on an
Integration.

What this does

Adds an EnableServiceLinks *bool field to the curated v1.PodSpec used by
spec.template.spec, mirroring the upstream Kubernetes PodSpec field
(json enableServiceLinks, defaults to true).

apiVersion: camel.apache.org/v1
kind: Integration
spec:
  template:
    spec:
      enableServiceLinks: false

The pod trait marshals spec.template.spec and applies it as a
strategic merge patch onto the workload pod spec, so the new field
propagates to Deployment, CronJob and Knative Service pods with no additional
trait logic.

Generated artifacts

Regenerated and committed:

  • CRDs: camel.apache.org_integrations.yaml, camel.apache.org_pipes.yaml
  • Helm CRD bundle: helm/camel-k/crds/camel-k-crds.yaml
  • zz_generated.deepcopy.go
  • apply-configuration client podspec.go

Note on deprecation

PodSpecTemplate / v1.PodSpec and the pod trait are marked
Deprecated: to be removed in future versions ("use container, init-containers
or owner traits instead"). I placed the field here because enableServiceLinks
is a pod-level toggle that no current non-deprecated trait can set — the
pod template is genuinely the only mechanism available today. Happy to move it
to a different home (e.g. a dedicated trait) if the maintainers prefer that over
extending the deprecated surface.

Testing

  • New unit test TestEnableServiceLinks in pkg/trait/pod_test.go verifies
    enableServiceLinks: false propagates to the deployment pod spec.
  • go build, go vet, gofmt, and golangci-lint (v2.12.2) pass on the
    affected packages; full pkg/trait suite is green.

Suggested reviewers

  • @squakez (Pasquale Congiusti) — most active on the pod trait / API and author
    of the Pod-trait deprecation; best placed to weigh in on the deprecation note.
  • Pranjul Kalsi — recent contributor to this area.

This change was prepared by Claude Code on behalf of Luis Sergio Carneiro (@lsergio).

…pod template

Add an EnableServiceLinks *bool field to the curated v1.PodSpec used by
spec.template.spec, so users can control the Kubernetes pod-level
enableServiceLinks flag (defaults to true) on an Integration.

The pod trait applies spec.template.spec as a strategic merge patch onto the
workload pod spec, so the new field propagates to Deployment, CronJob and
Knative Service pods with no further trait changes.

Regenerated the CRDs (integrations, pipes), the Helm CRD bundle, deepcopy and
the apply-configuration client. Added a unit test covering
enableServiceLinks: false.

Note: PodSpecTemplate / v1.PodSpec and the pod trait are deprecated, but this
is currently the only mechanism able to set a pod-level flag such as
enableServiceLinks (no non-deprecated trait covers it).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.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.

Support for setting enableServiceLinks on the pod spec template

1 participant