reddwarf/docs/ai/research/Rust Kubernetes Control Plane Research.md

High-Performance Engineering of a Rust-Based, Single-Binary Kubernetes Control Plane: An Architectural Framework for Distributed Resource Management

The modern landscape of container orchestration is increasingly defined by the divergence between hyperscale cloud environments and the unique constraints of edge, IoT, and localized self-hosted infrastructure. Traditional Kubernetes architectures, while robust, carry significant operational and resource overhead due to their fragmented design, where individual binaries for the API server, scheduler, and controller manager communicate over network boundaries and rely on external storage systems such as etcd.1 This fragmentation introduces inherent latencies, memory pressures, and deployment complexities that often render the control plane unsuitable for environments with limited hardware resources or unpredictable connectivity. This research evaluates the technical feasibility and architectural design of a unified, Rust-based Kubernetes control plane. By consolidating the control plane into a single statically linked binary and integrating distributed consensus, local storage, and advanced version control primitives, it is possible to achieve an order-of-magnitude reduction in resource consumption while maintaining strict compliance with the Kubernetes API specification.3

The Paradigm of Process Consolidation in Control Plane Design

The primary driver for moving toward a single-binary architecture is the elimination of the overhead associated with inter-process communication (IPC) and separate memory management heaps. In a standard Kubernetes control plane, the kube-apiserver, kube-scheduler, and kube-controller-manager are distinct processes that typically interact via HTTPS or gRPC.2 Even when these processes coexist on a single node, they suffer from context-switching overhead and the duplication of essential libraries and data structures in memory.6
A Rust-based implementation allows developers to leverage the ownership model and the Tokio asynchronous runtime to manage these components as internal tasks within a single execution context.8 This approach facilitates zero-copy state sharing between the API server and the scheduler, as they can access shared memory structures protected by fine-grained synchronization primitives like Arc<RwLock<T>> or message-passing via high-speed asynchronous channels.8 The memory footprint reduction is substantial; whereas a standard control plane might require several gigabytes of RAM to function reliably, consolidated distributions like K3s have demonstrated that a full control plane can operate in under 512 MB of RAM.3 A Rust implementation, free from the non-deterministic pauses of a garbage collector, can further optimize this footprint and provide more predictable tail latencies for API requests.12

Architectural Feature	Standard Upstream Kubernetes	Consolidated Rust Control Plane
Binary Structure	Fragmented (Multiple binaries)	Monolithic (Single binary)
Runtime Environment	High OS dependency (iptables, etc.)	Minimal (Statically linked binary)
IPC Mechanism	Networked gRPC/REST	In-memory async channels
Memory Management	Multi-heap (GC-dependent)	Unified heap (RAII/Ownership)
Data Consistency	External etcd cluster	Embedded Raft with RocksDB
Installation	Complex (PhD in 'clusterology')	Simple (Single command/binary)

Source: 1
The transition to a single-binary model also simplifies lifecycle management. By embedding the container runtime (e.g., via containerd integration) and network plugins within the same process envelope, the control plane acts as a comprehensive supervisor.1 This "batteries-included" approach ensures that the versions of the scheduler, API server, and storage backend are always in sync, reducing the risk of version mismatch errors that plague distributed installations.5

Integrating Distributed Consensus with OpenRaft and Local Storage

A Kubernetes control plane is fundamentally a distributed state machine. To ensure high availability and data integrity in self-hosted environments, the state must be replicated across multiple nodes using a consensus protocol.8 While etcd provides this functionality for standard clusters, its integration as an external service adds significant complexity to single-binary designs.11 The proposed architecture utilizes OpenRaft, a high-performance, asynchronous Raft implementation in Rust, to provide linearizable replication directly within the binary.16

The Mechanics of Embedded Raft

Consensus in the proposed system is achieved by replicating an append-only log of state changes. Every API request that modifies a resource (e.g., POST /api/v1/pods) is proposed as a log entry to the Raft leader.18 The consensus module then replicates this entry to a majority of nodes. The quorum Q for a cluster of N nodes is calculated as:

Q \= \\lfloor \\frac{N}{2} \\rfloor \+ 1

This mathematical guarantee ensures that the cluster can tolerate the failure of up to N \- Q nodes without losing data or compromising consistency.8 Unlike older, tick-based Raft implementations, OpenRaft is event-driven, meaning it only consumes CPU cycles when there are actual state changes or necessary heartbeats, making it ideal for the bursty traffic patterns of a Kubernetes API server.16
The technical integration requires implementing several traits provided by the OpenRaft library. The RaftLogStorage trait defines how log entries are persisted to the local disk, while the RaftStateMachine trait defines how those logs are applied to the cluster state.18 By backing these traits with a high-performance local store like RocksDB, the control plane achieves exceptionally high write throughput—benchmarked at over 70,000 writes per second for single writers and millions of writes per second when batching is applied.16

