Mukul SharmaandClaude Opus 5
919ebd5ab8
Matches the chart-side replacement in devops-infra-helm-charts. Three Applications now where there was one, since victoria-metrics-single bundles no scraper or exporter the way the Prometheus chart did. Sync order matters here specifically: victoria-metrics-single needs to exist before vmagent's remote_write target resolves, though ArgoCD sync failures are naturally retried so this only affects how quickly it converges, not whether it does. Verified with `helm template` against generic-argo-apps-chart and this values file: 11 Applications render, the three new ones present and correctly formed, nothing left pointing at the removed prometheus chartDir. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Wajog7nELA3i8JWTjxYGHF
179 lines
8.2 KiB
YAML
179 lines
8.2 KiB
YAML
clusterSpec:
|
|
# "k8s-admin-prd-ase1" only resolved in the fleet because that name was
|
|
# registered as an external cluster in the hub ArgoCD's cluster list.
|
|
# There's no hub here — one ArgoCD, running on the cluster it manages —
|
|
# so this has to be the built-in local-cluster alias instead.
|
|
destination:
|
|
server: ""
|
|
name: "in-cluster"
|
|
|
|
argocdSpec:
|
|
# Was argocd-admin (a separate hub namespace in the fleet's two-tier
|
|
# setup). Single ArgoCD instance here, so Application objects live in
|
|
# the same namespace as ArgoCD itself — see claude.md.
|
|
namespace: argocd
|
|
|
|
teamSpec:
|
|
devops:
|
|
source:
|
|
repoURL: http://gitea.192.168.1.7.nip.io/mukul/devops-infra-helm-charts.git
|
|
targetRevision: main
|
|
path: helm-templates
|
|
valueFiles: ../../helm-overrides/k8s-admin-prd-ase1
|
|
labels:
|
|
bu: infra
|
|
team: devops
|
|
env: prd
|
|
cluster: k8s-admin-prd-ase1
|
|
|
|
appSpec:
|
|
- name: argocd
|
|
nameOverride: argocd-admin-prd
|
|
namespace: argocd
|
|
chartDir: argo-cd
|
|
valuesDir: argocd-admin-prd
|
|
- name: gitea
|
|
# Adopting the already-running standalone install (helm release
|
|
# "gitea" in namespace "gitea", from deploy_gitea.sh) rather than
|
|
# deploying a second one — nameOverride pins the rendered
|
|
# Application's name (and therefore the Helm release name Argo
|
|
# renders with) to match those existing object names exactly.
|
|
nameOverride: gitea
|
|
namespace: gitea
|
|
chartDir: gitea
|
|
valuesDir: gitea
|
|
# NOT using the Application-wide `replace: true` here anymore — it
|
|
# forces a full PUT of every resource this Application renders, and a
|
|
# bound PVC's spec is immutable (volumeName/storageClassName get
|
|
# filled in by the provisioner after binding; a PUT that omits them
|
|
# looks like clearing them, which the API correctly refuses). The
|
|
# Deployment-only fix now lives as a per-resource sync-option
|
|
# annotation in helm-overrides/k8s-admin-prd-ase1/gitea/custom-values.yaml
|
|
# (deployment.annotations), which only Replaces the Deployment.
|
|
- name: vault
|
|
# Adopting the running production-mode Vault (helm release "vault" in
|
|
# namespace "vault", chart 0.34.1 — see helm-templates/vault/Chart.yaml).
|
|
# It's already initialized and unsealed; this Application only manages
|
|
# Vault's Deployment/config, never its data or seal state. Review the
|
|
# first diff carefully before syncing — this is the highest-consequence
|
|
# adoption in this repo so far.
|
|
nameOverride: vault
|
|
namespace: vault
|
|
chartDir: vault
|
|
valuesDir: vault
|
|
- name: contour
|
|
# Adopting the running ingress (helm release "contour" in namespace
|
|
# "projectcontour", chart 0.7.0 — the OFFICIAL projectcontour chart,
|
|
# not the Bitnami one that used to be wired up as helm-templates/contour
|
|
# — see the note in that Chart.yaml and claude.md issue #4). This is
|
|
# the ingress path for every other Application in this repo — review
|
|
# the diff before syncing, same caution as vault.
|
|
nameOverride: contour
|
|
namespace: projectcontour
|
|
chartDir: contour
|
|
valuesDir: contour
|
|
- name: external-secrets
|
|
# Correction from an earlier version of this file: "no nameOverride
|
|
# needed" was wrong. Without one, the Application (and therefore the
|
|
# Helm release name the chart templates with) becomes
|
|
# "external-secrets-admin-prd" — so the controller's ServiceAccount
|
|
# actually ends up named external-secrets-admin-prd, not
|
|
# external-secrets. secretstores/vault-backend.yaml's
|
|
# serviceAccountRef assumes the plain name, and Vault's role was bound
|
|
# to bound_service_account_names=external-secrets — both need this
|
|
# pinned name to match.
|
|
nameOverride: external-secrets
|
|
namespace: external-secrets
|
|
chartDir: external-secrets
|
|
valuesDir: external-secrets
|
|
# ClusterSecretStore's CRD (large embedded OpenAPI schema) exceeds the
|
|
# 256KiB last-applied-configuration annotation limit on a normal
|
|
# client-side apply. SSA sidesteps it entirely — see the note in
|
|
# generic-argo-apps-chart's template.
|
|
serverSideApply: true
|
|
- name: jenkins
|
|
# Fresh install, but pinning nameOverride anyway — learned from
|
|
# external-secrets that skipping it produces
|
|
# "jenkins-admin-prd"-suffixed resource names, which
|
|
# jenkins-admin-credentials (the ExternalSecret, namespace "jenkins")
|
|
# doesn't need to care about, but keeps naming predictable and
|
|
# consistent with every other app here regardless.
|
|
nameOverride: jenkins
|
|
namespace: jenkins
|
|
chartDir: jenkins
|
|
valuesDir: jenkins
|
|
- name: harbor
|
|
# Fresh install (helm list -n harbor came back empty despite claude.md
|
|
# saying otherwise). nameOverride pinned for the same predictability
|
|
# reason as jenkins — rendered object names all end up prefixed with
|
|
# this (harbor-core, harbor-registry, etc.), which is also what
|
|
# Jenkins needs to reference for internal image pushes
|
|
# (harbor-core.harbor.svc.cluster.local).
|
|
nameOverride: harbor
|
|
namespace: harbor
|
|
chartDir: harbor
|
|
valuesDir: harbor
|
|
- name: postgresql
|
|
# Backs toolshed's control plane. Own namespace rather than living
|
|
# inside toolshed, so it is addressed over cluster DNS like any other
|
|
# platform component and outlives whatever consumes it:
|
|
# postgresql.postgres.svc.cluster.local:5432
|
|
#
|
|
# nameOverride pinned for the same reason as everything else here —
|
|
# without it the rendered Application (and therefore the Helm release
|
|
# name, and therefore every object name) becomes
|
|
# "postgresql-admin-prd-prd".
|
|
#
|
|
# Hand-written chart, not Bitnami's: that registry has been actively
|
|
# unstable (infra issue #4) and PostgreSQL ships no official chart.
|
|
# Requires secretstores/toolshed-postgres-credentials.yaml to have
|
|
# synced first — the pod cannot start without the Secret.
|
|
nameOverride: postgresql
|
|
namespace: postgres
|
|
chartDir: postgresql
|
|
valuesDir: postgresql
|
|
- name: victoria-metrics-single
|
|
# Replaces the Prometheus server this entry briefly was (see git
|
|
# history on this file) — same job, lower RAM/disk footprint for the
|
|
# same metric volume, and it speaks Prometheus's own query API
|
|
# (/api/v1/query) so nothing downstream (toolshed's metrics
|
|
# connection, docs/PRODUCT-ARCHITECTURE.md step 5) needed to change,
|
|
# only the URL it points at.
|
|
#
|
|
# Vendored official chart (victoriametrics/helm-charts), same
|
|
# vendor-the-official-chart pattern as Contour/ArgoCD/Vault/Gitea/
|
|
# Harbor/Jenkins. This exact directory name already existed in this
|
|
# repo before — a leftover GKE-targeted vendored copy from the
|
|
# original Meesho monorepo import — and was removed rather than
|
|
# adapted; see that chart's own Chart.yaml comment.
|
|
#
|
|
# nameOverride pinned to exactly "victoria-metrics-single" for the
|
|
# same reason as postgresql/gitea/prometheus above: the chart's
|
|
# server Service renders as "<release-name>-server", so this is what
|
|
# makes it resolvable at a predictable hostname
|
|
# (victoria-metrics-single-server.monitoring.svc.cluster.local:8428)
|
|
# rather than "victoria-metrics-single-admin-prd-prd-server".
|
|
nameOverride: victoria-metrics-single
|
|
namespace: monitoring
|
|
chartDir: victoria-metrics-single
|
|
valuesDir: victoria-metrics-single
|
|
- name: vmagent
|
|
# The scraper — pulls from the same targets the Prometheus server
|
|
# used to scrape directly (kubelet's cAdvisor endpoint, and anything
|
|
# carrying a prometheus.io/scrape annotation, e.g. node-exporter
|
|
# below) and remote_writes into victoria-metrics-single. Needs that
|
|
# component's Service name, so bring it up after, not before.
|
|
nameOverride: vmagent
|
|
namespace: monitoring
|
|
chartDir: vmagent
|
|
valuesDir: vmagent
|
|
- name: node-exporter
|
|
# Host-level metrics (disk/memory/load) — independent of which TSDB
|
|
# stores them, so vendored standalone rather than as a subchart of
|
|
# anything. Was a subchart of the (now removed) Prometheus server
|
|
# entry; moved out to its own release when that server was replaced,
|
|
# since victoria-metrics-single has no equivalent bundled subchart.
|
|
nameOverride: node-exporter
|
|
namespace: monitoring
|
|
chartDir: node-exporter
|
|
valuesDir: node-exporter |