Operations

Use this page for day-to-day operations on a Kubernetes (Helm) deployment.

Common operations

Stop (scale down)

This stops the UI/API pods without uninstalling Helm releases.

kubectl scale deployment/frontend -n syntho --replicas=0
kubectl scale deployment/backend -n syntho --replicas=0
kubectl scale deployment/core -n syntho --replicas=0

Scaling down interrupts running jobs. Stop workloads first.

Start (scale up)

Scale back to your desired replica counts:

kubectl scale deployment/frontend -n syntho --replicas=<n>
kubectl scale deployment/backend -n syntho --replicas=<n>
kubectl scale deployment/core -n syntho --replicas=<n>

Check rollout status

kubectl rollout status deployment/frontend -n syntho
kubectl rollout status deployment/backend -n syntho
kubectl rollout status deployment/core -n syntho

Restart pods

kubectl rollout restart deployment/frontend -n syntho
kubectl rollout restart deployment/backend -n syntho
kubectl rollout restart deployment/core -n syntho

Check pods

kubectl get pods -n syntho -o wide

Redis health and capacity

For the chart-managed Redis, using namespace syntho:

kubectl exec -n syntho redis-0 -- redis-cli INFO persistence
kubectl exec -n syntho redis-0 -- redis-cli INFO memory
kubectl exec -n syntho redis-0 -- df -h /data

Check that aof_enabled is 1 and aof_last_write_status and aof_last_bgrewrite_status are ok. A rewrite may temporarily report aof_rewrite_in_progress:1. Monitor memory, available disk space, and application errors reporting rejected Redis writes or failed archival. Do not delete AOF files to reclaim space.

Increasing disk capacity does not increase Redis's in-memory data budget. If writes are rejected at redis.maxmemory, review that budget and the container memory limit together, leaving headroom for rewrites and process overhead.

Resize the Redis data PVC

The chart defaults to a 1Gi data claim. To increase an existing claim to, for example, 10Gi, expand the bound PVC, not the StatefulSet claim template. Replace the namespace and resource names below if your deployment uses different names.

Back up the Redis data volume before storage maintenance. Kubernetes supports expansion, not shrinking. Do not delete the PVC or PV as a resize workaround. A restart may be needed for filesystem expansion; plan for a maintenance window because a single Redis primary is unavailable while restarting.

1. Identify the data claim and its StorageClass:

   kubectl get pvc -n syntho
   kubectl get pvc redis-data-redis-0 -n syntho \
     -o jsonpath='{.spec.storageClassName}{"\n"}'
   kubectl get storageclass <storage-class-name> -o yaml

   Use redis-data-redis-0, not the separate redis-claim-redis-0 configuration claim. Confirm the data PVC is Bound, the StorageClass has allowVolumeExpansion: true, and the CSI driver supports volume and filesystem expansion. Check provider capacity and quota. If expansion is unsupported, contact your cluster administrator to plan a storage migration instead. A statically provisioned volume also requires the administrator to expand its backing storage; editing a PVC alone does not enlarge the physical disk.
2. Increase the PVC request:

   kubectl patch pvc redis-data-redis-0 -n syntho --type merge \
     -p '{"spec":{"resources":{"requests":{"storage":"10Gi"}}}}'

3. Monitor the resize:

   kubectl get pvc redis-data-redis-0 -n syntho -w

   Stop watching with Ctrl+C. Check conditions and events if it does not complete:

   kubectl describe pvc redis-data-redis-0 -n syntho

   If the driver supports online filesystem expansion, no restart is needed. If it requires remounting and reports FileSystemResizePending, pause new work and arrange a maintenance window before restarting Redis:

   kubectl rollout restart statefulset/redis -n syntho
   kubectl rollout status statefulset/redis -n syntho

   Investigate provisioning errors before restarting; a restart cannot resolve unsupported expansion or exhausted storage quotas.
4. Verify both Kubernetes capacity and the mounted filesystem:

   kubectl get pvc redis-data-redis-0 -n syntho \
     -o jsonpath='{.spec.resources.requests.storage}{" requested; "}{.status.capacity.storage}{" provisioned\n"}'
   kubectl exec -n syntho redis-0 -- df -h /data
   kubectl exec -n syntho redis-0 -- redis-cli INFO persistence

   Confirm the request and capacity are at least 10Gi, the filesystem has grown (usable space will be slightly lower), and Redis is healthy before resuming work.

Keep redis.persistence.size at the original StatefulSet template value (1Gi for a default installation). StatefulSet volumeClaimTemplates are immutable; changing this Helm value does not expand existing claims and can prevent subsequent Helm operations. The existing PVC remains expanded even though the template retains its original size. If you need to align the template for future claims, arrange a separate administrator-managed StatefulSet recreation preserving the existing PVCs. Do not change the storage class or PV selector as part of a resize.

Changing a StorageClass requires a separate storage migration, not a resize. Existing bound claims cannot switch classes. Work with your cluster administrator to back up and restore data onto suitable volumes, checking reclaim policy, node affinity, attachment behavior, and recovery before maintenance.

Logs

Follow logs

kubectl logs -n syntho -f <pod-name>

Save logs

kubectl -n syntho logs deployment/core >> core.log
kubectl -n syntho logs deployment/backend >> backend.log

Log sharing

Logs can contain hostnames, workspace names, and operational details.

Share logs only via approved internal channels or directly with Syntho Support.