Kubernetes requirements
Supported versions, required cluster capabilities, exact-target checks, and confirmed scheduling request floors.
Short glossary
- Helm release: an installed and independently managed resource set from one chart.
- Secret object: a Kubernetes resource referenced for sensitive values; the delivery charts do not own the values themselves.
- PersistentVolumeClaim (PVC): a storage request used by a bundled data component.
- NetworkPolicy: rules governing permitted network connections for application Pods.
- Container Storage Interface (CSI) and Container Network Interface (CNI) capabilities are provided by the customer cluster.
Supported matrix
These values come from the current chart metadata and administrator contract. Re-check the versioned artifact before every installation or upgrade.
| Area | Supported contract |
|---|---|
| Kubernetes | 1.33–1.36 |
| Helm | 4.2; apiVersion v2 chart format |
| Application identity | Immutable version from release/release-manifest.json in the downloaded package; latest is forbidden |
| Configuration | massaccess.io/onprem-values/v1alpha1 with deployment.method=kubernetes |
| Bundled topology | One instance per selected store, non-HA, RWO PVC, Retain/Retain claim retention |
| External PostgreSQL | 18.x, stable DNS, seven isolated roles, verify-full TLS or explicitly approved plaintext disable mode |
| External Kafka | 4.2.x, from one to twenty bootstrap endpoints, SASL_SSL or SASL_PLAINTEXT; broker count and replication policy are defined by company infrastructure |
| External ClickHouse | 26.4.x, single node, separate HTTP and native ports, three identities, optional verified TLS |
| External Redis | 8.6.x, stable writable-primary DNS, ACL namespace, AOF persistence, noeviction, optional verified TLS |
| Application scheduling floor | Application workloads and proxy-relay: 2075m/3575m CPU requests/limits and 1696Mi/3072Mi memory requests/limits in the local reference environment |
| All bundled stores scheduling floor | Four Pods: 400m/1250m CPU requests/limits and 1024Mi/1920Mi memory requests/limits in the local reference environment |
Cluster prerequisites and exact target
The customer operator provides and validates the Kubernetes platform before Helm can be used.
- A reviewed non-system namespace and distinct application and data release names for one single-tenant installation
- Working cluster DNS and a CNI whose default-deny NetworkPolicy enforcement is proven with allowed and denied traffic
- An explicitly assigned NetworkPolicy owner: the Helm package or company infrastructure
- Registry access and fresh pulls of every immutable image digest from a customer-managed imagePullSecret
- For bundled stores, a reviewed CSI StorageClass with RWO, binding mode, reclaim policy, expansion capability, capacity, and topology facts
- Enough quota and node allocatable CPU, memory, ephemeral storage, Pod count, and storage capacity for workloads plus platform overhead
- For external access, the company's chosen reverse proxy, load balancer, Ingress, Gateway API, DNS, and TLS; the installation-host endpoint does not depend on them
- Customer monitoring, encrypted off-cluster backup target, retention, and restore-test procedure
bash
kubectl config current-context
kubectl config view --minify --output json
./bin/install.sh --dry-runWarningChecked-in requests and limits are only a scheduling floor measured in a local reference environment. They are not customer sizing, capacity, performance, HA, or production-SLA evidence.