Ziti-k8s-agent: hardcoded CPU limit

Tunneler Apps Ziti Edge Tunnel
1

Hi all,

we run the ziti-k8s-agent in a self-hosted OpenZiti deployment and are trying to decide whether to keep building on it. Two observations first:

  • The injected ziti-tunnel sidecar's CPU limit is not configurable through the Helm chart. In our case the sidecar's default CPU limit was the binding constraint on throughput: sustained CFS throttling on the sidecar's cgroup, capping us at ~ 30 Mbit/s. Raising the limit took us to ~500 Mbit/s with no other changes.
  • PR #56 addresses precisely this (plus a few other chart gaps), but has had no review activity since April. The dependabot bump in #54 has been open since November 2025, and the most recent release is from November 2025 as well.

This isn't meant as a complaint — I'd just like to plan honestly rather than guess. So:

  1. Is ziti-k8s-agent considered a supported production component, or is it closer to an example/reference implementation? Both answers are useful to us, they just lead to different decisions, particularly since the webhook holds a Ziti admin identity with full management privileges. Relatedly: your own Kubernetes guides point to ziti-host and ziti-edge-tunnel rather than the agent, so I'd also like to know whether per-namespace sidecar injection is still a pattern you'd recommend.

  2. If it is maintained: is there a rough expectation for reviewing external chart PRs? I'm happy to help get #56 into a reviewable shape. The resource-configuration commit stands on its own; the sidecar-to-initContainer change is a behavioural change that probably deserves its own PR, an opt-in values flag and an explicit minimum Kubernetes version, since native sidecars also change effective pod requests and therefore interact with LimitRange and ResourceQuota.

  3. If it isn't a current priority: what's the pattern you'd recommend today for per-namespace tunneler identities in Kubernetes? We can fork and maintain our own build, but I'd rather not diverge if there's a better-supported direction.

Happy to contribute docs or tests if that helps move things along.

Thanks! Keep up the amazing Work!