ritual-net
Support for containerd / Kubernetes-native runtime (remove Docker socket requirement)
🚀 Feature Request: Native Containerd (Dockerless) Support
Summary:
Support for running Ritual node/container workloads in Kubernetes environments that use containerd (or other CRI runtimes) without Docker or dockershim—for example, default K3s, modern GKE/EKS/AKS, and Kubernetes v1.24+ clusters.
Background & Motivation
As of Kubernetes 1.24, the Docker runtime (dockershim) has been deprecated and removed.
Most modern Kubernetes clusters—including K3s, EKS, AKS, GKE, and microk8s—now use containerd or CRI-O by default and do not include Docker or /var/run/docker.sock.
Relevant reference:
See the official Kubernetes Dockershim Deprecation FAQ:
“Node provisioning scripts that call docker or use docker via its control socket... Kubernetes tools that require direct access to Docker (e.g. kube-imagepuller)... Other support scripts or daemons that expect Docker to be available and are run outside of Kubernetes (e.g. monitoring or security agents)....”
This means workloads or agents that require Docker or its socket will not work on containerd-only clusters, which is now the norm.
Problem / Current State
- The current Ritual node expects access to the Docker socket (
/var/run/docker.sock), which is not available on Kubernetes clusters using containerd or CRI-O as the runtime. - This creates a blocker for deploying on most modern Kubernetes clusters without special configuration or reverting to Docker.
Proposed Solution / Acceptance Criteria
- Refactor Ritual node (and any container orchestration logic) to:
- Document best practices for running in Dockerless Kubernetes environments
Benefits
- First-class support for modern, cloud-native K8s clusters (including K3s, EKS, AKS, GKE, etc.)
- No need to install or maintain Docker, or bind the Docker socket (improving security posture)
- Increased compatibility and adoption by the Kubernetes ecosystem
