Mukul SharmaandClaude Opus 5
04e7ef2f82
Lower RAM/disk for the same metric volume on an 8GB single node — VM's
own compression is the entire reason it exists as a project. Speaks
Prometheus's own query API (/api/v1/query), so nothing downstream
needed to change beyond the URL it points at: same PromQL, same
kubernetes-nodes-cadvisor-sourced container_cpu_usage_seconds_total /
container_memory_working_set_bytes toolshed's metrics work
(docs/PRODUCT-ARCHITECTURE.md step 5) already targets.
Three releases, matching the one-release-per-component convention
already used everywhere in this repo, since victoria-metrics-single has
no bundled scraper/exporter subcharts the way the Prometheus chart did:
- victoria-metrics-single: the TSDB + query engine. 3Gi/local-path,
7-day retention, resources capped at 512Mi — same trim reasoning as
the Prometheus server it replaces.
- vmagent: the scraper. Its default scrape_configs already includes
kubernetes-nodes-cadvisor and kubernetes-service-endpoints (the
chart's own comment says "COPY from Prometheus helm chart") — nothing
to override there, only remoteWrite pointed at victoria-metrics-single
and trimmed resources.
- node-exporter: pulled out of the removed Prometheus chart's bundled
subchart into its own standalone release, since victoria-metrics-single
has no equivalent. Same trim as before (32Mi/64Mi), same
prometheus.io/scrape annotation vmagent's default scrape config
already looks for.
Found and fixed while vendoring: helm-templates/victoria-metrics-single
already existed in this repo — a leftover GKE-targeted vendored copy
from the original Meesho monorepo import (commit b8575bb), with its own
templates/values.yaml for a different chart entirely. `mkdir -p` on an
already-existing directory silently did nothing, so the first vendoring
attempt left that old tree sitting alongside the new one and rendered
two ServiceAccounts/Services/StatefulSets with colliding names. Removed
outright rather than adapted, same reasoning as the ~35 charts
devops-helm-charts removed in its own prune — see this chart's own
Chart.yaml for the full note.
Verified with `helm template` against the real charts and these values
for all three releases individually, and again for the whole
generic-argo-apps-chart appSpec list (11 Applications render, including
the three new ones and nothing orphaned from the old prometheus entry).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wajog7nELA3i8JWTjxYGHF
devops-infra-helm-charts
This branch (main) is part of the restructuring process for the gcp-devops-admin repository, aimed at organizing helmcharts of all infrastructure tools and their corresponding value files. The purpose of this repository is to centralize and manage these resources efficiently.
Directory Structure
helm-templates
This directory is intended for caching or forking helm charts locally. If there's a need to modify or customize any helm chart, it can be done here. Otherwise, the charts will be used directly from the provider.
helm-overrides
The helm-overrides folder stores custom values files for helm charts. These files can be used to override the default values provided by the helm charts, whether they are forked or used directly from the provider.
cluster_name
Each tool within the repository may have different values based on the specific clusters. This directory is used to manage configurations and values tailored to different clusters.
manifests
The manifests directory contains manifest files that need to be applied only once. Examples include service-to-service configurations, storage classes, and any other manifest-related files necessary for the operation of the infrastructure tools.
Additional Notes
Please ensure that all changes made to this branch align with the restructuring objectives and follow the best practices for managing helm charts and infrastructure-related configurations.
For any questions or concerns, please reach out to the designated repository maintainers.