Fly Kubernetes
La nueva función “Fly Kubernetes” de Fly.io expone una API compatible con Kubernetes sobre su plataforma existente Machines, usando k3s y Virtual Kubelet para mapear pods directamente a las VMs de Fly. Los comentaristas sopesan los beneficios de este enfoque —configs declarativas, compatibilidad con herramientas y autoscaling pod-por-VM— frente a sus limitaciones y comportamiento no estándar, como el soporte incompleto para pods con múltiples contenedores y volúmenes persistentes. Algunos ven el cambio como un adaptador pragmático para organizaciones ya invertidas en Kubernetes, y otros como un paso arriesgado alejándose de la simplicidad original de Fly y un recordatorio de que la estabilidad de la plataforma y la documentación aún necesitan trabajo.
Qué es Fly Kubernetes (FKS)
- Se presenta como una interfaz opcional compatible con Kubernetes encima de Fly Machines, no como un traslado de la propia infraestructura de Fly a Kubernetes.
- Implementado como k3s + Virtual Kubelet ejecutándose en una sola Fly Machine; los Pods se asignan 1:1 a Machines.
- Objetivo: permitir que los equipos reutilicen herramientas de Kubernetes y YAML declarativo en Fly, mientras delegan la programación y la infraestructura en la plataforma de Fly.
Posicionamiento frente a otras ofertas en la nube
- Algunos lo ven como algo similar en espíritu a GKE Autopilot o EKS Fargate: facturación a nivel de pod sin gestión de nodos.
- Otros sostienen que es principalmente un “Kubernetes API shim” para la plataforma de Fly, no una distribución completa de Kubernetes.
- Varios comentaristas sugieren que la documentación y el marketing deberían explicar con más claridad qué es y qué no es FKS, y qué funciones de Kubernetes están soportadas.
Diseño técnico y limitaciones
- El plano de control es un k3s de un solo nodo con SQLite; no parece tener alta disponibilidad. Si esa Machine falla, el acceso a la API puede interrumpirse.
- Varios comentarios cuestionan el soporte para Pods con múltiples contenedores y sidecars; las Fly Machines actuales son de una sola imagen por Machine, así que la paridad completa no está clara y se reconoce como un trabajo en curso.
- La semántica de affinity/anti-affinity cambia cuando el “nodo” es un virtual-kubelet con un pod por VM; algunos patrones de resiliencia pueden no trasladarse directamente.
- El almacenamiento persistente sigue ligado a hosts físicos mediante Fly Volumes; Fly puede migrar volúmenes, pero una falla de hardware aún puede causar pérdida de datos, por lo que se recomiendan replicación de bases de datos a un nivel superior o bases de datos externas.
Ecosistema de Kubernetes frente a plataformas personalizadas
- Una postura: usar Kubernetes aprovecha un ecosistema de estándares, herramientas y talento, y evita reinventar la orquestación.
- La contraparte: Kubernetes es complejo, a veces excesivo; el scheduler y la red personalizados de Fly pueden ser más simples para su problema. FKS es solo un adaptador para quienes insisten en K8s.
Reacciones y preocupaciones de los usuarios
- Algunos están entusiasmados por obtener configs declarativas y flujos de trabajo basados en kubectl en Fly.
- Otros temen que esto diluya la simplicidad de PaaS de Fly o que sea un “footgun” que abrace la complejidad de Kubernetes.
- Surgen preocupaciones de fiabilidad sobre ciertas regiones de Fly y sobre la estabilidad general y la consistencia de la documentación de Fly.
- Varios piden garantías más claras sobre uptime, duración de los pods, comportamiento del almacenamiento y comportamiento entre regiones; muchos detalles siguen sin estar claros.