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 with kubectl cp
• 10. 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:

Storage class creation is controlled by the CreateStorageClass value (default: true). Set to false if the storage classes already exist in the cluster.

1.2 File Storage Class (castimaging-fs)

Only created and used when shared file storage for the Analysis Node is enabled (AnalysisNodeFS.enable: true). 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.).

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:

When AnalysisNodeFS.enable: true, pvc-shared-datadir switches to ReadWriteMany (file storage class), allowing multiple Analysis Node replicas to share the same workspace. When disabled (default), it uses ReadWriteOnce block storage and only a single Analysis Node replica is supported.

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

No persistent volumes are mounted in the main container. Init containers use ConfigMap-backed SQL scripts to update context URLs in the PostgreSQL database on startup (see Section 5).

4.11 console-authentication-service

No persistent volumes are mounted in the main container. When UseCustomTrustStore: true, a ConfigMap (authcacrt) holding the CA certificate is projected into the container (see Section 5).

4.12 console-service, console-gateway-service, console-sso-service, console-dashboards

None of these services mount persistent volumes. They rely entirely on database-backed state and environment variable configuration.

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)

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 Optional Components

8.5 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 with kubectl cp

The following commands download the contents of each log volume to a local ./Logs/ directory. Run them from the machine where kubectl is configured and authenticated against your cluster.

Namespace: All commands assume the namespace castimaging-v3. Adjust if your deployment uses a different namespace.

StatefulSet pods (predictable pod names)

These pods have a fixed, deterministic name.

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

Deployment pods (dynamic pod names)

For Deployment-managed pods, the pod name includes a random suffix. The pattern below retrieves the current pod name dynamically before copying.

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

Viewer AI Manager — AI Manager operational logs:

Linux:

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

Windows (PowerShell):

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

Viewer API — REST API service operational logs:

Linux:

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

Windows (PowerShell):

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

MCP Server (only if McpServer.enable: true) — MCP server operational logs:

Linux:

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

Windows (PowerShell):

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

Collect all logs in one shot

Linux — save the following as collect-logs.sh and run with bash collect-logs.sh:

#!/bin/bash
NAMESPACE="castimaging-v3"
DEST="./Logs/$(date +%Y%m%d_%H%M%S)"
mkdir -p "$DEST"

# StatefulSets (fixed pod names)
kubectl cp -n $NAMESPACE console-analysis-node-core-0:/usr/share/CAST/CAST/Logs  $DEST/console-analysis-node
kubectl cp -n $NAMESPACE viewer-neo4j-core-0:/var/lib/neo4j/logs                                $DEST/viewer-neo4j

# Deployments (dynamic pod names)
declare -A LOG_PATHS=(
  [viewer-server]="/opt/imaging/imaging-service/logs"
  [viewer-etl]="/opt/imaging/imaging-etl/logs"
  [viewer-aimanager]="/opt/imaging/open_ai-manager/logs"
  [viewer-api]="/opt/imaging/imaging-api/logs"
  [mcp-server]="/app/logs"
)
for SVC in "${!LOG_PATHS[@]}"; do
  POD=$(kubectl get pod -n $NAMESPACE -l imaging.service=$SVC -o jsonpath='{.items[0].metadata.name}' 2>/dev/null)
  if [ -z "$POD" ]; then
    echo "No pod found for $SVC, skipping."
    continue
  fi
  echo "Copying logs from $POD ($SVC)..."
  kubectl cp -n $NAMESPACE $POD:${LOG_PATHS[$SVC]} $DEST/$SVC
done

echo "All logs collected in $DEST"

Windows — save the following as collect-logs.ps1 and run with powershell -File collect-logs.ps1:

$NAMESPACE = "castimaging-v3"
$DEST = "./Logs/$(Get-Date -Format 'yyyyMMdd_HHmmss')"
New-Item -ItemType Directory -Force -Path $DEST | Out-Null

# StatefulSets (fixed pod names)
kubectl cp -n $NAMESPACE console-analysis-node-core-0:/usr/share/CAST/CAST/Logs  "$DEST/console-analysis-node"
kubectl cp -n $NAMESPACE viewer-neo4j-core-0:/var/lib/neo4j/logs                                "$DEST/viewer-neo4j"

# Deployments (dynamic pod names)
$SERVICES = @{
  "viewer-server"    = "/opt/imaging/imaging-service/logs"
  "viewer-etl"       = "/opt/imaging/imaging-etl/logs"
  "viewer-aimanager" = "/opt/imaging/open_ai-manager/logs"
  "viewer-api"       = "/opt/imaging/imaging-api/logs"
  "mcp-server"       = "/app/logs"
}
foreach ($SVC in $SERVICES.Keys) {
  $POD = kubectl get pod -n $NAMESPACE -l "imaging.service=$SVC" -o jsonpath='{.items[0].metadata.name}' 2>$null
  if (-not $POD) {
    Write-Host "No pod found for $SVC, skipping."
    continue
  }
  Write-Host "Copying logs from $POD ($SVC)..."
  kubectl cp -n $NAMESPACE "${POD}:$($SERVICES[$SVC])" "$DEST/$SVC"
}

Write-Host "All logs collected in $DEST"

Note: kubectl cp requires the tar binary to be available inside the container. This is the case for all CAST Imaging containers. If a pod is not running or not ready, the copy will fail for that service — check pod status first with kubectl get pods -n castimaging-v3.

10. Storage Summary Table

Notes:

1. db-data PVC only exists when CastStorageService.enable: true.
2. authcacrt ConfigMap only mounted when UseCustomTrustStore: true.
3. mcp-server and its PVC only deployed when McpServer.enable: true.
4. extendproxy and its PVC only deployed when ExtendProxy.enable: true.