What if Docker-like local containers and Kubernetes-like workload resources shared the same runtime path?

Github Repository: https://github.com/shizuku198411/Raind

Docker-like containers, Kubernetes-inspired resources, and runtime-level observability in one local runtime

Container tooling is usually split across several layers.

Docker-style tools are great when you want to build an image, run a single container, publish a port, mount a directory, or quickly inspect logs.

Kubernetes-style systems are great when you want to describe workloads as Pods, Services, Deployments, and network-oriented resources.

But in local development and runtime experimentation, these layers often feel disconnected. A single container, a multi-container application, and a Kubernetes-style workload are usually treated as separate worlds, even though they eventually depend on the same Linux primitives: namespaces, cgroups, mounts, networking, process execution, and runtime state.

Raind is an experimental project that tries to connect these layers.

Raind is a local container runtime and lightweight workload orchestrator for Linux. It provides Docker-like container commands, Kubernetes-inspired workload resources, runtime-managed networking, traffic visibility, security policy, and rootless container support through one runtime stack.

The project is still early and under active development, but the goal is clear:

Make container-level and workload-level execution testable, controllable, and observable through one consistent runtime path.

Why I Built Raind

Modern container workflows are powerful, but they can also become fragmented.

When using Docker-like tools, the experience is simple and direct:

docker run nginx
docker exec ...
docker logs ...

But once the workload grows beyond a single container, the user often moves to another layer: Compose, Kubernetes, service meshes, network policy engines, observability tools, and runtime-specific debugging tools.

Each tool solves a real problem, but the overall development experience can become harder to reason about:

• Where is the workload state managed?
• Which component owns networking?
• Which layer applies policy?
• Where can I see container-to-container traffic?
• Can I test Kubernetes-like resources locally without leaving the runtime model?
• Can single containers and Pod-style workloads share the same execution foundation?

Raind was started as an experiment to answer these questions from the runtime side.

Instead of treating container execution, workload resources, network policy, and traffic logs as unrelated systems, Raind tries to make them part of the same runtime architecture.

The Runtime Stack

Raind is split into three main layers:

raind CLI
  -> condenser
    -> droplet

raind CLI

raind is the user-facing command-line tool.

It exposes workflows for containers, images, networks, resources, Bottles, policies, and logs:

raind image ...
raind container ...
raind network ...
raind resource ...
raind bottle ...
raind security policy ...
raind logs ...

Condenser

Condenser is the high-level runtime service.

It owns image handling, container state, networking state, Kubernetes-style resource stores, controllers, policy state, DNS handling, netflow logs, Service and Ingress behavior, and the generation of low-level runtime specs.

Condenser does not directly become a container process. Instead, it manages workload intent and delegates low-level container execution to Droplet.

Droplet

Droplet is the low-level OCI-style runtime layer.

It is responsible for Linux container mechanics such as namespace setup, mount setup, pivot_root, cgroups, capabilities, seccomp, AppArmor on-exec handling, runtime state, attach, and exec.

This split allows Raind to keep high-level workload management and low-level container execution separate, while still making them part of one runtime path.

Docker-Like Container Workflows

At the container level, Raind supports a familiar Docker-like workflow.

For example:

raind container run --name web -p 8080:80 nginx:latest
raind container exec web /bin/sh
raind container logs web
raind container stop web
raind container rm web

A Raind container can use image references, published ports, bind mounts, environment variables, commands, logs, lifecycle operations, and exec.

Under the hood, the container is executed through Droplet. That means container lifecycle operations eventually pass through the same low-level runtime path used by higher-level workload resources.

The container unit is useful for:

• testing a single image
• debugging runtime behavior
• checking lifecycle behavior
• running local services
• validating namespace, mount, networking, and exec behavior

Bottles: Local Multi-Container Application Units

Raind also includes a concept called a Bottle.

A Bottle is a local multi-container application unit. It is intended for workloads that are larger than one container but do not necessarily need a full Kubernetes-style manifest.

A Bottle can describe multiple services, ports, mounts, dependencies, environment variables, and policy behavior in one YAML file.

Typical commands look like this:

raind bottle create -f bottle.yaml
raind bottle start wordpress
raind bottle show wordpress
raind bottle stop wordpress

The idea is similar in spirit to local multi-service application definitions, but Raind keeps the Bottle inside its runtime model. That means Bottle workloads can share the same container lifecycle, networking, policy, and observability mechanisms as other Raind workloads.

This is especially useful when testing communication between containers.

For example, instead of only asking “did the containers start?”, Raind can also help answer:

• Which container is talking to which other container?
• Is that communication expected?
• Should this east-west traffic be allowed?
• Can I observe the traffic from the runtime?

Kubernetes-Inspired Resources

Raind also supports Kubernetes-style resource workflows.

The goal is not to replace Kubernetes. Instead, Raind provides a local runtime path for experimenting with Kubernetes-inspired workload concepts.

Raind currently supports resources such as:

• Namespace
• Pod
• ReplicaSet
• Deployment
• Service
• Ingress

Example workflow:

raind resource apply -f app.yaml
raind resource pod ls
raind resource replicaset ls
raind resource deployment ls
raind resource service ls
raind resource rm -f app.yaml

A Pod groups one or more containers into a shared runtime unit. ReplicaSet and Deployment add reconciliation behavior. Service provides stable traffic handling for matching Pods. Ingress provides external routing through Raind’s local runtime layer.

