Kubernetes storage location information

Contents

• Overview
• 1. Storage Classes
• 2. Persistent Volume Claims (PVCs)
• 3. StatefulSet Volume Claim Templates
• 4. Per-Container Storage Details
• 5. ConfigMap-Backed File Mounts
• 6. Secret Mounts
• 7. Ephemeral (In-Memory) Volumes
• 8. Deployment Options Affecting Storage
• 9. Downloading Logs
• 10. Checking disk usage of volumes
• 11. Storage Summary Table

Overview

This document describes all storage locations used across the containers in a CAST Imaging Kubernetes deployment: persistent volumes, ConfigMap-backed configuration files, Secrets, and ephemeral (in-memory) volumes.

1. Storage Classes

Two storage class types are used, depending on the feature set enabled.

1.1 Block Storage Class (castimaging-ds)

Used for all standard persistent volumes (databases, logs, archives, etc.).

CSI provisioner and parameters vary by cloud provider:

1.2 File Storage Class (castimaging-fs)

This allows the Analysis Node’s shared data directory to use ReadWriteMany (RWX) access mode, enabling horizontal scaling of analysis nodes.

2. Persistent Volume Claims (PVCs)

All PVCs are created in the deployment namespace with the annotation helm.sh/resource-policy: keep, ensuring they are not deleted on helm uninstall.

All PVC sizes are configurable through values.yaml (e.g. size_db_data, size_shared_datadir, etc.). The console log PVCs introduced in 3.6.8 are sized with size_controlpanel_logs, size_gatewayservice_logs, size_authenticationservice_logs, size_consoleservice_logs, size_ssoservice_logs and size_dashboards_logs (default 2Gi each).

3. StatefulSet Volume Claim Templates

These volumes are provisioned automatically per pod replica via volumeClaimTemplates in StatefulSets. They use the castimaging-ds block storage class.

console-analysis-node (StatefulSet)

viewer-neo4j (StatefulSet)

A single neo4jdata volume (100Gi) is provisioned per pod. It is sub-divided using subPathExpr into three logical directories:

4. Per-Container Storage Details

4.1 console-postgres

The PostgreSQL database server used by all Console services and Keycloak.

The db-data PVC is only created when CastStorageService.enable: true. When using an external PostgreSQL instance (CustomPostgres.enable: true), no PVC is created and a separate init script (init-db-custom-pg.sh) is executed as an init container to set up the required users and databases on the external server.

4.2 console-analysis-node

The CAST analysis engine. Runs as a StatefulSet.

The pvc-shared-datadir sub-directories used at runtime:

The analysisnode-upgrade-script ConfigMap is mounted into a postgres-upgrade init container (see Section 5).

4.3 viewer-neo4j

The graph database for the Imaging Viewer. Runs as a StatefulSet.

All three paths share a single underlying 100Gi PVC via sub-paths.

4.4 viewer-server

The main Imaging Viewer frontend and backend service, fronted by Nginx.

4.5 viewer-etl

The ETL (Extract, Transform, Load) service responsible for importing analysis data into Neo4j.

4.6 viewer-aimanager

The AI/enrichment manager service.

4.7 viewer-api

The public REST API service for querying the Imaging graph.

4.8 mcp-server

The Model Context Protocol server. Only deployed when McpServer.enable: true.

4.9 extendproxy

The CAST Extend proxy service. Only deployed when ExtendProxy.enable: true.

4.10 console-control-panel

Init containers use the contexturl-controlpanel-update-script and contexturl-keycloak-update-script ConfigMap-backed SQL scripts to update context URLs in the PostgreSQL database on startup (see Section 5).

4.11 console-authentication-service

4.12 console-service

An init container also uses the contexturl-controlpanel-update-script, contexturl-keycloak-update-script, and license-extend-update-script ConfigMap-backed SQL scripts (see Section 5).

4.13 console-gateway-service

4.14 console-sso-service

