jklein
813c796a7b
Validate Helm Charts / Detect changed charts (pull_request) Successful in 3s
Validate Helm Charts / Resource quantities (pull_request) Successful in 8s
Validate Helm Charts / Build ${{ fromJSON(needs.detect-changed-charts.outputs.charts) }} (pull_request) Successful in 4s
Validate Helm Charts / Trivy config ${{ fromJSON(needs.detect-changed-charts.outputs.scan-charts) }} (pull_request) Successful in 11s
Validate Helm Charts / Install-test ${{ fromJSON(needs.detect-changed-charts.outputs.install-charts) }} (pull_request) Successful in 1m22s
Publish Helm Chart with patched Application Version / publish-helm-chart (push) Successful in 7s
Publish Valkey Helm Chart / Publish Valkey Helm Chart (push) Successful in 7s
A new chart for a single Valkey instance per application, replacing the
shared cluster-redis whose separation rests on one ACL file in one
1Password field - a construction in which every change touches six
applications and which cost a month of Paperless standstill.
Shape: StatefulSet with one replica, ClusterIP Service, no cluster mode,
no Ingress and no value to add one.
The password arrives as a finished configuration line ("requirepass
<secret>") in the 1Password field auth-conf, is mounted as a file and
included by the main configuration - never in argv, never in the
environment. The include is rendered last, so nothing in extraConfig can
override it. Because a misspelled or empty field would leave an open
server that looks perfectly healthy, an init container greps the mounted
file for the line and refuses to start the pod without it; it never
prints the file.
maxmemory is derived from the computed memory limit (maxmemoryFactor,
default 0.75) and a configured value above that limit aborts the render:
otherwise the kubelet's OOM kill decides what the eviction policy was
configured to decide. Persistence and eviction are documented as pairs -
queue (PVC + noeviction, the default) and cache (emptyDir +
allkeys-lru) - and the combination "no persistence + noeviction" carries
a warning in values.yaml and in NOTES.txt.
Probes: valkey-cli ping as an exec probe, authenticated through
VALKEYCLI_AUTH read out of the mounted file, with "-e" and an assertion
on the answer PONG. Without -e valkey-cli exits 0 on an error reply
(valkey 9.1.2, src/valkey-cli.c: the config.set_errcode branch in
cliReadReply), which would make the probe unable to fail.
Hardening: uid 999 / gid 1000 - the image's own valkey user - with
fsGroup matching, runAsNonRoot, readOnlyRootFilesystem, all capabilities
dropped and seccompProfile RuntimeDefault in the pod context so the init
container is covered too. /data is the only writable path.
NetworkPolicy on by default (first chart in this repo with one), with a
switch and a list of additional namespaces; values.yaml names that it is
only a boundary where the CNI enforces policies.
Wiring: publish-valkey.yml, the chart-name choice list, ci/valkey
fixtures for the persistent variant, a plain docker-versioning Renovate
block, README chart row.
34 lines
1.7 KiB
YAML
34 lines
1.7 KiB
YAML
apiVersion: v2
|
|
name: valkey
|
|
description: A Helm chart to deploy a single Valkey instance (cache or queue backend) for one application on Kubernetes
|
|
icon: https://avatars.githubusercontent.com/u/164458127
|
|
|
|
type: application
|
|
|
|
# appVersion is the exact image tag, "9.1.2-alpine" - the version AND the base
|
|
# flavour, so the "+up" suffix carries both with the dash normalized to a dot.
|
|
#
|
|
# Why "-alpine" and not the fully numbered "-alpine3.24" (Gitea #46, third plan
|
|
# comment): neither tag is immutable. Upstream rebuilds the whole tag matrix
|
|
# periodically, and the build timestamps prove it - "9.1-alpine" and
|
|
# "9.0.6-alpine3.24" were pushed within minutes of each other on 2026-09-21
|
|
# although 9.0.6 is the older release line. Only a digest is immutable. So the
|
|
# choice was never "immutable vs. moving" but between two equally moving tags
|
|
# with different Renovate behaviour, and "-alpine" is the better one: docker
|
|
# versioning splits at the first dash, reads 9.1.2 as the version and "alpine"
|
|
# as the compatibility suffix, so the suffix stays constant forever and the
|
|
# update path can never freeze. With "-alpine3.24" it would: upstream builds
|
|
# exactly one Alpine base per Valkey release, so the next base arrives as
|
|
# "9.1.3-alpine3.25" - a candidate a suffix-bound rule never offers, and
|
|
# "no update" looks identical to a working rule.
|
|
#
|
|
# The price, named rather than discovered: a rebuild of 9.1.2-alpine changes the
|
|
# running image with no change in this repository and nothing reports it. The
|
|
# remedy if that ever matters is pinDigests for this one image - see the valkey
|
|
# block in renovate.json5.
|
|
version: 1.0.0+up9.1.2.alpine
|
|
appVersion: "9.1.2-alpine"
|
|
|
|
maintainers:
|
|
- name: jklein
|