Repository navigation
feat(apexkube-agent): render a Service for the metrics agent (2.2.0) - #158
Merged
Merged
Conversation
The metrics profile had no stable in-cluster address: writers had to target the pod IP, so every consuming cluster created the Service itself (hydra31 did exactly that, out of band, to prove the mesh remote-write path end to end). The metrics profile now renders a ClusterIP Service <fullname>-metrics on metrics.envoy.containerPort (10000) with targetPort "http". No new values: an agent that writes into the mesh is written to by the local Prometheus, so the Service is part of what metrics.enabled means rather than an extra opt-in. Envoy preserves the request path, so writers POST to /api/v1/receive and the backend receives it unchanged. The access profile is untouched: access-only renders byte-identical to published 2.1.0 apart from the helm.sh/chart version and the checksums derived from it. For the metrics profile the only difference is the one added Service. Ticket: INTINF-428
Luv7804
force-pushed
the
agent/feat/apexkube-metrics-service
branch
from
October 31, 2026 07:22
c350ed0 to
a3a2630
Compare
Luv7804
changed the title
HussainTechSavvy
approved these changes
Oct 31, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
The metrics profile turns a cluster into a mesh metrics destination, but it gave that agent no stable in-cluster address. Writers had to target the pod IP, so every consuming cluster created the Service itself.
That is exactly what hydra31 needed to prove the path in INTINF-428: Prometheus remote-writes to
apexkube-agent-2-metrics-relay:10000/api/v1/receive, a Service applied out of band that GitOps does not own.What
metrics.enabled: truenow also renders oneClusterIPService<fullname>-metricson port10000(metrics.envoy.containerPort),targetPort: http.No new values. The cluster that writes to the agent — local Prometheus → agent → tunnel — always needs this Service, so it is part of what the metrics profile means rather than an extra opt-in switch.
Envoy preserves the request path, so writers POST to
/api/v1/receiveand the backend receives it unchanged — no rewrite, no extra hop.The Service adds discovery, not reachability: the metrics envoy already binds
0.0.0.0:10000, so the pod IP was always accepting in-cluster traffic. A cluster that only forwards mesh traffic to a local backend never uses the Service; one unused ClusterIP.Render impact
helm.sh/chartand the checksums derived from it; 8 objects, 0 ServicesService/<fullname>-metrics; no other object changedmetrics.envoy.containerPort: 99999999,targetPort: httphelm lintclean on both profiles. CI's metrics values exercise the new template throughct installon all four k8s versions.Version
2.2.0(additive).appVersionstays1.0.1.Ticket: INTINF-428