helm-charts

🛠️ Troubleshooting EnkryptAI Deployment

This guide provides step-by-step instructions for resolving common issues encountered during the installation and operation of the EnkryptAI and Platform Helm charts.

1. Rerun Redteam Jobs Using Argo Workflows Dashboard

To rerun any Redteaming jobs:

1. Port-forward the Argo server to your local machine:

   kubectl -n enkryptai-stack port-forward svc/argo-server 2746:2746
   

2. Open the dashboard in your browser: http://localhost:2746
3. Locate the workflow corresponding to the Redteam job.
4. Click Rerun or Resubmit to execute the job again.

2. Artifacts for Redteam Jobs

Artifacts generated by Redteam jobs can be accessed via Supabase:

1. Check Supabase storage to view and download artifacts.

2. Access Supabase using the ingress:

   auth.<domain.com>
   

   • Dashboard credentials are stored in onprem secrets with the following keys:

     • DASHBOARD_USERNAME
     • DASHBOARD_PASSWORD

3. Helm Installation Failed for Platform Stack

If Helm installation fails for the platform-stack:

• Verify that all required CRDs are installed.
• Check that the namespace exists:

  kubectl get ns <namespace>
  

• Inspect Helm error logs:

  helm install <release-name> <chart-path> --debug --dry-run
  

• Rerun the upgrade

helm upgrade --install platform enkryptai/platform-stack -n enkryptai-stack -f values.yaml --timeout 15m

5. Helm Installation Failed for EnkryptAI Stack

For enkryptai-stack Helm installation failures:

• Ensure all prerequisites are installed (Ingress, Cert Manager, Metrics Server).
• Verify namespace exists:

  kubectl get ns enkryptai-stack
  

• Run Helm dry-run for debugging:

  helm install enkryptai-stack ./enkryptai-lite --debug --dry-run
  

• Check for conflicting resources from previous installations.

6. Health Check for EnkryptAI Applications

To verify the status of deployed EnkryptAI applications:

kubectl get pods -n enkryptai-stack \
  -l app.kubernetes.io/instance=enkryptai,app.kubernetes.io/managed-by=Helm \
  --no-headers \
  | awk '$3 != "Running" {print $1, $3}'

• Above command will give you pods which are in not Running state
• Pods should be in Running or Succeeded state.
• If pods are Pending or CrashLoopBackOff, check events and logs for underlying issues (e.g., resource limits, missing secrets, misconfigured ingress) run below cmd for that

check Pod Events

kubectl describe pod <pod-name> -n <namespace>

• Look under the Events section for reasons like:

  • Insufficient cpu/memory (resource limits)
  • FailedMount (missing secrets or volumes)
  • ErrImagePull or ImagePullBackOff

check Pod Logs

kubectl logs <pod-name> -n <namespace>

• This shows the container logs and helps identify application-level issues.

7. Health Check for Platform Applications

Check Non-Running Pods in the Cluster

Since the Platform Helm chart is be deployed in multiple namespaces, you can use the following command to find all pods that are not in Running state across the entire cluster:

kubectl get pods --all-namespaces --no-headers \
  | awk '$4 != "Running" {print $1, $2, $4}'

Explanation:

• --all-namespaces → checks pods in all namespaces.
• --no-headers → removes the table header for cleaner output.
• awk '$4 != "Running" → filters pods whose STATUS is not Running.
• $1 → namespace, $2 → pod name, $4 → status.

Example Output:

enkryptai-stack frontend Pending
platform-stack platform-supa CrashLoopBackOff

This command helps quickly identify any problematic pods in your cluster regardless of namespace.

This documentation ensures that users can quickly debug installation failures, application health issues, and job reruns without guessing.