48 lines
2.3 KiB
Markdown
48 lines
2.3 KiB
Markdown
---
|
|
title: No Helm Policy
|
|
modified: 2026-04-04
|
|
tags:
|
|
- explanation
|
|
- kubernetes
|
|
---
|
|
|
|
# No Helm Policy
|
|
|
|
> **Note:** This article was drafted by AI and reviewed by Erich. I plan to rewrite all explanatory content in my own words - these serve as placeholders to establish the documentation structure.
|
|
|
|
BlumeOps avoids Helm charts as a deployment mechanism. Plain kustomize manifests are the standard for all services.
|
|
|
|
## Rationale
|
|
|
|
Helm templates add a layer of abstraction that works against the simplicity of Kubernetes YAML manifests. Go templates embedded in YAML are hard to read, hard to diff, and hard to reason about. A manifest should be a manifest — not a program that generates one.
|
|
|
|
Kustomize overlays preserve the readability of plain YAML while providing the composition and patching features needed for environment-specific configuration. Version bumps are a one-line `newTag` edit in `kustomization.yaml`, and `kubectl diff` shows exactly what will change.
|
|
|
|
## Current State
|
|
|
|
All services in blumeops use kustomize manifests except:
|
|
|
|
- **1Password Connect** — still deployed via Helm chart (`connect-helm-charts v2.3.0`). Migration is a future goal.
|
|
|
|
## Migration History
|
|
|
|
Services previously deployed via Helm that have been migrated to kustomize:
|
|
|
|
| Service | Migrated | Notes |
|
|
|---------|----------|-------|
|
|
| Grafana | 2026-02 | Converted during v12.x upgrade |
|
|
| CloudNative-PG | 2026-02 | Switched to upstream release manifest via forge mirror |
|
|
| External Secrets | 2026-03 | Static manifests rendered from chart |
|
|
| Homepage | 2026-02 | Replaced chart with plain manifests |
|
|
| Immich | 2026-04 | Converted during v2.6.3 upgrade |
|
|
|
|
## Guidelines
|
|
|
|
- **Do not introduce new Helm chart dependencies.** When deploying a new service, write kustomize manifests directly — even if the upstream project provides a Helm chart. The chart's `helm template` output is a fine starting point for writing those manifests.
|
|
- **When upgrading a Helm-based service**, consider whether it's a good time to migrate off Helm as part of the upgrade.
|
|
- **Upstream manifests** can be referenced directly in `kustomization.yaml` resources (like ArgoCD and Tailscale operator do) or applied via ArgoCD's `directory.include` (like CloudNative-PG). Both avoid Helm.
|
|
|
|
## Related
|
|
|
|
- [[review-services]] — Service review process
|
|
- [[architecture]] — Overall infrastructure design
|