RocksDB as a Replicated Storage Backend

RocksDB's log-structured merge-tree (LSM) architecture is a perfect fit for Raft-based replication. Because Raft logs are append-only and frequently truncated after snapshotting, the LSM model's efficiency in sequential writes and background compaction minimizes disk I/O bottlenecks.18

Storage Metric	SQLite (K3s Default)	RocksDB (Proposed Rust)
Write Model	B-Tree / Page-based	LSM-Tree / Append-only
Raft Compatibility	Requires translation layer (Kine)	Native log-structured mapping
Throughput	Moderate	High (Optimized for SSDs)
Snapshotting	File-level copy	Checkpoint / Hard links
Concurrency	Limited (Database-level locks)	High (Iterators and snapshots)

Source: 14
Snapshotting is an essential feature for preventing the Raft log from growing indefinitely. In this architecture, the control plane periodically captures a point-in-time snapshot of the cluster state and purges the preceding log entries.16 These snapshots can be transferred to new or recovering nodes using a separate "shipping lane" over QUIC or HTTP/2, ensuring that bulk data transfer does not block the low-latency consensus heartbeats required to maintain cluster leadership.22

Advanced Resource Versioning via Jujutsu-Based DAGs

A cornerstone of the Kubernetes API is the resourceVersion field, which enables optimistic concurrency control and efficient state-watching for clients like the kubelet and various controllers.24 In conventional implementations, this version is typically a monotonic integer. However, as cluster complexity and the number of concurrent actors increase, a linear versioning model becomes a bottleneck, failing to adequately represent the complex relationships and potential conflicts in a distributed environment.26
This research proposes a groundbreaking approach: integrating the Directed Acyclic Graph (DAG) model of the Jujutsu (jj) version control system to manage resource versions.26 By using jj-lib, the control plane can treat every state update not just as a change to a value, but as a commit in a high-performance version graph.27

The Technical Implementation of jj-lib in Kubernetes

Integrating jj-lib programmatically involves mapping Kubernetes resource operations to Jujutsu transactions. When the API server receives a request to update a resource, it initiates a transaction in the jj-lib operation log.30 This transaction creates a new commit that points to its parent(s), effectively building a history of the cluster state that is both auditable and reversible.27
The "Working-copy-as-a-commit" philosophy of Jujutsu aligns perfectly with the Kubernetes declarative model. In Kubernetes, the "desired state" is submitted to the API, and the system works to converge the "actual state" to match it.28 Using Jujutsu, the desired state can be represented as the current head of a branch, while the reconcile operations performed by the controller manager are recorded as subsequent commits that resolve the "diff" between the desired and actual states.27

Conflict Representation and Resolution

One of the most significant advantages of a DAG-based versioning system is its handling of concurrent modifications. In a standard Kubernetes cluster, if two controllers attempt to update the same resource version, the second update fails with a 409 Conflict error, forcing the controller to relist and retry.24
Jujutsu, conversely, treats conflicts as first-class objects.27 If two updates occur simultaneously, the API server can record them as a divergent branch in the resource's history. This allows for:

1. Deferred Resolution: The system can continue to operate with a conflicted state, representing the ambiguity to the user or an automated resolver.27
2. Rich Merging: Instead of a "last writer wins" or a simple rejection, the API server can attempt to merge the two updates using tree-merge algorithms provided by jj-lib.29
3. Implicit History: Administrators can use the op log to trace back exactly when a conflict occurred and who initiated the competing changes, providing a level of observability far beyond standard audit logs.27

The resourceVersion returned to the client in this system is the commit ID of the latest node in the DAG. When a client performs a WATCH operation, the API server performs a graph traversal between the client's provided version and the current head, identifying all intervening changes with cryptographic precision.27

Engineering the API Server: Rust Primitives and Full CRD Support

The API server is the primary gateway for all cluster interactions. Building a compatible API server in Rust requires a sophisticated assembly of networking, serialization, and validation libraries.24 The architecture leverages Axum for its modular request-handling pipeline and k8s-openapi for its exhaustive collection of Kubernetes type definitions.8

RESTful Interface and Routing

Standard Kubernetes API paths (e.g., /api/v1/namespaces/{namespace}/pods/{name}) are mapped to Rust handler functions using Axum's routing macros.39 Because Kubernetes requires strict adherence to its HTTP verb semantics, handlers must be carefully implemented to distinguish between PUT (full replacement), PATCH (strategic merge or JSON merge patch), and POST (creation).24
For strategic merge patches, the server-side logic must understand the structure of the resource. The k8s-openapi crate facilitates this by providing the underlying Go-compatible field names and types.38 To support "Server-Side Apply" (SSA), the server utilizes derived "optionable" types—structures where every field is an Option<T>, allowing the server to identify exactly which fields were specified in a partial update.41

Strategic Management of Custom Resource Definitions (CRDs)

