Troubleshoot Polyspace Access on Kubernetes

R2026b

This page lists known issues and limitations for the Polyspace^® Access™ Kubernetes installation and provides steps to diagnose common problems.

Known Issues and Limitations

LDAP Required with SAML

When you configure SAML as an identity provider, you must also configure an LDAP provider in the usermanager.server.config.providers array. The LDAP provider is required for user synchronization even when SAML handles authentication. A future release removes this requirement.

Deployments Cannot Be Scaled

Each Polyspace Access service deployment is limited to one replica and cannot be scaled horizontally. Do not increase the replica count for any service deployment.

Database Passwords Stored in Plaintext

The polyspaceAccess.db.passwordString and usermanager.server.config.db.password fields store database passwords in plaintext in the values.yaml file. To mitigate this, use polyspaceAccess.db.passwordSecret to reference a Kubernetes Secret instead. A future release provides Secret references for all password fields.

Collect Diagnostic Information

Use the following commands to gather diagnostic information about your installation. Include this information when you contact MathWorks^® Technical Support.

When you contact support, provide the following information:

Polyspace Access release version (for example, R2026b)
Helm chart version
Description of the symptom or error
Your values.yaml file with sensitive information (passwords, keys) masked
Logs from all pods
If you can reproduce your issue, follow these steps to create Polyspace Access service logs.
Output of kubectl describe for all deployments or pods

Check Pod Status

List all pods and their status:

kubectl get pods -n NAMESPACE

Pods in CrashLoopBackOff or Error state indicate a service failure. Use kubectl describe pod for more details:

kubectl describe pod POD_NAME -n NAMESPACE

Retrieve Service Logs

Get logs from a specific pod:

kubectl logs POD_NAME -n NAMESPACE

To get logs from a previously crashed container:

kubectl logs POD_NAME -n NAMESPACE --previous

To collect logs from all Polyspace Access pods at once:

kubectl logs -l app.kubernetes.io/instance=RELEASE_NAME -n NAMESPACE --all-containers

Check Cluster Resources

Check the status of PersistentVolumeClaims:

kubectl get pvc -n NAMESPACE

PVCs in Pending state indicate that storage could not be provisioned. Check that the StorageClass exists and that the underlying storage provisioner is available.

Common Issues

Issue	Cause	Resolution
Pods stuck in `Pending` state	Insufficient cluster resources or PVCs cannot be bound.	Verify PVCs with `kubectl get pvc`. Scale the cluster or adjust resource requests.
Pods in `CrashLoopBackOff`	Service configuration error or missing secrets.	Check logs with `kubectl logs POD_NAME --previous`. Verify that all required Secrets exist.
Cannot access web interface	Ingress misconfiguration or service not ready.	Verify Ingress with `kubectl get ingress`. Check that the Ingress controller pods are running. Confirm `global.ingress.host` resolves to the cluster.
LDAP authentication fails	Incorrect bind credentials or network connectivity issue.	Check User Manager logs. Verify the LDAP URL is reachable from inside the cluster. For LDAPS, verify that the CA certificate Secret is correctly configured.
Upload fails with 413 error	Ingress body size limit.	Set `nginx.ingress.kubernetes.io/proxy-body-size: "0"` in `global.ingress.annotations`.