feat: add port information to workload list output

[bgruszka]

Add Port Information to Workload List Output

Summary

This PR adds port information to the telepresence list command output, allowing developers to see which ports are available on interceptable workloads without needing to use kubectl. This is particularly useful for VS Code extensions and other tooling that need to display port information to users.

Problem Statement

Previously, when running telepresence list, users could see workload names, namespaces, and intercept status, but had no visibility into which ports were exposed by each workload. To discover ports, users had to run separate kubectl commands, which:

• Required additional permissions
• Added friction to the workflow
• Made it difficult for IDE extensions to provide port information

Solution

The feature now includes port information in the list output by:

1. Using the existing sidecar generation logic to discover service-to-container port mappings
2. Extracting port information from the generated sidecar configuration
3. Propagating port data through the RPC layer to the client
4. Displaying ports in multiple formats

Changes

Protocol Definitions

• rpc/manager/manager.proto: Added WorkloadPortInfo message with fields:
  • container_port_name - Symbolic name of the container port (mandatory field)
  • container_port - Numeric container port number (mandatory, always present)
  • protocol - Protocol used by the port (TCP or UDP)
  • service_port_name - Symbolic name of the service port (may be empty for headless services or replacements)
  • service_port - Numeric service port number (may be 0 for headless services or replacements)
• rpc/connector/connector.proto: Updated to use manager.WorkloadPortInfo directly (no duplicate definition)

Traffic Manager

• cmd/traffic/cmd/manager/state/workload_info_watcher.go:
  • Added extractPortsFromSidecar() - Extracts both container and service port information from sidecar configuration
  • Added extractPortsForWorkload() - Generates sidecar and extracts ports using service discovery
    • Performance optimization: Reuses existing sidecar config when traffic-agent is already installed, avoiding unnecessary regeneration
  • Modified rpcWorkload() - Includes port information in WorkloadInfo
  • Uses types.PortAndProto for protocol-aware deduplication (handles TCP/UDP on same port)
  • Populates all five WorkloadPortInfo fields: container port name/number, service port name/number, and protocol
  • Fixed import conflicts: aliased k8s types as k8stypes to avoid conflict with types package

Client

• pkg/client/userd/trafficmgr/session.go:
  • Simplified to use manager.WorkloadPortInfo directly (no type conversion needed)
  • Propagates port information through RPC layer

Tests

• cmd/traffic/cmd/manager/state/workload_info_watcher_test.go: Created with 13 comprehensive unit tests

  • Nil/empty sidecar handling
  • Single and multiple ports
  • Multiple containers
  • Port deduplication (same port/protocol)
  • TCP/UDP protocol support
  • Port name handling
  • Protocol string conversion
  • Complex scenarios with mixed configurations
  • Service port handling - Tests with both container and service port information
  • Headless service handling - Tests for workloads without service ports (container ports only)

• integration_test/list_watch_test.go: Added 4 integration tests

  • Test_ListWithPorts() - Verifies ports appear in JSON output with required fields
  • Test_ListWithPortsAndNamedPorts() - Tests named port handling
  • Test_ListWithServicePorts() - Verifies both container and service port fields are populated for normal services
  • Test_ListWithHeadlessServicePorts() - Verifies container ports are present for headless services

Documentation

• CHANGELOG.yml: Added v2.26.0 feature entry describing the new port information feature

Breaking Changes

None. This is a purely additive feature.

Migration Guide

No migration needed. The feature is automatically available when using telepresence list.

Checklist

• I made sure to update ./CHANGELOG.yml (our release notes are generated from this file).
• I made sure to add any documentation changes required for my change.
• My change is adequately tested.
• I updated CONTRIBUTING.md with any special dev tricks I had to use to work on this code efficiently.
• Once my PR is ready to have integration tests ran, I posted the PR in #telepresence-oss channel on the
  CNCF Slack so that the "ok to test" label can be applied.

[thallgren]

Looks like a useful addition.

[thallgren]

LGTM. Just some minor nits.

[github-actions]

This PR is stale because it has been open 30 days with no activity. Remove stale label or comment, or this will be closed in 14 days.