83 lines
5.4 KiB
Markdown
83 lines
5.4 KiB
Markdown
> Per AI Blitz Plan §claude. Layer: 1. Repo: devops-infra-helm-charts.
|
|
|
|
# 03 — Chart inventory
|
|
|
|
`helm-templates/` carries about 74 chart directories. They fall into three categories by structure and one cross-cutting category by lifecycle.
|
|
|
|
## By structure
|
|
|
|
### 1. Vanilla upstream cache
|
|
|
|
Most charts are pulled verbatim via `helm pull <repo>/<chart>` and committed. The `templates/` are *not* edited. Editing them silently forks the chart and the edits get clobbered the next time someone refreshes the cache. The pre-commit hooks do not catch this — only PR review does.
|
|
|
|
If a fork is intentional, it must be documented in the chart's `README.md` and called out in the PR. See [`../docs/platform/procedures/fork-upstream-chart.md`](../docs/platform/procedures/fork-upstream-chart.md).
|
|
|
|
Background: [`../wiki/analyses/ADR-A1-cache-vs-upstream-charts.md`](../wiki/analyses/ADR-A1-cache-vs-upstream-charts.md).
|
|
|
|
### 2. Thin wrapper
|
|
|
|
`Chart.yaml` declares `dependencies:` pointing at one or more upstream charts. The local `templates/` is empty or carries only a thin glue manifest. Used so a single Argo Application can install a stack (e.g., kube-prometheus-stack carries Prometheus + Alertmanager + Grafana + node-exporter + kube-state-metrics together).
|
|
|
|
When bumping a wrapper, refresh `Chart.lock` with `helm dependency update helm-templates/<chart>`. See [`../docs/platform/procedures/update-chart-version.md`](../docs/platform/procedures/update-chart-version.md).
|
|
|
|
### 3. Intentional fork
|
|
|
|
A small number of charts have deliberate `templates/` edits — local CRD patches, label injection, removed sub-resources we don't want, etc. Each fork should be self-documenting in its `README.md`. If the rationale is missing, treat the fork as suspect and escalate per [`../docs/global/escalation-matrix.md`](../docs/global/escalation-matrix.md).
|
|
|
|
## By lifecycle — versioned siblings
|
|
|
|
A chart family often has two siblings live simultaneously to support blue-green migrations:
|
|
|
|
| Stable | Migration target | Used for |
|
|
|--------|------------------|----------|
|
|
| `argo-cd` | `argo-cd-green` | Green-deploy of the Argo CD control plane itself |
|
|
| `contour` | `contour-v1.33.3` | Pinned-version migration of the ingress data plane |
|
|
| `keda` | `keda-2.17.1` | Autoscaler version cutover |
|
|
| `opentelemetry-collector` | `opentelemetry-collector-latest` | OTel collector cutover |
|
|
| `victoria-metrics-cluster` | `victoria-metrics-cluster-latest` | VM cluster cutover |
|
|
| `victoria-metrics-agent` | `victoria-metrics-agent-latest` | VM agent cutover |
|
|
| `sonarqube` | (was forward; `sonarqube-old` retained) | SonarQube major cutover |
|
|
|
|
The `-green` / `-vX.Y.Z` / `-latest` / `-old` suffix names the **migration target** (or in `-old`'s case, the kept-around predecessor). Both can be live at once on different clusters or even on the same cluster (different Argo Applications). Deletion of a sibling requires confirming zero references in the sister repo. See [`../wiki/analyses/ADR-A2-blue-green-sibling-pattern.md`](../wiki/analyses/ADR-A2-blue-green-sibling-pattern.md) and [`../docs/platform/procedures/blue-green-chart-migration.md`](../docs/platform/procedures/blue-green-chart-migration.md).
|
|
|
|
## Multi-Contour pattern
|
|
|
|
Contour is unique in that a single cluster runs **multiple separate Contour Helm releases**, each pinned to its own node pool / compute class. The standard set:
|
|
|
|
- `contour-external` — public-facing ingress, primary
|
|
- `contour-external-1` — public-facing ingress, secondary (capacity / blue-green)
|
|
- `contour-internal-0`, `contour-internal-1` — internal mesh ingress, redundant pair
|
|
- `contour-internal-intra-0`, `contour-internal-intra-1` — intra-VPC ingress, redundant pair
|
|
|
|
Per-cluster matrix of which release goes on which node pool: repo-root `contour-nodeselector-tolerations-summary.md`. Each release has its own `helm-overrides/<cluster>/<contour-release>/custom-values.yaml`.
|
|
|
|
## Notable individual charts
|
|
|
|
| Chart | Notes |
|
|
|-------|-------|
|
|
| `argo-cd` / `argo-cd-green` | Self-managing — Argo CD installs itself. Sync policy must be careful. |
|
|
| `vault` | Stateful HA on Raft. Edits to seal config or HA storage require platform-team review. |
|
|
| `external-secrets` | Source of truth for secret materialization on each cluster. See [`./06-secrets-and-identity.md`](./06-secrets-and-identity.md). |
|
|
| `kyverno` | Cluster-policy enforcement. Edits change admission behaviour for all workloads. |
|
|
| `kube-prometheus-stack` | Bundles Prometheus + Alertmanager. Alert rules pages on-call — validate PromQL. See [`../docs/global/coding-guidelines/observability.md`](../docs/global/coding-guidelines/observability.md). |
|
|
| `external-dns` | Publishes DNS records to Cloud DNS. Often paired with sidecar `external-dns-services/*.yaml` raw manifests. |
|
|
| `cert-manager` | Issues TLS certs (Let's Encrypt + Vault). |
|
|
|
|
## Image registry convention
|
|
|
|
Production overrides pin images to Meesho's Artifact Registry mirror:
|
|
|
|
```
|
|
asia-southeast1-docker.pkg.dev/meesho-devops-admin-0622/admin/sre/<image>
|
|
```
|
|
|
|
…rather than Docker Hub directly. Mirroring decouples deploys from upstream registry availability and rate limits.
|
|
|
|
## See also
|
|
|
|
- [`./01-repo-structure.md`](./01-repo-structure.md)
|
|
- [`./02-cluster-fleet.md`](./02-cluster-fleet.md)
|
|
- [`./04-override-hierarchy.md`](./04-override-hierarchy.md)
|
|
- [`../docs/platform/procedures/update-chart-version.md`](../docs/platform/procedures/update-chart-version.md)
|
|
- [`../docs/platform/procedures/fork-upstream-chart.md`](../docs/platform/procedures/fork-upstream-chart.md)
|