Container Orchestration Tools
Systems that decide where containers run, keep them running, and reschedule them on failure.
Decentralized.Host is an orchestrator with a different trust model: the scheduler proposes placements, but each host can refuse under its own policy, and desired, admitted and observed state are tracked separately. Runtimes are `process` and `docker` (digest-pinned images); it is far smaller than Kubernetes.
What orchestration actually decides
At its core, a container orchestrator answers three questions continuously, not just at deploy time: which machine should this container run on right now (scheduling, usually based on available CPU/RAM and constraints), is it still running (health checking), and what happens if it isn't (rescheduling, restarting, or failing over). Kubernetes is the dominant general-purpose answer to all three, with an enormous surface area (deployments, services, ingress, operators, CRDs) built to handle arbitrary workloads at any scale.
Systems that decide where containers run, keep them running, and reschedule them on failure. Decentralized.Host is an orchestrator with a different trust model: the scheduler proposes placements, but each host can refuse under its own policy, and desired, admitted and observed state are tracked separately. Runtimes are `process` and `docker` (digest-pinned images); it is far smaller than Kubernetes.