astral/kuber
3
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: enhance database and storage management with Longhorn support

Browse Source
This commit is contained in:
dmgnr
2026-09-02 14:07:14 +07:00 Unverified
parent 6c8c8e0c1b
commit 26c2d0f015
12 changed files with 632 additions and 133 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+17 -5
View File
@@ -108,7 +108,7 @@ For a permanent setup, write the generated script to a file and source it from y
- `logs -f [deployment]`: follow logs continuously
- `exec <deployment> <command...>`: execute a command inside a running deployment pod
- `db ls`: list managed Postgres claims declared in the current Compose file
- `db creds <service>`: print the generated connection details for a managed Postgres claim
- `db creds <service>`: reconcile and print the generated connection details for a managed Postgres claim
- `s3 ls`: list managed S3 claims declared in the current Compose file
- `s3 creds <service>`: print all generated S3 environment variables for a service
- `s3 ui <service>`: print the Garage UI object-browser URL for a service bucket
@@ -236,7 +236,12 @@ services:
- postgresql:user/database
```
This creates or reuses the managed CNPG role secret, reconciles the database resource, and injects `DATABASE_URL` into the generated app secret in Kubernetes.
This creates or reuses the managed CNPG role secret, reconciles the database
resource, and injects `DATABASE_URL` and
`REDIS_URL=redis://redis.database.svc.cluster.local` into the generated app
secret in Kubernetes. `REDIS_URL` is only added to services with a managed
Postgres claim. Running `kuber db creds <service>` performs the same focused
Secret, role, and Database reconciliation before printing credentials.
### Managed S3
@@ -297,7 +302,11 @@ This is also where generated values such as `DATABASE_URL` and the managed S3 en
- `postgresql:...` is treated as a managed database claim, not as a filesystem mount
- `s3:...` is treated as a managed object-storage claim, not as a filesystem mount
Named volumes also support kuber-specific storage hints.
Named volumes also support kuber-specific Longhorn storage hints. Kuber renders
each distinct placement policy as a deterministic, reusable Longhorn
`StorageClass`, then references that class from the PVC. The generated class
uses Longhorn's `numberOfReplicas`, `diskSelector`, and `dataLocality`
parameters; placement fields are never written directly to the PVC.
Default behavior:
@@ -329,8 +338,8 @@ services:
Meaning:
- `name(20Gi):/path` -> PVC size `20Gi`
- `name(20Gi on archive):/path` -> PVC size `20Gi`, `diskTag: ["archive"]`, `dataLocality: "none"`
- `name(20Gi on 1 archive):/path` -> PVC size `20Gi`, `replicaCount: 1`, `diskTag: ["archive"]`, `dataLocality: "none"`
- `name(20Gi on archive):/path` -> PVC size `20Gi`, with a StorageClass using `diskSelector: "archive"` and disabled data locality
- `name(20Gi on 1 archive):/path` -> PVC size `20Gi`, with a StorageClass using one replica and `diskSelector: "archive"`
Explicit extensions are also supported.
@@ -368,6 +377,9 @@ Precedence:
- top-level `volumes.<name>.x-*`
- fallback default `1Gi on 2 fast`
StorageClasses are cluster-scoped and content-addressed by policy. They are
shared across projects and intentionally retained when a project is removed.
## Building
Image builds run through the selected SSH builder. After a push, the registry's