Verify the install

After installing, work through these checks. Each one isolates a different part of the install, so a failure points you straight at the cause.

1. The components are running

kubectl get pods -n architect

You should see the three components, all Running:

NAME                                          READY   STATUS    RESTARTS   AGE
architect-admission-controller-<hash>-<id>    1/1     Running   0          1m
architect-control-plane-<hash>-<id>           1/1     Running   0          1m
architectd-<id>                               1/1     Running   0          1m

architectd is a DaemonSet, so expect one architectd-<id> pod per labeled node.

2. The RuntimeClass is registered

kubectl get runtimeclass runc-architect
NAME             HANDLER          AGE
runc-architect   runc-architect   1m

architectd creates this on startup. If it's missing, the daemon hasn't finished initializing. Wait a moment and recheck, then look at its logs (step 4).

3. Your nodes are labeled

kubectl get nodes -L architect.loopholelabs.io/node,architect.loopholelabs.io/critical-node

Every node that should run Architect workloads needs node=true, and at least one stable node needs critical-node=true:

NAME     ...   NODE   CRITICAL-NODE
node-1         true   true
node-2         true

4. The daemon is on every labeled node

kubectl get pods -n architect -l app.kubernetes.io/name=architectd -o wide

There should be a Running architectd pod on each node=true node. To read its logs (it also surfaces the shim's logs):

kubectl logs -n architect -l app.kubernetes.io/name=architectd --tail=50

5. The console shows the cluster as healthy

Open console.architect.io and select your cluster. Status should be healthy, with a heartbeat in the last ~30 seconds. If it stays pending, the daemon can't reach api.architect.io (see the table below).

6. A workload actually hibernates

Deploy a test workload and confirm it hibernates. The Quick Start walks through a Valkey example end to end; the key signal is the per-container status label flipping after the idle timeout:

# For a container named "valkey" in your pod:
kubectl get pod <pod> -o jsonpath='{.metadata.labels.status\.architect\.loopholelabs\.io/valkey}'
# RUNNING  -> SCALED_DOWN once idle, and back to RUNNING when woken

Diagnose a failed install

SymptomLikely causeWhat to check
No architectd pod on a nodenode isn't labeledkubectl get nodes -L architect.loopholelabs.io/node; label it
A component is Pendingscheduling (taints, resources, critical-node unlabeled)kubectl describe pod -n architect <pod>
A component is CrashLoopBackOffbad config or invalid machine tokenkubectl logs -n architect <pod> and kubectl describe pod
ImagePullBackOffcluster can't pull from ghcr.io/loopholelabsregistry egress / image pull secrets
runc-architect RuntimeClass missingarchitectd hasn't finished initializingwait, then kubectl logs -n architect -l app.kubernetes.io/name=architectd
Console stuck pendingdaemon can't reach api.architect.io:443egress/NetworkPolicy, in-cluster DNS, machine token
Your pod never hibernatesruntimeClassName not set, container not in managed-containers, or node unlabeledconfirm spec.runtimeClassName: runc-architect and the annotations

Still stuck? See Troubleshooting.