Keycloak is configured to log both to the standard output and to the file /opt/cast/imaging-services/logs/sso/sso.log (KC_LOG=console,file). The file is rotated daily (suffix .yyyy-MM-dd.gz) or when it reaches 10M (KC_LOG_FILE_ROTATION_MAX_FILE_SIZE), and is not rotated on pod startup.

4.15 console-dashboards

4.16 proxy-exclusions-cronjob

A suspended CronJob (schedule intentionally invalid) that can be triggered manually with kubectl create job --from=cronjob/proxy-exclusions-cronjob to refresh the reverse-proxy’s non_proxy_hosts list from the currently registered service subnets. It mounts no PVC.

5. ConfigMap-Backed File Mounts

The following ConfigMaps are mounted as files into containers or init containers.

6. Secret Mounts

The Secret imaging-pwd-sec is used both as environment variable source and as a file-system mount.

The file-system mount (/opt/secrets) in console-postgres is read-only and used by the init script to read passwords at startup.

7. Ephemeral (In-Memory) Volumes

8. Deployment Options Affecting Storage

8.1 Cloud Provider (K8SProvider)

Controls which CSI drivers are used for the castimaging-ds (and optionally castimaging-fs) storage classes. Accepted values: EKS, AKS, GKE.

8.2 Built-in vs. External PostgreSQL

8.3 Analysis Node Shared File Storage (AnalysisNodeFS.enable) - Imaging version < 3.6.0

When enabling file storage on EKS, the EFSsystemID value is required. Optionally, providing EFSaccessPointID causes an explicit PersistentVolume (pv-shared-datadir) to be created.

On AKS, if auto-provisioning is not available, set AnalysisNodeFS.AKSsharedDatadirPV.create: true and provide secretName and shareName to create an explicit PV backed by an Azure File Share.

8.4 Embedded PostgreSQL SSL (CastStorageService.ssl)

This is independent of CreatePostgresLoadBalancer, which exposes the embedded PostgreSQL service externally.

8.5 Optional Components

8.6 Storage Class Creation

Set CreateStorageClass: false to skip storage class creation (e.g., if the cluster admin has pre-provisioned them). The DiskClassName and FileClassName values must still match the names of the existing storage classes.

9. Downloading Logs

There are 2 types of logs:

• Standard output logs: correspond to the log avialable from kubernetes and containing anything services are writing to the standard output.
• Specific log files: some services have addtional logs available, stored in persistent files: console-postgres, console-analysis-node, viewer-neo4j, viewer-server, viewer-etl and, since 3.6.8, console-control-panel, console-gateway-service, console-authentication-service, console-service, console-sso-service, console-dashboards

The following commands can be used to download those logs. Run them from the machine where kubectl is configured and authenticated against your cluster.

Standard output logs (from all pods)

kubectl logs -l app=castimaging --all-containers=true --prefix=true --tail=-1 -n castimaging-v3 > all-pods-std-output.log

Specific log files stored inside pods

Postgres — postgres database logs stored in the db-data volume:
Adjust the console-postgres pod name if needed.
Linux:

kubectl cp -n castimaging-v3 \
  console-postgres-0:/var/lib/postgresql/data/log \
  ./Logs/postgres

Windows (PowerShell):

kubectl cp -n castimaging-v3 `
  console-postgres-0:/var/lib/postgresql/data/log `
  ./Logs/postgres

Analysis Node — CAST engine logs stored in the castdir volume:

Linux:

kubectl cp -n castimaging-v3 \
  console-analysis-node-core-0:/usr/share/CAST/CAST/Logs \
  ./Logs/console-analysis-node

Windows (PowerShell):

kubectl cp -n castimaging-v3 `
  console-analysis-node-core-0:/usr/share/CAST/CAST/Logs `
  ./Logs/console-analysis-node

Neo4j — graph database logs stored in the neo4jdata volume:

Linux:

kubectl cp -n castimaging-v3 \
  viewer-neo4j-core-0:/var/lib/neo4j/logs \
  ./Logs/viewer-neo4j

Windows (PowerShell):

kubectl cp -n castimaging-v3 `
  viewer-neo4j-core-0:/var/lib/neo4j/logs `
  ./Logs/viewer-neo4j

Viewer Server — Nginx access/error logs and application logs:

Linux:

POD=$(kubectl get pod -n castimaging-v3 -l imaging.service=viewer-server -o jsonpath='{.items[0].metadata.name}')
kubectl cp -n castimaging-v3 $POD:/opt/imaging/imaging-service/logs ./Logs/viewer-server

Windows (PowerShell):

$POD = kubectl get pod -n castimaging-v3 -l imaging.service=viewer-server -o jsonpath='{.items[0].metadata.name}'
kubectl cp -n castimaging-v3 "${POD}:/opt/imaging/imaging-service/logs" ./Logs/viewer-server

Viewer ETL — ETL service operational logs:

Linux:

POD=$(kubectl get pod -n castimaging-v3 -l imaging.service=viewer-etl -o jsonpath='{.items[0].metadata.name}')
kubectl cp -n castimaging-v3 $POD:/opt/imaging/imaging-etl/logs ./Logs/viewer-etl

Windows (PowerShell):

$POD = kubectl get pod -n castimaging-v3 -l imaging.service=viewer-etl -o jsonpath='{.items[0].metadata.name}'
kubectl cp -n castimaging-v3 "${POD}:/opt/imaging/imaging-etl/logs" ./Logs/viewer-etl

Console services (3.6.8 and later) — logs stored in the dedicated log volumes:

Example for console-control-panel (replace the label and path for the other services):

Linux:

POD=$(kubectl get pod -n castimaging-v3 -l imaging.service=console-control-panel -o jsonpath='{.items[0].metadata.name}')
kubectl cp -n castimaging-v3 $POD:/opt/cast/imaging-services/logs/control-panel ./Logs/console-control-panel

Windows (PowerShell):

$POD = kubectl get pod -n castimaging-v3 -l imaging.service=console-control-panel -o jsonpath='{.items[0].metadata.name}'
kubectl cp -n castimaging-v3 "${POD}:/opt/cast/imaging-services/logs/control-panel" ./Logs/console-control-panel

Collect all logs in one shot

Use the Util-CollectLogs.sh / Util-CollectLogs.ps1 utilities provided with the Helm chart.

10. Checking disk usage of volumes

The following commands check the disk usage of main volumes. Run them from the machine where kubectl is configured and authenticated against your cluster.

kubectl exec -it console-analysis-node-core-0 -n castimaging-v3 -- df -h /opt/cast/shared
kubectl exec -it console-analysis-node-core-0 -n castimaging-v3 -- df -h /usr/share/CAST
kubectl exec -it console-postgres-0           -n castimaging-v3 -- df -h /var/lib/postgresql/data
kubectl exec -it viewer-neo4j-core-0          -n castimaging-v3 -- df -h /var/lib/neo4j/config/neo4j5_data
kubectl exec -it viewer-etl-xxxxx             -n castimaging-v3 -- df -h /opt/imaging/imaging-etl/logs
kubectl exec -it viewer-etl-xxxxx             -n castimaging-v3 -- df -h /opt/imaging/imaging-etl/upload/archive
kubectl exec -it extendproxy-xxxxx            -n castimaging-v3 -- df -h /opt/cast_extend_proxy/data

11. Storage Summary Table

Notes:

1. db-data PVC only exists when CastStorageService.enable: true.
2. mcp-server and its PVC only deployed when McpServer.enable: true.
3. extendproxy and its PVC only deployed when ExtendProxy.enable: true.
4. Apart from their log volumes, console-control-panel and console-service do not have dedicated PVCs. They mount the shared pvc-shared-datadir volume also used by console-analysis-node (Section 3).
5. Console log PVCs are only present in 3.6.8 and later.