humanize docs: fix bold abuse, title case, single-item lists, ProtonVPN ref

This commit is contained in:
Tuan-Dat Tran
2026-04-28 18:54:23 +02:00
parent 3ac7d91101
commit c48ced6207
3 changed files with 35 additions and 51 deletions

View File

@@ -2,7 +2,7 @@
## Overview
Three storage tiers serve different workloads:
Three storage tiers, each doing a different job:
| Tier | System | Access | Used by |
|------|--------|--------|---------|
@@ -14,46 +14,30 @@ Three storage tiers serve different workloads:
## Longhorn
Longhorn provides distributed block storage across all 14 agent nodes. Each volume is replicated (default: 3 replicas) across different nodes.
Longhorn gives distributed block storage across all 14 agent nodes. Each volume is replicated (default: 3 replicas) across different nodes, using the local disk on each agent (128 GB each).
- **RWO** (ReadWriteOnce) — used for most services (Vaultwarden, Paperless, etc.)
- **RWX** (ReadWriteMany) — used where multiple pods need shared access
- Volumes are backed by the local disk on each agent node (128 GB each)
- Longhorn manager runs as a DaemonSet; the CSI plugin integrates with the K8s storage layer
- Snapshots and backups are supported via the Longhorn UI
RWO (ReadWriteOnce) covers most services. RWX (ReadWriteMany) is used where multiple pods need access to the same volume. Snapshots and backups are available through the Longhorn UI.
Control plane nodes (`k3s-server-*`) are tainted `NoSchedule` — Longhorn manager tolerates this taint and runs everywhere, but user workloads are pushed to agent nodes only.
Control plane nodes are tainted `NoSchedule` — Longhorn manager tolerates this and runs everywhere, but user workloads stay on agent nodes.
---
## CloudNativePG
The CNPG operator manages HA PostgreSQL clusters as first-class Kubernetes resources. Currently used by:
- **Immich** — primary database (photos, albums, users, ML embeddings)
CNPG handles streaming replication, failover, and scheduled backups. Data is stored on Longhorn PVCs.
CloudNativePG manages HA PostgreSQL clusters as Kubernetes resources. Immich uses it for its primary database (photos, albums, users, ML embeddings). CNPG handles streaming replication, failover, and scheduled backups, with data stored on Longhorn PVCs.
---
## NFS
A dedicated physical node (`aya01`) runs a bare-metal NFS server. This serves the media library to Jellyfin.
`aya01` is a dedicated bare-metal NFS server. Jellyfin mounts the share from `docker-host11` to access movies, TV shows, and music. Keeping the media library on a separate host means the Jellyfin VM can be rebuilt without touching the data.
- Movies, TV shows, and music live on `aya01`
- `docker-host11` (where Jellyfin runs) mounts the NFS share
- Separating media storage from the compute host means the Jellyfin VM can be rebuilt without touching the library
- NFS is not used for K8s workloads — Longhorn handles all PVC-backed storage
NFS is not used for K8s workloads — Longhorn handles all PVC-backed storage.
---
## Secret Storage
## Secrets
Kubernetes secrets are managed with **Sealed Secrets** (Bitnami). The workflow:
Kubernetes secrets go through Sealed Secrets (Bitnami). The workflow: create a regular `Secret`, encrypt it with `kubeseal` using the cluster's public key into a `SealedSecret`, then commit that to Git. Only the in-cluster controller can decrypt it.
1. Create a regular K8s `Secret`
2. Encrypt it with `kubeseal` using the cluster's public key → produces a `SealedSecret`
3. Commit the `SealedSecret` to Git — it is safe to store publicly
4. The in-cluster Sealed Secrets controller decrypts it into a regular `Secret` at apply time
Ansible secrets (VM credentials, API tokens) are encrypted with **Ansible Vault** and stored in `vars/group_vars/*/secrets_*.yaml`.
Ansible secrets (VM credentials, API tokens) are encrypted with Ansible Vault and live in `vars/group_vars/*/secrets_*.yaml`.