[agent-control-bootstrap] agent-control does not support ipv6

[cnellis101]

Bug description

agent-control-deployment is not IPv6-compatible on IPv6 or dual-stack EKS clusters. The chart hardcodes HTTP startup/liveness probes against the pod IP while also enforcing server.host = 0.0.0.0, which causes probe failures because the pod gets an IPv6 address and the status server is only listening on IPv4.

Version of Helm and Kubernetes

Helm 3.x
Kubernetes v1.34.3-eks-ac2d5a0

Which chart?

agent-control-deployment 1.6.1
Installed via agent-control-bootstrap 1.6.0

What happened?

agent-control pods entered CrashLoopBackOff on an IPv6 EKS cluster. The container starts successfully, logs starting HTTP server at http://0.0.0.0:51200, then kubelet fails the startup probe against the pod IPv6 address:

Startup probe failed: Get "http://[2600:...]:51200/status": connect: connection refused

The process exits cleanly with code 0; the restart is caused by the failed probe.

The chart also blocks configuration overrides that could fix this:

• fails if server.host != 0.0.0.0
• fails if server.enabled = false
• does not expose startupProbe / livenessProbe values

What you expected to happen?

The chart should support IPv6/dual-stack clusters by allowing the status server and probes to work with IPv6 pod networking, or by exposing probe/config settings so users can configure that safely.

How to reproduce it?

1. Create an EKS cluster with IPv6 pod networking.
2. Install agent-control-bootstrap / agent-control-deployment.
3. Observe the agent-control pod.
4. Pod starts, but startup/liveness probe fails against the IPv6 pod IP and the pod restarts.

Anything else we need to know?

Relevant chart logic:

• templates/_helpers.tpl explicitly fails if server.host is not 0.0.0.0
• probes are hardcoded in templates/deployment-agentcontrol.yaml

Proposed fixes:

• allow overriding server.host to ::
• expose startupProbe / livenessProbe in values.yaml
• or switch probes to an exec probe so they are not dependent on pod IP family