Erich Blume
c7e5af6d51
## Summary - Renders manifests from `connect-helm-charts v2.4.1` as plain kustomize (deployment + service) - Bumps 1Password Connect from 1.8.1 → 1.8.2 - Completes the no-helm-policy migration — all services now use kustomize - Retains all production hardening from the Helm chart (securityContext, runAsNonRoot, drop ALL, seccomp, resource limits) ## Changes - **New:** `deployment.yaml`, `service.yaml`, `kustomization.yaml` in `argocd/manifests/1password-connect/` - **Rewritten:** Both ArgoCD app definitions (indri + ringtail) — single source kustomize instead of multi-source Helm - **Deleted:** `values.yaml` (Helm values no longer needed) - **Updated:** `no-helm-policy.md`, `service-versions.yaml`, `README.md` ## Deployment plan 1. Sync `apps` app to pick up the new app definitions 2. `argocd app set 1password-connect --revision 1password-connect-kustomize` 3. `argocd app sync 1password-connect` — verify on indri 4. Repeat for ringtail 5. After merge: reset revision to main, re-sync both ## Test plan - [ ] `kubectl kustomize` renders cleanly (verified locally) - [ ] ArgoCD diff shows expected changes (Helm labels removed, images bumped) - [ ] Pods come up healthy on indri - [ ] External Secrets still resolves 1Password items - [ ] Repeat on ringtail Reviewed-on: #326
47 lines
2.4 KiB
Markdown
47 lines
2.4 KiB
Markdown
---
|
|
title: No Helm Policy
|
|
modified: 2026-04-06
|
|
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. The last Helm dependency (1Password Connect) was migrated in 2026-04.
|
|
|
|
## 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 |
|
|
| 1Password Connect | 2026-04 | Rendered from chart v2.4.1, bumped to 1.8.2 |
|
|
|
|
## 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
|