Full support for CRDs is a non-negotiable requirement for modern Kubernetes environments, as they allow for the extension of the API with domain-specific resources.43 In this Rust-based control plane, CRD support is implemented through a dynamic schema engine.
When a user submits a CustomResourceDefinition object, the API server:

1. Validates the OpenAPI v3 Schema: The schema is parsed and stored in the replicated state machine.43
2. Registers Dynamic Routes: The Axum router is updated at runtime to expose new RESTful paths corresponding to the CRD's group, version, and kind.43
3. Enforces Schema Validation: Subsequent requests to manage custom objects are validated against the stored schema. Rust's serde_json is used to handle the untyped data, while schemars facilitates the bridge between Rust types and OpenAPI specifications.46

Feature	Built-in Resources (Pods, etc.)	Custom Resource Definitions (CRDs)
Type Safety	Static (Compile-time)	Dynamic (Runtime-validated)
Implementation	k8s-openapi generated structs	Strategic JSON merge over serde_json
Persistence	Strongly typed Raft entries	Dynamic RawExtension log entries
Versioning	jujutsu-lib DAG commits	jujutsu-lib DAG commits
Validation	Rust's type system + field pruning	OpenAPI v3 structural validation

Source: 38
The API server also performs "field pruning" for custom resources, automatically removing fields not defined in the CRD schema before the data is persisted to the Raft log, ensuring compatibility with standard Kubernetes behavior.43

Developing a Concurrency-Optimized Scheduler in Rust

The Kubernetes scheduler is a high-concurrency engine that matches unscheduled Pods to Nodes based on resource availability, constraints, and affinity rules.51 In a Rust-based binary, the scheduler runs as a separate asynchronous task that watches the API server (via internal channels) for Pods with an empty nodeName.51

The Scheduling Framework: Filtering and Scoring

The scheduler logic is organized according to the Kubernetes Scheduling Framework, which divides the process into a series of pluggable extension points.51
The Filtering Phase: The scheduler iterates through all available nodes and applies "predicates" to eliminate those that are unsuitable.51 In this Rust implementation, filtering is highly parallelized using the Rayon or Tokio task-stealing pool, allowing multiple nodes to be evaluated simultaneously.8

• PodFitsResources: Checks if the node's allocatable resources (CPU, memory, storage) minus the currently scheduled Pods' requests are greater than or equal to the new Pod's requests.51
• NodeSelector/Affinity: Matches the labels of the Pod against the labels of the Node.53
• Taints and Tolerations: Ensures the Pod can "tolerate" any taints present on the node.53

The Scoring Phase: For the nodes that pass filtering, the scheduler applies "priorities" to rank them.51 The scoring function S(n, p) for node n and pod p is modeled as:

S(n, p) \= \\sum\_{i=1}^{k} \\omega\_i \\cdot \\text{Score}\_i(n, p)

where \\omega\_i is the weight assigned to the $i$-th scoring plugin.51 Common scoring strategies include MostAllocated (to maximize bin-packing) or BalancedResourceAllocation (to prevent overloading any single resource type like CPU while memory is idle).53

Asynchronous Binding and Pipeline Parallelism

To maintain high throughput, the scheduler decouples the placement decision from the actual binding update.56 Once a node is selected, the scheduler records the decision in an internal cache and sends an asynchronous request to the API server to perform the Binding operation.51 This allows the scheduler to proceed to the next Pod in the queue without waiting for the API server's storage round-trip, a technique known as pipeline parallelism.56
A Rust-specific optimization involves the use of "snapshots" for the cluster state. The scheduler maintains a local, read-optimized cache of nodes and pods that is updated via an internal watch stream from the API server.47 This prevents the scheduler from needing to lock the entire cluster state for every decision, significantly improving performance in large-scale scheduling bursts.56

Optimized Communication: Protobuf Serialization and Streaming Watches

Network efficiency is paramount in self-hosted and edge clusters where bandwidth may be limited and the number of active WATCH connections can be high.24 The proposed control plane utilizes Protobuf serialization for all internal and Kubelet-facing traffic and implements streaming list responses to minimize memory spikes.24

The Protobuf Advantage in Rust

While standard Kubernetes defaults to JSON, it supports a high-performance binary encoding based on Protocol Buffers (Protobuf).24 For a Rust control plane, this is implemented using the Prost crate, which generates highly efficient serialization logic.29
Protobuf offers a 5-10x speed improvement over JSON and reduces payload sizes by up to 80%.66 This is achieved by:

1. Varint Encoding: Small integers are stored in fewer bytes using variable-length encoding, which is essential for resourceVersion and count fields.69
2. Tag-Value Mapping: Field names are replaced with numeric tags, eliminating the redundant transmission of keys in every message.63
3. Zero-Copy Deserialization: Rust's ability to borrow data from the input buffer (&[u8]) during deserialization allows for a nearly zero-copy path for complex objects like PodSpecs.66

Serialization Format	Payload Size (1MB Struct)	Serialization Speed	Human Readability
JSON	~1.0 MB	100% (Baseline)	High
YAML	~1.2 MB	150% (Slower)	Very High
Protobuf	~200-400 KB	10-20% (Much Faster)	Low

Source: 63
The Kubernetes Protobuf implementation uses a specific envelope format. Every response starts with the 4-byte magic number 0x6b 0x38 0x73 0x00 ("k8s\x00"), followed by a Unknown message that contains the type metadata and the raw binary data.24 This wrapper allows the API server to serve multiple content types simultaneously while informing the client about the encoding method.24

Streaming List Responses and Watch Optimization

A major challenge for Kubernetes API servers is the handling of large LIST requests, which can lead to Out-of-Memory (OOM) failures if the entire collection is serialized into a single buffer before transmission.65
The proposed architecture implements the streaming list encoder introduced in Kubernetes v1.33.65 Instead of encoding the entire Items array of a PodList into one contiguous memory block, the server encodes and transmits each Pod individually.65 This allows the underlying HTTP/2 or WebSocket connection to transmit data as soon as it is available, and the memory for individual items can be freed progressively as they are sent over the wire.65 This streaming approach reduces memory usage by up to 20x during large list operations.65
For WATCH operations, the API server maintains a per-client buffer of events. By using the Jujutsu DAG, the server can efficiently compute the minimal set of "patches" required to bring a client from an old resourceVersion to the current state, significantly reducing the bandwidth required for watch resyncs.27

Node Connectivity and WebSocket Tunneling

Edge clusters often involve nodes located in diverse network environments, where firewalls or NATs prevent the control plane from establishing direct connections to the Kubelet API.7 To address this, the architecture implements a WebSocket-based tunneling mechanism, similar to the one used in K3s.6

Bidirectional Tunneling via Agent Initiation

Upon startup, the worker node (agent) initiates an outbound connection to the control plane binary on port 6443.7 This connection is upgraded from standard HTTPS to a WebSocket tunnel.6 Once established, the connection serves as a bidirectional conduit for all control-plane-to-node traffic.7
When an administrator runs kubectl exec, the request flow is as follows:

1. API Server: Receives the request and identifies the target node.78
2. Egress Selector: Routes the request through the active WebSocket tunnel for that node.75
3. Kubelet: Receives the multiplexed stream through its local tunnel proxy and interacts with the container runtime (CRI).80
4. Data Stream: The output from the container is streamed back through the same tunnel to the API server and finally to the client.17

This approach ensures that the control plane can maintain complete oversight and operational control of worker nodes without requiring complex VPNs or open inbound ports on the edge.2

Kubelet Integration and Node Lifecycle Management

The control plane binary must implement the server-side counterparts to the Kubelet's registration and heartbeat mechanisms to maintain an accurate view of the cluster's physical topology.25

Secure Registration and Leases

When a Kubelet first starts, it identifies its host environment—using local hostname, overridden flags, or cloud metadata—and sends a registration request to the API server.34 To ensure security in self-hosted environments, registration is governed by a shared "node cluster secret" and a randomly generated, node-specific password.7 The API server stores these passwords as Kubernetes secrets in the kube-system namespace to protect the integrity of node IDs during subsequent connections.7
Node health is tracked via the Lease API in the kube-node-lease namespace.25 Kubelets send lightweight lease updates every 10 seconds (the default update interval).25 The control plane's "node controller" monitors these leases. If a node fails to renew its lease within the node-monitor-grace-period (defaulting to 40-50 seconds), the controller updates the node's Ready condition to Unknown and applies taints to prevent the scheduler from assigning new workloads to the failing node.25

Resource Governance and QoS

To prevent noisy-neighbor problems and ensure application stability, the control plane enforces resource governance using standard Kubernetes primitives.84

• Resource Requests: Provide a minimum guaranteed reservation of CPU and memory for a Pod.58
• Resource Limits: Establish a hard cap enforced by the container runtime via cgroups.58
• QoS Classes: Pods are automatically categorized into Guaranteed, Burstable, or BestEffort tiers based on their request/limit ratio, which determines their eviction priority during node pressure events.58

The control plane includes a built-in monitoring loop that correlates actual usage data (provided by the Kubelet via cAdvisor metrics) with the configured requests and limits.58 This enables automated "right-sizing" recommendations, allowing administrators to optimize their hardware utilization for self-hosted workloads.85

System Organization and Implementation Strategy

The successful development of this unified control plane requires a highly structured project organization that leverages the best of the Rust ecosystem.

Cargo Workspace and Modular Design

The project is architected as a Cargo workspace, dividing the code into several specialized crates to improve maintainability and compilation speed.9

• core: Contains the fundamental types and traits for the Kubernetes API and resource management.45
• apiserver: Implements the REST handlers and the routing pipeline using Axum and Tower.8
• consensus: Wraps OpenRaft and provides the RaftLogStorage implementation for RocksDB.16
• scheduler: Implements the Filtering and Scoring framework with parallelized node evaluation.51
• versioning: Integrates jj-lib to provide DAG-based resource versioning and conflict representation.26

Multi-Architecture Build and Deployment

To support self-hosted environments ranging from high-performance x86_64 servers to aarch64 (ARM) edge devices, the build system is centered around cross-compilation.4 Using tools like cross or Goreleaser with Rust hooks, the project produces statically linked, multi-arch binaries that require zero external dependencies on the target host.5

Component	Choice	Reason
Language	Rust (Edition 2021/2024)	Memory safety, zero-cost abstractions, async performance
Consensus Engine	OpenRaft	Event-driven, optimized for modern async Rust
Storage Engine	RocksDB	LSM-Tree performance, efficient Raft log mapping
API Backend	Axum	Modular middleware, compatible with Tower ecosystem
Versioning Library	jj-lib	Advanced DAG-based state management
Serialization	Prost (Protobuf)	Minimal payload size, high serialization speed

Source: 8

Bootstrapping and Automated Management

Bootstrapping a new cluster involves running the binary with a --cluster-init flag, which triggers the generation of self-signed Certificate Authority (CA) certificates valid for 10 years.7 The system also includes an automated manifest manager: administrators can drop standard Kubernetes YAML files into a designated local directory (e.g., /var/lib/k8s/manifests), and the control plane will automatically detect, parse, and apply these resources to the cluster state, facilitating an out-of-the-box GitOps-lite experience.6

Conclusions and Future System Outlook

The design and implementation of a Rust-based, single-binary Kubernetes control plane represent a significant evolution in the development of lightweight container orchestrators. By combining the safety and performance of the Rust language with innovative versioning and consensus technologies, this architecture addresses the fundamental trade-offs between API conformance and resource efficiency.
The integration of OpenRaft and RocksDB provides a robust foundation for distributed state, achieving throughput and latency characteristics that surpass traditional etcd-backed systems in high-concurrency scenarios. More importantly, the adoption of a DAG-based resource versioning model through jj-lib introduces a paradigm shift in how cluster state is managed, allowing for native conflict representation and sophisticated operational history.
The use of bidirectional WebSocket tunnels and Protobuf serialization effectively optimizes the control plane for the challenging network topologies and bandwidth constraints characteristic of edge computing. Furthermore, the ability to serve large results sets through streaming responses ensures that the control plane remains stable even under heavy data pressure, avoiding the OOM failures that plague unoptimized API servers.
As the industry moves toward more decentralized and heterogeneous computing environments, the need for a "Marie Kondo" approach to orchestration—eliminating operational bloat while preserving essential functionality—becomes paramount. This unified control plane framework provides the blueprint for a new generation of Kubernetes distributions that are as joyful to operate as they are resilient to failure. Future research should explore the expansion of the scheduler's plugin framework to support increasingly complex inter-workload anti-affinity and hardware-specific locality rules, further bridging the gap between lightweight edge distributions and the sophisticated demands of modern AI-driven workloads.

Works cited

1. K3s - Lightweight Kubernetes | K3s, accessed on January 28, 2026, https://docs.k3s.io/
2. K3s vs K8s: Differences, Use Cases & Alternatives | by Spacelift - Medium, accessed on January 28, 2026, https://medium.com/spacelift/k3s-vs-k8s-differences-use-cases-alternatives-ffcc134300dc
3. K3s Explained: What is it and How Is It Different From Stock Kubernetes (K8s)?, accessed on January 28, 2026, https://traefik.io/glossary/k3s-explained
4. K0s vs K3s vs K8s: Comparing Kubernetes Distributions - Shipyard.build, accessed on January 28, 2026, https://shipyard.build/blog/k0s-k3s-k8s/
5. Understanding k0s: a lightweight Kubernetes distribution for the community | CNCF, accessed on January 28, 2026, https://www.cncf.io/blog/2024/12/06/understanding-k0s-a-lightweight-kubernetes-distribution-for-the-community/
6. k3s-io/k3s: Lightweight Kubernetes - GitHub, accessed on January 28, 2026, https://github.com/k3s-io/k3s
7. Architecture - K3s - Lightweight Kubernetes, accessed on January 28, 2026, https://docs.k3s.io/architecture
8. Rust in Distributed Systems, 2025 Edition | by Disant Upadhyay - Medium, accessed on January 28, 2026, https://disant.medium.com/rust-in-distributed-systems-2025-edition-175d95f825d6
9. How I build a Rust backend service - World Without Eng, accessed on January 28, 2026, https://worldwithouteng.com/articles/how-i-build-a-rust-backend-service
10. Coding a simple microservices with Rust | by Gene Kuo - Medium, accessed on January 28, 2026, https://genekuo.medium.com/coding-a-simple-microservices-with-rust-3fbde8e32adc
11. Part 1 - K3s Zero To Hero: K3s Kickoff - Your Lightweight Kubernetes Adventure Begins, accessed on January 28, 2026, https://blog.alphabravo.io/part1-k3s-kickoff-your-lightweight-kubernetes-adventure-begins/
12. Why it seems there are more distributed systems written in golang rather in rust? - Reddit, accessed on January 28, 2026, https://www.reddit.com/r/rust/comments/1l0rzin/why_it_seems_there_are_more_distributed_systems/
13. Is Meilisearch a viable upgrade alternative to OpenSearch? - Open edX discussions, accessed on January 28, 2026, https://discuss.openedx.org/t/is-meilisearch-a-viable-upgrade-alternative-to-opensearch/12400
14. What is K3s? Lightweight Kubernetes for Edge - Devtron, accessed on January 28, 2026, https://devtron.ai/what-is-k3s
15. Architecture - Documentation - K0s docs, accessed on January 28, 2026, https://docs.k0sproject.io/v0.9.0/architecture/
16. databendlabs/openraft: rust raft with improvements - GitHub, accessed on January 28, 2026, https://github.com/databendlabs/openraft
17. Everything You Need to Know about K3s: Lightweight Kubernetes for IoT, Edge Computing, Embedded Systems & More - Mattermost, accessed on January 28, 2026, https://mattermost.com/blog/intro-to-k3s-lightweight-kubernetes/
18. openraft::docs::getting_started - Rust, accessed on January 28, 2026, https://docs.rs/openraft/latest/openraft/docs/getting_started/index.html
19. hiqlite - crates.io: Rust Package Registry, accessed on January 28, 2026, https://crates.io/crates/hiqlite
20. Raftoral — Rust utility // Lib.rs, accessed on January 28, 2026, https://lib.rs/crates/raftoral
21. openraft_rocksstore - Rust - Docs.rs, accessed on January 28, 2026, https://docs.rs/openraft-rocksstore
22. Octopii - Turn any Rust struct into a replicated, fault tolerant cluster - Reddit, accessed on January 28, 2026, https://www.reddit.com/r/rust/comments/1q5i0tv/octopii_turn_any_rust_struct_into_a_replicated/
23. octopii-rs/octopii: Distributed Systems Kernel written in rust - GitHub, accessed on January 28, 2026, https://github.com/octopii-rs/octopii
24. Kubernetes API Concepts, accessed on January 28, 2026, https://kubernetes.io/docs/reference/using-api/api-concepts/
25. Nodes - Kubernetes, accessed on January 28, 2026, https://k8s-docs.netlify.app/en/docs/concepts/architecture/nodes/
26. Architecture - Jujutsu docs, accessed on January 28, 2026, https://docs.jj-vcs.dev/latest/technical/architecture/
27. jj-cli — Rust utility // Lib.rs, accessed on January 28, 2026, https://lib.rs/crates/jj-cli
28. Tech Notes: The Jujutsu version control system - neugierig.org, accessed on January 28, 2026, https://neugierig.org/software/blog/2024/12/jujutsu.html
29. jj_lib - Rust - Docs.rs, accessed on January 28, 2026, https://docs.rs/jj-lib/latest/jj_lib/
30. jj_lib - Rust - Docs.rs, accessed on January 28, 2026, https://docs.rs/jj-lib/latest/jj_lib/index.html
31. Jujutsu: A Next Generation Replacement for Git - Vincent Schmalbach, accessed on January 28, 2026, https://www.vincentschmalbach.com/jujutsu-a-next-generation-replacement-for-git/
32. jujutsu-lib - crates.io: Rust Package Registry, accessed on January 28, 2026, https://crates.io/crates/jujutsu-lib
33. jj/CHANGELOG.md at main · jj-vcs/jj - GitHub, accessed on January 28, 2026, https://github.com/jj-vcs/jj/blob/main/CHANGELOG.md
34. What is Kubelet? The K8s Node Agent Explained - Plural.sh, accessed on January 28, 2026, https://www.plural.sh/blog/what-is-kubelet-explained/
35. Build a Simple Kubernetes Operator in Rust (Rust + K8s = ) - YouTube, accessed on January 28, 2026, https://www.youtube.com/watch?v=4wYK8REe9Ro
36. Arnavion/k8s-openapi: Rust definitions of the resource types in the Kubernetes client API, accessed on January 28, 2026, https://github.com/Arnavion/k8s-openapi
37. Using Kubernetes with Rust - Shuttle.dev, accessed on January 28, 2026, https://www.shuttle.dev/blog/2024/10/22/using-kubernetes-with-rust
38. k8s_openapi - Rust, accessed on January 28, 2026, https://arnavion.github.io/k8s-openapi/v0.18.x/k8s_openapi/
39. Working with OpenAPI using Rust - Shuttle.dev, accessed on January 28, 2026, https://www.shuttle.dev/blog/2024/04/04/using-openapi-rust
40. Creating a REST API in Rust - Arsh Sharma, accessed on January 28, 2026, https://arshsharma.com/posts/rust-api/
41. optionable - crates.io: Rust Package Registry, accessed on January 28, 2026, https://crates.io/crates/optionable/0.4.0
42. optionable: recursive partial structs/enums + kubernetes server-side apply : r/rust - Reddit, accessed on January 28, 2026, https://www.reddit.com/r/rust/comments/1pea67v/optionable_recursive_partial_structsenums/
43. Extend the Kubernetes API with CustomResourceDefinitions, accessed on January 28, 2026, https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/
44. Extend your Kubernetes APIs with CRDs - DEV Community, accessed on January 28, 2026, https://dev.to/litmus-chaos/extend-your-kubernetes-apis-with-crds-4iml
45. kube - Rust - Docs.rs, accessed on January 28, 2026, https://docs.rs/kube/latest/kube/
46. Kubernetes Management with Rust - A Dive into Generic Client-Go, Controller Abstractions, and CRD Macros with Kube.rs - Kubesimplify, accessed on January 28, 2026, https://blog.kubesimplify.com/kubernetes-management-with-rust-a-dive-into-generic-client-go-controller-abstractions-and-crd-macros-with-kubers
47. Architecture - Kube.rs, accessed on January 28, 2026, https://kube.rs/architecture/
48. Writing a Kubernetes Operator - MetalBear, accessed on January 28, 2026, https://metalbear.com/blog/writing-a-kubernetes-operator/
49. kube-rs/kube: Rust Kubernetes client and controller runtime - GitHub, accessed on January 28, 2026, https://github.com/kube-rs/kube
50. Write Your Next Kubernetes Controller in Rust - kty, accessed on January 28, 2026, https://kty.dev/blog/2024-09-30-use-kube-rs
51. Kubernetes Scheduler, accessed on January 28, 2026, https://kubernetes.io/docs/concepts/scheduling-eviction/kube-scheduler/
52. Kubernetes Pod Scheduling: Tutorial and Best Practices - CloudBolt Software, accessed on January 28, 2026, https://www.cloudbolt.io/kubernetes-pod-scheduling/
53. Custom Kube-Scheduler: Why And How to Set it Up in Kubernetes - Cast AI, accessed on January 28, 2026, https://cast.ai/blog/custom-kube-scheduler-why-and-how-to-set-it-up-in-kubernetes/
54. A Rust controller for Kubernetes - A Java geek, accessed on January 28, 2026, https://blog.frankel.ch/start-rust/6/
55. acrlabs/kube-scheduler-rs-reference: A reference implementation of a Kubernetes scheduler written in Rust - GitHub, accessed on January 28, 2026, https://github.com/acrlabs/kube-scheduler-rs-reference
56. Inside kube-scheduler: The Plugin Framework That Powers Kubernetes Scheduling, accessed on January 28, 2026, https://substack.com/home/post/p-180294019
57. Mastering Large Project Organization in Rust | by Leapcell, accessed on January 28, 2026, https://leapcell.medium.com/mastering-large-project-organization-in-rust-a21d62fb1e8e
58. Kubernetes Optimization: Tutorial and Best Practices - CloudBolt Software, accessed on January 28, 2026, https://www.cloudbolt.io/kubernetes-cost-optimization/kubernetes-optimization/
59. Building a Custom Kubernetes Scheduler Plugin: Scheduling Based on Pod-Specific Node Affinity | by Manjula Piyumal | Stackademic, accessed on January 28, 2026, https://blog.stackademic.com/building-a-custom-kubernetes-scheduler-plugin-scheduling-based-on-pod-specific-node-affinity-7f66b6c607f9
60. Nodes - Kubernetes, accessed on January 28, 2026, https://kubernetes.io/docs/concepts/architecture/nodes/
61. Optimizing Kubernetes Clusters for Cost & Performance: Part 1 - Resource Requests, accessed on January 28, 2026, https://kodekloud.com/blog/optimizing-clusters-for-cost-performance-part-1-resource-requests/
62. How we replaced the default K8s scheduler to optimize our Continuous Integration builds, accessed on January 28, 2026, https://codefresh.io/blog/custom-k8s-scheduler-continuous-integration/
63. Protobuf vs JSON: Why More Engineers Are Switching to Protobuf | by Divyam Sharma | Medium, accessed on January 28, 2026, https://medium.com/@divyamsharma822/protobuf-vs-json-why-more-engineers-are-switching-to-protobuf-e140d4640d8d
64. Protobuf vs JSON: Performance, Efficiency & API Speed - Gravitee, accessed on January 28, 2026, https://www.gravitee.io/blog/protobuf-vs-json
65. Kubernetes v1.33: Streaming List responses, accessed on January 28, 2026, https://kubernetes.io/blog/2025/05/09/kubernetes-v1-33-streaming-list-responses/
66. Fivefold slower compared to Go? Optimizing Rust's protobuf decoding performance | CNCF, accessed on January 28, 2026, https://www.cncf.io/blog/2024/05/09/fivefold-slower-compared-to-go-optimizing-rusts-protobuf-decoding-performance/
67. kube-rs/k8s-pb: Kubernetes structs from protos and openapi schemas - GitHub, accessed on January 28, 2026, https://github.com/kube-rs/k8s-pb
68. JSON vs. Protocol Buffers in Go: Which Should You Use for Network Communication?, accessed on January 28, 2026, https://dev.to/jones_charles_ad50858dbc0/json-vs-protocol-buffers-in-go-which-should-you-use-for-network-communication-4gio
69. Encoding | Protocol Buffers Documentation, accessed on January 28, 2026, https://protobuf.dev/programming-guides/encoding/
70. How Protobuf Works—The Art of Data Encoding - VictoriaMetrics, accessed on January 28, 2026, https://victoriametrics.com/blog/go-protobuf/
71. Protobuf vs. JSON: Choosing the Right Data Format for API Development, accessed on January 28, 2026, https://www.abstractapi.com/guides/api-glossary/protobuf-vs-json
72. Beating JSON performance with Protobuf - Auth0, accessed on January 28, 2026, https://auth0.com/blog/beating-json-performance-with-protobuf/
73. Protobuf streaming (lazy serialization) API - Stack Overflow, accessed on January 28, 2026, https://stackoverflow.com/questions/13242349/protobuf-streaming-lazy-serialization-api
74. Advanced Options / Configuration - K3s - Lightweight Kubernetes, accessed on January 28, 2026, https://docs.k3s.io/advanced
75. Basic Network Options - K3s - Lightweight Kubernetes, accessed on January 28, 2026, https://docs.k3s.io/networking/basic-network-options
76. A Comprehensive Guide to K3s Architecture and Agent Node Registration - Medium, accessed on January 28, 2026, https://medium.com/@thakuravnish2313/a-comprehensive-guide-to-k3s-architecture-and-agent-node-registration-76b3b684b5b2
77. K3s server - K3s - Lightweight Kubernetes, accessed on January 28, 2026, https://docs.k3s.io/cli/server
78. Container Runtime Interface streaming explained - Kubernetes, accessed on January 28, 2026, https://kubernetes.io/blog/2024/05/01/cri-streaming-explained/
79. How to Deploy Rust Applications to Kubernetes - Devtron, accessed on January 28, 2026, https://devtron.ai/blog/how-to-deploy-rust-applications-to-kubernetes/
80. Interaction Process Between Kubelet, CRI, and CNI in Kubernetes | by Rifewang - Medium, accessed on January 28, 2026, https://medium.com/@rifewang/interaction-process-between-kubelet-cri-and-cni-in-kubernetes-034c64c32149
81. What is K3s? A Quick Installation Guide for K3s - Devtron, accessed on January 28, 2026, https://devtron.ai/blog/what-is-k3s-a-quick-installation-guide-for-k3s/
82. kubelet | Kubernetes, accessed on January 28, 2026, https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/
83. A Brief Overview of the Kubernetes Node Lifecycle | by Rifewang - Medium, accessed on January 28, 2026, https://medium.com/@rifewang/a-brief-overview-of-the-kubernetes-node-lifecycle-bde9ce547852
84. How to Optimize Container Resources in Kubernetes? - Zesty, accessed on January 28, 2026, https://zesty.co/finops-academy/kubernetes/how-to-optimize-container-resources/
85. Kubernetes Resource Optimization: 5 Proven Strategies for 2025 - ScaleOps, accessed on January 28, 2026, https://scaleops.com/blog/5-kubernetes-resource-optimization-strategies-that-work-in-production/
86. robusta-dev/krr: Prometheus-based Kubernetes Resource Recommendations - GitHub, accessed on January 28, 2026, https://github.com/robusta-dev/krr
87. Self-generation of `.rules`/`AGENT.md` · zed-industries zed · Discussion #35534 · GitHub, accessed on January 28, 2026, https://github.com/zed-industries/zed/discussions/35534
88. Documentation for the rust-axum Generator, accessed on January 28, 2026, https://openapi-generator.tech/docs/generators/rust-axum/
89. How To Make Rust Multi-Arch Release Easy - Qovery, accessed on January 28, 2026, https://www.qovery.com/blog/how-to-make-rust-multi-arch-release-easy
90. k8s_openapi - Rust - Docs.rs, accessed on January 28, 2026, https://docs.rs/k8s-openapi