values.yaml parameters reference

This section describes each parameter of the values.yaml file provided at the root of the Helm chart, when and how to adjust it, and the risks of changing it on a deployment that is already running. The parameters are listed in the order in which they appear in values.yaml.

Unless stated otherwise, a change in values.yaml is applied by running helm-upgrade.bat|sh. The When can it be changed column uses the following conventions:

Sections in this reference:

• Which values to review before deploying
• General settings
• License and CAST Extend
• Application networking
• Storage
  • Volume sizes
• PostgreSQL
• Passwords and Secrets
  • Using an external secret store
• Optional components
• Extra environment variables
• Analysis settings
• Security and registry access
• Replica counts
• Analysis node autoscaling
• Images
• Resources
• Pod placement

Which values to review before deploying

Most parameters can keep their default values. Use the following overview to focus on the ones that matter for your installation.

1. Always review and set before the initial installation

Review these values for one or more of the following reasons:

• Environment-specific: the default is a placeholder or a generic choice that must be adapted to your cluster (for example FrontEndHost, K8SProvider or the storage classes).
• Security-sensitive: the default is publicly known or exposes CAST Imaging more than you may want (passwords, public load balancer).
• Install-time only: the value can be set now, but never changed once CAST Imaging is deployed.

2. Set only if it applies to your situation

These values must be set when you use the corresponding feature or environment, and can otherwise keep their defaults:

3. Never change, even on a fresh installation (Keep default)

version, postgresqlDataMountPath, anadir.*, and the labelSelector* / podAffinityGroup* affinity rules.

4. Keep the defaults unless advised by CAST Support

*Image.tag and *Image.pullPolicy, the CSI driver names (*_DSdriver, *_FSdriver, install-time only), the log volume sizes, the other replica counts, the other *Resources, postgres_shmsize, AnalysisNode_shmsize, ConsoleEnableBackup, KCADMIN_USERNAME, and the ETL, AIMANAGER and GATEWAYSERVICE environment variables.

General settings

License and CAST Extend

Application networking

Only one of CreateIngress, UseIstioGateway, UseGatewayAPI and UseApplicationGateway can be enabled (the installation fails otherwise). CreateLoadBalancer should be set to false when one of them is used.

Storage

See Kubernetes storage location information for the list of volumes.

Volume sizes

Size the volumes according to the number and size of the applications you plan to analyze: size_castdir, size_shared_datadir, size_db_data and size_neo4jdata are the ones that grow with usage.

PostgreSQL

Enable either CastStorageService (embedded PostgreSQL) or CustomPostgres (external PostgreSQL), not both.

Passwords and Secrets

All passwords are base64-encoded: echo -n "mypassword" | base64 on Linux, or [Convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes("mypassword")) in PowerShell.

Using an external secret store

existingSecret accepts any Kubernetes Secret, whatever tool creates it. To keep the passwords in an external secret store, use a tool that creates the Secret in the CAST Imaging namespace from that store. The most common one is External Secrets Operator  (ESO), which works the same way on every platform and supports, among others:

Vendor operators (for example HashiCorp Vault Secrets Operator) and GitOps tools that decrypt secrets in the cluster (Sealed Secrets, SOPS) also work, as long as the result is a Secret with the expected keys. The Secrets Store CSI Driver is not suitable: it only synchronizes a Secret while a pod mounts the corresponding CSI volume, and CAST Imaging pods do not.

To use ESO:

1. Install ESO and create a SecretStore (in the CAST Imaging namespace) or a ClusterSecretStore for your store. See the list of ESO providers  for the configuration of your store.

2. In your secret store, create a secret (for example cast-imaging/passwords) containing a JSON object with the keys postgres-db-password, operator-db-password, operator-db-password-crypted2, keycloak-db-password, keycloak-admin-password, neo4j-password and, when SMTP.enable is true, smtp-password. Store the values in plain text, not base64-encoded. For operator-db-password-crypted2, store the complete CRYPTED2:... string generated by cast-imaging-encryption-tool.jar.

3. Create the namespace (kubectl create namespace castimaging-v3) and an ExternalSecret in it:

   apiVersion: external-secrets.io/v1
   kind: ExternalSecret
   metadata:
     name: imaging-passwords
     namespace: castimaging-v3
   spec:
     refreshInterval: 1h
     secretStoreRef:
       kind: ClusterSecretStore      # or SecretStore
       name: my-secret-store
     target:
       name: imaging-passwords       # Secret name to set in existingSecret
     dataFrom:
       - extract:
           key: cast-imaging/passwords
   

   On ESO versions earlier than 0.17, use apiVersion: external-secrets.io/v1beta1. If your store holds one secret per password instead of a JSON object, replace dataFrom with one data entry per key (secretKey set to the expected key name, remoteRef.key set to the name in your store).

4. Check that the Secret is synchronized: kubectl get externalsecret imaging-passwords -n castimaging-v3 must show SecretSynced.

5. Set existingSecret: imaging-passwords in values.yaml and run the installation (or helm-upgrade on an existing deployment, with the passwords currently in use).

Optional components

Extra environment variables

The sections NEO4J, ETL, SERVER, AIMANAGER, MCPSERVER, CONTROLPANEL, ANALYSISNODE, API, AUTHENTICATIONSERVICE, CONSOLESERVICE, DASHBOARDS, GATEWAYSERVICE, SSOSERVICE and EXTENDPROXY add environment variables to the corresponding containers (NAME: value). Only add variables documented by CAST or requested by CAST Support. Changing them restarts the corresponding pods.

Analysis settings

Security and registry access

Replica counts

To stop and start CAST Imaging, use the Util-ScaleDownAll and Util-ScaleUpAll scripts rather than changing the replica counts.

Analysis node autoscaling

The AnalysisNodeAutoscaling parameters (enabled, minNodes, maxNodes, pollIntervalSeconds, scaleUpStabilizationSeconds, scaleDownStabilizationSeconds, stuckPodTimeoutSeconds, dryRun, allowNodeRead, resources) are described in the Analysis node autoscaling section of this page.

Images

Each *Image parameter (InitUtilImage, ConsolePostgresImage, ConsoleSSOServiceImage, ConsoleServiceImage, ConsoleGatewayServiceImage, ConsoleAnalysisNodeImage, ConsoleControlPaneImage, ConsoleAuthenticationServiceImage, ConsoleIntegratedDashboardsImage, ViewerNeo4jImage, ViewerServiceImage, ViewerEtlImage, ViewerAiManagerImage, ViewerApiImage, McpServerImage, ExtendProxyImage) has three settings:

Resources

The *Resources parameters (ConsolePostgresResources, SSOServiceResources, ConsoleServiceResources, GatewayServiceResources, AnalysisNodeResources, ControlPanelResources, AuthenticationServiceResources, IntegratedDashboardsResources, ViewerNeo4jResources, ViewerServerServiceResources, ViewerEtlResources, ViewerAiManagerResources, ViewerApiResources, McpServerResources, ExtendProxyResources, InitContainerResources) define the CPU and memory requests (reserved for the pod) and limits (maximum allowed) of each container.

• Increase AnalysisNodeResources when analyzing large applications or when increasing MaxParallelAnalysisPerNode, and ViewerNeo4jResources (together with the NEO4J heap settings) for large applications in the Viewer.
• The cluster nodes must have enough allocatable CPU and memory for the requests, otherwise pods stay Pending.
• A container exceeding its memory limit is restarted (OOMKilled).

On an existing deployment, changing resources restarts the corresponding pods: for AnalysisNodeResources, ConsolePostgresResources and ViewerNeo4jResources, do it when no analysis is running.

Pod placement