Files
devops-infra-argo-config-gcp/values/incubator-infra-k8s-admin-prd-ase1-values.yaml
T
Mukul SharmaandClaude Opus 5 1c6c6fc2c3 Register the prometheus appSpec entry
Points at the chart and values just added to devops-infra-helm-charts.
nameOverride pinned to "prometheus" so the Helm release name matches
what the chart's server Service naming depends on
("<release-name>-server") — see that repo's commit for the full
reasoning, since this file is the one place that decision has to be
made correctly for toolshed's already-seeded PROMETHEUS_URL to resolve.

Needs the usual two syncs to actually deploy: this values file only
takes effect once incubator-infra-k8s-admin-prd-ase1 is synced (which
creates/updates the child "prometheus" Application object), and that
child Application then needs its own sync to actually create anything
in the cluster.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wajog7nELA3i8JWTjxYGHF
2026-09-06 07:30:51 +05:30

161 lines
7.3 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: prometheus
# Server only — see custom-values.yaml for exactly why the chart's
# alertmanager/kube-state-metrics/node-exporter/pushgateway subcharts
# are all disabled, and why that is enough for what consumes this:
# toolshed's per-app CPU/memory metrics (docs/PRODUCT-ARCHITECTURE.md
# step 5), read straight from the built-in kubernetes-nodes-cadvisor
# scrape job.
#
# Vendored official chart (prometheus-community/prometheus), not
# hand-written — unlike postgresql, this one has a real official
# chart, and Contour/ArgoCD/Vault/Gitea/Harbor/Jenkins already use
# this same vendor-the-official-chart pattern rather than reinventing
# RBAC and Kubernetes service discovery by hand.
#
# nameOverride pinned to exactly "prometheus" for the same reason as
# postgresql/gitea above — without it every rendered object name
# becomes "prometheus-admin-prd-prd" instead. This one matters more
# than most: the chart's server Service renders as
# "<release-name>-server", so pinning the release name to "prometheus"
# is what makes it "prometheus-server" — the exact hostname toolshed's
# PROMETHEUS_URL already points at
# (prometheus-server.monitoring.svc.cluster.local), seeded before this
# existed so the connection would already be correct the day it did.
nameOverride: prometheus
namespace: monitoring
chartDir: prometheus
valuesDir: prometheus