SEPPO
Kubernetes SDK for Rust. No YAML. No CLI. Just code.
This is a learning project - exploring Kubernetes SDK patterns in Rust.
use Context;
let ctx = new.await?;
ctx.apply.await?;
ctx.wait_ready.await?;
Why
The problem: Kubernetes tooling is fragmented. You write YAML, shell out to kubectl, maintain bash scripts, and wrestle with templating engines. Your "infrastructure as code" isn't really code—it's configuration files with code-like aspirations.
The vision: What if Kubernetes operations were just... code? Real code. In your language. With types, IDE support, and compile-time checks.
Seppo makes Kubernetes a library call:
// This is your deployment. No YAML.
let deployment = new
.image
.replicas
.port
.build;
ctx.apply.await?;
ctx.wait_ready.await?;
No YAML. No kubectl. No templating. Just Rust.
What We Want to Achieve
- Escape YAML — Define resources in code, not configuration files
- Native SDK — First-class Rust library, not a CLI wrapper
- Full kubectl coverage — Everything kubectl does, but programmatic
- Ecosystem integration — Import from Helm/Kustomize as migration path, then stay in code
- Multi-language — Same concepts in Rust (Seppo) and Go (Ilmari)
The goal: you should never need to write YAML again.
How It Works
┌──────────────────┐ ┌─────────────────┐ ┌──────────────┐
│ Context::new() │────▶│ Context │────▶│ Kubernetes │
│ (your code) │ │ (namespace) │ │ (any cluster)│
└──────────────────┘ └─────────────────┘ └──────────────┘
│ │
│ ├── apply() → create resources
│ ├── get/list() → read resources
│ ├── delete() → remove resources
│ ├── wait_ready() → poll until ready
│ ├── port_forward() → port forward
│ ├── exec() → run commands
│ └── logs() → stream logs
Each Context manages a namespace. Resources are created via kube-rs. The optional #[seppo::test] macro adds automatic cleanup and failure diagnostics.
Install
[]
= "0.1"
Requires a Kubernetes cluster (Kind, Minikube, EKS, GKE, etc.)
Usage
Standalone
use Context;
async
With Test Macro
use Context;
async
// Cleanup automatic on success, diagnostics on failure
Resource Builders
use deployment;
let deploy = deployment
.image
.replicas
.port
.env
.label
.build;
ctx.apply.await?;
Deploy Stacks
use stack;
let s = stack
.service
.image
.replicas
.port
.service
.image
.replicas
.port
.service
.image
.port
.build;
ctx.up.await?;
Async Conditions
use eventually;
eventually
.timeout
.await?;
Failure Diagnostics
When tests fail, Seppo keeps the namespace and dumps diagnostics:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
SEPPO TEST FAILED
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Namespace: seppo-test-a1b2c3d4 (kept for debugging)
─── Pod Logs ───────────────────────────────────────────────────
[myapp-xyz123]
ERROR: Connection refused to postgres:5432
─── Events ─────────────────────────────────────────────────────
• 10:42:00 Pod/myapp Scheduled Assigned to node-1
• 10:42:01 Pod/myapp BackOff Image pull error
─── Debug ──────────────────────────────────────────────────────
kubectl -n seppo-test-a1b2c3d4 get all
kubectl delete ns seppo-test-a1b2c3d4
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Features
| Category | Features |
|---|---|
| Core | Context, apply/get/list/delete, wait_ready |
| Network | Port forwarding, exec, logs |
| Builders | DeploymentFixture, PodFixture, ServiceFixture, Stack |
| Testing | #[seppo::test], eventually/consistently, assertions |
| Diagnostics | Pod logs, events, failure reports |
| Providers | Kind, Minikube, existing clusters |
| Assertions | Semantic assertions on pods, deployments, services |
Roadmap
| Phase | Goal |
|---|---|
| 0 | Rebrand as SDK, expose Context::new() standalone |
| 1 | Complete primitives: patch, watch, copy, diff |
| 2 | Helm/Kustomize import, migration CLI |
| 3 | Operational: scale, rollback, restart, drain |
| 4 | Multi-cluster, impersonation, audit |
Naming
Seppo (Finnish smith god from Kalevala) - Part of a Finnish tool naming theme:
- SEPPO (smith) - Kubernetes SDK for Rust
- ILMARI (smith) - Kubernetes SDK for Go
- SYKLI (cycle) - CI orchestrator
- NOPEA (fast) - GitOps controller
- KULTA (gold) - Progressive delivery
- RAUTA (iron) - Gateway API controller
License
Apache-2.0