Edera containerd runtime shim

3 min read · Intermediate

Platform Engineer Developer

TL;DR

Edera integrates with Kubernetes as a containerd runtime shim, containerd-shim-edera-v2.
containerd handles the Kubernetes Container Runtime Interface (CRI) and hands Edera pods to the shim, which runs each pod in its own zone. This is the default integration since v1.12.

You operate Edera the same way you operate other runtimes under containerd, such as runc or Kata Containers, and containerd’s existing logging, networking, and tooling apply to Edera pods.

Big picture

The Kubernetes integration is built from several components that work together:

  • kubelet: Schedules pods and talks to containerd over the CRI, exactly as it does for any other runtime.
  • containerd: Implements the CRI, prepares pods, and sets up networking through your cluster’s CNI.
  • containerd-shim-edera-v2: The Edera runtime shim. containerd calls it through its standard runtime shim API, over a local socket.
  • protect-daemon: Owns zone and workload lifecycle. The shim passes work to it.
  • Zones: Each pod runs inside its own zone, with its own Linux kernel.

One shim, many containers

  • Runtimes such as runc typically start one shim per container.
  • Edera runs one shim for many containers, because pod and container state lives in protect-daemon, not in the shim.
  • This keeps the shim lightweight and reduces overhead on the host.

Data & control flow

  1. The kubelet schedules a pod that uses the Edera RuntimeClass and sends the request to containerd over the CRI.
  2. containerd prepares the pod, including networking through your cluster’s CNI.
  3. containerd hands the pod’s containers to containerd-shim-edera-v2.
  4. The shim passes the work to protect-daemon, which provisions the zone and runs the workloads inside it.
  5. containerd reports pod and container status back to the kubelet as usual.

What changes for cluster administrators

Because Edera runs under containerd rather than alongside it, much of what you already use for containerd applies to Edera pods:

  • Networking → Edera pods use your existing cluster CNI configuration through containerd. See Kubernetes networking with Edera.
  • Logs and errors → The shim reports errors through standard containerd flows. Start troubleshooting with journalctl -u containerd.
  • Metrics → Some metrics for Edera pods are available through containerd, alongside the metrics Edera exposes on its own endpoint. See Metrics.
  • Configuration → Edera is configured as a runtime under containerd, in the same shape as other runtimes, rather than as a separate integration.

What stays the same

  • Developers still select Edera with a RuntimeClass.
  • The Kubernetes experience for deploying and running workloads is unchanged. See Deploy your app to Edera.

Legacy protect-cri

Before v1.12, Edera integrated with Kubernetes through protect-cri, a separate service that implemented the CRI itself and ran alongside containerd. The containerd runtime shim replaces it as the default.

  • Opting in → Install the legacy service by passing --env EDERA_PROTECT_INSTALLER_CONTAINERD_SHIM=false to the Edera Installer.
  • Logs → Errors and logs are reported through the protect-cri systemd service: sudo systemctl status protect-cri and sudo journalctl -u protect-cri.
  • CNI paths → Nonstandard CNI plugin binary or configuration paths are set in cri.toml.

Further reading

Last updated on