Kubernetes Integration

After installing Edera on your nodes, you need to configure Kubernetes to use the Edera runtime. This involves creating a RuntimeClass and verifying that pods can run with Edera isolation.

Step 1: Verify Nodes Are Online

After the installation and reboot, confirm your nodes have rejoined the cluster:

kubectl get nodes

All Edera-enabled nodes should show Ready status.

Step 2: Create the RuntimeClass

Kubernetes uses RuntimeClass to route pods to specific container runtimes. Create the Edera RuntimeClass:

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

Verify it was created:

kubectl get runtimeclass

You should see:

NAME     HANDLER   AGE
edera    edera     5s

Step 3: Deploy a Test Pod

Create a simple test pod that uses the Edera runtime:

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: edera-test
  namespace: default
spec:
  runtimeClassName: edera
  containers:
  - name: nginx
    image: nginx:latest
    ports:
    - containerPort: 80
EOF

Step 4: Verify Pod is Running with Edera

Check the pod status:

kubectl get pod edera-test

The pod should transition to Running state.

Verify it’s using the Edera runtime:

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

You should see Runtime Class Name: edera in the output.

Step 5: Verify Zone Creation

SSH into the node where the pod is running and check that an Edera zone was created:

ssh root@<node_ip>
protect zone list

You should see your test pod listed as a running zone.

Common RuntimeClass Patterns

Default to Edera for Specific Namespaces

You can configure namespace-level defaults using admission controllers or policy engines like Kyverno:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: add-edera-runtimeclass
spec:
  rules:
  - name: add-edera-runtimeclass
    match:
      resources:
        kinds:
        - Pod
        namespaces:
        - production
    mutate:
      patchStrategicMerge:
        spec:
          runtimeClassName: edera

Mix Edera and Standard Runtimes

You can run both Edera-isolated and standard containers in the same cluster:

• Sensitive workloads: Use runtimeClassName: edera
• Low-risk workloads: Omit runtimeClassName (uses default runtime)

This gives you flexibility to apply isolation where it matters most.

Kubelet Configuration

The Edera installer automatically configures the kubelet to use the Edera CRI socket. If you need to verify or manually configure it, check /etc/default/kubelet:

Amazon Linux:

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

Linode/Akamai (LKE):

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

After modifying kubelet configuration, restart the kubelet:

systemctl restart kubelet

Troubleshooting RuntimeClass Issues

RuntimeClass Not Found

If pods fail with “RuntimeClass not found”:

kubectl get runtimeclass -o yaml

Verify the RuntimeClass exists and the handler is set to edera.

Pods Stuck in Pending

If pods remain in Pending state:

kubectl describe pod <pod-name>

Look for events indicating scheduling or runtime issues.

Check if nodes are properly labeled or have taints preventing scheduling.

CRI Connection Errors

If you see CRI connection errors:

ssh root@<node_ip>
systemctl status protect-cri
journalctl -u protect-cri

Ensure the protect-cri service is running and the socket is available.

What’s Next?

Kubernetes integration complete? Let’s look at AWS EKS-specific deployment, or skip ahead to best practices.

Up next: AWS EKS Deployment →