kvz es una distribución de Kubernetes de código abierto que ejecuta todo el plano de control como un único proceso de macOS, sin una máquina virtual Linux por debajo, y arranca cada pod Linux en su propia microVM. El proyecto está publicado en GitHub por la organización kvz-platform bajo licencia Apache 2.0, está escrito en Go y exige un Mac con Apple Silicon y macOS 26 o posterior. Su historial público arranca el 02/11/2026.
Las claves de kvz, el Kubernetes nativo para Mac, en 30 segundos
- Es un binario único, al estilo de k3s, que integra Kubernetes 1.37, etcd, el planificador y los controladores en un solo proceso.
- Cada pod puede ser una microVM Linux, una máquina virtual macOS completa o un proceso nativo del Mac.
- Según sus autores supera los 454 tests de conformidad de Sonobuoy, aunque piden no usarlo aún en producción.
- Sus propias pruebas lo sitúan por delante de k3s en Lima en arranque y consumo, y por detrás en ancho de banda entre pods.
El repositorio tiene un único autor humano en el historial, que firma como Subham K., además de las actualizaciones automáticas de dependencias de Dependabot. A 07/11/2026 sumaba 122 commits en la rama principal, 9 estrellas y ninguna bifurcación, así que se trata de un proyecto muy reciente. El módulo de Go todavía declara la ruta github.com/GrowlyX/kvz, distinta de la del repositorio actual. Hay dos etiquetas de versión (v1.35.10-1 y v1.37.2-2), cuyo nombre sigue la versión de Kubernetes que lleva dentro, y una web propia en kvz.systems.
Un plano de control en un proceso y cuatro formas de ejecutar pods
La documentación de arquitectura explica que kvz importa k8s.io/kubernetes v1.37.2 como biblioteca, sin bifurcar el código, y ejecuta kube-apiserver, controller-manager y el planificador dentro de un proceso de macOS. etcd 3.7 va embebido. Para el nodo usa una copia adaptada de virtual-kubelet, el proyecto que permite presentar a Kubernetes como nodo algo que no es un kubelet tradicional.
Hay una decisión de diseño que un administrador debería conocer. En macOS etcd sincroniza cada escritura con F_FULLFSYNC, que vacía la caché del SSD y cuesta unos 4 ms por operación. kvz cambia por defecto a F_BARRIERFSYNC, una barrera que mantiene el orden de escritura y la consistencia ante caídas, pero que según la propia documentación puede perder los commits más recientes en un corte de corriente repentino. Quien quiera durabilidad estricta puede volver al comportamiento original con --etcd-sync=full.
El tipo de pod se elige con runtimeClassName, y kvz crea las RuntimeClass al arrancar:
- linux (por defecto): cada pod arranca en frío su propia microVM a través de Virtualization.framework, el marco de virtualización de Apple. Usa un kernel Linux 6.18 LTS recortado a 8,5 MB y un init propio escrito en Go como PID 1. La imagen se comparte en solo lectura por virtiofs, con una capa escribible en memoria.
- macos: una máquina virtual macOS completa. El disco se clona con
clonefilede APFS, el pod queda listo cuando el invitado responde por SSH ykubectl execfunciona sobre esa conexión. Acepta paquetes de VM con el formato de tart o imágenes OCI. - darwin: procesos nativos del Mac, pensados para compilaciones con Xcode, firma de código o trabajo con la GPU.
- apple: el primer runtime del proyecto, basado en la herramienta
containerde Apple, que se mantiene sobre todo como referencia para comparar.
La red de pods la monta un switch L2 dentro del propio proceso, construido sobre la pila de red de gVisor. Los autores explican que descartaron el NAT de Virtualization.framework porque cada VM conectada así crea una interfaz vmenet en el kernel, y las máquinas detenidas a la fuerza las dejaban huérfanas hasta que el Mac se negaba a crear más (unas 251 en su Mac Studio). Los límites también están documentados: Virtualization.framework admite unas 127 VMs por Mac, así que kvz ejecuta hasta 120 pods Linux por nodo y pone el resto en cola con el motivo WaitingForVMSlot. macOS solo permite dos invitados macOS por equipo.
La instalación que propone el README pasa por Homebrew. Después basta con arrancar el servidor y, desde otra terminal, apuntar kubectl al kubeconfig que genera:
brew install kvz-platform/tap/kvz
kvz server # starts the cluster and prints how to connect
export KUBECONFIG=~/.kvz/kubeconfig.yaml
kubectl run web --image=nginx:alpine
kubectl get podsLenguaje del código: PHP (php)La guía de inicio añade cómo sumar más Macs al clúster con el comando de unión que imprime el servidor, y cómo dejarlo como servicio de launchd:
kvz agent --server https://192.168.1.20:6443 --token K10…::…
kvz install server # or: kvz install agent --server … --token …Lenguaje del código: PHP (php)La documentación tiene alguna incoherencia. La sección de límites de ARCHITECTURE.md da como pendientes los Services con kube-proxy, el DNS del clúster y el enrutado de pods entre nodos, mientras que la página de funcionalidades de Kubernetes describe Services ClusterIP, NodePort y LoadBalancer, un DNS interno en 10.43.0.10 y una red superpuesta autenticada entre Macs. Lo más probable es que uno de los dos textos se haya quedado atrás, pero el repositorio no lo aclara. También conviene saber que las primeras versiones van firmadas ad hoc y no notarizadas, por lo que un binario descargado con el navegador necesita quitarle el atributo de cuarentena antes de ejecutarse.
Las cifras que publican sus autores
El README asegura que kvz es más rápido en todas las métricas de ciclo de vida que midieron y más lento en ancho de banda entre pods. Las pruebas, fechadas el 02/11/2026, las firman los propios desarrolladores y no hay, por ahora, mediciones independientes. Se hicieron en tres Mac mini con M4 (10 núcleos, 16 GB, macOS 26.6.2) y un Mac Studio con M5 Max (18 núcleos, 36 GB, macOS 27.0.1). El documento reconoce que el Studio tenía unos 26 contenedores de OrbStack funcionando a la vez y que los mini ejecutaban tareas de otros proyectos en segundo plano. Todas las plataformas se midieron con el mismo binario cliente (kvzbench), con las imágenes descargadas de antemano y, según los autores, sin grupos de VMs precalentadas ni instantáneas. Los valores son medianas.
| Métrica (mediana de los Mac mini M4) | kvz | k3s en Lima | Apple container cluster |
|---|---|---|---|
| Arranque desde cero hasta API lista | 3,9 s | 17,8 s | 58,6 s |
| CPU en reposo (% de un núcleo) | 1,6 % | 20,1 % | 26,1 % |
| Memoria en reposo | 257 MB | 3.192 MB | 2.453 MB |
| Un pod nginx hasta Ready | 99 ms | 421 ms | 859 ms |
| 50 pods nginx hasta Ready | 1,51 s | 4,48 s | 4,20 s |
| Creaciones por segundo en la API (2.000 ConfigMaps, 32 clientes) | 9.614 | 3.200 | 7.974 |
| Ancho de banda pod a pod, un flujo (un mini M4) | 52,5 Gbps | 83,9 Gbps | 86,4 Gbps |
Hay matices que la tabla no recoge. La ventaja en la latencia entre crear un objeto y recibir el evento de watch depende en parte del modo de sincronización de etcd: con --etcd-sync=full esa cifra pasa de unos 0,4 ms a unos 4 ms, según el mismo documento. Los autores alegan que el fsync de un invitado Linux en Virtualization.framework tampoco llega a vaciar la caché del disco, pero es una comparación que conviene tener presente. En red, kvz pierde porque cada pod es una VM y el tráfico cruza el switch en espacio de usuario; la latencia de ping medida fue de 0,39 ms frente a 0,10 ms de k3s en Lima.
El documento también incluye una prueba de fiabilidad de 20 rondas de 50 pods en el Mac Studio, 1.000 ciclos de vida de VM, sin fallos ni VMs huérfanas. La memoria residente de kvz creció de 301 a 736 MB durante esa prueba, algo que atribuyen al heap de Go y a las cachés de watch del API server. En un clúster con el Studio como servidor y los tres mini como agentes, 200 pods Linux quedaron listos en 1,68 s.
Dónde encaja frente a k3s, Lima y las herramientas de Apple
La forma más habitual de tener Kubernetes en un Mac sigue siendo meter una VM Linux y ejecutar dentro una distribución ligera. k3s y Lima son proyectos de la CNCF (Cloud Native Computing Foundation) con licencia Apache 2.0, años de uso y una comunidad amplia, y en este medio ya se ha contado cómo Lima acerca Linux al Mac con máquinas virtuales ligeras o cómo hetzner-k3s despliega clústeres en Hetzner Cloud. En ese esquema todos los pods comparten un kernel, lo que explica su mejor ancho de banda interno.
Apple, por su parte, publicó su propia herramienta container, también con licencia Apache 2.0, que ejecuta cada contenedor en una VM ligera. Es la base del runtime apple de kvz y una de las referencias de sus pruebas, y ya se analizó aquí como la alternativa nativa a Docker para Mac. Los autores de kvz sostienen que el demonio de Apple arranca las VMs de una en una, a unas dos por segundo, y que por eso escribieron su propio monitor de microVMs.
En el terreno de las cargas macOS existe un precedente conocido: Agoda presentó a principios de 2025 macOS-vz-Kubelet, que permite a un clúster de Kubernetes gestionar máquinas virtuales macOS mediante Virtualization.framework, pensado para su integración continua. La diferencia de kvz es que no se conecta a un clúster existente, sino que trae el plano de control completo dentro del Mac y mezcla en él pods Linux, macOS y nativos.
Eso lo hace interesante para granjas de Mac mini dedicadas a CI de iOS y macOS, laboratorios o entornos de desarrollo, y la documentación incluye una guía específica para convertir varias máquinas en un clúster. Pero el propio README es claro: el proyecto es joven y, aunque ejecuta Deployments, StatefulSets, Jobs, Ingress o planos de control en alta disponibilidad, los autores advierten de que nadie lo ha usado todavía en producción y piden no hacerlo. Tampoco admite espacios de nombres de usuario, AppArmor ni perfiles seccomp, porque confía el aislamiento entre pods a la frontera de la VM.
Preguntas frecuentes
¿Qué es kvz?
Es una distribución de Kubernetes de código abierto para Mac con Apple Silicon que ejecuta el plano de control como un proceso nativo de macOS. Los pods pueden ser microVMs Linux, máquinas virtuales macOS o procesos nativos del Mac.
¿Qué requisitos tiene kvz?
Un Mac con Apple Silicon (M1 o posterior) y macOS 26 o posterior. kubectl es opcional porque kvz incluye uno propio, y tart solo hace falta para pods macOS a partir de imágenes OCI.
¿Se puede usar kvz en producción?
Sus autores piden expresamente que no se use todavía en producción. Supera el conjunto de pruebas de conformidad de Kubernetes según el README, pero nadie lo ha probado aún en un entorno real de ese tipo.
¿Cuántos pods admite un Mac con kvz?
Unos 120 pods Linux por Mac, por el límite de unas 127 VMs de Virtualization.framework, y dos pods macOS. Los pods nativos no consumen VMs, y para ir más allá hay que añadir más Macs al clúster.
Fuentes:
