Common Administrative Tasks

Operational procedures for a running self-managed JuliaHub installation. These apply to all installation methods unless noted otherwise.

For configuring the platform itself — authentication, registries, credentials — see Admin Settings.

Restarting services

JuliaHub runs as a set of cooperating services. Restarting them is a common first step when diagnosing a problem, and is occasionally requested by JuliaHub support.

To restart every platform service:

kubectl rollout restart deploy

To restart a single service — for example the main API server:

kubectl rollout restart deploy/teamsrvr

Restarts are rolling, so a single-service restart is generally non-disruptive. Restarting everything briefly interrupts in-flight requests.

Generating a support bundle

When you open a support ticket, JuliaHub will usually ask for a support bundle — an archive of logs and cluster resource information used to diagnose the issue.

Admin Console installations

On installations managed through the Replicated Admin Console, open the console and use the Troubleshoot tab to generate a bundle. If the installation has outbound internet access, the console can upload the bundle to JuliaHub directly; otherwise download it and attach it to your ticket.

Helm installations

Helm-based installations have no Admin Console. Instead, the JuliaHub chart installs a support bundle specification into the cluster, and you generate the bundle with the support-bundle kubectl plugin.

1. Install the tool

Install the tool on a machine with kubectl access to the cluster. It reads the same kubeconfig as kubectl. Choose one of these methods:

• krew installs it as a kubectl plugin, run as kubectl support-bundle:

  kubectl krew install support-bundle

• Homebrew installs it from Replicated's tap as a standalone command, run as support-bundle:

  brew install replicatedhq/replicated/support-bundle

• Manual: download the support-bundle archive for your platform from the troubleshoot releases page and extract it. Put the binary on your PATH as support-bundle to run it as a standalone command, or as kubectl-support_bundle to run it as kubectl support-bundle.

The commands below use the kubectl plugin form. If you installed the standalone command, run support-bundle in place of kubectl support-bundle. The arguments are the same.

2. Generate the bundle

kubectl support-bundle --load-cluster-specs -n <namespace>

--load-cluster-specs picks up the specification the chart installed, so no spec file is needed. When collection finishes the plugin shows a summary of any problems it found (press q to exit, or pass --interactive=false to skip it) and writes a support-bundle-<timestamp>.tar.gz archive to the current directory.

The account running the command needs read access to the JuliaHub namespace, including Secrets (where the specification is stored), and permission to create on pods/exec (used to copy configuration and bootstrap logs out of running pods).

The bundle contains cluster and node information, the Kubernetes resources in the JuliaHub namespace, logs from the JuliaHub platform services, the bootstrap and migration logs, and connectivity checks for authentication and an external PostgreSQL database. Passwords, tokens, and connection strings are redacted automatically.

If the installation failed before the chart finished installing, the specification may not be present in the cluster. Use the generic specification instead:

kubectl support-bundle https://raw.githubusercontent.com/replicatedhq/troubleshoot-specs/main/in-cluster/default.yaml

3. Send the bundle to JuliaHub

• If JuliaHub has given you access to the Replicated Enterprise Portal, upload the archive there from the Support page. Uploads are limited to 500 MB.
• Otherwise, attach the archive to your support ticket, or ask JuliaHub support for an upload link if it is too large to attach.

Include the chart version (from helm list -n <namespace>) and the time window of the problem in your ticket.

Expanding the configuration volume

If the configuration volume fills up, its persistent volume can be expanded. This applies to installations using dynamic volume provisioning.

1. Confirm the storage class allows expansion

The StorageClass backing the volume must support expansion. Check the ALLOWVOLUMEEXPANSION column:

kubectl get storageclass <storage-class-name>

NAME                 PROVISIONER          RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
longhorn (default)   driver.longhorn.io   Delete          Immediate           true                   34m

If this reads false, the volume cannot be expanded in place and the data must be migrated to a volume on a storage class that supports expansion.

2. Request a larger size

Increase the requested storage size in your installation's configuration — the Storage section of the Admin Console, or the corresponding value in your Helm values file — then apply the updated configuration.

3. Scale down the workloads

The volume will not resize while workloads are mounting it. Stop them:

kubectl scale deployment -l app.kubernetes.io/part-of=juliahub --replicas=0
kubectl delete job -l app.kubernetes.io/part-of=juliahub
kubectl scale statefulset/redis --replicas=0
kubectl scale statefulset/postgres --replicas=0

4. Wait for the resize

Resizing may take several minutes. Watch progress and confirm the new capacity:

kubectl describe pvc juliahub-config-dynamic
kubectl get pvc juliahub-config-dynamic

NAME                      STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
juliahub-config-dynamic   Bound    pvc-e871b6f0-cad5-46ca-b672-a1af44e35e1c   100Gi      RWX            longhorn       50m

5. Scale the workloads back up

kubectl scale deployment -l app.kubernetes.io/part-of=juliahub --replicas=1
kubectl scale statefulset/redis --replicas=1
kubectl scale statefulset/postgres --replicas=1

Verify the platform is reachable and healthy before ending the maintenance window.

Resetting the Admin Console password

This applies to installations managed through the Replicated Admin Console, and resets the Admin Console password only — not any JuliaHub user password.

kubectl kots reset-password -n <namespace>

Use default as the namespace on an Embedded Cluster installation.