Okube

Coordination through explicit state

Managers and workers share task and membership state through etcd. Workers register, publish heartbeats, and report lifecycle changes. Managers participate in leader election, but only the leader watches pending tasks and dispatches placement decisions; followers retain the information needed to take over manager leadership.

The design gives the educational prototype a concrete coordination model. It does not make every component highly available, and it does not secure manager-to-worker traffic for untrusted networks.

Placement is a pipeline, not a single score

Scheduling separates feasibility from preference. Resource and network filters remove unsuitable workers first. Resource and latency-aware scores then compare the remaining candidates before selection. This makes it possible to explain why a worker was rejected instead of hiding every concern in one opaque number.

I implemented the network-aware and multi-node path alongside the task and worker stores that supply the scheduler’s inputs. A simpler round-robin strategy remains useful when richer placement data is not needed.

Service order and failure behavior

Multi-service manifests are ordered from their dependency graph. Services start in dependency order, receive environment-based discovery information, and are torn down in reverse order. Health and restart behavior handles failed containers within the project’s intentionally small operating model.

The missing capabilities are as important as the implemented ones: there is no overlay network, horizontal scaling, broad security model, or evidence for production use. Okube is a focused way to study leadership, scheduling, state, and container lifecycle—not a Kubernetes replacement.