v0.2 · vista previa · Apache-2.0

Un Kubernetes completo en un solo binario, en reposo con 23 MiB.

litek8s sirve la API real de Kubernetes, así que kubectl, Helm y Argo CD funcionan sin cambios. El plano de control, el scheduler, los controladores, el DNS, el proxy de servicios y el agente de nodo son un solo proceso de Rust. Para desarrollo local, home labs y el edge.

brew install jairoFernandez/tap/litek8s
$ litek8s dev up
litek8s-dev ready in 1.28s (vm, http://127.0.0.1:6443, kubectl context litek8s-dev)
$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
litek8s-dev Ready control-plane 3s v1.33.0+litek8s
$

De dev up a nodo Ready: 1.28 s en macOS, 0.17 s en Linux. bench/RESULTS.md

Funciona con las herramientas que ya usas

  • kubectl
  • Helm
  • Argo CD
  • docker
  • docker compose
  • Dev Containers
  • Testcontainers
  • Grafana
  • Claude Code (MCP)

Junto a los clusters que ya tienes, no en su lugar

Un proceso

Un proceso hace lo que una distribución de Kubernetes reparte entre etcd, el API server, el controller manager, el scheduler, CoreDNS, kube-proxy, el kubelet y containerd, más una API compatible con Docker y una pila de métricas, logs y alertas.

Números

Medido, con los scripts del repositorio

Contra k3s, kind y k3d. Cada fila enlaza al archivo con la configuración, los datos crudos y las salvedades. Más corto es mejor.

Orquestador completo, 5 pods de nginx

PSS, v0.2.1; en reposo, sin pods: 23.2 vs 567

bench/RESULTS.md

33.5MiB

  • litek8s33.5 MiB
  • k3s minimal579 MiB

Argo CD + una app sincronizada

memoria del orquestador

bench/RESULTS.md

90MiB

  • litek8s90 MiB
  • k3s minimal900 MiB

dev up a nodo Ready, Linux

cluster de desarrollo local

bench/RESULTS.md

0.17s

  • litek8s0.17 s
  • k3d11.1 s
  • kind31.6 s

dev up a nodo Ready, macOS

cluster de desarrollo local

bench/RESULTS.md

1.28s

  • litek8s1.28 s
  • k3d10.4 s
  • kind34.3 s

Memoria en reposo del cluster de desarrollo, Linux

cluster de desarrollo local

bench/RESULTS.md

47MiB

  • litek8s47 MiB
  • k3d398 MiB
  • kind526 MiB

Métricas, logs y alertas, memoria añadida

vs kube-prometheus-stack + Loki

bench/RESULTS.md

+1.8MiB

  • litek8s+1.8 MiB
  • kube-prometheus-stack + Loki1,371 MiB

Corpus de compatibilidad

kubectl, CRDs, workloads, red, 47 charts de Helm

119/ 119

k3s: 119/119 · compat/RESULTS.md

En macOS un cluster de desarrollo corre en una pequeña VM Linux, y el Monitor de Actividad muestra la VM entera: unos 240 MiB recién iniciada, ~380 MiB después de descargar y correr 5 pods de nginx, porque macOS conserva cada página que el guest tocó hasta que la VM se detiene. Los 6 fallos de conformance: 5 son solo de macOS (DNS por TCP en el puerto 53, un binding de hostPort) y pasan en Linux; 1 era un watch, ya corregido. Un plano de control HA de 3 servidores sigue siendo linealizable ante caídas del líder y particiones, y un cluster de 3 nodos corrió 21 h bajo carga sin fugas. Memoria en macOS, bench/HA.md, bench/SOAK.md.

Qué trae el binario

Todo lo que un cluster necesita, nada que armar

  1. kind, k3d o minikube sin Docker. Tantos clusters como quieras, cada uno con tantos nodos como quieras, en un sandbox sin root en Linux o en una pequeña VM de Virtualization.framework en macOS que crece su memoria a demanda. NodePorts en localhost, tu directorio home montado en la misma ruta.

    Leer más: Clusters de desarrollo
    $ litek8s dev up --name ci --nodes 3
    $ litek8s dev load myapp:dev    # a local image
    $ litek8s dev list             # state, API port, nodes, memory
    $ litek8s dev down             # objects and images are kept
  2. docker, docker compose, docker build, Dev Containers y Testcontainers corren sobre el cluster de desarrollo, junto a (no en lugar de) Docker u OrbStack. Los proyectos de Compose pueden tener presupuestos de CPU y memoria.

    Leer más: API de Docker Engine
    $ export DOCKER_HOST=unix://$HOME/.litek8s/docker.sock
    $ docker compose up -d --build
    $ docker run --rm -it alpine sh
    # the same cluster, the same images
    $ kubectl get pods -A
  3. Si tu pipeline necesita un cluster, este es el paso de setup: Ready en ~2.5 s en lugar de los ~45 s de kind en los runners de GitHub, jobs de Helm y multi-nodo 3–5× más cortos con 26–37× menos memoria, y 1.8× más rápido que kind en Docker in Docker en jobs de contenedor estilo GitLab.

    Leer más: Kubernetes en CI
    # .github/workflows/e2e.yml
    - uses: jairoFernandez/litek8s/.github/actions/setup-litek8s@v0.2.1
    - run: helm install hello ./chart --wait && helm test hello
    # cluster Ready in ~2.5 s, job 21 s (kind: 79 s)
  4. litek8s ui: estado del cluster, una vista de Kubernetes al estilo k9s, contenedores por proyecto de compose con logs y shells, imágenes, volúmenes, limpieza de disco. Se maneja con el teclado y funciona por SSH.

    Leer más: UI de terminal
    litek8s ui: the Kubernetes view, a k9s-style list of pods
  5. Un almacén de series de tiempo embebido con una API compatible con Prometheus (Grafana funciona), búsqueda de logs en todos los pods y nodos, reglas de alerta hacia un webhook, ntfy o Telegram, y kubectl top sin metrics-server.

    Leer más: Observabilidad integrada
    $ litek8s logs -l app=web --since 1h --grep ERROR
    $ litek8s query 'topk(5, sum by (pod) (rate(container_cpu_usage_seconds_total[5m])))'
    $ litek8s alerts
    $ kubectl top pods -A --containers
  6. litek8s apiserver en una máquina; las demás se unen con un token al estilo k3s que fija la CA. Los pods hablan entre nodos por una malla WireGuard que litek8s arma solo, y corren directamente sobre crun: sin containerd, sin contenedores pause.

    Leer más: Servidores y nodos reales
    # the server; prints the join command
    $ curl -fsSL https://raw.githubusercontent.com/jairoFernandez/litek8s/main/install.sh | sh -s -- server
    # every other machine
    $ curl -fsSL …/install.sh | sh -s -- agent --join https://192.168.1.10:6443 --token K10<hash>::<secret>
  7. 3 o 5 API servers comparten el almacén con Raft, sin etcd. Cualquier servidor puede caer sin perder escrituras; litek8s lb le da a kubectl una sola dirección delante de los tres.

    Leer más: Plano de control HA
    $ install.sh | sh -s -- server --cluster-init
    $ install.sh | sh -s -- server --server https://<first>:6443 --token <token>
    $ litek8s lb --listen 127.0.0.1:6443 --server http://192.168.1.10:6443
  8. litek8s mcp es un servidor MCP (clusters de desarrollo, objetos, diagnóstico de pods, logs, PromQL, alertas) con protecciones: las herramientas destructivas piden confirmación, hay modo de solo lectura y límites de salida. litek8s skill instala un skill para agentes.

    Leer más: Para agentes LLM
    $ claude mcp add litek8s -- litek8s mcp
    $ claude mcp add litek8s-ro -- litek8s mcp --read-only
    $ litek8s skill --install ~/.claude/skills
  9. Validación de esquemas OpenAPI, reglas CEL con chequeo de tipos y costo estimado al crear la CRD, ratcheting, y server-side apply con managedFields, conflictos y pruning, como un API server de Kubernetes 1.33.

    Leer más: CRDs bien hechas
    x-kubernetes-validations:
      - rule: "self.replicas <= self.maxReplicas"
        message: "replicas must not exceed maxReplicas"
    # a typo is rejected when the CRD is created:
    ERROR: <input>:1:5: undefined field 'replica'
Cómo funciona

Un proceso, de la laptop al rack

How litek8s works kubectl, Helm, Argo CD, litek8s ui and MCP agents talk to the Kubernetes API server on port 6443; docker, compose, Dev Containers and Testcontainers talk to the Docker Engine API on docker.sock. Both live in one litek8s process with the object store (a WAL, or Raft in HA), the controllers and scheduler, DNS and the service proxy, metrics, logs and alerts, and the node agent. The node agent and the Docker API run containers on crun, with no containerd and no pause containers. kubectl · Helm · Argo CD litek8s ui · MCP agents docker · compose Dev Containers · Testcontainers :6443 docker.sock litek8s · one process Kubernetes API server CRDs + CEL · server-side apply · watch Docker Engine API containers · networks · images · build object store WAL, or Raft in HA controllers + scheduler DNS + service proxy metrics · logs alerts node agent pods · logs · exec pods crun: containers no containerd, no pause containers one Rust process idles at 23 MiB

kubectl, Helm y Argo CD llegan al API server de Kubernetes en :6443; docker y compose llegan a la API de Docker Engine en docker.sock. Ambos viven en un proceso con el almacén de objetos, los controladores y el scheduler, el DNS y el proxy de servicios, las métricas, logs y alertas, y el agente de nodo, y ambos corren contenedores sobre crun.

Leer la documentación
Instalar

Dos comandos hasta un cluster

macOS (Apple silicon) y Linux (x86_64, aarch64). macOS no necesita nada más: ni Docker Desktop, ni Lima, ni sudo.

brew install jairoFernandez/tap/litek8s
  • El script descarga el último release para tu sistema y arquitectura, verifica su SHA-256 e instala litek8s en ~/.local/bin.
  • En Linux, los clusters de desarrollo corren sin root y necesitan crun, uidmap, passt (o slirp4netns), iproute2 e iptables: litek8s dev setup revisa todo y dice qué falta.
  • Desde el código con cargo: Rust ≥ 1.90; macOS además necesita el guest de la VM.
$ litek8s dev up
$ kubectl create deployment web --image=nginx
$ kubectl expose deployment web --type=NodePort --port 80
$ curl localhost:$(kubectl get svc web -o jsonpath='{.spec.ports[0].nodePort}')
$ litek8s ui  # explóralo todo
$ export DOCKER_HOST=unix://$HOME/.litek8s/docker.sock
$ docker run --rm hello-world  # el mismo cluster habla la API de Docker
$ litek8s dev up --name ci --nodes 3  # otro cluster, tres nodos
$ litek8s dev down  # detener; los objetos y las imágenes se conservan

En servidores Linux. Un comando por máquina, como el instalador de k3s: una unidad de systemd, el token en /etc/litek8s, pods que siguen corriendo entre reinicios y actualizaciones.

Multi-nodo y HA
Plataformas

Dónde corre

clusters de desarrolloservidor / nodobinario del release
macOS, Apple silicon (13+)sí, en una VM (Virtualization.framework)solo para desarrollo (runtime Docker)darwin-arm64, guest de la VM incluido
Linux x86_64 / aarch64, sin rootsí, sandbox de user namespaces (kernel ≥ 5.11, cgroup v2)–linux-x86_64, linux-aarch64 (estáticos)
Linux, root con crunsísí: la configuración prevista para servidores y nodoslos mismos
macOS Intel, Windowsno (WSL2 sin probar)no–

Probado en Ubuntu 24.04 (arm64 y x86_64) y macOS reciente en Apple silicon. Ubuntu ≥ 23.10 necesita sudo litek8s dev setup una vez.

Limitaciones

La lista honesta

Vista previa temprana, hecha y probada por una persona: espera asperezas.

La autenticación y RBAC son más simples que en upstream.

Los servidores autentican clientes y aplican RBAC desde la 0.2.12, pero no hay login OIDC ni webhook ni revocación de certificados. Los clusters de desarrollo siguen abiertos en 127.0.0.1; en un servidor, igual mantén el puerto 6443 (y el de Raft, 6444) fuera de redes no confiables.

Tiene semanas.

Las APIs, flags y formatos en disco pueden cambiar entre versiones 0.x sin migración.

No todo el comportamiento del kubelet.

Sin eventos Unhealthy/BackOff; un emptyDir en memoria es un tmpfs por montaje de contenedor; ValidatingAdmissionPolicy y los matchConditions de webhooks se aceptan pero no se aplican.

Las métricas llegan hasta la plataforma.

Cubren contenedores, nodos y estado del cluster; los endpoints /metrics de las aplicaciones no se scrapean.

La VM de macOS conserva la memoria que tocó.

Un límite de Virtualization.framework; litek8s mantiene pequeño el guest a cambio.

Los servidores macOS son para desarrollo.

Usan Docker para los pods; corre servidores y nodos reales en Linux.

Más en la referencia de diferencias

Arranca un clusteren un segundo.

Libre y de código abierto, Apache-2.0. Comentarios e issues son muy bienvenidos.

brew install jairoFernandez/tap/litek8s