> For the complete documentation index, see [llms.txt](https://docs.syntho.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.syntho.ai/deploy-syntho/deploy-syntho-using-kubernetes/operations.md). # 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. ```bash kubectl scale deployment/frontend -n syntho --replicas=0 kubectl scale deployment/backend -n syntho --replicas=0 kubectl scale deployment/core -n syntho --replicas=0 ``` {% hint style="warning" %} Scaling down interrupts running jobs. Stop workloads first. {% endhint %} #### Start (scale up) Scale back to your desired replica counts: ```bash kubectl scale deployment/frontend -n syntho --replicas= kubectl scale deployment/backend -n syntho --replicas= kubectl scale deployment/core -n syntho --replicas= ``` #### Check rollout status ```bash kubectl rollout status deployment/frontend -n syntho kubectl rollout status deployment/backend -n syntho kubectl rollout status deployment/core -n syntho ``` #### Restart pods ```bash kubectl rollout restart deployment/frontend -n syntho kubectl rollout restart deployment/backend -n syntho kubectl rollout restart deployment/core -n syntho ``` #### Check pods ```bash kubectl get pods -n syntho -o wide ``` ### Redis health and capacity For the chart-managed Redis, using namespace `syntho`: ```bash 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. {% hint style="warning" %} 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. {% endhint %} 1. Identify the data claim and its StorageClass: ```bash kubectl get pvc -n syntho kubectl get pvc redis-data-redis-0 -n syntho \ -o jsonpath='{.spec.storageClassName}{"\n"}' kubectl get storageclass -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: ```bash kubectl patch pvc redis-data-redis-0 -n syntho --type merge \ -p '{"spec":{"resources":{"requests":{"storage":"10Gi"}}}}' ``` 3. Monitor the resize: ```bash kubectl get pvc redis-data-redis-0 -n syntho -w ``` Stop watching with `Ctrl+C`. Check conditions and events if it does not complete: ```bash 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: ```bash 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: ```bash 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 ```bash kubectl logs -n syntho -f ``` #### Save logs ```bash 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.
--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.syntho.ai/deploy-syntho/deploy-syntho-using-kubernetes/operations.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.