Verification & Health Checks

Before diving into troubleshooting, let’s establish what “working correctly” looks like. These health checks help you verify your Edera installation.

RuntimeClass Verification

The RuntimeClass must exist and be configured correctly for Kubernetes to route pods to Edera.

Check if RuntimeClass exists:

kubectl get runtimeclass

Expected output:

NAME     HANDLER   AGE
edera    edera     5d

Inspect RuntimeClass details:

kubectl get runtimeclass edera -o yaml

You should see:

apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: edera
handler: edera

If the RuntimeClass is missing, apply it:

kubectl apply -f https://public.edera.dev/kubernetes/runtime-class.yaml

Edera Services Health

Six systemd services power Edera on each node. All must be active and running.

Quick service check:

ssh root@<node_ip>
systemctl list-units --type=service | grep protect

Expected output shows six active services:

protect-cri.service              loaded active running   Edera Container Runtime Interface
protect-daemon.service           loaded active running   Edera Core Daemon
protect-networking-daemon.service loaded active running   Edera Networking Daemon
protect-orchestrator.service     loaded active running   Edera Orchestrator
protect-storage-daemon.service   loaded active running   Edera Storage Daemon
protect-preinit.service          loaded active running   Edera Pre-Initialization

Check individual service status:

systemctl status protect-cri
systemctl status protect-daemon

If any service is not running:

systemctl restart <service-name>
systemctl status <service-name>

Pod Execution Verification

Verify that pods are actually running in Edera zones.

Method 1: Using kubectl

Deploy a test pod:

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: edera-verify
  namespace: default
spec:
  runtimeClassName: edera
  containers:
  - name: busybox
    image: busybox
    command: ["sleep", "3600"]
EOF

Check the RuntimeClass assignment:

kubectl describe pod edera-verify | grep -B 3 edera

You should see Runtime Class Name: edera.

Method 2: Using protect CLI

SSH into the node where the pod is running:

ssh root@<node_ip>
protect zone list

You should see your pod listed as an active Edera zone:

ZONE ID                              NAME            STATUS
z-abc123...                          edera-verify    Running

CRI Socket Verification

The kubelet must be configured to use the Edera CRI socket.

Check kubelet configuration:

cat /etc/default/kubelet

Amazon Linux expected configuration:

KUBELET_EXTRA_ARGS="--container-runtime-endpoint=unix:///var/lib/edera/protect/cri.socket"

Linode/Akamai (LKE) expected configuration:

KUBELET_EXTRA_ARGS="--cloud-provider=external --container-runtime-endpoint=unix:///var/lib/edera/protect/cri.socket"

If the configuration is incorrect, edit the file:

nano /etc/default/kubelet

Then restart the kubelet:

systemctl restart kubelet

Node Reboot Verification

Edera requires the node to reboot after installation to load the hypervisor.

Check uptime to verify reboot occurred:

uptime

If uptime shows the node has been running since before the Edera installation, reboot it:

reboot

Health Check Checklist

Before proceeding with troubleshooting, verify:

• ✅ RuntimeClass exists and handler is set to edera
• ✅ All six Edera services are active and running
• ✅ Test pods can be created with runtimeClassName: edera
• ✅ Pods appear in protect zone list output
• ✅ Kubelet configuration points to Edera CRI socket
• ✅ Node has rebooted since installation

If all checks pass, your Edera installation is healthy. If any check fails, continue to the next section for troubleshooting.

Up next: Common Issues & Solutions →