D2K - a Portainer SkunkWorks Project
Docker, but inside a Kubernetes Namespace...
Platform engineers and developers want different things from infrastructure, and that tension is real. Platform teams want Kubernetes: reliable, scalable, production-grade clusters with proper resource governance, namespace isolation, and RBAC. Developers want Docker: fast, familiar, zero learning curve. They want to run docker run, docker logs, and docker exec and get on with their work.
d2k makes both sides happy at the same time.
The model is straightforward. A platform engineer builds and operates a Kubernetes cluster the way they would anyway: with proper resource limits, network policies, and production-grade reliability. They slice that cluster into namespaces and deploy a tiny d2k pod into each one. Each developer gets pointed at their namespace’s d2k endpoint and, from their perspective, they have a Docker host. They connect with the Docker CLI, with Portainer, or with any Docker SDK client. They run containers, view logs, exec into shells, watch events, and check stats. None of that requires them to know what a Deployment is.
The developer’s “Docker host” is a synthetic construct sitting on top of Kubernetes infrastructure that far exceeds what any laptop can provide. For teams with remote developers, particularly those working from locations where hardware constraints make local development challenging, this pattern is compelling. All compute happens centrally. The developer connects to their namespace endpoint and works as if the environment is local. The platform team retains full control and visibility over what’s actually running.
d2k translates the Docker API surface into Kubernetes operations scoped to a single namespace. docker run -p 80:8080 creates a Deployment and a LoadBalancer Service. docker volume create creates a PersistentVolumeClaim. docker logs --follow streams from the pod log API. docker exec -it mycontainer /bin/bash opens a shell in the pod via SPDY. docker stats pulls real metrics from the cluster’s metrics-server. docker events replays Kubernetes event history and streams live resource changes.
That said, d2k is different from KubeDock, which is the closest comparable project. KubeDock also exposes a Docker API backed by Kubernetes, but its design target is CI pipelines and testcontainers: short-lived ephemeral containers in a Tekton or similar pipeline context. It uses Pods directly (not Deployments), implements port-forwarding for local access, and handles volumes by copying content in via init containers. It is optimised for fast container turnover in automated test runs. d2k targets interactive developer use: longer-lived workloads, Portainer UI integration, WebSocket console access, real stats, and event streaming. The two tools solve adjacent problems for different audiences.
d2k is a Portainer Skunkworks project, MIT licensed, with multi-arch images (amd64 and arm64) published on every commit. The code is at github.com/portainer/d2k.
You can see a demo of d2k in use here: