Kubernetes installation and verification

Safe data and application release installation, repeat execution, application-level checks, and external access.

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.

Install and repeat safely

Use the primary install.sh script: inspect the read-only plan first, then run the installation. The script applies the required stages in the defined order and finishes with a final verification.

  1. Before running, verify the current kube context and API address; namespace and other decisions come from configuration/deployment-plan.json and configuration/installation-config.yaml
  2. Run install.sh --dry-run and resolve every FAIL before allowing writes
  3. If PVC data-massaccess-postgresql-0 already exists, choose preserve to retain it or recreate to remove only that PVC; for a non-interactive run pass --postgresql-existing-data
  4. Run install.sh: massaccess-data is installed first only when bundled stores exist, then massaccess and the required proxy-relay are installed
  5. Check the final healthcheck, local sign-in, work/admin-credentials.env mode 600, and the absence of unexpected restarts
bash
./bin/install.sh --dry-run
./bin/install.sh
./bin/healthcheck.sh

Post-install verification

Resource readiness is necessary but is not application acceptance.

  • Read back Helm revisions, Deployments, StatefulSets, Pods, Services, Jobs, PVCs, Events, readiness, and restart counts
  • Verify dashboard sign-in, API, WebSocket upgrade, webhook paths, licensing and metering through the configured TLS entry point
  • Perform authenticated application write/read flows for PostgreSQL, Kafka, ClickHouse, and Redis; a TCP connection alone is insufficient
  • Verify metrics discovery, bounded redacted logs and Events, and the deterministic diagnostic bundle without Secret or payload values

Installation-host publication and external access

The installer publishes the web UI on the installation host at http://127.0.0.1:3001 without DNS, TLS, Ingress, or Gateway API. The DevOps engineer creates an external route separately through company infrastructure.

  • Verify local sign-in at http://127.0.0.1:3001/web/login on the installation host
  • For external access, company infrastructure provides the reverse proxy, load balancer, Ingress, Gateway API, DNS, and TLS
  • Test dashboard, API, /web/api/ws/ WebSocket upgrade, messenger callbacks, and customer webhook routes end to end
  • The public hostname is the application's canonical address and is never used as the local port-forward bind address