Add revisionHistoryLimit parameter to control how many old ReplicaSets are
retained for rollback purposes, reducing etcd storage usage compared to
Kubernetes default of 10.
Changes:
- Add revisionHistoryLimit parameter in values.yaml (default: 3)
- Add revisionHistoryLimit to deployment.yaml spec
- Provide comprehensive documentation with recommendations
- Bump chart version 2.5.0 -> 2.5.1 (patch - minor enhancement)
- Add changelog annotation for Artifact Hub
Benefits:
- Reduce etcd storage usage (especially important in large clusters)
- Maintain reasonable rollback capability (3 previous versions)
- Allow customization based on deployment needs
- Can be set to null to use Kubernetes default (10)
Default rationale:
- 3 revisions provides sufficient rollback capability for most use cases
- Reduces cluster resource usage (etcd storage, API server load)
- Follows best practices from production Kubernetes deployments
- Users can override if they need more history
Example usage:
# Use default (3 revisions)
revisionHistoryLimit: 3
# Increase for critical deployments
revisionHistoryLimit: 10
# Use Kubernetes default (10)
revisionHistoryLimit: null
# Disable history (not recommended)
revisionHistoryLimit: 0
See: https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#revision-history-limit
Co-Authored-By: Claude <noreply@anthropic.com>
Signed-off-by: Aleksei Sviridkin <f@lex.la>
Add startupProbe to give Jellyfin sufficient time to start, especially
with large media libraries or slow storage. This prevents Kubernetes
from killing the pod during initial startup phase.
Changes:
- Add startupProbe configuration in values.yaml with sensible defaults
- failureThreshold: 30 (allows up to 5 minutes for startup)
- periodSeconds: 10
- Uses tcpSocket check on http port
- Update deployment.yaml to include startupProbe from values
- Bump chart version 2.5.0 -> 2.5.1
- Add changelog annotation for Artifact Hub
Benefits:
- Prevents pod restarts during slow initial startup (large media libraries)
- Liveness and readiness probes remain responsive after successful startup
- Fully configurable and can be disabled by setting startupProbe: null
- No breaking changes, backward compatible
The startup probe gives Jellyfin up to 5 minutes (30 attempts * 10 seconds)
to complete initialization. After the first success, liveness and readiness
probes take over with their normal timing.
Co-Authored-By: Claude <noreply@anthropic.com>
Signed-off-by: Aleksei Sviridkin <f@lex.la>