The important part is that these resources are not managed by a completely separate execution path. They eventually map back to the same low-level container runtime foundation.

This makes Raind useful for testing transitions between:

• a single local container
• a multi-container local application
• a Pod-like workload
• a Deployment-like reconciled workload
• a Service-routed workload

Runtime-Level Policy and Netflow

One of the most important goals of Raind is to make workload communication visible and controllable from the runtime.

Raind includes runtime-managed policy and netflow logging.

Policy types include:

• east-west container-to-container policy
• namespace egress observation
• namespace egress enforcement

Example policy command:

raind security policy add --type ew \
  --source frontend \
  --destination backend \
  --protocol tcp \
  --dport 8080 \
  --comment 'allow frontend to backend'

raind security policy commit

Raind also records network flow logs:

raind logs netflow --line 50
raind logs netflow --json
raind logs netflow -t web

The runtime can enrich traffic logs with metadata such as container ID, container name, IP address, interface, and identity information when available.

This is one of the areas where Raind’s workload-centric model becomes useful.

In many local environments, a workload may start correctly, but traffic visibility is still difficult. You might know that a frontend cannot reach a backend, but you may not immediately know whether the traffic was sent, where it went, whether it matched a policy, or how it maps back to runtime entities.

Raind tries to make those questions part of the runtime experience.

Rootless Containers

Raind also supports rootless execution for standalone containers.

Rootless support is currently focused on containers created through raind container run and raind container create. Pod-managed rootless containers are not supported yet.

Raind currently provides two rootless mapping modes.

shifted-root

This is the default rootless mode.

In this mode, container UID/GID ranges are shifted into a subordinate host ID range.

Conceptually:

container 0..65535 -> host 100000..165535

This isolates container root from the login user, but files written to bind mounts by container root may appear as subordinate host IDs.

login-root

The login-root mode is designed for a more Docker-rootless-like local development experience.

In this mode, container root maps to the invoking login user:

container 0        -> host login UID/GID
container 1..65535 -> host subordinate UID/GID range

This is useful when a development container writes into a bind-mounted project directory and the host user should be able to edit or remove the files without manual chown.

Example:

mkdir -p /tmp/raind-login-root

raind container run --name login-root-demo \
  --rootless-mode login-root \
  -v /tmp/raind-login-root:/data \
  alpine:latest /bin/sh -c 'id; echo hello > /data/hello.txt; sleep 60'

ls -lan /tmp/raind-login-root

Raind also separates rootless image layer caches by mapping policy, so shifted-root and login-root do not overwrite each other.

Rootless support is still evolving, but it is already an important part of the project direction.

Container Exec and Namespace Handling

raind container exec is also implemented as part of the runtime model.

Exec must enter the target container’s namespaces, adopt the target root filesystem, use the correct working directory, and resolve commands against the container environment rather than the host environment.

This sounds simple, but it is one of the areas where runtime details matter.

For example, a bare command such as:

raind container exec web nginx -v

should resolve nginx inside the container root filesystem, not on the host. It also has to work consistently for rootful and rootless containers.

Raind’s exec path uses namespace entry and container rootfs handling so that exec behavior matches the container’s runtime context.

This is one of the reasons Raind is interesting as a runtime experiment: features that look like simple CLI commands often force the runtime to make precise decisions about namespaces, rootfs, UID/GID mappings, environment variables, and process execution.

Current Status

Raind is experimental.

It is not intended to be a production container runtime today.

The current focus is:

• container runtime stability
• rootless execution
• image handling
• Dockerfile build support
• Kubernetes-style resource compatibility
• local workload networking
• policy and netflow visibility
• runtime security profiles
• developer documentation and project maturity

The project already includes documentation for architecture, containers, rootless modes, networking, resources, manifests, runtime layout, testing, and security profiles.

But many areas are still evolving. Dockerfile parsing, image manifest handling, Kubernetes manifest compatibility, rootless networking, and production-grade hardening are all active areas of development.

Why This Project Matters

Raind is not trying to be “another Docker” or “a replacement for Kubernetes.”

It is a runtime experiment around a specific idea:

What if container execution, local workload orchestration, network policy, and runtime observability were designed as one connected system?

That idea matters because local container workflows often sit between two worlds.

On one side, Docker-like tools are easy to use but mostly container-centric.

On the other side, Kubernetes-like systems are powerful but often too large when the goal is local runtime experimentation.

Raind explores the space between them.

It provides:

• Docker-like container ergonomics
• Kubernetes-inspired workload resources
• Bottle-based local multi-container application units
• runtime-managed network policy
• netflow-based communication visibility
• rootless container execution modes
• a low-level OCI-style runtime layer implemented in Go

For developers interested in containers, Linux namespaces, cgroups, networking, policy, or local Kubernetes-style testing, Raind is a project worth exploring.

Getting Started

The repository is available on GitHub:

https://github.com/shizuku198411/Raind

A typical local flow looks like this:

raind image pull nginx:latest
raind network create devnet
raind container run --name web -p 8080:80 nginx:latest
raind container logs web
raind container exec web nginx -v

For Kubernetes-style resources:

raind resource apply -f app.yaml
raind resource pod ls
raind resource service ls

For runtime traffic visibility:

raind logs netflow --line 50

Raind is still young, but the project is moving quickly. Feedback, issues, ideas, and contributions are welcome.

If you are interested in container runtimes, Linux workload isolation, local Kubernetes-style workflows, or runtime-level traffic visibility, I would be happy if you tried Raind or followed the project.