fix(controller): add container ports so workloads can be targeted by name - #4382

Included review availability: This review used your included allowance. Your plan provides up to 4 included reviews per hour; 3 remain after this review.

Summary

• Added a named container port for each workload endpoint.
• Sanitized endpoint keys and generated unique port names when sanitized keys collide.
• Changed Service targetPort values to reference the matching container port name.
• Added workload.toContainerPorts() and used it in built-in component templates.
• Container ports do not change application bindings or traffic routing. The pod template changes trigger a rolling restart. Services may temporarily have no ready endpoints as updated pods start.

Changed files

API and CRD surface

• Changed exported ServicePortEntry.TargetPort from int64 to string.
• Added exported ContainerPortEntry, with Name, ContainerPort, and Protocol fields.
• Added ContainerPorts to DerivedContext.
• Added the workload.toContainerPorts() CEL macro.
• No Kubernetes API or CRD schema files changed.
• Compatibility risk: Medium. Consumers of the exported Go types or derived context may need updates. Pod template changes trigger a rollout, and Services now require matching named ports on ready pods.

Tests

Updated or added tests for:

• Service port target names across HTTP, gRPC, and UDP endpoints.
• Target-port defaults, differing service and target ports, sanitized names, and name collisions.
• The workload.toContainerPorts() macro and its receiver guard.
• CEL integration output for named Service targets and container ports.
• Non-nil ContainerPorts in an empty derived context.

The supplied changes do not show tests for rendered Deployment or Pod output, rollout behavior, or integration with Linkerd, NetworkPolicy, CiliumNetworkPolicy, admission policies, or Prometheus pod-role scraping. No test execution results were provided.

Risk hotspots

• Reconciliation and rollout: The pod template change causes existing Deployments to roll out.
• Traffic routing: Service target names must match the container port names on ready pods. A Service update before replacement pods are ready can cause a temporary endpoint gap.
• Authn/authz and policy integration: The new named ports enable integrations such as Linkerd Server bindings and named network-policy rules. No direct authentication or authorization policy changes are shown.
• RBAC: No RBAC changes are shown.
• Secrets: No secret handling changes are shown.
• Install and upgrade paths: No installer or upgrade files changed. Existing workloads still need the rollout that adds their declared container ports.

Walkthrough

The pipeline derives named container ports from workload endpoints and uses their names as service targetPort values. A CEL macro exposes the derived ports. Sample Deployment templates render those ports in container specifications.

Changes

Named container port rendering

Priority: ⚪ Not assessed

Estimated code review effort: 3 (Moderate) | ~20 minutes

Change: Bug fix · Severity of issue fixed: Medium

Sequence Diagram(s)

sequenceDiagram
  participant DeploymentTemplate
  participant toContainerPortsMacro
  participant DerivedContext
  participant ServiceTemplate
  participant toServicePortsMacro
  DeploymentTemplate->>toContainerPortsMacro: evaluate workload.toContainerPorts()
  toContainerPortsMacro->>DerivedContext: select containerPorts
  DerivedContext-->>DeploymentTemplate: container port entries
  ServiceTemplate->>toServicePortsMacro: evaluate workload.toServicePorts()
  toServicePortsMacro->>DerivedContext: select servicePorts
  DerivedContext-->>ServiceTemplate: service ports with named targetPort

Security Blast Radius

• inferred — The demonstrated effect is on Service-to-pod port resolution for workloads using the changed template contract. The supplied evidence does not establish an attacker-controlled route or cross-tenant exposure.

Trust Boundaries and Controls

• observed — The tested CEL receiver restriction rejects toContainerPorts() on an unrelated receiver; no changed test range establishes a new authentication or privilege boundary.

Resilience and Maintainability Implications

• inferred — Uncoordinated adoption of named Service targets and named pod ports could disrupt availability during a mixed-version rollout; actual reconciliation ordering and recovery behavior are not established.

Hardening Proposals

• proposed — Before changing a Service to named targets, verify that its selected pod templates declare matching names, and define upgrade and rollback handling for existing templates and pods.

❌ Failed checks (1 warning)

• X
• Mastodon
• Reddit
• LinkedIn

Review finished.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.