# Manually disable Edera Kubernetes integration

This guide explains how to manually disable the Edera Kubernetes integration on a node.

⚠️ This is an emergency procedure—not a supported uninstall—and should only be used if the Edera container runtime proxy is interfering with normal Kubernetes operations.

Please follow the [general troubleshooting steps](https://docs.edera.dev/support/troubleshooting/general/) first or contact [Edera support](mailto:support@edera.dev).

## When to use this  
Use this procedure only if:

- The `protect-cri` service is failing and can no longer proxy requests to the system `containerd`, disrupting normal Kubernetes operation.
- Your node is stuck or degraded due to the Edera runtime integration.
- In the event of an Edera CRI failure that impacts Kubernetes operations and no formal recovery plan is available.

This procedure leaves Edera installed on the node but disconnects it from the kubelet. Workloads that don’t use the `runtimeClass` will continue to run.

⚠️ Do not run this procedure on production systems unless you have no other option. Disabling the Edera runtime proxy removes all Edera protections. If the steps are applied incorrectly, you can break your node or cluster.

## If you only want to bypass Edera  
To run workloads outside Edera, you can remove the `runtimeClassName` field from your pod specifications. You don’t need to follow the rest of this guide for that.

## AMI-based nodes (recommended recovery)  
If your cluster uses AWS-managed node groups or self-managed node groups with AMIs:

- Create a new node pool using stock AWS EKS AMIs.
- Scale down or remove the node pool that uses Edera AMIs.

This method is the safest and most reliable way to remove Edera from your cluster and is preferred over manual steps when available.

## Prerequisites  
- You have local administrative access to the node.
- You can restart the kubelet.

## Step 1: Edit the kubelet configuration  
Use the following command to open kubelet configuration files. These may be in `/etc/default`, `/etc/sysconfig`, or another location depending on your system.

```bash
sudo find /etc -name kubelet -exec $EDITOR {} +
```

In each file, look for a line like the following:

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

Remove the line, or remove only the `--container-runtime-endpoint` argument. Save and close the file.

## Step 2: Revert systemd overrides  
Revert any `kubelet` service overrides to restore vendor defaults:

```bash
sudo systemctl revert kubelet
```

## Step 3: Reload and restart the kubelet  
Reload systemd and restart the kubelet:

```bash
sudo systemctl daemon-reload
sudo systemctl restart kubelet
```

This change should not require a full node reboot. Workloads that were not using the `edera` runtime class will remain unaffected.

## Step 4: Verify node status  
Run the following command to verify that the node is healthy:

```bash
kubectl get nodes -o wide
```

The node should be in the `Ready` state and running workloads as expected.

## Summary  
This break-glass procedure disables the Edera container runtime integration without uninstalling Edera. It is intended for emergency use only and should not be part of your normal workflow or recovery plan.